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

by LINE Developers

Slide 1

Slide 1 text

-*/&ελϯϓͷ43&JOHࣄྫूɿ େ͖ͳεύΠΫΞΫηεΛࡹͨ͘Ίͷ43&JOH 43&/&95 -*/&גࣜձࣾ43& NBSV 9!NBSVMPPQ -*/&ελϯϓ ண͔ͤ͑ ϗʔϜλϒ ΢ΥϨοτλϒ

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

過去の「あけおめ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

Slide 23

Slide 23 text

平常時のアクセス数の前年比 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

Slide 24

Slide 24 text

前年の実際の「あけおめ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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Prioritized Load Shedding準備のためのワークショップ開催 Goal 高負荷に陥った際、ユーザー影響の小さい機能を停止して、重要な機能だけでも死守したい。どのAPIをLoad Sheddingしても良いか、事前に決定しておく。 Steps 1. 企画・クライアント・サーバー・QAなどのメンバーが全員集まる1時間の会議予定を取る 2. アクセス数が多いAPI順に、開発環境でエラーを返すようにしていく • 開発環境で動作確認をして、ユーザーインパクトごとにAPIをLow, Middle, Highでランク付けをする 3. LowのAPIは、担当者の独自判断でLoad Sheddingして良いという取り決め 35 残り-59

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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