日々のこと

まいにちの暮らしをつれづれ書きます

SRE NEXTへ行ってきました（前編）

勉強会 おでかけ つれづれ

昨日、豊洲で開催されたSRE NEXTへ行ってきました。
国内初（！）のSREのカンファレンスだそうです。
とてもよかったです！

sre-next.dev

発表資料まとめ

タイムテーブル

参加したきっかけは、同じ会社の人が運営に関わっていて、「誰か参加しませんか？」と会社のSlackで呼びかけてくれていたこと。
SREの活動については前職にいたころから気になっていたので（DevOpsとか、開発と運用の分断とかでもやもやしてた）、SREのカンファレンスがあるんだ！聞いてみたい！と思って参加することにしました。

当日朝は、SRE的な活動をしていない自分が参加してもいいのかな？という気持ちで向かったのですが、聞いてよかった話がいっぱいでした。
同じ時間帯に聞きたい話がたいてい複数あるので、どのセッションを聞くか迷いました。
カンファレンス後は、SREの活動はソフトウェアエンジニアリングなので、ソフトウェアエンジニアならみんな関係のあることなんだな、と思いながら帰途につきました。

早く会場に着いた人は、会場で席に座りながらヨガをする早期来場者特典があって、体が伸びてとても気持ちよかったです。
会場のエンジニアの方がみんなヨガしている姿もなんだかよかったです。

A0 分散アプリケーションの信頼性観測技術に関する研究

坪内 佑樹 さん（さくらインターネット研究所）

さくらインターネット研究所、坪内さんによる、SREとはなんであるかと、'NEXT'の一つとして地理的に分散したアプリケーションの信頼性向上についての講演でした。

SREとはサイト信頼性を制御するための工学であること、失敗を許容する前提で運用を設計すること、人間の認知負荷を前提とした自動化など今後人間中心のアプローチになっていくという話がとても興味深かったです。

1. 研究の背景

自動化の皮肉（1983）

1983年なので、コンピュータでなく航空制御などの文脈

  • 自動化により人間の作業負担を低減できる
  • 自動化すればするほど人間の認知負荷が高まる
  • 認知負荷に耐えられるように高度な訓練が必要となる

人間と計算機を合わせた制御系の設定が必要になる

自動化の皮肉に対するアプローチ

  • 認知範囲外のことを扱うとかえって信頼性低下することがある（認知範囲外のことはこわい）
  • 失敗を許容する前提で運用を設定する
  • 信頼性低下のリスクを制御下におくことで、変更速度を最大化する
  • 信頼性という守りを制御することで、安心して変更速度を早くする攻めに転じることができる
  • SREとは「サイト信頼性を制御するための工学」

応答性能に閉めるネットワーク転送遅延の問題

  • ネットワーク遅延を考えると、クラウドだけでやっていくのは今後厳しいかもしれないという予想
  • 今はクラウドに置いているが、地理的に分散したコンピューティングが出てくる
  • 地理分散コンピューティングの課題
    • システム構成要素数が爆発的に増えてしまう！
    • システム内ネットワーク遅延の増加

2. 研究の目的

  • 大目的：地理的に分散させたアプリケーションの信頼性向上
  • 制約：既存のAPやMWのコードを変更せず、性能影響を与えない
  • 3つの目的
    • 時間軸の可観測性：時系列データベースの性能と互換性の両立
    • 空間軸の可観測性：依存関係を低負荷かつ網羅的に追跡
    • データの一貫性を保証しつつ、応答性能を最大化できるよう制御

3.互換性と性能を両立する時系列データベースの研究

時間都合で割愛

4.分散アプリケーションの依存関係追跡の研究

  • Linuxのiptables（パケットフィルタログ）を利用して、どこと通信しているか取得できる
  • Linuxカーネルの通信機構を利用するので、プロセスに対して透過的に追跡可能
  • 課題
    • 全ノードにインストールする前提なので、オーバーヘッド
    • パケットを無作為にサンプリングするため、検知漏れの可能性がある
  • ネットワークのソケットに着目してそこを監視する
    • ソケットの監視は、プロセスの通信には割り込まないので、オーバーヘッドが存在しないはず（CPUは使う）
    • 偽陰性の解決は、全てのソケットを監視することで解決
  • CMDB（接続情報管理DB）に保存
    • 分散して自律的に持つことを考えている

