道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー
Google Cloud Japan Team
※この投稿は米国時間 2023 年 9 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。
入社したばかりの Java デベロッパーが、簡単な Java サービスを作る仕事を割り当てられたとしましょう。DevOps モデルでは開発チームと運用チームが責任を共有するので、Java コードだけでなく、ビルド パイプラインやモニタリング計測のような運用コードの作成も求められるかもしれません。しかも、クラウド プラットフォームは以前の仕事で覚えたものとは異なります。
あっという間に YAML ファイルの山に溺れ、簡単な Java サービスの構築が難事業になってしまいました。決めなければならないことがたくさんあります。コードの構成はどうしよう？継続的デリバリーにはどのツールを使用したらいいのだろう？
DevOps モデルは開発者に耐えられないほどの学習の手間をもたらすことがあります。オンボーディングが困難になり、生産性が低下し、燃え尽き症候群のリスクもあります。
プラットフォーム エンジニアリングとは、組織において有用な抽象化を行い、セルフサービス インフラストラクチャを構築するアプローチです。散乱したツールをまとめ、デベロッパーの生産性を高める効果があります。プラットフォーム エンジニアリングの狙いは、デベロッパーが体験する日常的な困難を解消して、行きすぎた責任共有モデルが引き起こす学習の手間を抑制することです。
では、どのような抽象化とセルフサービス インフラがデベロッパーに最大の恩恵をもたらすのでしょうか。答えはゴールデンパスにあります。
ゴールデンパスとは
Cloud Native Computing Foundation の定義では、ゴールデンパスは「迅速なプロジェクト開発に役立つ巧みに統合されたコードと機能のテンプレート構成」とされています。簡単に言うと、よくあるタスクのためのセルフサービス テンプレートです。
入社初日に Java Spring Boot のゴールデンパス テンプレートを手渡されたとしましょう。これがなければ、膨大な数のツールとインフラストラクチャに囲まれながら悪戦苦闘するしかない状況でした。このソースコードのリポジトリには、次のものが含まれています。
スタートガイド
スケルトン ソースコード
依存関係の管理
CI / CD パイプライン テンプレート
クラウド Infrastructure as Code 用テンプレート
Kubernetes YAML ファイル
ポリシー ガードレール
ロギングとモニタリング計測
リファレンス ドキュメント
このゴールデンパスがあれば、入ったばかりの組織の Java 推奨慣行へのオンボーディングが楽になり、フォーク可能なリポジトリ テンプレートでビルド完了までの時間が短縮されます。
入社した会社が「React ウェブ フロントエンド」から「Python による ML」まで、さまざまなタスクに適用できるゴールデンパス テンプレートを用意してくれるとしましょう。もう暗闇の中で 1 人で悪戦苦闘しなければならないデベロッパーはいません。ゴールデンパスが道を照らしてくれます。
ゴールデンパスの対象者
組織内のさまざまな職種がゴールデンパスの恩恵を受けることができます。アプリケーション デベロッパーはオンボーディングに利用できるほか、サポート対象のツール使用までの道筋が明確になることで、ビルドが高速化します。後のメンテナンスを考慮して、インフラストラクチャ コードはカスタマイズを抑えます。複数のアプリケーション チームが同じゴールデンパスをもとに構築するのであれば、基盤が共通なので情報共有が容易になり、共有ツールの作成が促され、組織全体にわたってアジリティとモビリティが改善します。
この一貫性によって、サイト信頼性エンジニア（SRE）は、本番環境サービス群をモニタリングしやすくなります。たとえば、社内の多くのサービスが同じ指標のエクスポーターやラベルを使用している場合、サービスの停止時にデバッグ時間が短縮されます。
セキュリティ管理者もゴールデンパスの恩恵を受け、ポリシー ガードレールの実装が容易になります。たとえば、セキュリティ チームがファイアウォール ルールの新しい要件を適用したい場合、プラットフォーム チームと協力してゴールデンパス テンプレートを更新できます。
最後に、ゴールデンパスで費用が最適化されることにより、組織全体に恩恵がおよる可能性があります。たとえば、Kubernetes ベースのサービス向けゴールデンパスを使用して、GKE Autopilot クラスタ内に名前空間を作成することで、ほとんどのキャパシティが使用されずに終わる大規模な専用 GKE クラスタの作成を回避できます。これにより、インフラストラクチャ レベルの最適化を定義し、抽象化できます。
ゴールデンパスの恩恵は、まだまだ多くの人におよぶ可能性があります。デベロッパーや ML エンジニアからテスターや FinOps まで、あらゆる人が一般的な抽象化と簡単なセルフサービスの恩恵を受けることができます。
ゴールデンパスの原則
ゴールデンパスはどれも異なっているように見えます。しかし、たいていは次のような共通の原則が見られます。
決して妥協しない明確な 1 つの方法を提示して、特定のタスクの達成を支援します。
学習の手間の軽減を図り、抽象化と入門ドキュメントで対象ユーザーを導きます。
既存の社内デベロッパー プラットフォームと統合します。ゴールデンパスは、プラットフォーム チームが管理する抽象化されたインフラストラクチャの土台のうえで機能します。そのため、たとえば、デベロッパーがゴールデンパスをもとに新しいサービスを作成すると、新しいソフトウェア カタログ エントリが生成されます。別の例では、ゴールデンパス リポジトリに Kubernetes Deployment テンプレートが含まれる場合、この Deployment はプラットフォーム チームが管理する GKE クラスタと名前空間に適用されます。
開発環境から本番環境までのすべての道のりを照らします。ローカル開発、CI / CD パイプラインのテンプレート、ステージングと本番環境のための Infrastructure as Code 用テンプレートの手順が含まれることもあります。
セルフサービスです。組織のデベロッパーの全員がゴールデンパスを見つけて、使用できます。チケット管理システムを経由する必要はありません。
透明性の高い抽象化を提供し、土台となるインフラストラクチャを覆い隠すことはありません。DevOps の責任共有モデルでは、デベロッパーは保守、最適化、デバッグのために自分のサービスのフルスタックをいずれ理解する必要があります。
組織固有のニーズに対処します。組織が取り扱うのは主に「ブラウンフィールド」移行で、それに少数の新しい「グリーンフィールド」サービスが伴う形ですか？サポートされる移行パスのゴールデンパスの構築を検討してください。
柔軟性を確保して、複数の対象グループの要件をサポートできるようにします。たとえば、デフォルトで Spanner のような SQL データベースをサポートするゴールデンパスは、Firestore のような NoSQL データベースと簡単に切り替えられるようにします。
選択権を与えます。ニーズを満たさないゴールデンパスの採用を、デベロッパーが強制されないようにします。
ゴールデンパスの実践
ここまで、ゴールデンパスに関して誰が、何を、なぜ行うかを説明しました。次に、いつ、どのように行うかを説明します。
ゴールデンパスを構築するタイミング
ゴールデンパスの構築と保守には費用がかかります。少数のサービスしか稼働させていない小さな組織なら、ゴールデンパス構築の費用が便益を上回ります。同じようなサービスをいくつか稼働させるようになったときに、最初のゴールデンパスを構築することを推奨します。同じようなフレームワークが同じようなインフラストラクチャ上で稼働している状況です。
組織の典型的なデベロッパーが日常的に遭遇しているトラブルに目を向けることも推奨します。たとえゴールデンパスの対象チームが少数でも、業界固有の規制要件がある場合や、複雑で不均質なインフラストラクチャ環境では、デベロッパーも会社もゴールデンパスによる抽象化の恩恵を受けます。
パスの選び方
組織に 50 の開発チームがあり、4 つのプログラミング言語を扱っているとしましょう。最初に構築するゴールデンパスをどのように選びますか？
まず、各チームと協力して共通のパターンを突き止めます。フロントエンド デベロッパーは Flutter と React のどちらも使用しているでしょう。おそらく Flutter と React の 2 つのフロントエンド ウェブ ゴールデンパス テンプレートを構築することになります。1 つしか構築する時間がない場合、アーキテクチャが簡単な方を選ぶとよいでしょう。あるいは、期待を高めていて、最初のゴールデンパスの共同開発とテスト使用に取り組む余裕のあるチームを突き止めます。
構築と保守を行うのは誰？
ゴールデンパス テンプレートには技術的な要素が含まれ、構築、ドキュメント化、保守のプロセスを伴います。各テンプレートは、プラットフォーム チームと 1 つ以上のステークホルダー チームを横断して、最低でも 2 人もしくは 2 チームで共同開発することを推奨します。
なぜ共同開発するのがよいかというと、第一に、複数のゴールデンパス間での一貫性をプラットフォーム チームが保持できるようにするためです。たとえば、組織のすべてのゴールデンパスが同じインフラストラクチャをコードスタックとして使用するようにします。第二に、テンプレートに何を含めるかに関してステークホルダー チームが意見を表明できるようにするためです。アプリケーション開発チームが最初から関与すると、ゴールデンパス テンプレートが採用される可能性が高まります。
ゴールデンパス テンプレートの保守やイテレーションは、長期的に組織のスピード感、サポートされるゴールデンパスの総数、ゴールデンパスの全体的な採用状況に応じて変動します。1 つの手法として、プラットフォーム チームがすべてのゴールデンパス テンプレートの保守とバージョン管理を担当するが、他チームの貢献も認めるという方法もあります。
全体としては、ゴールデンパスの責任共有モデルを導入することで、DevOps カルチャーの最良の部分が協調されます。それは、コミュニケーション、共同学習、高度な協力は報われ、参加したすべての人が恩恵を受けるという点です。
成功の測定とイテレーション
最初のゴールデンパス テンプレートの特定、設計、構築、リリースを終えたとしましょう。成功したかどうかをどのように判定しますか？
まず、組織内での成功がどのようなものかを特定することが重要です。デベロッパーの満足度の向上ですか？四半期ごとのリリース数の増加ですか？社内プラットフォームをプロダクトとみなすと、このプロダクトの成功はどのようなものになりますか？
測定しやすい指標があります。たとえば、ゴールデンパスを採用した新サービスの数です。KPI と定量的な目標を設定し、ダッシュボードを作成して組織内のゴールデンパスの採用状況を追跡します。
測定がより困難な指標もあります。デベロッパーの自律性をどのように測定しますか？チーム間の調整費用の低減は？この場合、社内デベロッパー アンケートのような定性的測定が有用です。サポート チャネルを作成してゴールデンパス ユーザーからのフィードバックを収集し、最初の実装に失敗しても怖気づくことなくイテレーションを行います。
定量的測定と定性的測定の結果が出たら、フィードバックを参考にしてロードマップとリリース スケジュールを作成し、開発チームに伝えます。プラットフォームを売り込んでみるのもよいでしょう。ニュースレターやランチ ミーティングで、最新ゴールデンパスの特徴の認知度を高めることができます。
道を照らす
この投稿では、ゴールデンパスについてざっくり紹介しました。セルフサービスの抽象化がエンジニアリングのスピード感とチーム横断的なコラボレーションを高めるありさまを説明しています。組織内でどのようなゴールデンパスを構築し、使用するかについて考えるヒントになれば幸いです。
何から始めたらよいかお困りの場合は、Google Cloud の Terraform ブループリント ページをチェックして、Google Cloud Infrastructure as Code の例をご覧ください。プラットフォーム エンジニアリング全体の理解をまだ求めている場合、プラットフォーム エンジニアリングの落とし穴について説明している、Google の Alex McWilliam のブログ投稿や、プラットフォーム エンジニアリングに関する CNCF のホワイトペーパーをチェックしてください。
- アプリケーション モダナイゼーション担当 EMEA ソリューション リード Darren Evans
- スタッフ デベロッパー アドボケイト Megan O'Keefe
