Monthly LT 2024-12-18 高トラフィック で な をする際の参考書 IBaraki keigo
 茨木 啓瑚 負荷試験 Cloud RUn

自己紹介 茨木 啓瑚 Cyberagent / AI 事業本部 ibaraki keigo

はじめに アドベントカレンダーにも公開しているので是非！ 参考：https://zenn.dev/oyasumipants/articles/3aaecc8c082d33

はじめに 広告配信システムにおける負荷試験 17 Cloud Run に対してある程度大きい規模の負荷試験をしたので tips 共有 SPANNER Cloud RUn

はじめに 広告配信システムにおける負荷試験 17 Cloud Run に対してある程度大きい規模の負荷試験をしたので tips 共有 SPANNER Cloud RUn

1負荷試験を始める前 B 達成したい条件の明確6 B コストがどれくらいかかるの B 可視化（ダッシュボード） 2負荷試験中に考え、改善していったこと B 4つのオートスケールのポイントを知ƒ B 平均 CPU 使用率と同時実行数を定めƒ B 最大台数と最小代数を定めƒ B クォータを正しく確認すƒ B Support の方を頼ƒ B CPU / Memory の大きさを決定すƒ B Start up Boost を使ってみる 3負荷試験を行なった後 B 最終的な負荷試験の結– B 負荷試験共有会 4課題に思っていること B オートスケールに関する柔軟Ð B サイドカーが CPU 使用率に影響すƒ B 可視化の課Æ B 継続的に負荷試験を実施するための CI パイプライ¶ B 予測不可能なリクエスト増量やワークロード アジェンダ

1負荷試験を始める前 B 達成したい条件の明確6 B コストがどれくらいかかるの B 可視化（ダッシュボード）

達成したい条件の明確化 負荷試験を効果的に進めるために明確な目標を 58 シナリオを決める w 1台のインスタンスが捌ける QPS の限界を測V w 平均 10,000 QPS を 1時間 維持できるか確G w スパイク 30,000 QPS に耐えられるか検証 w 目標 SLI/SLO: 「リクエストの99パーセンタイル応答時間が 100ミリ秒以下であること」 w テストデータの準ƒ w リクエストの種類を分散 8 SLI / SLO を決める ¥8 データを明確にする

コストがどれくらいかかるのか Cloud Run の課金形態を頭に叩き込む ※ 全て tier1 の料金で記載 ※ 紫の部分がコンテナ内のプロセスが CPU をフルに使える時間 ※ 無料枠の記載は割愛 参考：https://cloud.google.com/run/pricing?hl=ja

可視化（ダッシュボード） システムの状態をリアルタイムで把握できるようにする

負荷試験中に考え、改善していったこと U 4つのオートスケールのポイントを知7 U 平均 CPU 使用率と同時実行数を定め7 U 最大台数と最小代数を定め7 U クォータを正しく確認す7 U Support の方を頼7 U CPU / Memory の大きさを決定す7 U Start up Boost を使ってみる 2

4つのオートスケールのポイントを知る オートスケールのポイントを頭に叩き込む AI 既存インスタンスの 1分間の平均 CPU 使用率 iI 同時実行数(Concurrency) yI インスタンスの最大数 ‰I インスタンスの最小数 参考：https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja

平均 CPU 使用率と同時実行数を定める 密接に関連する平均 CPU 使用率と同時実行数 Yc なぜ同時実行数を適切に設定する必要があるのか？ 参考：https://cloud.google.com/run/docs/about-concurrency?hl=ja#maximum_concurrent_requests_per_instance

平均 CPU 使用率と同時実行数を定める 密接に関連する平均 CPU 使用率と同時実行数 FQ さらに検証を深める TQ どう設定すれば良いか？ t 同時実行数（Concurrency）を最大の 1000 に設定す† t 負荷試験を行い、CPU 使用率が 60% に達するタイミングでの同時実行数を確認す† t 確認した同時実行数を基準に、適切な同時実行数を設定する t インスタンスの最大数を 1 に設 t CPU 使用率が 60% 程度で安定した際の同時実行数 参考：https://zenn.dev/google_cloud_jp/articles/cloudrun-concurrency