5.データの一貫性を保証しつつ応答性能を最大化する

  • まずやりやすい読み込み性能をあげることに着目
  • 中央にオリジン、全データセンターにキャッシュの複製を配置
  • 書き込みは全部、中央のデータセンターに置いて、一貫性を保持しつつ、書き込みをキャッシュに伝搬させる
  • キャッシュと中央の一貫性が保てない課題
    • 真ん中にProxyを置く
    • 書き込みするとき、中央とキャッシュに同期的に更新をかけてアプリケーションに反映

QuorumCacheアーキテクチャ

  • 同期更新の範囲をネットワーク遅延に応じて調節可能
  • アプリケーションの読み書き回数の比率に対して同期更新の範囲を適応的に決定可能にする
  • 外側のデータセンターは非同期にする
  • 読み出すときの一貫性が保たれないので、読み取りするとき、近いデータセンターから同期更新が保たれているデータセンターに読み出しに行く
  • Proxyに間を挟んで、観測ポイントを用意する
    • データではなく可観測性の話になる

むすび

  • SREは失敗を前提として信頼性を制御するアプローチであると解釈
  • 今後、地理分散コンピューティングが今後台頭してくる予想に対して、3つの研究を紹介
  • 最近のマイクロサービス、クラウドネイティブなどの話をしていると人間の認知負荷を前提とした自動化というのが出てくる
  • 人と組織の話
    • 人間中心のアプローチ

C1 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

渋谷 充宏 さん（メルカリ）
高木 潤一郎 さん（メルペイ）

メルペイのSREリーダー高木さんのお話で、組織やチームの段階によってもやるべきことはちがうので、最初は障害もトイルも受け入れて、できるところからやろう、という話がよかったです。

メルカリ

メルカリのエンジニアリングマネージャーの渋谷さんの、マイクロサービス移行とSREチームの変化についてのお話でした。

マイクロサービス移行の進展

  • モノリシックからマイクロサービスに移行
  • 段階的な機能切り出しを可能にしている
    • モノリシック　さくら石狩
    • マイクロサービス　GCP東京
  • 石狩-東京間の通信レイテンシを緩和するためにchoconを開発している
  • メルカリSREはマイクロサービス移行を支えている
  • 開発チームの半分近くは、マイクロサービス配下での機能開発ができているので、SREもそれを後押ししたい

SREのありかたの変化

  • 本番環境を支える「門番」としてプロダクトの信頼性に貢献してきた
  • マイクロサービスは組織としてのプラクティスである
  • 門番モデルでは、SREがボトルネックになるリスクを孕む
  • マイクロサービス開発チームのスケーラビリティを担保するようにSREチームをアップデートしたい！
  • 共通の責務を担いつつ、専門性の異なる3つのサブチームに
    • SRE core：土台（Datastore など）
    • SRE edge：マイクロサービスの入り口（CDN など）
    • SRE advocacy：個別のマイクロサービス

メルペイ

メルペイのエンジニアリングマネージャーとリーダーの高木さんのお話で、サービスの変化に伴って、SREのリーダーとして何をしてきて、SREチームがどのように変わってきたかについてのお話でした。

一人目SRE時代

  • メルカリはSREチームがあったが、別組織だったので、なにやっていいかわからなくて、キャッチアップ、メルペイのインフラのコード化、設計などしていた

SREばらばら時代

  • SREが2-3人でリリースを目指す
  • リリースしなければいけないので、やばいものからやる
  • マネージャーというよりプレイヤー
  • 個人の集まり、ついてこれないひとは辞めてしまう
  • チームとしてリリースまでは動けてなかった
  • そしてリリース！

SREチーム構築チーム

  • 2人で運用はつらい、SREチームをつくっていくぞ、サービス運用がんばってやっていくぞ
  • トイルとのたたかい
  • 採用したい

