Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring

『Jagu'e'r 月末 Tech Lunch #1』
https://jaguer-tech-lunch.connpass.com/event/352740/

Transcript

1. Cloud Run を解剖して コンテナ監視を考える 26th May, Jagu'e'r 月末 Tech Lunch #1 Kento Kimura 1
2. わたしは… • 所属： Technical Solutions / Sales Engineer • 担当： パブリッククラウドのアーキテクト知識を活かした 　 Datadog のプリセールス技術支援 • 表彰： Google Cloud Partner Top Engineer 2023-25 Jagu'e'r Award 2023, 2024 優秀賞 2022-24 Japan AWS All Certifications Engineer AWS Community Builder(Cloud Operations, since 2024) • Jagu'e'r：人材育成・オブザーバビリティ・クラウドネイティブ・ Tech Writers 分科会、Next × Jagu'e'r・月末 TL の運営 • 好きな Google Cloud サービス： Cloud Run, Cloud Observability 木村 健人 (Kento Kimura) Datadog Japan GK History データセンター管理運用→パブリッククラウド技術支援 →プリセールス技術支援 2
3. おはなし 3 01 Cloud Run の概要 04 コンテナ監視 03 Cloud Run の監視 02 Cloud Run のアーキテクチャ
4. 4 Cloud Run の概要
5. 5 Cloud Run の概要: 基本 Google Cloud のマネージドコンテナサービス Cloud Run の特徴 • services, jobs, functions の3つのデプロイ方式があり、ユースケースに合わせて選択できる • 要件に合わせた柔軟なデプロイ ◦ yaml 定義やコンテナイメージを指定してのデプロイ ◦ 単一のソースコードファイルを利用したデプロイ ◦ Vertex AI Studio, App Design Center などから直接デプロイ Cloud Run jobs 明示的に起動する一時的なバッチ処 理向けの機能 処理完了後は自動終了し、並列実行 や定期実行にも対応している。 Cloud Run functions Eventarc や Pub/Sub, GCS などの イベントをトリガーに短時間の処理を 行う関数を実行する機能 インフラ管理不要で、軽量で繰り返し 行われる処理に向いている。 Cloud Run services HTTP リクエストで起動するコンテナ を実行する機能 アクセスに応じて自動スケールし、 Web アプリや API サーバーなど常駐 型の処理に適している。
6. 6 Cloud Run の概要: 詳細 Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム Cloud Run の仕組み • Knative 互換 API で Linux マイクロ VM をベースとしたコンテナを実行する • コンテナへのリクエストは Google Front End と HTTP Proxy を経由して到達する • トリガーを必要としない常駐コンテナ形式の Worker Pools が Preview で発表されている Cloud Run の特徴 • services, jobs は Knative Serving 互換の API/yaml でスケーリング設定ができる • functions は service を実行環境として起動するサーバレス関数 • どれもフルマネージドで、コントロールプレーンや実行基盤はユーザーから秘匿されている ◦ 監視対象となるのは、実行しているコンテナや関数のみ ◦ Google Cloud はメトリクス・ログ・トレースをそれぞれ提供している ▪ メトリクス：リクエスト数・インスタンス数・CPU/メモリ使用量などが記録される ▪ ログ：標準出力・標準エラー出力の内容が全て Cloud Logging に記録される ▪ トレース：HTTP Proxy を通過したリクエスト-レスポンス間が自動的に記録される
7. 7 Cloud Run のアーキテクチャ
8. Cloud Run のアーキテクチャ: 基本 実行時のアーキテクチャ • services, functions はHTTP(S) リクエストを トリガーとして起動する • jobs は Scheduler や API から起動する • services, jobs はマルチコンテナに対応 ◦ Ingress として扱えるのは一つのコンテナ ◦ コンテナ間で共有ボリュームを扱える ◦ コンテナ間通信は localhost で行える その他のアーキテクチャ • ソースコードから直接デプロイする場合は、 Cloud Build が裏側でコンテナイメージを作る • Identity-Aware Proxy(IAP) で、トリガー時に 認証を挟むことができる • *.run.app の形式で一意の URL が用意される 8 Cloud Run 443:containerPort *.run.app Cloud Scheduler
9. 9 Google Front End Google Cloud Zone Cloud Run Container Instance Ingress container Cloud Load Balancing HTTP Proxy Global External HTTP LB Shared volume sidecar containers sidecar containers sidecar containers *.run.app Custom Domain Cloud Run のアーキテクチャ: 詳細 実行時のアーキテクチャ • Google Front End(GFE) を暗黙的に経由し、 Cloud Run 毎に用意される HTTP Proxy に 一意の URL でアクセスする • HTTP Proxy を通過したリクエストは、 Ingress コンテナの任意ポートへアクセスし、 エントリーポイントに応じた処理がされる • サイドカーコンテナは localhost で Ingress コンテナとやり取りをしたり、共有ボリューム でデータを受け渡すことができる • リクエスト・CPU 使用率に応じて、コンテナ インスタンスの単位で全てのコンテナが 同時にスケールする
10. 10 Cloud Run の監視
11. Cloud Run の監視: 基本 基本の監視 • Google Cloud Console の Cloud Run 画面から、 各 Cloud Run リソースに関連する監視情報を 簡単に確認できる • メトリクス・ログはリアルタイムに画面が更新 されて、デプロイの失敗やエラーログの発生を アノテーションとしてグラフ上に表示できる • メトリクス・ログは Cloud Logging/Monitoring に収集され、ダッシュボード作成やエクスポート が自由にできる • トレースは暗黙的に Cloud Trace に収集され、 レイテンシーの遅延やエラーの発生を視覚的に 確認できる 11
12. 12 Cloud Run の監視: 詳細 詳細な監視 • Cloud Logging には標準出力・標準エラー出力の 他に、/var/log, /dev/log, /varlog/system に保存されるものも自動的に収集される • 重大度がエラー以上のログは Cloud Logging から 自動的に Error Reporting に記録されて、同様の エラーをまとめて管理できる • 自動的に HTTP Proxy で生成されるトレースは、 X-Cloud-Trace-Context, Traceparent が HTTP ヘッダーがリクエストに挿入され、後続の コンテナへ伝搬(propagate)される • コンテナのトレースを有効にする場合は、サイド カーで Google Cloud Exporter/OTLP Exporter が 内包された OpenTelemetry Collector が必要 Google Front End Google Cloud Zone Cloud Run Container Instance Ingress container Cloud Load Balancing HTTP Proxy Global External HTTP LB /var/log /dev/log /varlog/system stdout stderr Cloud Logging Shared volume sidecar containers sidecar containers sidecar containers run.googleapis.com Error Reporting *.run.app Custom Domain severity >= ERROR Google Front End Google Cloud Zone Cloud Run Container Instance Ingress container Cloud Load Balancing HTTP Proxy Global External HTTP LB Cloud Trace sidecar containers sidecar containers sidecar containers *.run.app Custom Domain Tracing SDK propagate OpenTelemetry Collector Google Cloud Exporter Tracing SDK propagate :4317 :4318 Trace Data
13. 13 コンテナの監視
14. 14 コンテナの監視: Cloud Run コンテナの監視 メトリクス・ログ・トレース を集めて、できる限り詳細を 把握する Google Front End Google Cloud Zone Cloud Run Container Instance Ingress container Cloud Load Balancing HTTP Proxy Global External HTTP LB sidecar containers sidecar containers sidecar containers *.run.app Custom Domain Shared volume Control Plane(Cloud Run APIs) コントロールプレーンの監視 可用性などの信頼性の管理は Google Cloud に任せて、 デプロイや利用状況を可視化 データプレーンの監視 スケーリングに必要なリソー スの使用状況のみを確認する
15. まとめ • Cloud Run はコンテナ環境特有のコントロールプレーンやデータプレーンなどの基盤を 意識せずにフルマネージドでコンテナや関数を実行できるコンピューティングサービス • アーキテクチャを正しく理解することで、どこまでを Google Cloud に任せて、 どこからがユーザー自身が詳細に監視をする必要があるかがわかる • 特に、コンテナ上で実行されるアプリケーションの挙動はトレースで確認するのが有効 • Cloud Run のだいたいぜんぶの監視方法はそれぞれブログにまとめています！ メトリクス ログ トレース 15
16. Thank you! 16
17. 17 Appendix
18. 18 Autopilot モード ワーカーノードの管理を Google Cloud に委任できる。 ノードの自動スケールや作成/削除 ・OS 管理を行う必要がないが、アク セスができない。 Cloud Run(参考) ノードを意識することなく、アプリケー ションコンテナをデプロイしホスティン グできる。 サイドカー機能によりマルチコンテナ の起動も可能。 Standard モード ノード配置やレプリカの選択肢として シングル・マルチゾーンやリージョンク ラスターがある。 基盤となる GCE ノードに直接アクセ スできる。 GKE の概要 Google Cloud のマネージド Kubernetes サービス GKE の仕組み Google Compute Engine(GCE) を利用した Node でクラスターを形成する。Standard モードはコント ロールプレーンを Google Cloud が管理し、Autopilot モードはワーカーノードの管理も行う GKE の特徴 コントロールプレーンやワーカーノードの管理を委任できるため、コンテナ上のアプリケーションや プロセスの監視に注力できる