Google Cloud Next ’24 にて行われたセッション「The future of platform engineering is application-centric」のレポートです。
Google Cloud Next ’24 とは？
2024 年 4 月 9 ～ 11 日にラスベガスのマンダレイ ベイで開催されている、Google Cloud が主催する最大級規模のイベントです。
https://cloud.withgoogle.com/next/
登壇者
Google Cloud, Principal Engineer
Srinivas Krishnan 氏
Google Cloud, Product Manager
Sahil Nanda 氏
Broadcom, Director Product Management
Deepak Mani 氏
Yahoo, Sr. Director of Production Engineering, Yahoo Mail
Dan Nater 氏
セッション内容
プラットフォームエンジニアリングについて
- DevOps チームが、アプリケーションとインフラストラクチャの両方を管理する場合、以下の問題点がある
- 複雑な分散システムを理解する必要があるため、エンジニアへの認知的負荷がかかる
- 企業が成長するにつれてアプリケーションの拡大断片化が進むため、異なるツールの多様化などにより一貫性が失われる
- プラットフォーム エンジニアリングとは何か？
- 開発者の効率化のためのツールとシステムの標準化
- ユーザー体験：どこにいても対応できる一貫したインターフェース
- セキュリティとコンプライアンス：デフォルトで標準化および準拠されている
- ゴールデンパス：テンプレートと自動化を使用したセルフサービス インフラストラクチャ
- マネジメント：セルフサービス機能とアップグレード
- 製品としてのプラットフォーム：ユーザー中心の必要最低限のプラットフォーム
- プラットフォームの構築は難しい！
- プラットフォームを保ちながら標準化を行うが、独自の製品ニーズを全て満たすのは難しい
- プラットフォームの数に応じてスケーリングの問題が発生
- 2つ以上のプラットフォームではツールの相互一貫性が欠如
- 対応には大規模なチームが必要 → チームの認知負荷が増加
- 高可用性、耐障害性のある安全なインフラストラクチャを提供する責任もある
- これらをN個のプラットフォームにわたって大規模に維持するのは不可能な作業
- では、柔軟かつ標準化されたプラットフォームを作るにはどうするか？
- 製品とプラットフォーム間の異なる作業量に合わせて、それらの結合を確保するメカニズムが必要
- 私たちはアプリケーション中心のクラウドが、標準化を保ちつつ独自のニーズを満たす柔軟なプラットフォームを提供すると信じている！
Yahoo Mail の事例
- Yahoo Mail の構成図
- プラットフォーム エンジニアリングの経験談
- 人間関係：共同作業や考え方の摩擦
- 専門知識を持ったエンジニアと生産エンジニアの垂直構造のチームといったキャリアパス
- 垂直構造のアプリケーションチームに共通のソリューションを持ち出すのは難しい
- プロセス：手作業や一貫性のないワークフロー
- 共通のソリューションの構築は一元的なオーナーシップがないと維持するのが難しい
- Snowflake によるルーチンタスクの重複
- テクノロジー：ツールチェーンの複雑さと管理
- 複雑なスケーリングモデル
- 非標準の高可用性モデル
- プラットフォームに期待すること
- Google Cloud のプロジェクトやフォルダ、IAM、セキュリティ、ネットワーキング、可観測性の全社標準化モデル
- 標準化されたフレームワークとツールによって、今後のテクノロジーなどを積極的に取り入れることができる
- Yahoo Mail の操作性、効率性、コストを最適化した共有インフラストラクチャ
- 全てのアプリケーション インフラストラクチャの依存関係を簡単に理解できる
Broadcomの事例
- Broadcomの構成図
- Agile Operations Division（AOD）という製品に着目
- プラットフォーム エンジニアリングの経験談
- 人間関係：共同作業や考え方の摩擦
- 製品チームは「イネーブラーとして製品を提供するインフラストラクチャ」に、プラットフォームチームは「サポートする多数の製品にわたる標準化」に重点を置いている
- 両チームの優先順位が一致していないため、連携が取れていないことがある
- プラットフォームによって独自のリリースタイミングであることが、製品の要求に応じて開発されたシャドウツールの構築に繋がる
- プロセス：手作業や一貫性のないワークフロー
- 製品のインフラストラクチャの要求はサービスチケットを通して提供されるが、チームが異なるためチケットや優先順位の増加につながる
- インフラストラクチャの増加により、製品が標準化に準拠しているかの確認だけでも時間がかかる
- テクノロジー：ツールチェーンの複雑さと管理
- テクノロジーの多様な利用により管理が複雑化
- レガシー製品は、プラットフォームを標準化しROLを示すことが困難（ROLが何かはわからず…）
- 拡張によるボトルネックを解消し複数の要求に対応するには、プラットフォームへのしっかりした投資が必要
- プラットフォームに期待すること
- 「製品」または「アプリケーション」ごとに 1 つのコントロール プレーン
- 関係者、製品チーム、プラットフォームチームが「ビジネス オファリング」を構成するが何か可視化できるようになる
- 次のような質問に答えられるようにする
- この製品はどのようなインフラストラクチャで実行されるか
- この製品の運用にはどれくらいの費用がかかるか
- この製品は健康に良いか、問題はどこにあるか
- どのようなテクノロジーが使用されているか
- どのようなプラットフォームサービスが使用されているか
- この製品の「二酸化炭素排出量」はどれくらいか
- 誰が、この製品によって消費される「どの」インフラストラクチャサービスにアクセスできるか
- 製品は現在のセキュリティ管理に準拠しているか
- このような視点により、製品チームとプラットフォームチームが製品の実行に関して生産的な議論ができるようになる
まとめ
- なぜアプリケーション中心のクラウドなのか？
- ビジネスの管理 = アプリケーションの管理
- 全てのコア機能やサポート機能がアプリケーションに対する理解を持つものである
- アプリケーションは製品チームにとってセルフサービス的なプラットフォームを実現し、接着剤の役割となる
- 製品は複数のアプリケーションと複数のチームから構築される
- アプリケーションは階層的に目的や意図が組み込まれて構成されている
- アプリケーションの管理はチームスポーツ
- プラットフォームが提供するアプリケーション サンドボックスにより、開発者が目的の業務にすぐに取り掛かることができる
- プラットフォームエンジニアリングはアプリケーション サンドボックスに対するランタイムと標準化を定義する
- 非機能要件はほとんどなく、テンプレートやコスト、スケーリングは製品とプラットフォーム間で共有される
感想
最近よく聞くプラットフォームエンジニアリングについて詳しく理解できるセッションでした。
プラットフォームエンジニアリングが求められるようになってきた背景から、どのようなことを実践していくべきかまで包括的に説明されており、その重要性を改めて認識しました。
また、事例の紹介もあったため、企業で実際に起こりうる問題点を人間関係、作業プロセス、技術的な面から体感することができました。
弊社も正に成長中の企業なので、社員一人一人がプラットフォームエンジニアリングを理解し、このような意識を持って組織を動かしていきたいと思いました。
 |
4月19日16時より「【iret presents】Google Cloud Next’24 Recap」を開催します。4月9～11日にラスベガスで開催される Google Cloud が主催する「Next’24」のポイントを解説する Recap イベントです。
詳細はこちら： |