SREチーム拡大時代

  • 4→7人へ、良いチームをつくっていきたい
  • 入社したメンバーをオンコールできるように育成していく
  • トイル減らそう、自動化
  • チームとしてプロジェクトを進めていこう
  • 半分がテックリード、半分がチーム運営
  • 夏入ってくれた人も慣れて成長してきた
  • 8人チーム

今

  • 未来のためのしくみをつくろう
  • SLOのような考え方を、開発、会社全体に広めて、運用をSLOベースにしよう
  • 信頼性を高める工夫
  • メンバーにできるだけ任せて必要なところだけみよう
  • 難しい判断だけ自分、それ以外はメンバーにやってもらう
  • 会社全体の運用や生産性を見れるようになってきた

まとめ

  • リーダー、会社によって求められるものちがう
  • 組織やチームの段階によってもやるべきことはちがう
  • できることからやろう
  • 最初は障害もトイルも受け入れよう
  • 最終的に、SREチームを超えて、エンジニア組織の信頼性や生産性を高めるのが使命なのかなと思っている

B2 計画的に負荷リスクを排除するためのキャパシティプランニング

赤野 裕喜 さん（マッチングエージェント）　　

高負荷による障害発生をきっかけに、負荷リスクを減らす取り組みについてのお話。
本番環境と同じスペックの負荷テスト環境を誰でも用意できるようにしたり（安全のためにAWSアカウントは別）、施策の企画段階から負荷レビューをさしこむようにしたり、地道にしっかり負荷リスクに取り組まれていました。

タップルSREのビジョン

  • 趣味をきっかけにするマッチングアプリ「タップル誕生」
  • タップルのセキュアベース（安心感）となりタップルを成長させる
  • 安心感を作りつつ、組織に大きなチャレンジを促せる存在を目指す

キャパシティプラニングに取り組むきっかけ

  • 高負荷による障害発生
    • push通知を起因に大量のアクセスが発生
    • 復旧に時間かかった
  • 負荷的な不安を取り除けない状況
    • 経験則を元にした負荷チェックしかできない
    • 負荷レビューのためにシステムキャパシティを把握が必要

キャパシティプランニングのゴール

  • 継続的なシステムキャパシティの把握
  • 負荷レビューの手順と実施フローの整備

やったこと

継続的なシステムキャパシティの把握のために

定期的に負荷テストを実施できる環境づくり

  • 本番と別に、AWSアカウント別に負荷テスト環境を作成
  • アプリケーション環境は同じ、性能も同じ
  • 誰でもできるように、スクリプト流すだけで実施準備が終わる

負荷試験のフロー整備

負荷テストの種類は3つ

  • 限界値を把握するためのロードテスト（定期）
  • 限界値を把握するためのスパイクテスト（定期）
    • どのくらいのスパイクアクセスに耐えられるか
  • 性能劣化をチェックするテスト（エンジニア判断）
    • ロジックや設計の変更で性能が劣化するかテストする
    • テストの実施はバックエンドエンジニアに任せて、SREはテスト計画や結果のレビューを行う

負荷テスト終了条件になるレイテンシSLOの策定

  • APIがスローダウンした状況を再現できるdev環境を用意し、不快に感じるAPI遅延体感チェック会を実施して決めた
  • リーダー、PMも参加

負荷レビューの手順と実施フローの整備のために

施策単位のレビューフロー整備

  • 施策の企画段階で、負荷的に問題ないか判断
  • 施策開発フローに組み込んだ
  • 四半期ごとに施策のロードマップが決まるその後に、施策一覧をSREがレビューする
  • 明らかに負荷が厳しそうな施策がないかをチェック（この時点では具体的な情報がないので、経験則と体感的なチェック）
  • 企画後のエンジニア相談のタイミングで、担当エンジニアが負荷レビュー
    • レビューは施策の担当エンジニアが実施
    • SRE側で負荷レビュー手順書を作成
  • 施策単位の負荷レビューは全施策のレビューはしていない（コストかかりすぎ）
  • システム負荷への影響が大きい施策のみに絞る（DAU増加か、カード フリック増加）

