$30 off During Our Annual Pro Sale. View Details »

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

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

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

LINE Developers

September 29, 2023
Tweet

More Decks by LINE Developers

Other Decks in Technology

Transcript

  1. LINEスタンプのアーキテクチャ 基本的なアーキテクチャ • ドメインごとに分かれたマイクロサービス 「あけおめLINE」で影響するサービス • 約15マイクロサービスで負荷が増える 5 残り-94 所有権確認サービス

    画像配信サービス 検索サービス サブスクリプション確認サービス スタンプ送信可否判断サービス Gatewayサービス 絵文字情報サービス スタンプ情報サービス などなど….
  2. 意識すべきマイルストーン 6 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE 想定外の何かに対処するために、 遅くとも2ヶ月前に増設開始したい アプリケーションやインフラの変更によるリグレッショ ンを防ぐために、この日以降は基本的にリリース禁止
  3. サーバー増設開始までに行う主なタスク 7 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE • 影響サービスの洗い出し • アクセス見積もり • 処理性能確認 予防重視
  4. コードフリーズまでに行う主なタスク 8 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE • 過負荷時の初動改善 • パフォーマンスチューニング • エラーハンドリング改善 対処重視
  5. コードフリーズ後に行う主なタスク 9 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE • 監視ダッシュボードの整備 • 待機人員の整理 検知重視
  6. 全体スケジュール 10 残り-94 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE • 影響サービスの洗い出し • アクセス見積もり • 処理性能確認 • 監視ダッシュボードの整備 • 待機人員の整理 • 過負荷時の初動改善 • パフォーマンスチューニング • エラーハンドリング改善
  7. サーバー増設開始まで (約30日間) のタスク 11 残り-94 1. アクセス増加見込みのあるマイクロサービスを確認 2. 各マイクロサービスの処理性能を確認 3.

    各マイクロサービスのアクセス数を見積もる 4. サーバーの増設台数を計算 5. 異常時の予想アクセス数を関連サービスに確認 前年と同じなら15サービスだが、それ以外に増えてないか確認する 各マイクロサービスで、どのくらいのピークアクセス数になるか見積もり 各マイクロサービスで、秒間 何リクエストを処理できるか確認 実際にどのくらいのサーバーを増やすべきか計算する 異常時のフォールバックアクセス数などをヒアリング 目的:サーバー増設を余裕を持って行うための準備
  8. アクセス増加見込みのある新サービス/新機能の確認 目的 • 今年の新サービスや新機能やアーキテクチャ変更は見積もり漏れが怖い • それらも対応が必要か確認する 進め方 • wikiを1ページ作り、関連するサーバーサイドエンジニアに記入してもらう 13

    残り-94 # 着せかえローテーション機能(新機能) ローテーション機能を設定しているユーザーが前回のアプリ起動時から一定時間 経過していると、自動で別の着せかえが適用される。 着せかえ適用時にAPIリクエストが発生するため、「あけおめLINE」時にLINEを起 動したユーザーによるアクセス増加が予想されるが、API自体は非常にキャッシ ュヒット率が高いため、DB負荷は小さい e.g.
  9. カオスエンジニアリングによる高負荷試験の実践 1. アプリケーションのリリースタイミングを事前にプロダクト側と調整しておく • リリースと重ならないタイミングでカオスエンジニアリングを実施するため 2. ダッシュボードを準備する 3. アクセスを少しずつ特定インスタンスに寄せていく 1.

    最も簡単な方法は、実際にアプリケーションをshutdowさせる 2. もし、動的にルーティングを変更する機能を持っているなら、その機能を使う 4. CPU 70%を超えるまでのレイテンシーとエラー率を記録していく 5. 予期せぬエラーやレイテンシーが記録されたら、直ちに実験を中止する 19 残り-91
  10. 3種類の見積もり結果から、悲観的な値を採用する この中で最も悲観的な 13,310 req/secを見積もりとして採用。 例外的な処理 • 今年リリースされた新機能のため、前年のデータが一切ない • 近いマイクロサービスのデータを参照する、他のキャンペーン時のアクセス数を参考にする •

    データに異常値があり、見積もり結果も異常になってしまった • データが異常な理由を確認した上で、見積もり結果から取り除く 25 残り-71 「あけおめLINE」時のアクセス数の変化率の幾何平均 13,310 req/sec 平常時アクセス数の前年比 13,310 req/sec 前年の実アクセス数 12,100 req/sec
  11. 補足:アクセス数の変化率の幾何平均について MAUは変わってないのに、アクセス数が増えてたら? 考えられる可能性 • なんらかによって、ユーザーの行動が大きく変容した • UIが変わって、アクセスしやすい所に機能が配置された • クライアントのロジックが変わって、呼び出し頻度が増えた 26

    残り-71 変化率の幾何平均は、アクセス数以外の指標と直接比較することが可能。 例えば、最も単純なWebサービスのモデルとして、MAUとアクセス数が比例する場合。 理由が何であれ、前年と比較して予期せぬアクセス負荷がくるかもしれない、要注意サービス
  12. サーバーの増設台数の計算 Goal アクセス数の見積もり結果と処理性能から、サーバー増設台数を計算する Steps 1. 各サービスにおいて、不確実性の大きさを確認する • 3種類の見積もり結果の標準偏差がどのくらいあるか • MAUの変化率の幾何平均からどれだけ離れているか

    • 最近大きな変更をした機能か • 最近ローンチしたばかりの機能か 2. 不確実性が大きいサービスについては、安全マージンを大きく取る 28 残り-69 必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン
  13. 安全マージンの例 29 残り-69 必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン

    サービスの説明 安全マージン倍率 安全マージンの根拠 LINEスタンプ送信時の所有権検証 1.3倍 ユーザー数や機能が安定しており、3 種類の見積もり結果もほぼ同じ予測値 複数のマイクロサービスのレスポンスを集約 2倍 今年サーバースペックを大きく変更し たため、大きめのマージン HTTP to RPCへ変換, 認証など 2倍 大規模なアーキテクチャ変更によって 、アクセス数需要の予測精度に不安
  14. 意識すべきマイルストーン 32 残り-61 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE 予防策として、サーバー増設のための準備は完了。 ここからは、障害発生を前提とした対策を主に行う。
  15. コードフリーズまで(45日間)の主なタスク 33 残り-61 1. Prioritized Load Shedding準備のためのワークショップ開催 2. ワークショップ中に発見したエラーハンドリング改善 3.

    処理性能の確認時に発見されたボトルネックの改善 過負荷になった際に、どのAPIからFailさせるか優先度を確認する 残る時間で可能な限りのパフォーマンス改善 Failになった場合でも、最低限のUXを担保する 目的:サーバーの増設、障害発生を前提とした対策、可能な範囲でのチューニング
  16. Prioritized Load Shedding準備のためのワークショップ開催 Goal 高負荷に陥った際、ユーザー影響の小さい機能を停止して、重要な機能だけでも死守したい。 どのAPIをLoad Sheddingしても良いか、事前に決定しておく。 Steps 1. 企画・クライアント・サーバー・QAなどのメンバーが全員集まる1時間の会議予定を取る

    2. アクセス数が多いAPI順に、開発環境でエラーを返すようにしていく • 開発環境で動作確認をして、ユーザーインパクトごとにAPIをLow, Middle, Highでランク付けをする 3. LowのAPIは、担当者の独自判断でLoad Sheddingして良いという取り決め 35 残り-59
  17. 意識すべきマイルストーン 41 残り-16 09/29 本日 11/01 サーバー増設開始 12/15 コードフリーズ 01/01

    あけおめLINE 障害を前提とした対策も完了。 障害検知のための整備を中心に行う。
  18. 「あけおめLINE」当日までの主なタスク 42 残り-16 1. 監視用ダッシュボードの整備 2. 当日の待機(監視)人員の配置調整 3. マーケティングチームに当日push通知の予定時刻を確認 Golden

    Signalsメトリクスをサービスごとに確認できるダッシュボードの準備 当日予期せぬアクセスで慌てなくて済むように・・・。 誰がどのサービスを監視するか、誰が休んで良いかの調整 目的:不安を取り除くために、事前に決められることを決めていく
  19. 「あけおめLINE」当日 50 残り-00 23:00 23:30 23:50 00:00 01:00 02:00 定点報告

    定点報告 定点報告 日本の「あけおめLINE」 台湾の「あけおめLINE」 タイの「あけおめLINE」