Google Cloud Next Tokyo '24に参加しました〜ハンズオン編〜

はじめに

こんにちは! NILTOチームでインフラエンジニアをしている太田です。

2024年8月1日(木)と2日(金)の2日間、パシフィコ横浜ノースにて開催された、Google Cloud Next Tokyo '24に参加してきました。

会場では、カテゴリごとに分かれた多数のセッションが聴講できるほか、Innovators Hive・Expoといった展示ブース、認定資格者ラウンジといったコミュニケーションのスペースなど、さまざまな催しものが楽しめました。

今年のGoogle Cloud Next Tokyoでは、個人的にこれから深掘りしたいテーマである「プラットフォームエンジニアリング」に焦点を当てて、参加するセッションを選びました。

その中でも本記事では、参加した「基礎から学ぶPlatform Engineering」というハンズオンセッションについて、レポートします。 このセッションは、GKE EnterpriseとCloud Workstationsを利用して、Google Cloudでのプラットフォームエンジニアリングを実践するものでした。

ハンズオン:基礎から学ぶPlatform Engineering

ここからは、実際にハンズオンセッションでやったことを紹介します。 なお、ハンズオンで使用したソースコードや、手順の記載されたチュートリアルがGitHubで公開されているので、詳細に踏み込みたい方はこちらを見ると参考になりそうです。

ハンズオンの作業はteachmeコマンド1によって表示されるチュートリアルを見ながら進める形式でした。 コンソールとチュートリアルを見比べながら作業できますし、Cloud Shellに直接コマンドを貼り付ける機能もあったりして便利でした。 なお、チュートリアルの作り方もドキュメントがあります。 コマンドを使った作業手順の作成などにも使えそうですね。

ハンズオンの準備

GKEやCloud Workstationsのクラスタ作成には時間がかかるため、早速ハンズオンの作業から開始でした。

gcloud CLIのプロジェクト・リージョン・ゾーンの設定および必要なGoogle Cloud APIの有効化を行った後、実際のリソースを作成しました。 この段階では、VPC・サブネット・Cloud NATなどのネットワーク関連リソースと、GKEクラスタ・Cloud Workstationsクラスタを作成しました。

プラットフォームエンジニアリングとは

クラスタの作成を待つ間、プラットフォームエンジニアリングの概要と、GKE Enterpriseでのマルチテナント管理について、スライドでの解説がありました。

プラットフォームエンジニアリングとは、アプリ開発者を開発に集中してもらい、開発チームの生産性を高めるために、アプリ開発者がセルフサービスで利用できる開発基盤となるインフラストラクチャ2を構築・運用していくアプローチのことをいいます。 複雑なインフラストラクチャの詳細を抽象化し、そのユーザーインタフェース3をアプリ開発者に提供することで、アプリ開発者の生産性向上を図ります。 それと同時に、インフラストラクチャ運用における反復作業を自動化4することで、ソフトウェア開発全体を合理化することがプラットフォームエンジニアリングの目的です。

プラットフォームエンジニアリングとは
プラットフォームエンジニアリングとは

セッションでは、上記のようなプラットフォームをシンプルに構築することを可能にする、GKE Enterpriseを利用したマルチテナント構成についての解説があり、その後ハンズオンの続きに移っていきました。

GKE Enterprise を利用したマルチテナント構成

GKE Enterpriseでは、複数のクラスタ上で複数のチームがアプリケーションを開発・運用していくための、さまざまなサービスが提供されています。

例えば、今回ハンズオンで利用したチーム管理の機能を使うと、クラスタ内にチームごとの名前空間を作成した上でアプリがデプロイできるため、本番環境と開発環境の分離、リージョンの分離など実行環境を分離しつつ、複数チームでのクラスタ共有が実現できます。

複数のGKEクラスターで、複数のチームを管理する
複数のGKEクラスターで、複数のチームを管理する

ハンズオンでは、以下の流れで作業をしていきました。

  • GKE Enterpriseの有効化
  • フリートの作成
  • クラスタのフリートへの登録
  • チームスコープの作成
  • クラスタのチームスコープへの登録
  • 名前空間の追加
  • チームスコープ内の名前空間へのアプリケーションのデプロイ
  • デプロイしたアプリケーションの動作確認
  • Fleet Loggingの設定
  • Advanced Vulnerability Insightsの有効化

