こんにちは。技術本部Strategic Products Engineering Unit SREグループの辻田です。先日、Google Cloudさんが主催する「Platform Engineering Jump Start」に参加してきました。
このプログラムを通じて得た学びと、今後のアクションについてまとめます。
1日目
Google Cloudさんのオフィスに到着すると、まずはおいしいコーヒーとクッキーがお出迎えしてくれました。なんというホスピタリティでしょう。ありがたくいただいた後、プログラムの開始です。
初日は、座学を通じてPlatform Engineeringの基本的なコンセプトを学びました。その後、実際にプラットフォームの利用者ペルソナを作成し、ユーザーストーリーを考えるワークショップに取り組みました。
学び
- DevOps導入によるメリットデメリット: Devと運用のプロセスを統合することでマーケット投入への速度を上げられるが、DevOpsチームはセキュリティ、サービスメッシュ、CI/CDなど幅広い知識が必要になってしまいました。DevOpsのデメリットを解消するものがPlatform Engineeringです。
- プラットフォームもプロダクトとして扱う: プラットフォームをプロダクトの1つとして考え、その管理にはプロダクトマネージャーの存在が重要だと感じました。
- ユーザーニーズに基づく設計: 開発者のニーズを的確に捉えたプラットフォーム設計が求められています。ユーザーからのフィードバックを収集するために、アンケートやフィードバックチャンネルを活用することが大切です。
- 定量・定性的な指標の活用: 使用量やリードタイムといった定量的なデータに加え、アンケートなどで定性的なフィードバックも収集します。
- GKE Autopilotモード: Control Planeに加え、NodeもGoogle Cloudが管理します。セキュリティ、各種設定など本番ワークロードに適したベストプラクティスが適用されます。そのため利用者はワークロードに集中できます。PDB（PodDisruptionBudget）を適切に設定することで、ダウンタイムなしで自動クラスタアップデートが可能です。また、課金はPod単位で行われるため、利用リソースに即した課金へ最適化されます。PodやNamespaceごとのコスト分析もできます。
- GKE Extended Support: リリースチャンネルにはRapid, Regular, Stable, Extendedの4つがあります。Extendedではマイナーバージョンを最大24カ月間使用できます。
2日目
2日目はインセプションデッキの作成やアーキテクチャについてのディスカッションを行い、プロジェクトの方向性を固めました。また、翌日のプロトタイプ作成に向けてGKEとCloud Runを比較し、GKEを採用することを決定しました。
学び
- インセプションデッキのすすめ: プロジェクトの意義やエレベーターピッチ、スコープの明確化が重要で、これらをしっかり言語化することでプロジェクトの方向性を共有しやすくなります。
- Cloud Workstationsの活用: マネージドな開発環境を提供するサービスです。管理者は全体の開発環境を管理でき、セキュリティポリシーや利用ツールの一括管理が可能です。開発者は環境構築に時間をかけることなく、オンデマンドですぐに開発を始められます。VS CodeやIntelliJ IDEAなどのIDE（DataGripは対象外。ベースイメージのリストはこちら。）を利用できます。ただし、日本では東京リージョンのみで提供されており、大阪などでの使用は、JetBrains GatewayやGemini Code Assistとの組み合わせで重くなる可能性があるため注意が必要です。
- 共有VPCの利点: 複数プロジェクトでVPCピアリングを行う際、共有VPCを使用することでシンプルかつ管理しやすい環境を構築できます。
インセプションデッキ
考えてみたインセプションデッキはこちらです。もう少し独自性のある内容で練り直したいですが、大まかな方向性が明確になったので良かったです。
われわれはなぜここにいるのか
私たちは、開発者が本質的な課題に集中できるように、Platformを構築しています。
- 開発者のために: リードタイムを短縮し、エンドユーザーに価値を早く届けることを目指しています。また、価値検証のイテレーションを迅速に回し、早くPMFを達成することが目的です。繰り返し作業を自動化することで、生産性を向上させます。
- 品質の向上: メトリクスや監視環境を事前に整備し、統一された品質基準を確立します。
エレベーターピッチ
私たちのPlatformは、エンドユーザーへの価値提供を加速し、開発者の生産性を向上させます。リードタイムの短縮、繰り返し作業の自動化、そして品質基準の統一化を通じて、開発プロセスを革新します。
プロジェクトのスコープ
- やること:
- コンテナ基盤の提供
- CI/CDの導入サポート
- アプリケーションテンプレートとオブザーバビリティの仕組みの提供
- やらないこと:
- 製品機能の開発やGKE以外のインフラ構築
GKEとCloud Runの比較
抽象度と柔軟性のトレードオフでは、Cloud Runが抽象度が高く、GKEが柔軟性が高いという特徴があります。
GKEの特徴
- マネージドなKubernetesサービス
- Kubernetesの知識が必要
- Kubernetesのエコシステムを活用できる
- Autopilotモードで運用の簡略化、コスト最適化が可能
- Podに関連するLoadBalancerなどのリソースをマニフェストにまとめて管理できる
Cloud Runの特徴
- サーバーレスなコンテナ実行環境
- 高速に0 to Nスケールが可能
- コンテナのスペックや実行時間に制限がある
- コンテナに関連するLoadBalancerやNEGなどのリソースを別途管理する必要がある
上記のようにそれぞれメリット・デメリットがありますが、
- Argo CDやArgo RolloutsなどのKubernetesエコシステムを活用したい
- AutopilotモードではGKEの良いところを残しつつ、運用負荷の削減、コスト最適化、セキュリティの向上が実現されている
- Kubernetesの学習コストに抵抗がない
という理由から、GKE（Autopilot mode）を採用することを決定しました。
3日目
最終日は、プロトタイプを作成し、サンプルアプリをGKEにデプロイする実践的な作業に取り組みました。
Platform構築チームとPlatform利用チームに分かれて、プロトタイプを作成しました。担当した内容は次の通りです。
Platform構築チーム
- Cloud Workstationsの作成
- Artifact Registryにイメージの登録（Workstations用, Application用）
- Cloud Workstationsのカスタマイズ
- GKE Clusterの作成
- Argo CDインストール
Platform利用チーム
- Gitの準備
- 開発チーム向けGoogle Cloudプロジェクトの作成
- Cloud SQLの作成→サンプルのデータを登録
- 実際に利用しているアプリケーションのBuildpackでのコンテナ化（GAE, app.yaml）
- 事前に用意いただいたマニフェストのテンプレートの適用
学び
わたしはPlatform構築チームで作業をしていました。その中で得た学びは次の通りです。
- GKEのリリースチャンネル: コンソール上ではRegularが推奨されていますが、運用の安定性を重視するならStableを選ぶのがおすすめです。
- サービスアカウントの設定: 初回構築時に専用のサービスアカウントを作成して紐づけることがベストプラクティスです。サービスアカウントは初回のみ設定でき、後から変更はできません。
- オートスケール戦略: HPAのほかに、CA（Cluster Autoscaler）やNAP（Node Auto-provisioning）など、ニーズに応じた自動スケーリングが可能です。NAPではPodの要求するCPUやメモリ、GPU、Taintに基づいてノードプールを用意してくれます。他にも、Balloon Podという、優先度の低いダミーのPodを作成しておくことでノードのスケールを発生させずにPodをスケールさせるテクニックもあります。
- CWSの効率化: CWSのベースイメージは重いので、Kaniko cacheを有効にすることで、ビルド時間の短縮が期待できます。
- GKEとCWSの通信: Cloud Workstationsからkubectlコマンドなどを実行する際は、
Control plane authorized networksの設定でCWSのネットワークを許可する必要があります。 - ツールの管理: Argo CDなどのインストールはhelmfileで管理し、バージョンアップはrenovateなどのツールを活用すると便利です。
- ネットワーク設定の整理: 複雑なIAMやネットワーク設定を整理し、テンプレート化して管理することが求められます。また、共有VPCとService Networking APIの有効化により、プロダクト間の通信を効率化できます。
いざ手を動かすと、ネットワーク周りの設定や権限設定がたくさん必要なことが分かりました。
特にCWSとGKEが通信できてない問題を特定するのに時間がかかりました。Google Cloudのエンジニアの方々のサポートによって1時間もかからず解決できました。きっと自分たちだけで構築していたら半日以上かかっていたことでしょう。
いろいろと問題は発生しましたが、最終的にサンプルアプリをGKE上で動かせるようになりました。ただし、ウォークスルー的に開発者の立場で一連を試すことはできなかったため、帰ってからの宿題です。
今後のアクション
今後われわれが取り組むべきことは次の通りです。
- 権限やネットワーク周りの設定が予想以上に複雑だったため、テンプレートとスコープを見直す。
- プラットフォームの正式名称の決定。
- インセプションデッキを仕上げる。
- Cloud Workstationsでの本格的な開発体験を試す。
- Platformの実運用と継続的な改善。
まとめ
「Platform Engineering Jump Start」を通じて、プラットフォームの設計や運用における基本的な考え方やグッドプラクティスを学びました。また、Google Cloudの最新技術やサービスを活用することで、より効率的なプラットフォーム構築が可能であることを実感しました。
決めかねていたGKE VS Cloud Runについても全員が納得のいく形で決定でき、アーキテクチャの方向性が明確になったのは大きな成果でした。
今後の経過や成果についてもまたブログで共有しますので、お楽しみに！
最後に、Google Cloudのみなさま、本当にお世話になりました。貴重なお時間をありがとうございました！
p.s.
3日間どっぷりPlatform漬けだったので、六本木ヒルズの前にいるドラえもんたちがPodに見えました。
