CloudRun, Spanner に対する負荷試験の反省と オブザーバビリティによるアプローチ

広告配信システムにおけるCloud RunおよびSpannerの負荷試験の経験をもとに、システムの可視化（オブザーバビリティ）を活用した最適化アプローチについて詳述しています。負荷試験の結果や改善点、ボトルネックの特定方法を説明し、DatadogやOpenTelemetryを活用した監視手法の考察も含まれています。さらに、Cloud Runのスケーリング戦略やSpannerのスキーマ最適化、セッション管理のポイントなどを具体的に解説し、今後の課題としてシステム重要指標の言語化やメトリクスの精緻化についても言及しています。

Transcript

1. CloudRun, Spanner に対する負荷試験の反省と オブザーバビリティによるアプローチ 株式会社サイバーエージェント 茨木 啓瑚（いばらき けいご）
2. • 自己紹介 • 本日の流れ • 作っているシステムと負荷試験について • 上手く行った点 • もう少し上手くできた点 • これから取り組みたい点 • まとめ 2
3. 自己紹介 3
4. 茨木 啓瑚（いばらき けいご） • 所属 ◦ サイバーエージェント > AI 事業本部 • 業務内容 ◦ 広告配信システムの構築 @oyasumi_pant s 4
5. 本日の流れ 5
6. • 実際に作っているサービスや負荷試験について • オブザーバビリティ的な観点で取り組めた知見や反省 • “もっとこういうことできそう！” の議論がしたい 本日の流れ 6
7. 作っているシステムと 負荷試験について 7
8. 広告配信システムとは？ 8
9. 広告配信システムの イメージ 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 配信サーバー 計測サーバー 広告主 クリエイティブ 集計用DB 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 メインDB Storage 大まかな流れ 9
10. 広告配信システムのアーキテクチャ 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 CloudRun CloudRun 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS Google Cloud に置き換え PubSub 10
11. 大体こんな処理をしています 配信サーバーの例 配信サーバー 11
12. システムの処理と要件 配信サーバーの例 配信サーバー 　1. 100 を超える処理 12
13. システムの処理と要件 配信サーバーの例 配信サーバー 　1. 100 を超える処理 　2. 100 msec 以内にレスポンス 13
14. システムの処理と要件 配信サーバーの例 配信サーバー 　1. 100 を超える処理 　2. 100 msec 以内にレスポンス 　3. 10,000 qps を超えるリクエスト 14
15. どんな負荷試験をしたの？ 15
16. 負荷試験の詳細 想定したシナリオ 　1. 1台あたりのインスタンスで処理可能な QPS の限界値を測定 16
17. 負荷試験の詳細 想定したシナリオ 　1. 1台あたりのインスタンスで処理可能な QPS の限界値を測定 　2. P(99) で 10,000 QPS のリクエストを 100msec 以内に返す 17
18. 負荷試験の詳細 想定したシナリオ 　1. 1台あたりのインスタンスで処理可能な QPS の限界値を測定 　2. P(99) で 10,000 QPS のリクエストを 100msec 以内に返す 　3. 30,000 QPS 程度のスパイクで P(99) で 100msec 以内に返す 18
19. 負荷試験の詳細 想定したシナリオ 　1. 1台あたりのインスタンスで処理可能な QPS の限界値を測定 　2. P(99) で 10,000 QPS のリクエストを 100msec 以内に返す 　3. 30,000 QPS 程度のスパイクで P(99) で 100msec 以内に返す 19 詳細はこちらに 記載しております！ https://zenn.dev/oyasumipants/articles/3aaecc8c082d33
20. ダッシュボードの紹介 Cloud Run 20 Spanner CloudRun Spanner を中心にメトリクスの計測を可能にした
21. オブザーバビリティツール DATADOG Vector Cloud Logging 使用ツール一覧 Cloud Trace Cloud Monitorin g 21
22. オブザーバビリティツール Cloud Logging 使用ツール一覧 22 Cloud Run DATADOG Vector Cloud Trace Cloud Monitoring DATADO G ログの収集 トレースの収集 メトリクスの収集 標準ログの収集 トレースの収集 メトリクスの収集
23. これらを踏まえた反省 ここから話すこと 23 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS PubSub Cloud Run Cloud Run 23 1. 上手く行った点 2. もう少し上手くできた点 3. これから取り組みたい点
24. 上手く行った点 24
25. 上手く行った点 3つの観点 25 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS PubSub Cloud Run Cloud Run 25 1. CloudRun に対する話 2. Spanner に対する話 3. 配信サーバ全体に対する話
26. CloudRun に対する話 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS CloudRun PubSub Cloud Run Cloud Run 26
27. リソースのポイントを抑える CloudRun のスケールポイントを抑える • 既存インスタンスの 1分間の平均 CPU 使用率 • 1分間でのリクエストの同時実行数と比較した現在の同時実行数 • インスタンスの最大数 • インスタンスの最小数 https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja CloudRun 27
28. リソースのポイントを抑える https://cloud.google.com/monitoring/api/metrics_gcp?hl=ja#gcp-run CloudRun のポイントをメトリクスに起こす 最大同時リクエスト Cloud Run Revision - Max Concurrent Requests CloudRun の CPU 使用率 Cloud Run Revision - Container CPU Utilization 現状のインスタンス数 Cloud Run Revision - Instance Count 28
29. メトリクスを組み合わせて活用 • Container Instance を 1に設定する • CPU 使用率が 60% 程度になった時の同 時実行数を見極める https://zenn.dev/google_cloud_jp/articles/cloudrun-concurrenc y 同時実行数を見定める Instance は 1台に固定 29
30. CloudRun Spanner に対する話 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 GCS Spanner PubSub CloudRun Spanner 30
31. リソースのポイントを抑える Spanner のポイントを抑える • ”今回は” CPU 使用率が 65% 以下になるように • スキーマ設計を最適化する • クエリの最適化をする https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja Spanner 31
32. Spanner とオブザーバビリティ Key Visualizer https://cloud.google.com/blog/ja/topics/developers-practitioners/understanding-cloud-spanner-performance-metrics-scale-key-visuali zer • データ分布とホットスポットを可視化 し、ボトルネックを特定 • 適切に負荷分散することで、スケーラ ブルなパフォーマンスを維持 Key Visualizer 32
33. Spanner スキーマ設計のベスプラ ヒートマップパターン 均等分布 ヒートマップで読み取り・書 き込みが均等に行われている 一定のホットキー 特定の行範囲が時系列で 一貫してアクセスが多い 単調増加 シーケンシャルキーを示す アンチパターン 一定の頻度 短時間での行単位のシーケン シャルな読み取り・書き込み 33 https://cloud.google.com/blog/ja/topics/developers-practitioners/understanding-cloud-spanner-performance-metrics-scale-key-visuali zer
34. Spanner スキーマ設計のベスプラ スキーマ変更の Before After 単調増加型でシーケンシャルスキャン スキーマ変更 アクセスが分散される 34
35. 配信サーバー全体に対する話 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS アプリケーション PubSub CloudRun CloudRun CloudRun Spanner 35
36. APM を使ったボトルネック解消 Span・Trace の活用 • APM の Trace を活用し、複数のサー ビス層を横断的に分析 • 遅延発生の原因になってた Cloud Resource へのアクセスを最適化する ために、In-Memory に乗せる • Cloud Resource へのアクセス回数 を削減し、レスポンス時間を改善 ボトルネックになっていそうな箇所 が いくつか見つかる ボトルネックになっていそうな箇所 が いくつか見つかる 36
37. もう少し上手くできた点 37
38. もう少し上手くできた点 2つの観点 38 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS PubSub Cloud Run Cloud Run 38 1. クォータの整理と可視化 2. 重要なポイントの抑え忘れ
39. クォータの整理と可視化 CloudRun クォータ ex... https://cloud.google.com/run/quotas?hl=ja 説明 上限 インスタンスあたりの 同時リクエストの最大数 HTTP/2 クライアント接続あたりの 同時ストリームの最大数 リクエストごとの タイムアウトまでの最大時間 HTTP/1 リクエストの最大サイズ HTTP/1 レスポンスの最大サイズ インスタンスごとの 1秒あたりの アウトバウンド接続 1,000 100 60分 HTTP/1 サーバーを使用する場合は 32MiB. HTTP/2 サーバーを使用する場合は無制限. Transfer-Encoding：chunked または ストリーミングメカニズムを使用しない場合は 32MiB 700 様々なクォータが 設定されている 39
40. クォータの整理と可視化 • “インスタンスごとの HTTP/1 コンテナ ポートへの 1 秒あたりのインバウンド リ クエスト数” が 800 という制約がある • この制約のために HTTP/2 に切り替え、 処理できるリクエスト数が 爆増 • クォータを把握した上でメトリクスに起 こすことで更に早く問題解決できたは ず... CloudRun のクォータ 1min 辺り 4,800qps から 伸びてない... https://cloud.google.com/run/quotas?hl=ja 40
41. 抑えきれてなかった重要なポイント 本来はリソースのポイン トを抑えるでやっておき たかった、、、 • クライアントとデータベース間のやり取りを セッション で行 い、読み取り・書き込みトランザクションを実行できる • 適切な セッション管理 がリソース効率と性能を高める Spanner のセッション 項目 説明 Min Sessions Max Sessions Num Channels 1つのクライアントが実行すると予想される同時トランザクション数に設 定 1つのクライアントが実行できる同時トランザクションの最大数に設定 [MaxSessions / 100 ] に設定 1つの gRPC チャネルで最大 100 件のリクエストを同時に処理可能 https://cloud.google.com/spanner/docs/sessions?hl=ja 41
42. 重要なポイントを再度可視化 https://cloud.google.com/blog/ja/products/spanner/troubleshooting-cloud-spanner-applications-with-opencensus-metri cs OpenCensus • メトリクス収集やトレースを簡単に行え るオープンソースライブラリ • Spanner と組み合わせることで、データ ベースクエリやレイテンシなどの重要な メトリクスを可視化・分析可能 • 問題発生時の根本原因を効率的に特定 し、迅速なトラブルシューティングが実 現可能 42
43. 重要なポイントを再度可視化 OpenCensus でセッションの可視化 B 同時に利用中となるセッションの最大数 max_in_use_sessions A 許可されているセッションの最大数 max_allowed_sessions C 現在プール存在するセッションの総数 num_sessions_in_pool D 実際に開かれているセッションの数 open_session_count 設定した max 数に 達していないことを確 認 43
44. これから取り組みたい点 44
45. これから取り組みたい点 4つの観点 45 配信面 1. 枠情報のリクエス ト 0. クリエイティブ登 録 3. 広告の返答 広告主 クリエイティブ BigQuery 4. 閲覧・クリック・CV 2. 最適な広告の選定 5. 予算・配信結果集 計 Spanner GCS PubSub Cloud Run Cloud Run 45 1. 詳細化しきれていないメトリクス 2. システムで重要になる点の言語化 3. 3つの柱の融合 4. メトリクスを育てていく
46. 詳細化しきれていないメトリクス https://cloud.google.com/blog/ja/products/serverless/cloud-run-now-supports-multi-container-deployme nts サイドカーの可視化 実際にサイドカーが影響して context cancel が問題 に... • サイドカーアーキテクチャの採用が容易 となり、複雑なアプリケーションを効率 的に運用可能 • CPU 使用率や Memory 使用率を Container 毎 に詳細に出せるようにし たい 46
47. システムで重要になる点の言語化 クラウドプロバイダを観測する • オブザーバビリティに関しては「何が 重要か」という分類ができる • オブザーバビリティによってシステム を理解することは、 特定のビジネス/ 技術的目標の達成 に役立つのかを考 える https://www.oreilly.co.jp/books/9784814401024/ 7章 インフラストラクチャの観 測 47
48. 技術目標の達成のためには？ 技術目標の言語化 https://www.oreilly.co.jp/books/9784814401024/ • 処理が膨大な中で低レイテンシを実現した い • クラウドとの接続を減らし Container Memory を活用しまくる • Memory をより詳細に可視化したい 48 A が占める割合 B が占める割合 C が占める割合 D が占める割合 Cloud Run Container Memory
49. 3本の柱の融合の重要性を考慮 融合によるメリット 49 トレース メトリクス ログ • ログに Trace ID や Span ID を記録 することで、異常発生時に前後関係が 明確になり、原因の特定が容易になる • メトリクスを基に高負荷な箇所を特定 し、関連するトレースを追跡できる ようにする
50. メトリクスを育てていく 50 ダッシュボードの整理 • 実は重要なメトリクスは限られてい ることに気づく • 「何故重要なのか？ 」の共通認識が 取れているようにしたい • DATADOG 上に持ってこられていな い重要なメトリクスも持ってきたい 負荷試験を通して 実際に欲しいメトリクスが 絞られた セッション数を DD 上でも見れる ようにしたい
51. メトリクスを育てていくアイデア 51 メトリクスの言語化 • 歴史的な背景が不明になった場合 や、新しく入ってくるメンバーに対 して、当該メトリクスが「 何故重要 なのか？」を記載しておける https://speakerdeck.com/recruitengineers/datadoglive2024-mopp?slide=48 参考：うちにも入れたい Datadog
52. OpenTelemetry 導入予定...！ https://www.oreilly.co.jp/books/9784814401024/ • OpenTelemetry の概要から導入・ 実運用までを解説し、システムの可視 性と信頼性向上を支援する入門書 • OpenTelemetry の思想やこれから 目指す立ち位置も記載してあり、導入 したくなる 入門 OpenTelemetry 52
53. まとめ 53
54. まとめ 54 アプリケーションに APM を仕込み、ボトルネックの解消ができ たことは大きな成果だが、さらなる改善の余地がある 特に、サイドカーの影響を可視化することで、より詳細なボトルネック分析とパフォーマンス向上が 期待できる。アプリケーションで重要な点を言語化し、適切なモニタリングを行うことが今後の課題 Cloud Service 全体の特性を理解し、サービスごとの重要なポイン トやクォータを抑えて可視化することが不可欠である Cloud Run や Spanner に限らず、各サービスの制約を把握し、適切なリソース管理を行うことで、安 定した運用が可能になる 負荷試験で得た教訓は、本番運用にも活用すべきである 負荷試験を単なる事前検証で終わらせるのではなく、本番環境でも継続的にオブザーバビリティを高める ことで、運用改善を実現する
55. ご清聴ありがとうございました 55