はじめに
Google Cloud Next '23 現地参加組の田中孝明です。
Google Cloud Next はクラスメソッドからは初参加らしいので現地の雰囲気も合わせてお伝えできればと思います。
お知らせ
9/4(月) 帰国後すぐにクラスメソッド日比谷オフィスにて recap イベント開催します。ビアバッシュ交えながら現地の熱狂をお伝えできればと思いますので是非ご参加お願いします。
セッション概要
コンテナーは最新のアプリケーションの中心であり、その採用は急速に増加し続けています。Google Cloud のマネージド コンテナ プラットフォームである Cloud Run と GKE を使用すると、開発プロセスを高速化し、セキュリティ体制を向上させることができます。このセッションでは、Etsy が Cloud Run と GKE のデプロイメント パスを活用して、チームがサービスの提供と拡張方法ではなくビジネス ロジックに集中できるようにする方法を学びます。
セッション動画
セッション内容
Cloud Run は、コンテナーをすべて稼働させるための迅速な方法。
これから説明する点は Cloud Run から GKE、または GKE から Cloud Run への移行が簡単であるかを話す。
過去60日間で、Kubernetes の歴史の中で主要なクラウドベンダーの多くが行った以上の貢献を Kubernetes に対して行ってきた。
我々の仕事は Kubernetes から難しい部分を取り除くこと。
クラスターが増えるほど管理が難しくなっていく。
基調講演で発表された GKE Enterprise について。
フリートの構築、可観測性の構築、セキュリティの構築、コンプライアンスの構築、マルチクラスター管理を複数チーム間での速度を向上させる。
これらは GKE と Anthos の長所を統合している。
2019 年にクラウドに移行する前は、Et Sy's は主にデータセンターにある php モノリスを利用していた。彼らは何を構築できるかについて、技術的にもハードウェア的にも制約を受けていた。
複数のサービスが絡み合っており帰属も曖昧だった。
最終的にチームでビジョンを策定し、サービスの作成をサービスが処理するインフラストラクチャから切り離すことにした。そしてアーキテクチャの標準とガードレールを導入した。
サービスプラットフォームを成功させ、開発者エクスペリエンスを強化して開発者の作業を容易にすることは明白ではあるが、より深く考える必要があった。
エンジニアリング組織全体がこのプラットフォームの潜在的な市場であることを認識し、サービスプラットフォームが提供できる価値を迅速に反復できるようにしたいと考えていた。
Google または他のプロバイダーによる最高レベルのサービスを使用する必要があることを最初から知っていた。
ビジョンや顧客が実際に必要としているものに忠実であり続けるために彼らがとった3つのステップ。
第一に与えられたビジョンを確認するために、ビジョンを作成したメンバーと毎週会って確認した。
第二に顧客が実際に必要としているものに忠実であること。
最後の非常に柔軟で適応性のあるロードマップ戦略を用いた。
プロトコルでは gRPC を標準化し、シリアル化形式に protobuf を使用した。
Google サービスは、プラットフォームのこれらのコンポーネントで重要な役割を果たした。
サービスプラットフォームは、一貫した CLI インターフェイスを提供する他のツールのラッパー。
新しいサービスを作成したり、すでに作成されたサービスを操作したりするための一般的なタスクが提供する。
サポートされているサービス言語ごとに、ランナーと呼ばれる小さなフレームワークを提供する。
バックステージにはサポートされている各クライアント言語のクライアントが含まれている。
サービスカタログには、サービスディスカバリ、認証などが含まれている。
サービスのサービスカタログページはサービスのハブとなるため、利用者はサービスを参照したり、さらに情報が必要な場合に参照する。
VPCコネクタに関する課題にぶつかった。
立ち上げたサービスにつなげるために、いくつか専用のVPCコネクタを用意する必要ができた。
Cloud Run の Sidecar 対応がアルファ版かプライベートプレビューの時に試した。
テレメトリ、ロギング、可観測性において OpenTelemetry を利用している。
コードの横でエージェントを実行すること。
言語に関係なく共通の機能を提供する、エントリーポイントという名前のプロキシを実行する。
Google および、社内の GKEチーム と協力して従来の GKEプラットフォーム でも動作するようにサービスプラットフォームを拡張していった。
フルマネージド環境で大規模なコンテナ化されたアプリをデプロイする話をします。Cloud Run と GKE を一緒に利用できることを伝えます。
移植性について、同じソフトウェアデプロイメントアーティファクトである oci コンテナイメージをサポートする Cloud Run と GKE によって有効になる。同じイメージを両方で実行できる。
ファイルの差分もごくわずか。
一貫した管理の面で Cloud Deploy という製品がある。
これにより Cloud Run 環境と GKE 環境の両方に展開できるようになる。
必要に応じて kubectl を実行してサービスを管理できる。
可観測性に関しては Cloud Logging へのログのサポートがある。 Cloud Monitoring ダッシュボードで Cloud Run と GKE の指標を観測できる。
セキュリティに関しても Workload Identity でサービスを実行できる権限を最小の権限にできる。
脆弱性に関してもコンテナをスキャンして結果を見れる。
Binary Authorization でデプロイするか決めることができる。
それら全て VPC の範囲内に配置できる。
ネットワークに関してもグローバルまたはリージョナルの Load Balancing を使用すると Cloud Run のエンドポイントと GKE のエンドポイントにサービスを提供できる。
それら全て VPC の範囲内に配置できる。
必要に応じて後から行き来できるので、自動スケーリングサービス、パッチジョブが要件の場合は Cloud Run から始めることをお勧めする。
所感
Cloud Run / GKE のアップデート内容よりも、アプリケーションを作る上で最初のどれを選択したほうがいいのか伝えているセッションでした。Duet AI のサポートによっては今後移行の障壁も減ってくることが期待できそうです。
9