一通り設定が完了した後は、デプロイしたアプリケーションと、作成したチームに関係するログ・モニタリング・セキュリティダッシュボードを一通り確認しました。 チーム単位で必要な情報がダッシュボードにまとめられるので、たくさんのアプリ開発プロジェクトがある場合に便利だなと感じました。

第一部はここまでで、休憩タイムに入りました。

Cloud Workstations による開発環境のカスタマイズ

第二部は、Cloud Workstationsを使って、開発〜デプロイまでの流れを追っていきます。

Cloud Workstationsは、マネージドなリモート開発環境です。 チーム間で一貫した設定を共有しつつ、開発者がどこからでもアクセスできる開発環境を提供します。

プラットフォームエンジニアとしての役割は、Cloud Workstations用のコンテナイメージおよび関連リソースを作成・管理し、アプリケーション開発者にWorkstationsを提供することです。 また、アプリケーションの容易なデプロイを可能にするための、CI/CDパイプラインの整備も担当します。

Cloud Workstationsを活用したプラットフォームエンジニアリング
Cloud Workstationsを活用したプラットフォームエンジニアリング

作業は以下の流れで行いました。

  • Artifact Registryの作成
  • Cloud Workstationsコンテナイメージの作成
  • Cloud WorkstationsイメージPull用サービスアカウントの設定
  • Cloud Workstations構成の作成
  • Workstationsの作成
  • CI/CDパイプラインの準備

ここまでがプラットフォームエンジニアとしての作業となります。 ここからはアプリケーション開発者として、実際にWorkstationsを利用したアプリの実行・デプロイの作業でした。

  • サンプルアプリケーションの入手
  • アプリケーションのローカル実行
  • GKE(ステージング環境)へのアプリケーションのデプロイ
  • GKE(ステージング環境)でのアプリケーションの実行
  • Cloud Deployでの本番環境へのプロモート

ハンズオンは以上で完了でした。

製品(プロダクト)としてのプラットフォーム

プラットフォームエンジニアリングを発展させた概念として、Platform as a Productがあります。

Platform as a Productでは、アプリケーション開発者に提供するプラットフォームを製品(プロダクト)としてとらえます。また、アプリケーション開発者を、製品を利用するユーザーとしてとらえます。 その上で、製品開発と同じように、以下のサイクルを回していきます。

  • ユーザーのニーズを調査する
  • ユーザーにとって価値のある機能を開発する
  • ユーザーからのフィードバックを収集して、継続的な改善を図る

このサイクルを繰り返すことにより、アプリケーションの開発チームにとってより使いやすく、価値のあるプラットフォームを目指して改善していきます。

プラットフォームを製品(プロダクト)としてとらえる
プラットフォームを製品(プロダクト)としてとらえる

ハンズオンの第二部冒頭では、Platform as a Productのアプローチによるプラットフォーム開発の簡単な解説と、実際にユーザーストーリーを書いてみるワークもありました。

おわりに

イベント全体では生成AIの話題が多かったのですが、今回のGoogle Cloud Next Tokyo '24の参加にあたり、個人的なメインテーマは「GKEとプラットフォームエンジニアリング」でした。 特に、ハンズオンのセッションを思い出しながらこの記事を書いている時に、掲げたテーマに沿った多くの学びがあったなと、改めて感じました。

また、記事では触れていませんでしたが、Jagu'e'r(Japan Google Cloud User Group for Enterprise)という公式ユーザー会での交流の機会もあり、技術コミュニティでの活動の楽しさも感じたイベントでした。

Jagu'e'rのブースでいただいた入浴剤
Jagu'e'rのブースでいただいた入浴剤

次回のGoogle Cloud Next Tokyoは、1年後の2025年8月5日〜6日に、東京ビッグサイトで開催されるとのことなので、ぜひまた参加したいです。


  1. 実際には、cloudshell launch-tutorialコマンドのエイリアスになっています。
  2. Internal Developer Platform / Internal Developer Portal、略してIDPと呼ばれる基盤を構築します。
  3. ここでいうユーザーインタフェースは単に操作画面だけでなく、アプリケーションテンプレートとしてのパッケージや、そのドキュメントも含みます。
  4. IaC(Infrastructure as Code)の適用・CI/CD基盤の構築・モニタリングおよびセキュリティのコード化など