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