LINEスタンプのSREing事例集：大きなスパイクアクセスを捌くためのSREing

2023/09/29 - SRE NEXT 2023
LINE株式会社 SRE
maru (X: @maruloop)
LINEスタンプ, 着せかえ, ホームタブ, ウォレットタブ

Transcript

1. -*/&ελϯϓͷ43&JOHࣄྫूɿ େ͖ͳεύΠΫΞΫηεΛࡹͨ͘Ίͷ43&JOH 
   
   43&
   /&95
    -*/&גࣜձࣾ
   43& NBSV
   9
   !NBSVMPPQ -*/&ελϯϓ
   ண͔ͤ͑
   ϗʔϜλϒ
   ΢ΥϨοτλϒ
2. 残り-94 ࠓ͔Β͜ͷηογϣϯͷؒɺΈͳ͞Μ͸ࢲͱಉ͡νʔϜϝϯόʔͰ͢ɻ ໿ϲ݄ޙʹഭΔʮ͚͓͋Ί-*/&ʯΛҰॹʹ৐Γӽ͑·͠ΐ͏ɻ 「あけおめLINE」までの日数(9/29から)
3. 「あけおめLINE」とは？ • 元旦の午前0時0分にLINEメッセージを送り合うこと • 特にスタンプを送る場合は「あけおめスタンプ」と呼ぶことも 3 残り-94 去年のあけおめスタンプキャンペーン
4. 「あけおめLINE」対応プロジェクトとは？ Goal • 元旦のアクセスを安全に乗り切る • ビジネスチャンスとして活かす アクセス規模 • 平日ピークの13倍の瞬間アクセス 4 残り-94
5. LINEスタンプのアーキテクチャ 基本的なアーキテクチャ • ドメインごとに分かれたマイクロサービス 「あけおめLINE」で影響するサービス • 約15マイクロサービスで負荷が増える 5 残り-94 所有権確認サービス 画像配信サービス 検索サービス サブスクリプション確認サービス スタンプ送信可否判断サービス Gatewayサービス 絵文字情報サービス スタンプ情報サービス などなど….
6. 意識すべきマイルストーン 6 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE 想定外の何かに対処するために、 遅くとも2ヶ月前に増設開始したい アプリケーションやインフラの変更によるリグレッショ ンを防ぐために、この日以降は基本的にリリース禁止
7. サーバー増設開始までに行う主なタスク 7 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE • 影響サービスの洗い出し • アクセス見積もり • 処理性能確認 予防重視
8. コードフリーズまでに行う主なタスク 8 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE • 過負荷時の初動改善 • パフォーマンスチューニング • エラーハンドリング改善 対処重視
9. コードフリーズ後に行う主なタスク 9 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE • 監視ダッシュボードの整備 • 待機人員の整理 検知重視
10. 全体スケジュール 10 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE • 影響サービスの洗い出し • アクセス見積もり • 処理性能確認 • 監視ダッシュボードの整備 • 待機人員の整理 • 過負荷時の初動改善 • パフォーマンスチューニング • エラーハンドリング改善
11. サーバー増設開始まで (約30日間) のタスク 11 残り-94 1. アクセス増加見込みのあるマイクロサービスを確認 2. 各マイクロサービスの処理性能を確認 3. 各マイクロサービスのアクセス数を見積もる 4. サーバーの増設台数を計算 5. 異常時の予想アクセス数を関連サービスに確認 前年と同じなら15サービスだが、それ以外に増えてないか確認する 各マイクロサービスで、どのくらいのピークアクセス数になるか見積もり 各マイクロサービスで、秒間 何リクエストを処理できるか確認 実際にどのくらいのサーバーを増やすべきか計算する 異常時のフォールバックアクセス数などをヒアリング 目的：サーバー増設を余裕を持って行うための準備
12. 残り-94 ΞΫηε૿ՃݟࠐΈͷ͋ΔϚΠΫϩαʔϏεΛ֬ೝ 前年と同じなら15サービスだが、それ以外に増えてないか確認する。
13. アクセス増加見込みのある新サービス/新機能の確認 目的 • 今年の新サービスや新機能やアーキテクチャ変更は見積もり漏れが怖い • それらも対応が必要か確認する 進め方 • wikiを1ページ作り、関連するサーバーサイドエンジニアに記入してもらう 13 残り-94 # 着せかえローテーション機能(新機能) ローテーション機能を設定しているユーザーが前回のアプリ起動時から一定時間 経過していると、自動で別の着せかえが適用される。 着せかえ適用時にAPIリクエストが発生するため、「あけおめLINE」時にLINEを起 動したユーザーによるアクセス増加が予想されるが、API自体は非常にキャッシ ュヒット率が高いため、DB負荷は小さい e.g.
14. 残り-91 ֤ϚΠΫϩαʔϏεͷॲཧੑೳΛ֬ೝ͢Δ 各マイクロサービスで、秒間 何リクエストを処理できるか確認 94日 à
15. 各マイクロサービスごとに処理性能を確認する Goal • 各マイクロサービスが何 req/sec捌けるか確認する • ついでに改善した方が良い課題があればメモしておく Limitation • 15マイクロサービスを約15日で計測完了したい 15 残り-91
16. カオスエンジニアリングの考え方で、QPSを確認 16 残り-91 15日間で15マイクロサービスの処理性能を確認したい マイクロサービスごとのシナリオを準備する余裕はない マイクロサービスごとの独立環境を準備する余裕はない
17. カオスエンジニアリングの考え方で、QPSを確認 17 残り-91 15日間で15マイクロサービスの処理性能を確認したい マイクロサービスごとのシナリオを準備する余裕はない マイクロサービスごとの独立環境を準備する余裕はない ユーザーがアクセスしているインスタンスを減らし、高負荷状態を再現する
18. カオスエンジニアリングの考え方で処理性能を確認する 定常状態における振る舞いの仮説 • このAPIサーバーは99%のリクエストを100ミリ秒以内に、エラーなく処理ができる • CPU使用率が70%以下では、この定常の振る舞いを維持できる 実験方法 • インスタンスを少しずつダウンさせ、特定インスタンスにアクセスを集中させる 18 残り-91
19. カオスエンジニアリングによる高負荷試験の実践 1. アプリケーションのリリースタイミングを事前にプロダクト側と調整しておく • リリースと重ならないタイミングでカオスエンジニアリングを実施するため 2. ダッシュボードを準備する 3. アクセスを少しずつ特定インスタンスに寄せていく 1. 最も簡単な方法は、実際にアプリケーションをshutdowさせる 2. もし、動的にルーティングを変更する機能を持っているなら、その機能を使う 4. CPU 70%を超えるまでのレイテンシーとエラー率を記録していく 5. 予期せぬエラーやレイテンシーが記録されたら、直ちに実験を中止する 19 残り-91
20. 残り-71 ϐʔΫΞΫηε਺Λݟੵ΋Δ ピークのアクセス数を去年のデータなどを使って見積もる 91日 à
21. ピークアクセス数を見積もる 目的 • サーバー増設のために、ピークアクセス数を見積もる 進め方 • 異なる3つの予測を行い、悲観的な予測値を採用する 1. 過去の「あけおめLINE」時のアクセス数の変化率の幾何平均 2. 平常時アクセス数の前年比 3. 前年の実際の「あけおめLINE」時のアクセス数 21 残り-71
22. 過去の「あけおめLINE」時のアクセス数の変化率の幾何平均 1つ目の見積もり方法は、アクセス数の変化率の幾何平均(相乗平均)を用いる方法。 例えばあるサービスで、下記のようなアクセス数の場合、変化率の幾何平均は1.1になる。 アクセス数の変化率の幾何平均から、2024年のアクセス数を求める場合： 前年のアクセス数に平均変化率をかけて…. 22 残り-71 2021年1月1日 00:00 10,000 req/sec 2022年1月1日 00:00 10,550 req/sec 2023年1月1日 00:00 12,100 req/sec 2024年1月1日 00:00 XX,XXX req/sec
23. 平常時のアクセス数の前年比 2つ目の見積もり方法は、平常時(例えば平日ピーク)の前年比を用いて見積もる方法。 今回のケースでは、平常時のアクセス数の前年比が1.1倍なので、 前年のアクセス数にその比率をかけて… 23 残り-71 2022年10月11日 19:00 1,000 req/sec 2023年10月11日 19:00 1,100 req/sec 2023年01月01日 00:00 12,100 req/sec 2024年01月01日 00:00 XX,XXX req/sec 平日ピーク あけおめLINE X1.1
24. 前年の実際の「あけおめLINE」時のアクセス数 3つ目の見積もり方法はシンプルに前年のアクセス数を見積もりとして扱う。 複数の見積もり結果の中で悲観的な値を採用するロジックを採用しているため、 最低でも前年と同じアクセス数を見積もるという意味で本見積もり方法も利用。 今回のケースでは、2024年01月01日は、12,100 req/secのアクセスが来ると見積る。 24 残り-71 2023年01月01日 00:00 12,100 req/sec 2024年01月01日 00:00 XX,XXX req/sec
25. 3種類の見積もり結果から、悲観的な値を採用する この中で最も悲観的な 13,310 req/secを見積もりとして採用。 例外的な処理 • 今年リリースされた新機能のため、前年のデータが一切ない • 近いマイクロサービスのデータを参照する、他のキャンペーン時のアクセス数を参考にする • データに異常値があり、見積もり結果も異常になってしまった • データが異常な理由を確認した上で、見積もり結果から取り除く 25 残り-71 「あけおめLINE」時のアクセス数の変化率の幾何平均 13,310 req/sec 平常時アクセス数の前年比 13,310 req/sec 前年の実アクセス数 12,100 req/sec
26. 補足：アクセス数の変化率の幾何平均について MAUは変わってないのに、アクセス数が増えてたら？ 考えられる可能性 • なんらかによって、ユーザーの行動が大きく変容した • UIが変わって、アクセスしやすい所に機能が配置された • クライアントのロジックが変わって、呼び出し頻度が増えた 26 残り-71 変化率の幾何平均は、アクセス数以外の指標と直接比較することが可能。 例えば、最も単純なWebサービスのモデルとして、MAUとアクセス数が比例する場合。 理由が何であれ、前年と比較して予期せぬアクセス負荷がくるかもしれない、要注意サービス
27. 残り-69 αʔόʔͷ૿ઃ୆਺Λܭࢉ 予測ピークアクセス数と処理性能(req/sec)から、必要台数を計算 71日 à
28. サーバーの増設台数の計算 Goal アクセス数の見積もり結果と処理性能から、サーバー増設台数を計算する Steps 1. 各サービスにおいて、不確実性の大きさを確認する • 3種類の見積もり結果の標準偏差がどのくらいあるか • MAUの変化率の幾何平均からどれだけ離れているか • 最近大きな変更をした機能か • 最近ローンチしたばかりの機能か 2. 不確実性が大きいサービスについては、安全マージンを大きく取る 28 残り-69 必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン
29. 安全マージンの例 29 残り-69 必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン サービスの説明 安全マージン倍率 安全マージンの根拠 LINEスタンプ送信時の所有権検証 1.3倍 ユーザー数や機能が安定しており、3 種類の見積もり結果もほぼ同じ予測値 複数のマイクロサービスのレスポンスを集約 2倍 今年サーバースペックを大きく変更し たため、大きめのマージン HTTP to RPCへ変換, 認証など 2倍 大規模なアーキテクチャ変更によって 、アクセス数需要の予測精度に不安
30. 残り-65 ؔ࿈αʔϏεʹɺϑΥʔϧόοΫ࣌ͷڍಈ΍ΞΫηεݟੵ΋ΓΛ֬ೝ 他サービスからのフォールバックによって、予期せぬアクセスが増えることがある その際に障害にならないように確認 69日 à
31. 関連サービスからフォールバックアクセスを確認する Background 関連サービスによっては、あるサービスAが障害のときだけ、フォールバックとしてサービスBにア クセスするように設計していることがある。 フォールバックアクセスは普段のメトリクスには表れないので、地道に確認する。 Goal フォールバックによって、カスケード障害にならないようにする Steps • 関連サービスにフォールバック時のアクセス見積もりを聞いておく 31 残り-65
32. 意識すべきマイルストーン 32 残り-61 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE 予防策として、サーバー増設のための準備は完了。 ここからは、障害発生を前提とした対策を主に行う。
33. コードフリーズまで(45日間)の主なタスク 33 残り-61 1. Prioritized Load Shedding準備のためのワークショップ開催 2. ワークショップ中に発見したエラーハンドリング改善 3. 処理性能の確認時に発見されたボトルネックの改善 過負荷になった際に、どのAPIからFailさせるか優先度を確認する 残る時間で可能な限りのパフォーマンス改善 Failになった場合でも、最低限のUXを担保する 目的：サーバーの増設、障害発生を前提とした対策、可能な範囲でのチューニング
34. 残り-59 1SJPSJUJ[FE
    -PBE
    4IFEEJOH४උͷͨΊͷϫʔΫγϣοϓ։࠵ 過負荷になった際に、どのAPIからFailさせるか優先度を確認する 65日 à
35. Prioritized Load Shedding準備のためのワークショップ開催 Goal 高負荷に陥った際、ユーザー影響の小さい機能を停止して、重要な機能だけでも死守したい。 どのAPIをLoad Sheddingしても良いか、事前に決定しておく。 Steps 1. 企画・クライアント・サーバー・QAなどのメンバーが全員集まる1時間の会議予定を取る 2. アクセス数が多いAPI順に、開発環境でエラーを返すようにしていく • 開発環境で動作確認をして、ユーザーインパクトごとにAPIをLow, Middle, Highでランク付けをする 3. LowのAPIは、担当者の独自判断でLoad Sheddingして良いという取り決め 35 残り-59
36. 残り-51 ϫʔΫγϣοϓதʹൃݟ͞ΕͨΤϥʔϋϯυϦϯάͷվળ Failになった場合でも、最低限のUXを担保する 59日 à
37. ワークショップ中に発見されたエラーハンドリングの改善 Goal ワークショップでエラーを返して動作確認をする中で、エラーハンドリングで改善できる部分があ れば改善する Steps 1. クライアント側でタスクを進行する • このタスクの優先順位も含めて、クライアント側に一任 • 今年の「あけおめLINE」に間に合わなくても問題ないぐらいの優先度タスク 37 残り-51
38. 残り-51 ॲཧੑೳͷ֬ೝ࣌ʹൃݟ͞ΕͨϘτϧωοΫͷվળ 残る時間で可能な限りのパフォーマンス改善 59日 à
39. 処理性能の確認時に発見されたボトルネックの改善 時間の許すかぎり、 あらゆる手段を用いてチューニングをする 39 残り-51 Goal カオスエンジニアリングによる性能確認時に発見されたボトルネックの解消
40. 改善したボトルネックの例 1. JsonWebTokenのverificationでCPU使用率が非常に高かったので、セッションストア方式に変更 2. CPUより先に、Heapメモリが枯渇しGC頻度が上がっていたので、サーバースペック変更 3. マイクロサービス間でN+1のようなAPIアクセスがあったため、APIを開発して修正 40 残り-51
41. 意識すべきマイルストーン 41 残り-16 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE 障害を前提とした対策も完了。 障害検知のための整備を中心に行う。
42. 「あけおめLINE」当日までの主なタスク 42 残り-16 1. 監視用ダッシュボードの整備 2. 当日の待機(監視)人員の配置調整 3. マーケティングチームに当日push通知の予定時刻を確認 Golden Signalsメトリクスをサービスごとに確認できるダッシュボードの準備 当日予期せぬアクセスで慌てなくて済むように・・・。 誰がどのサービスを監視するか、誰が休んで良いかの調整 目的：不安を取り除くために、事前に決められることを決めていく
43. 残り-15 ؂ࢹ༻μογϡϘʔυͷ੔උ 対象サービスについての Golden Signalsのモニタリングダッシュボードを整備する 51日 à
44. 監視用ダッシュボードの整備 Goal 当日に使うための監視用ダッシュボードの整備 Steps 1. Golden Signalsをサービスごとに一覧できるダッシュボードを作る 2. 特に、予測アクセス数と処理限界にマーカーを書き、予測値や限界値をわかりやすくする 44 残り-15
45. 残り-13 ౰೔ͷ଴ػ ؂ࢹ ਓһͷ഑ஔௐ੔ 誰がどのサービスを監視するのか、事前に決めておく 15日 à
46. 当日の待機(監視)人員の配置調整 Goal 誰がどのマイクロサービスを担当して、当日監視するかを事前に決めておく Steps 1. マイクロサービスを”近い”サービスごとに、いくつかのグルーピングする 2. マイクロサービスグループごとに、当日誰が監視するか整理する 46 残り-13
47. 残り-13 ϚʔέςΟϯάνʔϜʹ౰೔ͷQVTI௨஌࣌ࠁΛ֬ೝ マーケティングチームによるPR予定についても事前に確認 15日 à
48. マーケティングチームに当日のpush通知時刻を確認 Goals マーケティングチームが独自に企画するpush通知の時刻を事前に把握し、当日びっくりしなくて良 いようにする Steps • 当日のPush通知の時刻表を共有してもらう 48 残り-13 2023年の元旦は、23:30頃に突発的な負荷が来たが、心構えができていた
49. 意識すべきマイルストーン 49 残り-00 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01 あけおめLINE あけおめLINE当日
50. 「あけおめLINE」当日 50 残り-00 23:00 23:30 23:50 00:00 01:00 02:00 定点報告 定点報告 定点報告 日本の「あけおめLINE」 台湾の「あけおめLINE」 タイの「あけおめLINE」
51. 高負荷が予測される「あけおめLINE」への対応まとめの追体験 51 残り-364 短期的なプロジェクトとして、予防だけに偏らないよう意識的に取り組んでいる • 「予防」「検知」「対処」をバランス良く その他、長期的な対応として下記も実施 • 発生可能性の低減 • リスクの移転・共有 • リスクの受容 • 影響の低減 • リスクの増加 • リスク源の除去 • リスクの回避