6社合同SRE勉強会 登壇してみた
2022年3月12日に開催された6社合同SRE勉強会で登壇しました。
【Online】6社合同 SRE勉強会 - connpass
登録者が1300人を超え、liveでの視聴もおおよそ200名を超えていたようです。運営・登壇した皆様、また視聴いただいた皆様、ありがとうございました。
この記事では登壇者視点で、ずらずらと感想という名のポエムも記します。また、私のセッションに関していただいた質問などにもここで回答していきます。
Ask the Speakerについて
今回のイベントの一番の特徴が、登壇者が別のセッションのAsk the Speakerのモデレーターを務めるというものだったと思います。
私のセッションではリクルートの近藤さんが担当してくださいました。(ありがとうございます！)
この仕組は登壇者視点で非常に良かったです。すべてのイベントでやらせて欲しいぐらい好き。
その理由をつらつら書いていきます。
希望制で自分からAtSの担当を選べた
今回、事前準備として、各登壇者自身がどのセッションでAtSのモデレーターをやりたいか？という希望ベースで交通整理を運営の方にやっていただきました。
これはもう役得としか言えない体験で、気になるセッションを聞いた直後、自分が好き放題15分間質問できるんです。
もちろんSlidoで視聴者の方の質問もピックアップするわけですが、それでもモデレーターの思いつきでさらに深堀り質問できたりと
昔オフラインの懇親会でやっていて、オンラインになってから物足りなかったのはこれだったんだ！！という発見でした。
「質問が来ないんじゃないか」という不安から解放
質問時間のあるイベントの場合、質問が来ないこともままありますよね。
そのときはオーガナイザーの方などが代表して質問してくださったり、様々な配慮をしてくださることが多いと思います。
でも今回はもうAtSのモデレーターの方が自身から希望して質問してくれるわけですよね。本当に頼もしい限りでした。
スライドの準備が数日早くなった
これは完全にSide effectだと思うのですが、AtSの方に事前にスライドを共有しよう！というムーブメントが自然と発生しました。
(たぶん最初はMerpayの佐藤さんから生まれたムーブメントだったと思います)
これによって、普段は当日になって作られるような(!)スライドが、数日前には一通り完成したものが飛び交い
事前に登壇者同士でペアレビューのような形で、気になった部分をコメントしていました。
実際にコメントした部分は発表当日には補足説明が追加されていたりと、クオリティの面でも良い方向に寄与したと思います。
私のセッションについての補足
ここからは私のセッションについての補足説明をつらつら書いていきます。主にliveやtwitterで質問されたことを補足していく。
余談ですが、このイベントの話が来たときはまだ12月で、あけおめLINEを障害なく捌けるか不明瞭な状態でした。
そのため、もし過負荷が発生したら「公開ポストモーテムにしますね！」と伝えていました。需要があるかは不明...
約9倍のスパイクに備える取り組み(LINEスタンプのあけおめLINE)
GatewayでのThrottlingについて詳しく聞きたい
Throttlingと呼んだとき、私は主に2つの機能を指すことが多いです。
- Ratio limitting
- 50%エラーにするなどの割合で制限する
- RPS limitting
- 2000 rpsまでに制限する
RPS limittingは基本的に常に設定されており、「あけおめLINE」などのタイミングで負荷試験をやったついでに設定値見直しをすることが多いです。
具体的な実装としては、Leaky bucket algorithmを使うことがほとんどだと思います。
Ratio limittingは障害時の緊急対応として使われる機能ですね。今回のセッションでは過負荷が発生した際の初動対応として使うため、Ratio limittingを前提としていました。
「あけおめ」以外にも似たようなイベントで負荷対策はやっているんですか？
繰り返し行われるキャンペーンでは似たような確認をやっています。
そのため、イベントごとのメトリクスや考察のまとめられたwikiページが社内wikiのSREスペースにありますね。
Elasticsearchの負荷対策でDual cluster以外の候補はありましたか？
はい、いくつか候補がありました。例えばRedisのキャッシュを追加する等は、同時に実施しています。
Elasticsearchのパフォーマンス・チューニングについてはやりませんでした。
理由として「あけおめLINEの準備」という締切がある状態で、効果の不確かな改善に割けるリソースがなかったためです。
そのため、基本的にはスケールアウトさせる方向で検討して、1つのクラスタを大きくするか？dual clusterにするか？を検討しました。
その上で下記の利点から、Dual clusterのアーキテクチャを採用しました。
- コストの面から、「あけおめLINE」が終わったらScale-inしたい
- 今後ESのバージョンアップにもロジックが流用できる
負荷試験を実施したマイクロサービスの選出基準は？
スタンプ関連で定義しているクリティカルユーザージャーニー(CUJ)をベースに、CUJの処理に必須のサービスを選んで負荷試験を実施しました。
このグラフじゃノードごとの偏りがわからないような？
完全に説明不足です、すいません。このグラフ、requests/secがnodeごとに表示されています。(重なりすぎて一本のグラフに見える...)
Priority load sheddingのワークショップはどのくらいの規模でやりました？
サーバー・クライアント・QA・企画で希望者全員でやったので、最終的に参加者は30名から40名オーバーだったと思います。
このワークショップはリーズナブルだし、本当におすすめですね。
分散トレーシングは活用していますか？
はい、今回の「あけおめLINE」でも活用しています。
LINEの場合、zipkinが社内の監視プラットフォームチームから提供されているので、embedded SREの私はそれを使わせてもらっている立場ではあるのですが、
特に、GatewayレイヤーでのPriority load sheddingの効果を事前確認するために使いました。
Priority load sheddingで、どのAPIをThrottlingできるのか？は決まるのですが、ではそのAPIをThrottlingした結果、どのサービス・DBの負荷が下がるのか？までは分散トレーシングなしではとても追いきれません。
許容限界を超えた負荷が来た場合の対応はThrottling以外に、例えば緊急増設などありましたか？
はい、非常に良い質問&耳に痛い質問ありがとうございます！
基本的にthrottlingが第一施策で、その後VM増設もすぐに行うのですが10分以上(30分程度)かかってしまう現状です。
そのため増設をするとしても、日本のあけおめLINEではなく台湾やタイのあけおめLINE向けの対策になってしまっています。
これは今少しずつk8sに移行していっており、改善できる兆しがある・・・程度のフェーズですね。
ピーク時に障害が発生したときの目標復旧時間など数値目標はありましたか？
スタンプのシステムの範囲内では、そこの厳密な数値目標は現状なく、今後整備していきたいなと思っています。
おおよそいただいた質問は補足しつつ、回答できる範囲で回答してみました。
また気になることや相談があれば、Meetyでカジュアル面談を申し込んでいただいても良いですし
twitterで雑にリプライを送っていただいても構いません(答えられるかは保証できませんが...)！
Meety: SREとかなんでも
@maruloop / Twitter
ここまで読んでいただいて、ありがとうございました。
Discussion