はじめに
Google Cloud Next '23 現地参加組の田中孝明です。
Google Cloud Next はクラスメソッドからは初参加らしいので現地の雰囲気も合わせてお伝えできればと思います。
お知らせ
9/4(月) 帰国後すぐにクラスメソッド日比谷オフィスにて recap イベント開催します。ビアバッシュ交えながら現地の熱狂をお伝えできればと思いますので是非ご参加お願いします。
セッション概要
Cloud Run のサイドカーを使用すると、ユーザーは Cloud Run のメイン コンテナと一緒に追加のワークロードを実行できます。サイドカー コンテナは、OpenTelemetry または Prometheus 用の Google Cloud マネージド サービスを使用する場合に、カスタム トレース、モニタリング、ロギングなどの機能を提供できます。Envoy、クライアント プロキシ、または認証サイドカーを追加することで、アプリの機能を拡張して、ネットワーク、セキュリティ、高度なルーティングを向上させることもできます。このセッションに参加して、Nasdaq がアプリケーションと一緒に Envoy サイドカーをホストすることで、この機能がコードのリファクタリングを大幅に削減するのにどのように役立ったかを学びましょう。
セッション動画
セッション内容
Cloud Run はコンテナ化されたアプリケーションをサーバーレスで実行するためのフルマネージドプラットフォーム。
ユースケースとしてはユーザーが REST や Graph QL などのサービスを公開すること、WebSocket によるストリーミング、プライベートサービスでプライベートネットワーク内に相互に通信すること、最後にキューメッセージの処理を含むデータ処理パイプラインの実行などが含まれる。
Cloud Run にはサービスとジョブがある。
サービスには従量課金性のリクエストごとの支払いなど複数の価格オプションがある。
ジョブは HTTP リクエストでトリガーされることはなく、手動または自動スケジュールによって完了するまで実行される一連のコンテナです。
Cloud Run は現在、200以上の国と地域を含む38のすべてのリージョンと数百のチームで利用できる。
Cloud Run は Sidecar をサポートしており、独立したコンテナをメインのサービス提供コンテナと並行して実行できる。
Cloud Run の Sidecar はいくつか重量な機能がある。
Sidecar は一つだけではなく、最大で10個ある。
複数のコンテナ間でメモリボリュームを共有することで、Sidecar とプライマリアプリケーションがより多くの作業を連携できるようになる。
個々のコンテナに対して、 Kuberbetes スタイルのヘルスチェックを構成することで効率が向上する。
古典的な Sidecar の使用例は監視する2番目のコンテナを追加することです。
OpenTelemetry Sidecar をデプロイして、Prometheus マネージドサービスに指標を書き込み、Cloud Monitoring ですべてのランタイムで同じ指標を取得する。
問題を明確に分離することができ、コンテナ自体のパフォーマンスを向上させる。
Nginx や Envoy など高度なプロキシインフラストラクチャで、アプリケーションに複雑なロジックを入れる必要もなくなる。
Envoy には高度なネットワーク機能がある。このパターンは独自の Service Mesh を Cloud Run に持ち込むことができる。
データベースクライアントプロキシを使用して接続を認証し、Sidecar にプールしている。これによりバックエンドのデータベース負荷は軽減される。
利点としてはデータベースが実際にどこに存在するかを気にする必要がなくなる。ローカルテスト環境ではテストのためにローカル接続を使用できる。実環境の Cloud Run では同じ接続文字列が利用される。
IAMベース認証などの高度な認証機能も利用できる。
現在 Cloud SQL と AlloyDB のデータベースクライアントプロキシを提供している。
２つの Sidecar を連携させることもできる。Open Policy Agent の長所と Envoy の長所を連携して動作することができる。
Cloud Run と GKE の両方が実行できるワークロードのセットを拡張します。構成ファイルの変更点もごくわずかであることがわかります。
ナスダック は Google Cloud の顧客であり、顧客が持続可能性のパフォーマンスを効率的に監視し、報告できるよう支援することに尽力している。
2022年、ナスダックは企業が環境パフォーマンスを報告できるプラットフォームである Metrio を買収した。
Metrio は別のクラウドベンダーの VM上 で稼働していた Ruby on Rails 環境を Google Cloud に移行した。
古いアーキテクチャは全てが同じマシン上に配置されていたため拡張することが困難であった。
Cloud Run への移行
Metrio は顧客ごとに 6 つのクラウド サービスを使用しており、現在 800 を超えるクラウドオンサービスが実稼働環境で実行されている。
Envoy を Sidecar でデプロイすることでコードのリファクタリングを回避し、サービスを更新することができた。
将来的には Metrio は Sidecar を利用して金融サービスの厳格なコンプラインアンス基準を遵守しながら GKEワークロード と Cloud Run 間の通信を保護する予定。
OpenTelemetry を使用する予定で、中間ホップなしに Cloud Trace に直接送信できるため、SLOおよびSLIサポートが最適に実装できる。
Cloud Run を使用することでマイクロサービス管理の簡素化、拡張性の向上、スケーラビリティなどの様々なメリットを享受できた。
所感
Cloud Run でGAになった Sidecar について、利用例を交えながらナスダックでのコンテナ化の取り組みが話されるなど、この辺りの移行を考える時に参考になりそうな話が聞けました。
9
