はじめに
Ubieプラットフォームチームのonoteru(@teru0x1)です。4/9-11にかけて開催されたCloud Next'24に参加してきたので、イベントの様子や参加したセッション、そこから考えた今後のUbieに必要なクラウド施策についてレポートします。
Cloud Next'24
Google Cloudが毎年主催する一大イベントで、技術、製品、サービスに関する最新情報や、ユーザー企業による知見を共有する場です。去年は8月の終わりにサンフランシスコで開催されましたが、今年はそれから1年経たない内に初のラスベガス開催となりました。
Ubieからは自分と、プラットフォームチームのリーダーであるsakajun(@sakajunquality)が現地参加しました。sakajunはブレイクアウトセッションで2件登壇し、Ubie社内で最近実施したGKE Autopilotへのマルチクラスタマイグレーションや、Cloud Deployを用いたモダンな継続的デリバリーに関するセッションを行いました。
現地の様子
今回の会場となるラスベガスは別のカンファレンスで2年前にも訪れたことがありますが、当時はまだ建設途中だった巨大な球体施設である「Sphere」が鎮座していました。近くで見ると想像よりも遥かに大きくなかなかの迫力でした。
会場となるホテルにはセッションスペースの他にGoogle Cloudの提携企業・ユーザ企業のブースが多く並んでおり、普段Ubieでも活用しているFastlyやElasticのブースが見られました。企業ブースでは生成AIを組み合わせたソリューションを押し出している企業が多く、クラウド周辺領域の分野でも強く推進されてるのを感じました。
参加セッション
ブレイクアウトセッション
The future of platform engineering is application-centric
プラットフォームエンジニアリングという言葉は最近よく耳にするようになってきました。提唱者であるガートナーの言葉によると、「インフラオペレーションのセルフサービス機能を提供することで、開発者体験と生産性を向上させ、顧客に素早く価値提供できるようにするもの」がその定義とされています。よくSREやクラウドエンジニアと同列で語られてるため混同されがちですが、SREはインフラ運用にソフトウェア開発のアプローチを適応し、信頼性の向上・制御をその主な目的としたものです。それに対してプラットフォームエンジニアリングは、自社に最適化されたプラットフォームとそのインタフェースを整備し、アプリケーション開発者の生産性向上を主眼に置いています。
責務に明確な違いがあるものの、会社によってはスキルセットの類似性やエンジニアリングリソースの兼ね合いからSREsとプラットフォームエンジニアが兼任というところも多いのではないでしょうか。Ubieも例に漏れずそのようになっており、私もSREとPlatform Engineerの両方のロールを持っています。Ubieでのプラットフォームエンジニアリングに関しては、Ubieにおけるプラットフォームエンジニアリングの取り組み2023 をご覧ください。
さて、これらの前提を踏まえた上でこちらのセッションでは、BroadcomとYahoo、そしてGoogleのエンジニアがプラットフォームエンジニアリングの未来について話すという内容でした。まず上述したようなプラットフォームエンジニアリングの基礎から始まり、各社抱えている問題点やプラットフォームに期待することを整理していきました。特に、プロダクトごとに次のような質問に関して答えられることが重要という洞察がありました。
- どのインフラ上で動いているのか？
- どの程度コストがかかっているのか？
- ヘルスステータスは？
- 誰がそのインフラにアクセスする権限を持っているのか？
確かに、いずれの質問もプロダクトごとに各チームがオーナーシップを持つためには重要なことです。
これらの質問に答えるために、セッションではApplication Design Centerというアプローチを紹介していました。Application Design Centerとは、プラットフォームチームが社内のプロダクトチームに提供するDeveloper Portalのようなものです。これは単なるサービスカタログにとどまらず、アプリケーションに必要な設定を汎用テンプレートとして持ち、プロダクトチームがWebUIを操作するだけでアプリケーションの立ち上げから更新、モニタリングまでを可能にするものです。
Google Cloudでは最近GAになったApp HubというサービスがこのApplication Design Centerとして利用できるという紹介がありました。
また、GeminiとApplication Design Centerとの連携を推進しており、プラットフォームエンジニアリングの分野でも生成AIを活用する機運が高まっているのを感じました。
UbieではBackStageを用いたサービスカタログと、ubieformという内製のサービステンプレートツールによって、社内にApplication Design Centerに相当する機能を提供しています。一方でその体験はシームレスに接続されておらず、アプリケーションエンジニアが複数の画面を行ったり来たりしないといけない事もあります。そのような課題の対処法として、App HubやGeminiを用いた開発者体験の向上は今後社内でも検証する価値がありそうです。
How Google Kubernetes Engine autopilot leveraged Ubie’s re-architecting of its microservices
sakajunのセッション1つ目です。
Ubieでは、規模や特性の異なる大小70以上のマイクロサービスを運用しています。それらの大部分は1つのGKEクラスタ上で稼働していましたが、急激な事業成長とともに、システム的、開発効率的な課題を複数抱えていました。そこでプラットフォームチームでは、昨年後半から今年にかけてマルチクラスタ構成の新基盤を作成し、既存のマイクロサービスのマイグレーションを実施しました。これまではインフラとしてGKE Standardを利用していましたが、新基盤ではマルチクラスタになり運用負荷が増大することを考えて、より運用を自動化できるGKE Autopilotを選択しました。
このセッションでは、インフラ移行にまつわる背景、教訓などをGKE Autopilotの利点に触れながら発表し、最近発表されたGKE Autopilotのburstingといった新機能についても紹介しました。
詳細は別途sakajunがブログを書くそうなのでそちらをご覧ください。
GKE Autopilotは以前まで存在していた制限が徐々に無くなり、より運用しやすいプラットフォームになっています。今後の進化にも期待ですね！
How to deliver a large-scale Kubernetes network with Shopify
Ubieにおけるマルチクラスタ戦略では、toB、toC事業、個人情報を扱うサービス、といった領域や機密度に応じてサービスを複数のクラスタに分割しています。このようなマルチクラウド戦略では耐障害性やセキュリティレベルの向上といったメリットはありますが、複数クラスタの統一的な管理や、クラスタ間の通信制御といった観点では複雑度が増してしまいます。Ubieではこの課題をAnthos FleetやAnthos Service Meshといったマネージドサービス、及び内製テンプレーティングツールのubieformによるマニフェストの自動生成といった手法で対処しています。
一方で、Ubieのビジネスが成長し、よりワークロードが増大した場合にどのような問題が起こりうるかという点に関しては深く理解しておく必要がありました。そこで、Eコマースプラットフォーム大手であるShopifyがマルチクラスタ環境における課題と取り組みを紹介するセッションに参加しました。
セッションではGKEネットワークのアーキテクチャや歴史から始まり、Shopifyの規模感などの説明がありました。Shopifyではブラックフライデーなどのピーク時には最大で400クラスタ、35,000のインスタンスが起動しているようです（CI/CDや分析系のジョブも含めて）。
これまでのShopifyのクラスタでは、データプレーンとしてGKEのデフォルトだったCalicoベースのものが利用されていましたが、クラスタの規模が大きくなるにつれてルートのconvergenceに時間がかかる、サービス間通信のレイテンシが伸び始めるといった問題が発生していました。これの原因としては、Calicoがやりとりするkube-proxyがiptablesベースで運用されていたため、サービス数の増加に伴いiptablesがボトルネックになってしまう、といったものが挙げられていました。
最近のGKEのクラスタはDataplane V2が利用されています。こちらはciliumがベースとなっており、基本的にkube-proxyは使われません。そのため、ShopifyではこのDataplane V2を利用するクラスタへワークロードを移行させることで、ボトルネックの解消を行なったとのことでした。
その他にも、Network Topilogyを用いたクラスタネットワーク状況の把握や、基調講演でも発表のあったGemini Cloud Assistを使ったPod, Serviceに対するIPアドレス割り当てレンジの最適化などについてデモが実施されました。
UbieのGKEクラスタは最近新しく作成されたものなので全てDataplane V2が利用されますが、トラブルシューティングやオブザーバビリティといった観点において、より大規模な環境を運用している先駆者の知見は貴重なものでした。
Best practices for strategically deploying applications on Google Cloud
sakajunのセッション2つ目です。
このセッションでは、クラウドにアプリケーションをデプロイする際に直面しがちな課題を整理し、マネージドのCI/CDサービスであるCloud Deployの概要とその利点をまとめ、Ubie内でのCloud Deployの活用事例について紹介しました。
Ubieではマルチクラスタ移行をした際にデプロイ周りをGitHub ActionsからCloud Deployに移行しており、実際の運用の中で得られた知見や、テンプレーティングツールを用いたデプロイ設定の自動生成といったトピックについて深掘りしました。
これも後日内容の詳細についてブログが出ると思います。
Gemini for Google Cloud: Efficiently manage your application lifecycle with Gemini Cloud Assist
今回の基調講演で発表されたGemini Cloud Assistに関するデモがメインのセッションです。デモの内容はCloud Assistのチャットを利用して各種リソースの構築や最適化、インシデントレスポンスをするといったものです。Cloud Assistは最新の公式ドキュメントの内容を常にコンテキストとして保持しいているだけでなく、SlackOverflowの質問と回答なども学習しているようです。
特に注目すべきなのが、現在プロジェクトにあるリソースの情報を持っており、回答に具体的なリソースIDが含まれるという点です。例えばコスト削減の方法を質問した際は、「sample-clusterのXXのノードプールの費用が高いので、~のような最適化をするべき。$Yのコスト削減が見込まれる」のような回答を返してくれます。これはクラウドと直接統合されているAIだからこそできる事なので、とても印象的でした。
Ubieでは、アプリケーションエンジニアがインフラ周りで支援を受けたい時に、プラットフォームチームにチケットベースで依頼が出せるようになっています。その内容の例としては、「アプリケーションのデプロイが何らかの理由で失敗するので、ログの見方を教えて欲しい」と言ったものです。このようなチケットはこのCloud Assistでの自動応答が可能になるはずなので、運用負荷の軽減に役立ちそうです。
Build an internal developer portal with Backstage to accelerate Google Cloud adoption
BackStageはSpotifyが中心となって開発するDeveloper Portalを作成するためのOSSのフレームワークです。このセッションでは、BackStageの活用事例と、それを用いたDeveloper Portalの作成方法、Cloud Runアプリケーション構築のデモが紹介されていました。
セッション中の事例ではしっかりとBackStageを作り込んでおり、templating機能によりサービス構築が数クリックで完了する様子がわかりました。
コンセプト自体は面白かったですが、UbieではBackStageの作り込みにそこまで大きな投資をできないことと、templating機能は使わない意思決定をしているので、個人的にこのセッションから得られたものは少なかったです。
基調講演
Opening Keynote: The new way to cloud
オープニングセレモニーとなる基調講演です。CEOのThomasを始めとしてVPクラスのGooglerが多数登壇していました。
内容はほぼ生成AI一色で、google workspaceとgeminiの統合、gemini 1.5を用いたマルチモーダルな自動応答Botなどの紹介と、生成AIをビジネスに活用しているユーザ企業の声を紹介していました。
インフラよりの内容としては少しだけ、期待していたARMのaxionチップに関するアナウンスもありました。
ちなみに基調講演は早く入場しないと定員オーバーで会場には入れなくなります。ライブストリームを別部屋でやってるのでそれを視聴しました。
Fast. Simple. Cutting edge. Pick three
2日目の開発者向け基調講演です。こちらも生成AIをテーマにしたデモが大部分を占めました。
また、Gemini Cloud Assistのアナウンスがありました。このプロダクトは、Google Cloudが提供する様々なプロダクトに対してGeminiのチャットUIが組み込まれ、システムの状態やトラブルシューティング方法、具体的なコマンドなどについて教えてくれます。ライブデモではWebサービスに障害が起きたことを想定し、Geminiのチャットを用いてFirewallの設定不備が障害の原因であることを特定していました。クラウド運用には多くの知識を必要とするため、こういったAIが支援してくれるようなサービスは生産性向上に大きく寄与しそうです。
Googlerとのミーティング
Cloud Next参加の一番の目的がこのミーティングです。Google Cloudが提供する各プロダクトのPMやエンジニアと直接話すことができ、プロダクトに対するFeature Requestをしたり、今後のロードマップを聞いたりすることができます。以下のサービスの担当と話しました。
- VPC Service Control
- Service Mesh
- AlloyDB
- Cloud Monitoring * 2
- GKE Enterprise
- Cloud Run
ブログではNDAの関係で書けないことが多いですが、得られた情報は今後のUbieプラットフォーム開発の方針を立てるにあたり大変参考になりました。
各種懇親会
日本から来た参加者との交流会なども主催していただきました。他社のアーキテクチャや関心ごと、表には出ない裏話を聞けるのは面白いですね。最近はなかなか物理で懇親会などに参加できてなかったので、実際に顔を合わせて会話することの良さを思い出しました。
終わりに
今年は去年と同様に生成AI、特にマルチモーダルAIや各種プロダクトとの統合に関してのアナウンスやセッションが多く見られました。インフラ運用やプラットフォームエンジニアリングといったコンテキストでの活用を提案するものも多く、特に開発者の認知負荷を下げることで生産性を上げるプラットフォームエンジニアリングのアプローチとは相性が良さそうでした。
Ubieプラットフォームでも次のような生成AIの活用ができそうです。
- プラットフォームチームがプロダクトチームから受けるトラブルシューティングや質問、要望などのチケット応答の自動化、サマリーの生成
- サービスカタログ上での、特定サービスの設定やステータスに関するサマリやアドバイス
- Gemini Cloud Assistのポリシー策定と社内での利用推進
期間中関わった全ての皆様、ありがとうございました。
Ubieではソフトウェアエンジニアを採用中です。
Discussion