最大台数・最小台数を定める スケールの下限・上限を決定する '2 最大台数の設定 A2 最小台数の設定 q スケールアウトの制御が難しR q 最大台数を絞ることで過剰なスケールアウトを防ぐ q スケールアウトの遅延リス‚ q 最小台数を 1 以上に設定する

クォータを正しく確認する 検証に合ったクォータを確認する 35 CPU の大きさの制限 D5 HTTP による制約 e メインコンテナ と サイドカー を含めて、1インスタンスあたりの最大 vCPU 数が 8 に制限 e HTTP/1.1 コンテナポートに対する 1秒あたりのインバウンドリクエスト数 に 800 という制約

Support の方を頼る プロの力を頼った方が物事が迅速に進む B5 サポートを活用するメリット h Google Cloud 側でしか確認できない内部メトリクv h 内部の実装やクォータ制約に関する情R h 解決策と折り合いのポイントの明確化

CPU・Memoryの大きさを決定する 最終的なスペックの決定 35 CPU の決定 @5 Memory の決定 ‚ CPU に関してはサイドカーのエージェントにかかる料金と比較しながらメインコンテナの cpu をより大きくする選定 ‚ Memory に関しては十分に計算しt ‚ Go は型で bit 数が決まるので、不要な大きさを確保しないように型から見直し 参考：https://go.dev/ref/spec#Numeric_types

Start up boost を使ってみる $" コールドスタート B" Startup CPU Boost でコールドスタートの改善 参考：https://cloud.google.com/run/docs/configuring/services/cpu?hl=ja#startup-boost d 負荷が急増した際に、リクエストの処理が間に合わず遅延やタイムアウトが発生するリスクがある d 通常の CPU 割り当てに加えて一時的に CPU リソースをブーストする機 d 起動時間の短縮とコールドスタート時のレスポンス改善

負荷試験を行なった後 $ 最終的な負荷試験の結 $ 負荷試験共有会 3

最終的な負荷試験の結果 !% １台で捌ける QPS の限界 1 4,500 QPS 程度までは捌け7 1 3,000 QPS 程度なら 100msec 以内に返せる

%! 10,000 QPS を定常的に受けられるか（1時間程度） 最終的な負荷試験の結果 T max6台程度で安定して捌けていそう

30,000 QPS のスパイクに耐えられるか 最終的な負荷試験の結果 B max10台程度することで急激なスパイクにも耐え得る

負荷試験共有会 最も効果があったと思うこと 0 実際にやったこと s 負荷試験共有会を行なっF s 負荷試験の理解を深めQ s コスト認識の共T s 開発チームへの実践共T s ビジネス要件の擦り合わせ s チーム間でビジネス的な要件を擦り合わせるx s 「SREとビジネスの話」 参考：https://zenn.dev/oyasumipants/articles/d2a2648bbc8bc5

課題に思っていること X オートスケールに関する柔軟D X サイドカーが CPU 使用率に影響すV X 可視化の課4 X 継続的に負荷試験を実施するための CI パイプライ X 予測不可能なリクエスト増量やワークロード 4

課題に思っていること $ オートスケールに関する柔軟性 D サイドカーが CPU 使用率に影響する G 可視化の課題 „ Cpu 使用率が 60% で固定されている点が柔軟性に欠けると感じた... „ CPU 使用率の判定にサイドカーの CPU 使用も合算されて計算されるので影響を考慮しないといけない,,, „ メインコンテナとサイドカーの CPU 使用率を個別に表示したい...

課題に思っていること "5 継続的に負荷試験を実施するための ci パプライン Y5 予測不可能なリクエスト増量やワークロードへの対応 ‡ 新しい機能を追加した際などに ci で負荷試験を実施できるようにしたい ‡ 突発的なスパイク、夜間リクエスト量が低下してから再度上昇するワークロードなどこれから経験値を積みたい

THANK YOU ! IBaraki keigo
 茨木 啓瑚