プッシュ通知の配信設定へのレビューフロー整備

  • サービスをスローダウンさせずにPUSH通知を配信するためにSREが配信設定を負荷レビュー
  • 配信数と流入期待値から想定流入値を出す
  • 想定流入値から必要となるスループットを出す
  • スパイクテストの結果を元に配信スケジュールを決定

アクションを行ってきた結果

  • エンジニア手動で気軽に負荷試験を実施することができるようになった
  • チームの負荷的な不安を取り除くことができた
  • SREがセキュアベースとして機能

今後の展望と改善

  • 負荷試験環境のスペックを調整して使用できるように改善（本番同等の環境が不要な場合もありコストも抑えられる）
  • 負荷的な観点以外のリスク改善にも取り組んでいきたい

B3 グループウォレットアプリ、6gramの運用をはじめてみた

佐藤 良祐 さん（ミクシィ）

グループウォレットアプリの開発運用で、クレジットカード業界のセキュリティ基準を完全準拠しつつも運用負荷をできるだけ下げるためにどんなことをしたか、というお話でした。

6gramについて

  • グループウォレットアプリ、6gramの開発、運用をしている
  • 2019年11月にAndoroid版を正式リリース
  • 招待制（mixiさんは招待制が好きとのこと）
  • iOSは審査中

決済サービスの基礎的な概念

  • 出金と入金の両方とも自社でシステムを実装
  • PCI DSSに準拠しなければいけない
    • クレジットカード業界のセキュリティ基準
    • 準拠することにより、カード番号などの情報を保持することができる
    • 12要件、400項目
    • 古くさい
    • 運用の基準を定めているもの

PCI DSS完全準拠の工夫

アカウント要件

  • コンピュータにアクセスできる各ユーザに一意のIDを割り当てる
  • パスワード要件は、少なくとも90日間で変える
  • ウィルスチェック
    • 侵入検知　IDS IPSをいれる
  • ファイル改竄の変更検出メカニズムを導入してファイル変更を監視、警告する
  • ウィルス検知ソフトウェア、侵入検知ソフトウェアが落ちてもインシデントになってしまう

運用負荷をできるだけ下げたい！

インスタンスを使わない

  • AWSは、IAMにアカウント管理を集約しやすい
    • 90日に1回、パスワード変更祭りをすればよい
  • インスタンスがいないので、サーバがリブートするのをスキップすることができる

コンテナもRead Onlyで動かす（読み取り専用）

  • Fargateはリモートコンソールが存在しないためそもそも侵入できない
  • ファイル変更検知ソフトウェアが不要に
  • コンテナをFargate上で動かしている

クレジットカード

  • AWSのDynamoDBを全てに載せている
  • KMSによるテーブルの透過的暗号化
  • スケーリングや管理を全てAWにお任せできる
  • DynamoDBを起因とする障害は今のところない

DynamoDBのメリット

  • 管理もスケーリングも勝手にやってくれて高可用性もあって最高

DynamoDBのデメリット

  • 最初に作ったスキーマを変更できない
  • 集計や解析処理が大変（一旦エクスポートして頑張る）

定時実行処理

  • CodeBuildを使用
  • AWS BatchはEC2が爆誕するのでいやだ
  • Lambdaは実行時間が短すぎる
  • Fargateはリトライが大変

まとめ

  • 少人数で運用するために運用負荷を減らす努力
  • PCI DSSパズル
  • フルマネージドサービスを使うことで高い信頼性を確保

開発運用体制

  • SREの専門職ロールはなく、全員で開発運用
  • Rollbarというものを使って、対処する必要があるものに対してはSlak通知
    • 次にするべきことを書く
  • インシデント対応計画シミュレーションの実施
    • カード情報が漏洩した時など、どう対処しなければいけないかを年に1回など、机上でシミュレーションする

課題

  • 可観測性が低い
  • 細かいトレーシングができていない
    • 分散トレースがほしい
  • 自動化を突き詰めていく
  • 開発環境をより本番環境に近づけていく
    • 決済ネットワークに接続しなければいけないのでなかなか難しい
    • 決済ネットワークとの繋ぎ込みを含め開発環境を再現する環境を作りたい

それぞれの現場で地道にやっていることが、すごく参考になる、と思いました。
この続きは、後編で書きたいと思います。