CX新規事業開発本部 リニューアル開発部 共通基盤チームの鈴木です。
先日、Google Cloud が主催する「Platform Engineering Jump Start」に参加してきました。
この記事ではプログラムを通じて得た学びについてまとめます。
Platform Engineering Jump Start は、Google Cloudがプラットフォームエンジニアリングの導入を検討している企業に対して提供しているプログラムです。
Google Cloudでは、こちらのブログにあるように、プラットフォームエンジニアリングを「組織において有用な抽象化を行い、セルフサービス インフラストラクチャを構築するアプローチ」と考えています。このプラットフォームを導入する方法について、座学やハンズオンを通して学ぶものになっています。今回のプログラムでは下記動画で講演されている関本さんが講師を務めてくださいました。
1日目
1日目は座学を通じてプラットフォームエンジニアリングの基本的な概念について学びました。
その後、インセプションデッキ構築を通して、自社の課題・優先順位・やらないことについて議論しました。
最後に GKE と Cloud Run の比較を行い、どちらが自分たちのプロダクトに適しているかの議論をしました。
プラットフォームエンジニアリングとは
学び
- プラットフォームエンジニアリングは開発者の生産性を向上させる。
- SRE との違いは、SRE は信頼性、プラットフォームエンジニアリングは生産性にフォーカスしている。
- 厳選した体験を提供し、プラットフォームをプロダクトとして提供し、進化できるようにする。
- ゴールデンパス：プラットフォームが開発者のロケットスタートのために用意するもの。
- CI/CD
- テンプレートの提供
- セルフサービス UX
- ガバナンスガードレール：ユーザーが考慮しなくても規定のセキュリティなどが満たされる。
インセプションデッキ構築
インセプションデッキとは、プロジェクトの目的や方向性を明確にするためのフレームワークです。チームで考えたインセプションデッキは以下になります。
全員で議論することで、プラットフォームを作る目的と優先順位について、チームで共有することができました。
我々はなぜここにいるのか
エンタープライズ向けのお客様に高品質かつ低コストでプロダクトを提供する
エレベーターピッチ
これは1万人以上のユーザーにも安定した品質のプロダクトを提供できるプラットフォームです。
開発、リリース、運用の一部をプラットフォームが担保することで品質向上と開発速度の効率化につながります。
さらに、重複する開発作業や運用コストが削減されるため、全体的なコストダウンにもつながります。
やらないことリスト
- 海外展開
- 多言語化対応（英語以外）
トレードオフスライダー
トレードオフスライダーとは、プロジェクトにおいて優先すべき項目を明確にするためのツールです。私たちは以下の優先順位を設定しました。
- 品質
- 機能を全部揃える
- リリース期日を遵守する
- 予算内におさめる
GKE と Cloud Run の比較
GKE と Cloud Run には以下のメリットがあります。
GKE のメリット
- Kubernetes エコシステムの活用: Argo CD などの Kubernetes ネイティブツールをシームレスに統合できます。これにより、GitOps ベースのデプロイフローを実現し、構成の一貫性と監査可能性を確保できます。
- ステートフルワークロードのサポート: 永続ボリュームを使用したステートフルアプリケーションの実行が可能です。
- マイクロサービス間通信の最適化: クラスター内部でのサービス間通信を閉じることができるため、外部ネットワークを経由せずに低レイテンシの通信が可能です。
- 詳細なリソース制御: CPU、メモリ、ストレージなどのリソース割り当てを細かく制御できます。リソース要求と制限を設定することで、アプリケーションの安定性を確保できます。
- 高度なネットワーク機能: マルチゲートウェイ構成によるフェイルオーバーが可能で、トラフィックの冗長性と高可用性を確保できます。また、ネットワークポリシーを使用して、きめ細かいセキュリティ制御を実装できます。
- BFF (Backend For Frontend) パターンの実装: フロントエンドごとに最適化されたバックエンドサービスを同一クラスター内に配置できるため、BFF パターンをシンプルに構成できます。
Cloud Run のメリット
- 運用オーバーヘッドの削減: クラスター管理が不要で、インフラストラクチャのプロビジョニングや管理を Google Cloud が担当します。これにより、アプリケーション開発に集中できます。
- コスト効率: 従量課金制（100ミリ秒単位）で、使用したリソースに対してのみ課金されます。トラフィックがない場合はゼロインスタンスまでスケールダウンするため、コストを最小限に抑えられます。
- 自動スケーリング: トラフィックの変動に応じて自動的にスケールアップ・ダウンするため、突発的な負荷にも対応できます。手動での介入なしにスケーリングが行われます。
- 迅速なデプロイ: ソースコードまたはコンテナイメージを提供するだけで、数秒でデプロイが完了します。CI/CD パイプラインとの統合も容易です。
- イベントドリブンアーキテクチャとの親和性: Pub/Sub、Cloud Storage などのイベントソースと連携しやすく、イベントドリブンなアプリケーションの構築に適しています。
GKE (Autopilot) を選択した技術的理由
今回のプロジェクトでは、以下の理由から GKE (Autopilot) を採用しました：
-
複雑なマイクロサービスアーキテクチャ: 開発予定のアプリケーションは複数のマイクロサービスで構成され、サービス間の通信が頻繁に発生します。GKE のクラスター内通信により、レイテンシを最小限に抑えられます。
-
高度なトラフィック管理: Gateway API を使用したきめ細かいトラフィックルーティングと、複数のゲートウェイによる冗長構成が必要です。GKE では Gateway API を活用して、高度なトラフィック制御とフェイルオーバーメカニズムを実装できます。
-
一貫した開発・運用環境: 開発環境から本番環境まで一貫した Kubernetes 環境を提供し、Argo CD と Kustomize を活用した GitOps アプローチにより、環境間の構成ドリフトを防止します。Git リポジトリを単一の信頼源として、Kustomize のオーバーレイ機能で環境固有の設定を効率的に管理できるため、デプロイの再現性と信頼性が向上します。
-
運用負荷の軽減: GKE Autopilot は、GKE Standard と比較して、ノードプロビジョニング、クラスターサイジング、セキュリティパッチ適用などの運用タスクを自動化します。これにより、インフラ管理の工数を削減し、アプリケーション開発に集中できます。
これらの比較検討の結果、2日目以降のプロトタイプ作成では GKE (Autopilot) と Argo CD を使用した CI/CD に決定しました。
2日目
2日目は Cloud Workstations を使いながら、プロトタイプの作成を行いました。
Cloud Workstations
Cloud Workstations は Google Cloud 上のマネージドな開発環境です。
個人的には以下の2点が特に有用な機能だと感じました。
- Workstations から VPC 内のリソースに直接アクセスできる。
- Workstations 内で起動させたサーバーを特定のユーザーのみに限定公開できる。
プロトタイプ作成（GKE、GitHub Actions、Argo CD の構築）
プロトタイプの GKE を使用した CI/CD は下図のような流れになりました。
- 開発者が Cloud Workstations 内で書いたコードをリモートリポジトリに push する。
- GitHub Actions を使い、push をトリガーとして Docker image を build し、コミットハッシュ値をタグとして Artifact Registry に image を push する。
- 開発者がアプリケーションのマニフェストの image のタグを変更する。
- Argo CD 上から Sync を行い、新しい image のアプリケーションをデプロイする。
上記のために以下の作業をチーム内の人に分担しながらも、全作業を全員で確認しながら行いました。
Kubernetes や Google Cloud をあまり触ったことがない人もいたので、全ての流れを全員で確認しながら行ったことは非常に有益でした。
- GKE クラスターの作成
- Artifact Registry の設定
- GitHub Actions 用のサービスアカウントの作成
- GitHub Actions ワークフローの作成
- サンプルコードの作成と Docker imageの push
- Argo CD を GKE 上にデプロイ
3日目
3日目はプロトタイプ作成で実際に Argo CD 上から新しいアプリケーションをデプロイすることを行いました。
また、RBAC と Gateway について Kubernetes における基本的なことから、GKE 固有の機能に関してなど丁寧に解説していただきました。
プロトタイプ作成（実際に Argo CD を使って新しい image のデプロイ）
2日目までの作業では、アプリケーションコードの作成と最初の Docker image のビルド、Artifact Registry への push までを完了していました。
3日目には、まずアプリケーションのマニフェストを作成し、2日目に push した Docker image を使って直接 kubectl コマンドでデプロイを行いました。これにより、Kubernetes の基本的なデプロイフローを体験することができました。
その後、アプリケーションコードに修正を加え、新しい Docker image を Artifact Registry に push しました。この新しい image については、マニフェストのタグを更新した後、Argo CD を通じてデプロイを行いました。
私は Argo CD を実際には触ったことがなかったので、Sync ボタンを押すだけで新しいアプリケーションが簡単にデプロイできる効率性に非常に感銘を受けました。従来の kubectl による手動デプロイと比較して、GitOps アプローチによる変更の追跡性と再現性の高さを実感することができました。
GKE 各論（RBAC・Gateway）
GKE 各論では特に RBAC と Gateway にフォーカスして解説していただきました。
RBAC パートでは Kubernetes における認証・認可・RBAC について学びました。また GKE における RBAC の原則や Google Group を用いた管理、Workload Identity を使った Google Cloud リソースへのアクセスについても学びました。
Gateway パートでは Ingress との違いを中心に、Gateway でできることについて学びました。Gateway の実態とルーティング設定の HTTP Route のリソースが分かれています。そのため、アプリケーション開発者側で HTTP Route を設定するだけで、ルーティングの設定ができます。また、Gateway リソースへの影響がないことが大きなメリットだと感じました。
今回のハンズオンで得た知識とスキルは、実際の業務環境でも直接活用できるものでした。特に以下の点で実践的な価値を感じています：
1. クラウドネイティブアーキテクチャの設計力向上
GKE と Cloud Run の比較検討を通じて、ワークロードの特性に応じた最適なサービス選択の判断基準について理解を深めることができました。この知識は、今後担当するプロジェクトでのアーキテクチャ設計において、コスト効率と運用効率のバランスを考慮した意思決定に役立てられると考えています。
2. GitOps による開発者体験の向上
Argo CD と Kustomize を活用した GitOps の実装方法を学んだことで、新規プロダクト開発における効率的なデプロイパイプラインの構築イメージが明確になりました。GitOps の導入により、開発者がインフラストラクチャの詳細を気にすることなくコードの変更に集中でき、環境間の一貫性が保証されることで、デバッグの容易さや変更の追跡性が向上します。これは新規プロダクト開発において、開発チーム全体の生産性と品質向上に直結する価値があります。
3. マイクロサービスの効率的な設計と運用
マイクロサービスアーキテクチャを最初から適切に設計・構築するための知識を得られたことは、新規プロダクト開発において非常に価値があります。特にサービス間通信の最適化やリソース分離の考え方は、スケーラブルで保守性の高いシステム構築に不可欠な視点です。また、Kubernetes を活用したマイクロサービスの効率的なデプロイと運用管理の手法は、新規プロダクトを長期的に安定して提供するための基盤となります。
今後は、このハンズオンで構築したプロトタイプをベースに、自社の開発環境に適した Kubernetes 基盤の構築を進め、開発チーム全体のクラウドネイティブスキル向上にも貢献していきたいと考えています。
今後私たちが取り組むことは次の通りです。
- プロダクトの年内のリリース
現在のプロトタイプを本番環境に適用し、年内にリリースを目指します。 - プラットフォームの実運用と導入による効果測定
開発速度の向上、運用コストの削減、品質向上などの指標を設定し、効果を測定します。 - 社内にプラットフォームエンジニアリングを広める
今回の学びを社内勉強会などで共有し、他チームへの展開を検討します。
「Platform Engineering Jump Start」を通して、参加した全員でプラットフォームエンジニアリングに対する共通認識を持つことができました。プラットフォームエンジニアリングは単なる技術的な取り組みではなく、開発者体験を向上させ、組織全体の生産性を高めるための重要なアプローチであることを学びました。
また実際にプロトタイプの作成を通じて、GKE・Argo CD の構築や使い方を学び、今後の開発体験を共有することもできました。特に CI/CD パイプラインの自動化や、Kubernetes のエコシステムを活用した開発フローの効率化は、今後の開発において大きな価値をもたらすと確信しています。
このプログラムで学んだことをチームだけでなく、社内全体に浸透させていきたいと思います。
最後に、このような貴重な機会を作ってくださった Google Cloud のみなさま、本当にありがとうございました。
Views: 0
