$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
PRO

September 29, 2023
Tweet

More Decks by LINE Developers

Other Decks in Technology

Transcript

  1. -*/&ελϯϓͷ43&JOHࣄྫूɿ
    େ͖ͳεύΠΫΞΫηεΛࡹͨ͘Ίͷ43&JOH
    43&/&95
    -*/&גࣜձࣾ43&
    NBSV 9!NBSVMPPQ

    -*/&ελϯϓ ண͔ͤ͑ ϗʔϜλϒ ΢ΥϨοτλϒ

    View Slide

  2. 残り-94
    ࠓ͔Β͜ͷηογϣϯͷؒɺΈͳ͞Μ͸ࢲͱಉ͡νʔϜϝϯόʔͰ͢ɻ
    ໿ϲ݄ޙʹഭΔʮ͚͓͋Ί-*/&ʯΛҰॹʹ৐Γӽ͑·͠ΐ͏ɻ
    「あけおめLINE」までの日数(9/29から)

    View Slide

  3. 「あけおめLINE」とは?
    • 元旦の午前0時0分にLINEメッセージを送り合うこと
    • 特にスタンプを送る場合は「あけおめスタンプ」と呼ぶことも
    3
    残り-94
    去年のあけおめスタンプキャンペーン

    View Slide

  4. 「あけおめLINE」対応プロジェクトとは?
    Goal
    • 元旦のアクセスを安全に乗り切る
    • ビジネスチャンスとして活かす
    アクセス規模
    • 平日ピークの13倍の瞬間アクセス
    4
    残り-94

    View Slide

  5. LINEスタンプのアーキテクチャ
    基本的なアーキテクチャ
    • ドメインごとに分かれたマイクロサービス
    「あけおめLINE」で影響するサービス
    • 約15マイクロサービスで負荷が増える
    5
    残り-94
    所有権確認サービス
    画像配信サービス
    検索サービス
    サブスクリプション確認サービス
    スタンプ送信可否判断サービス
    Gatewayサービス
    絵文字情報サービス
    スタンプ情報サービス
    などなど….

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  9. コードフリーズ後に行う主なタスク
    9
    残り-94
    09/29
    本日
    11/01
    サーバー増設開始
    12/15
    コードフリーズ
    01/01
    あけおめLINE
    • 監視ダッシュボードの整備
    • 待機人員の整理
    検知重視

    View Slide

  10. 全体スケジュール
    10
    残り-94
    09/29
    本日
    11/01
    サーバー増設開始
    12/15
    コードフリーズ
    01/01
    あけおめLINE
    • 影響サービスの洗い出し
    • アクセス見積もり
    • 処理性能確認
    • 監視ダッシュボードの整備
    • 待機人員の整理
    • 過負荷時の初動改善
    • パフォーマンスチューニング
    • エラーハンドリング改善

    View Slide

  11. サーバー増設開始まで (約30日間) のタスク
    11
    残り-94
    1. アクセス増加見込みのあるマイクロサービスを確認
    2. 各マイクロサービスの処理性能を確認
    3. 各マイクロサービスのアクセス数を見積もる
    4. サーバーの増設台数を計算
    5. 異常時の予想アクセス数を関連サービスに確認
    前年と同じなら15サービスだが、それ以外に増えてないか確認する
    各マイクロサービスで、どのくらいのピークアクセス数になるか見積もり
    各マイクロサービスで、秒間 何リクエストを処理できるか確認
    実際にどのくらいのサーバーを増やすべきか計算する
    異常時のフォールバックアクセス数などをヒアリング
    目的:サーバー増設を余裕を持って行うための準備

    View Slide

  12. 残り-94
    ΞΫηε૿ՃݟࠐΈͷ͋ΔϚΠΫϩαʔϏεΛ֬ೝ
    前年と同じなら15サービスだが、それ以外に増えてないか確認する。

    View Slide

  13. アクセス増加見込みのある新サービス/新機能の確認
    目的
    • 今年の新サービスや新機能やアーキテクチャ変更は見積もり漏れが怖い
    • それらも対応が必要か確認する
    進め方
    • wikiを1ページ作り、関連するサーバーサイドエンジニアに記入してもらう
    13
    残り-94
    # 着せかえローテーション機能(新機能)
    ローテーション機能を設定しているユーザーが前回のアプリ起動時から一定時間
    経過していると、自動で別の着せかえが適用される。
    着せかえ適用時にAPIリクエストが発生するため、「あけおめLINE」時にLINEを起
    動したユーザーによるアクセス増加が予想されるが、API自体は非常にキャッシ
    ュヒット率が高いため、DB負荷は小さい
    e.g.

    View Slide

  14. 残り-91
    ֤ϚΠΫϩαʔϏεͷॲཧੑೳΛ֬ೝ͢Δ
    各マイクロサービスで、秒間 何リクエストを処理できるか確認
    94日 à

    View Slide

  15. 各マイクロサービスごとに処理性能を確認する
    Goal
    • 各マイクロサービスが何 req/sec捌けるか確認する
    • ついでに改善した方が良い課題があればメモしておく
    Limitation
    • 15マイクロサービスを約15日で計測完了したい
    15
    残り-91

    View Slide

  16. カオスエンジニアリングの考え方で、QPSを確認
    16
    残り-91
    15日間で15マイクロサービスの処理性能を確認したい
    マイクロサービスごとのシナリオを準備する余裕はない
    マイクロサービスごとの独立環境を準備する余裕はない

    View Slide

  17. カオスエンジニアリングの考え方で、QPSを確認
    17
    残り-91
    15日間で15マイクロサービスの処理性能を確認したい
    マイクロサービスごとのシナリオを準備する余裕はない
    マイクロサービスごとの独立環境を準備する余裕はない
    ユーザーがアクセスしているインスタンスを減らし、高負荷状態を再現する

    View Slide

  18. カオスエンジニアリングの考え方で処理性能を確認する
    定常状態における振る舞いの仮説
    • このAPIサーバーは99%のリクエストを100ミリ秒以内に、エラーなく処理ができる
    • CPU使用率が70%以下では、この定常の振る舞いを維持できる
    実験方法
    • インスタンスを少しずつダウンさせ、特定インスタンスにアクセスを集中させる
    18
    残り-91

    View Slide

  19. カオスエンジニアリングによる高負荷試験の実践
    1. アプリケーションのリリースタイミングを事前にプロダクト側と調整しておく
    • リリースと重ならないタイミングでカオスエンジニアリングを実施するため
    2. ダッシュボードを準備する
    3. アクセスを少しずつ特定インスタンスに寄せていく
    1. 最も簡単な方法は、実際にアプリケーションをshutdowさせる
    2. もし、動的にルーティングを変更する機能を持っているなら、その機能を使う
    4. CPU 70%を超えるまでのレイテンシーとエラー率を記録していく
    5. 予期せぬエラーやレイテンシーが記録されたら、直ちに実験を中止する
    19
    残り-91

    View Slide

  20. 残り-71
    ϐʔΫΞΫηε਺Λݟੵ΋Δ
    ピークのアクセス数を去年のデータなどを使って見積もる
    91日 à

    View Slide

  21. ピークアクセス数を見積もる
    目的
    • サーバー増設のために、ピークアクセス数を見積もる
    進め方
    • 異なる3つの予測を行い、悲観的な予測値を採用する
    1. 過去の「あけおめLINE」時のアクセス数の変化率の幾何平均
    2. 平常時アクセス数の前年比
    3. 前年の実際の「あけおめLINE」時のアクセス数
    21
    残り-71

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  25. 3種類の見積もり結果から、悲観的な値を採用する
    この中で最も悲観的な 13,310 req/secを見積もりとして採用。
    例外的な処理
    • 今年リリースされた新機能のため、前年のデータが一切ない
    • 近いマイクロサービスのデータを参照する、他のキャンペーン時のアクセス数を参考にする
    • データに異常値があり、見積もり結果も異常になってしまった
    • データが異常な理由を確認した上で、見積もり結果から取り除く
    25
    残り-71
    「あけおめLINE」時のアクセス数の変化率の幾何平均 13,310 req/sec
    平常時アクセス数の前年比 13,310 req/sec
    前年の実アクセス数 12,100 req/sec

    View Slide

  26. 補足:アクセス数の変化率の幾何平均について
    MAUは変わってないのに、アクセス数が増えてたら?
    考えられる可能性
    • なんらかによって、ユーザーの行動が大きく変容した
    • UIが変わって、アクセスしやすい所に機能が配置された
    • クライアントのロジックが変わって、呼び出し頻度が増えた
    26
    残り-71
    変化率の幾何平均は、アクセス数以外の指標と直接比較することが可能。
    例えば、最も単純なWebサービスのモデルとして、MAUとアクセス数が比例する場合。
    理由が何であれ、前年と比較して予期せぬアクセス負荷がくるかもしれない、要注意サービス

    View Slide

  27. 残り-69
    αʔόʔͷ૿ઃ୆਺Λܭࢉ
    予測ピークアクセス数と処理性能(req/sec)から、必要台数を計算
    71日 à

    View Slide

  28. サーバーの増設台数の計算
    Goal
    アクセス数の見積もり結果と処理性能から、サーバー増設台数を計算する
    Steps
    1. 各サービスにおいて、不確実性の大きさを確認する
    • 3種類の見積もり結果の標準偏差がどのくらいあるか
    • MAUの変化率の幾何平均からどれだけ離れているか
    • 最近大きな変更をした機能か
    • 最近ローンチしたばかりの機能か
    2. 不確実性が大きいサービスについては、安全マージンを大きく取る
    28
    残り-69
    必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン

    View Slide

  29. 安全マージンの例
    29
    残り-69
    必要サーバー台数 = アクセス数見積もり / 1台あたりの処理性能(rps) * 安全マージン
    サービスの説明 安全マージン倍率 安全マージンの根拠
    LINEスタンプ送信時の所有権検証 1.3倍 ユーザー数や機能が安定しており、3
    種類の見積もり結果もほぼ同じ予測値
    複数のマイクロサービスのレスポンスを集約 2倍 今年サーバースペックを大きく変更し
    たため、大きめのマージン
    HTTP to RPCへ変換, 認証など 2倍 大規模なアーキテクチャ変更によって
    、アクセス数需要の予測精度に不安

    View Slide

  30. 残り-65
    ؔ࿈αʔϏεʹɺϑΥʔϧόοΫ࣌ͷڍಈ΍ΞΫηεݟੵ΋ΓΛ֬ೝ
    他サービスからのフォールバックによって、予期せぬアクセスが増えることがある
    その際に障害にならないように確認
    69日 à

    View Slide

  31. 関連サービスからフォールバックアクセスを確認する
    Background
    関連サービスによっては、あるサービスAが障害のときだけ、フォールバックとしてサービスBにア
    クセスするように設計していることがある。
    フォールバックアクセスは普段のメトリクスには表れないので、地道に確認する。
    Goal
    フォールバックによって、カスケード障害にならないようにする
    Steps
    • 関連サービスにフォールバック時のアクセス見積もりを聞いておく
    31
    残り-65

    View Slide

  32. 意識すべきマイルストーン
    32
    残り-61
    09/29
    本日
    11/01
    サーバー増設開始
    12/15
    コードフリーズ
    01/01
    あけおめLINE
    予防策として、サーバー増設のための準備は完了。
    ここからは、障害発生を前提とした対策を主に行う。

    View Slide

  33. コードフリーズまで(45日間)の主なタスク
    33
    残り-61
    1. Prioritized Load Shedding準備のためのワークショップ開催
    2. ワークショップ中に発見したエラーハンドリング改善
    3. 処理性能の確認時に発見されたボトルネックの改善
    過負荷になった際に、どのAPIからFailさせるか優先度を確認する
    残る時間で可能な限りのパフォーマンス改善
    Failになった場合でも、最低限のUXを担保する
    目的:サーバーの増設、障害発生を前提とした対策、可能な範囲でのチューニング

    View Slide

  34. 残り-59
    1SJPSJUJ[FE-PBE4IFEEJOH४උͷͨΊͷϫʔΫγϣοϓ։࠵
    過負荷になった際に、どのAPIからFailさせるか優先度を確認する
    65日 à

    View Slide

  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

    View Slide

  36. 残り-51
    ϫʔΫγϣοϓதʹൃݟ͞ΕͨΤϥʔϋϯυϦϯάͷվળ
    Failになった場合でも、最低限のUXを担保する
    59日 à

    View Slide

  37. ワークショップ中に発見されたエラーハンドリングの改善
    Goal
    ワークショップでエラーを返して動作確認をする中で、エラーハンドリングで改善できる部分があ
    れば改善する
    Steps
    1. クライアント側でタスクを進行する
    • このタスクの優先順位も含めて、クライアント側に一任
    • 今年の「あけおめLINE」に間に合わなくても問題ないぐらいの優先度タスク
    37
    残り-51

    View Slide

  38. 残り-51
    ॲཧੑೳͷ֬ೝ࣌ʹൃݟ͞ΕͨϘτϧωοΫͷվળ
    残る時間で可能な限りのパフォーマンス改善
    59日 à

    View Slide

  39. 処理性能の確認時に発見されたボトルネックの改善
    時間の許すかぎり、
    あらゆる手段を用いてチューニングをする
    39
    残り-51
    Goal
    カオスエンジニアリングによる性能確認時に発見されたボトルネックの解消

    View Slide

  40. 改善したボトルネックの例
    1. JsonWebTokenのverificationでCPU使用率が非常に高かったので、セッションストア方式に変更
    2. CPUより先に、Heapメモリが枯渇しGC頻度が上がっていたので、サーバースペック変更
    3. マイクロサービス間でN+1のようなAPIアクセスがあったため、APIを開発して修正
    40
    残り-51

    View Slide

  41. 意識すべきマイルストーン
    41
    残り-16
    09/29
    本日
    11/01
    サーバー増設開始
    12/15
    コードフリーズ
    01/01
    あけおめLINE
    障害を前提とした対策も完了。
    障害検知のための整備を中心に行う。

    View Slide

  42. 「あけおめLINE」当日までの主なタスク
    42
    残り-16
    1. 監視用ダッシュボードの整備
    2. 当日の待機(監視)人員の配置調整
    3. マーケティングチームに当日push通知の予定時刻を確認
    Golden Signalsメトリクスをサービスごとに確認できるダッシュボードの準備
    当日予期せぬアクセスで慌てなくて済むように・・・。
    誰がどのサービスを監視するか、誰が休んで良いかの調整
    目的:不安を取り除くために、事前に決められることを決めていく

    View Slide

  43. 残り-15
    ؂ࢹ༻μογϡϘʔυͷ੔උ
    対象サービスについての Golden Signalsのモニタリングダッシュボードを整備する
    51日 à

    View Slide

  44. 監視用ダッシュボードの整備
    Goal
    当日に使うための監視用ダッシュボードの整備
    Steps
    1. Golden Signalsをサービスごとに一覧できるダッシュボードを作る
    2. 特に、予測アクセス数と処理限界にマーカーを書き、予測値や限界値をわかりやすくする
    44
    残り-15

    View Slide

  45. 残り-13
    ౰೔ͷ଴ػ ؂ࢹ
    ਓһͷ഑ஔௐ੔
    誰がどのサービスを監視するのか、事前に決めておく
    15日 à

    View Slide

  46. 当日の待機(監視)人員の配置調整
    Goal
    誰がどのマイクロサービスを担当して、当日監視するかを事前に決めておく
    Steps
    1. マイクロサービスを”近い”サービスごとに、いくつかのグルーピングする
    2. マイクロサービスグループごとに、当日誰が監視するか整理する
    46
    残り-13

    View Slide

  47. 残り-13
    ϚʔέςΟϯάνʔϜʹ౰೔ͷQVTI௨஌࣌ࠁΛ֬ೝ
    マーケティングチームによるPR予定についても事前に確認
    15日 à

    View Slide

  48. マーケティングチームに当日のpush通知時刻を確認
    Goals
    マーケティングチームが独自に企画するpush通知の時刻を事前に把握し、当日びっくりしなくて良
    いようにする
    Steps
    • 当日のPush通知の時刻表を共有してもらう
    48
    残り-13
    2023年の元旦は、23:30頃に突発的な負荷が来たが、心構えができていた

    View Slide

  49. 意識すべきマイルストーン
    49
    残り-00
    09/29
    本日
    11/01
    サーバー増設開始
    12/15
    コードフリーズ
    01/01
    あけおめLINE
    あけおめLINE当日

    View Slide

  50. 「あけおめLINE」当日
    50
    残り-00
    23:00
    23:30
    23:50
    00:00
    01:00
    02:00
    定点報告
    定点報告
    定点報告
    日本の「あけおめLINE」
    台湾の「あけおめLINE」
    タイの「あけおめLINE」

    View Slide

  51. 高負荷が予測される「あけおめLINE」への対応まとめの追体験
    51
    残り-364
    短期的なプロジェクトとして、予防だけに偏らないよう意識的に取り組んでいる
    • 「予防」「検知」「対処」をバランス良く
    その他、長期的な対応として下記も実施
    • 発生可能性の低減
    • リスクの移転・共有
    • リスクの受容
    • 影響の低減
    • リスクの増加
    • リスク源の除去
    • リスクの回避

    View Slide