DevOps & SRE

Unified Maintenance: Google Cloud 全体のメンテナンスを管理するための新たな統合ソリューション

Wed, 11 Mar 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 3 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

ビジネスの継続性とアプリケーションのパフォーマンスを確保するうえで、定期メンテナンスの管理は不可欠です。しかし、使用するクラウドサービスの増加に応じて、メンテナンススケジュールの把握が複雑になり、時間がかかるようになる可能性があります。現在の各種アプローチでは、通知の一貫性がなく、プロダクトごとに制御レベルが異なることがよくあります。そこで Google Cloud は、お客様がメンテナンス期間を見逃して業務の中断を発生させることがないよう、Google Cloud サービス全体のメンテナンスイベントを表示および管理できる一元化されたダッシュボード「Unified Maintenance」の一般提供を開始いたしました。

Unified Maintenance では、メンテナンスの更新情報が 1 つのビューに統合されるため、予定されているイベントを簡単に追跡できます。Unified Maintenance の機能は次のとおりです。

定期メンテナンスの表示: Compute Engine、Google Kubernetes Engine（GKE）、Cloud SQL、Memorystore、AlloyDB、Looker などのサービスのイベントを 1 つのダッシュボードで確認できます（サポート対象サービスを参照）。
アラートの標準化: Cloud Logging から一貫したメンテナンス情報を取得できるため、アラートを設定して、既存のモニタリングシステムやチケット発行システムに統合できます。
制御できるイベントの把握: ダッシュボードで、ユーザーが制御できるメンテナンスイベントを明確に把握できます。

次のステップ

Google Cloud は、より多くの Google Cloud サービス向けのサポートを追加し、プラットフォームの機能を強化できるよう尽力しています。ロードマップには、フォルダおよび組織のスコープの拡大と、アプリケーションレベルの可視化が含まれています。

Google Cloud コンソールで直接 Unified Maintenance ダッシュボードにアクセスして、サブスクリプションサービスで予定されているイベントを確認できます。これらの新機能の使用方法について詳しくは、ドキュメントとスタートガイドをご覧ください。

- プロダクトマネージャー、Erol-Valeriu Chioasca

プラットフォーム使用の落とし穴（パート 1）: アクティビティの多さが必ずしも価値の高さを示すとは限らない理由

Fri, 13 Feb 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 2 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

社内デベロッパープラットフォームに投資した組織では、必ず「実際に機能しているのか？」という疑問が生じます。

導入率を追跡するだけでは、プラットフォームがデベロッパーに真の価値をもたらしているかどうかはわかりません。英国の大手小売業者である John Lewis も、この課題に直面していました。これまでの記事（パート 1 とパート 2）では、John Lewis Digital Platform（JLDP）が数十のプロダクトチームによる高品質なソフトウェアの迅速な構築を可能にし、www.johnlewis.com やその他の重要なアプリケーションを強化した方法を紹介しました。しかし、このプラットフォームが実際に成功を収めたことはどのようにしてわかったのでしょうか？収益や販売などの従来のプロダクト指標をこの分野にそのまま当てはめることはできません。テナントがプラットフォームを使用しているかどうかだけを重視していると、プラットフォームがテナントに価値をもたらしているかどうかを把握できません。

この記事では、John Lewis のプラットフォームチームの Alex Moss 氏が、単純な使用状況の指標から、プラットフォームの真の価値を測定するための洗練された多段階のアプローチを開発するまでの経緯について説明します。この取り組みは、リードタイムの指標から DORA、そして最終的には「技術的健全性」スコアへと発展しました。その過程で、JLDP の目的がどのように進化し、それとともにその価値がどのように高まってきたのかを探ります。- Darren Evans

最初の測定: プラットフォームの価値に焦点を当てる

プラットフォームの初期の頃は、その価値の把握は実際にははるかに簡単でした。これは、プラットフォームが非常に明確な目的、つまり変更の迅速化を実現するために作成されたからです。John Lewis のビジネス部門は、johnlewis.com の複数の機能を並行して開発する複数のプロダクトチームを編成し、それらの機能を顧客に迅速に提供してフィードバックを得たいと考えていました。

同社のオンラインビジネス「John Lewis Digital」の世界で生まれたため、非常に早い段階からプロダクトとして扱われ、その分野のレポートメカニズムとも統合されました。そのため、プラットフォームの目標をオンラインビジネスのより広範な目標に四半期ごとにリンクさせ、測定可能かつ主要な成果を報告することが標準になりました。これにより、このプラットフォームが重要とみなす理由に焦点を当てることができました。プラットフォームの改善は、別のプラットフォームを探すのではなく、そのプラットフォームを使用し続けることを正当化するものでしょうか？現状に満足してはなりません。

6 つの年間指標が四半期ごとに報告されています。具体的な対策は年々変化しました。

これに加えて、プラットフォームの最初の数年間は、プラットフォーム作成の根拠を最もよく示す 3 つのシンプルな指標がありました。

サービス作成のリードタイム: テナント（プロダクトチームがソフトウェアを作成するスペース）の作成にかかった時間
オンボーディングのリードタイム: プロダクトチームが本番環境にデプロイするのにかかった時間
最初の顧客までのリードタイム: プロダクトチームがサービスを「顧客向けに本稼働開始」するまでに要した時間

プラットフォームの自社作成サービスカタログの初期バージョンのスクリーンショット。前述の 3 つの指標を追跡

これをプラットフォームに存在するテナントの数と組み合わせてレポートを作成し、上記の初期の自社製サービスカタログの一部として表示しました（その後、Backstage に置き換えられました）。このレポートには 2 つの目的がありました。

プラットフォームの導入状況と、稼働開始までの時間（特に「サービス作成」は、従来チームが数週間待つ必要があったのに対し、1 桁の時間で測定）を、関係者向けに非常にわかりやすく可視化する。これは、プロダクトの初期段階では、継続的な成長を実証して投資を正当化する必要があるため重要です。
どのチームが本番環境への移行に時間をかけているかを、プラットフォームチーム自身（および関係者）が確認できるようにする。プロダクトは実際に役に立っているか？そうでない場合、他に何ができるか？

これをテナントとの会話のきっかけとして利用することで、プラットフォームの機能にいかせる豊富なフィードバックを得ることができました。テナントに「本稼働開始を妨げているものは何ですか？」と尋ねたところ、多くの場合、構築しているプロダクトが複雑すぎるという回答が返ってきました。しかし、独自のプロセスが妨げになっていることもよくありました。これは重要なことでした。これにより対策を講じることができたからです。

これらの障壁のうち、当社が最も簡単に克服できたのは、通常、技術関連のものでした。これまでの記事では、「チームが PubSub をプロビジョニングするために Terraform の記述に多くの時間を費やしている」と「Kubernetes の使用方法を学ぶのに苦労している」という 2 つの例を取り上げました。これに対処するため、プラットフォームチームは「Paved Road（舗装された道）」を作り、セルフサービスプロビジョニングや Kubernetes の簡素化を実現して、チームの負担を大幅に軽減しました。

新しいサービスを本番環境に移行する手順を合理化するためのより大きな機会は、当社のプロセス（セキュリティ承認など）に存在していました。プラットフォームがこのような組織機能を簡素化できるように強化されていれば、得られるメリットは非常に大きくなります。その一例が、情報セキュリティリスク保証プロセスです。必要なセキュリティ承認を得て、必要なドキュメントを作成する作業が必要でしたが、時間がかかりました。また、ビジネスの変化の速さから、多くのチームが並行してこの作業を行っていました。プラットフォームチームは、テナント向けの簡素化されたプロセスを交渉で獲得しました。これは、プラットフォームに常駐することで、セキュリティ管理が実施され、ポリシーが遵守されていることを保証できたからです。これは、このニーズを満たす機能をプラットフォームが構築し、それらの機能が使用されているという証拠を提示できたことから直接もたらされた結果です。これにより、テナントチームがこれをドキュメント化したり、独自に考案したりする必要がなくなりました。このソリューションは技術的な要素が少ないものですが、プラットフォームエンジニアリングを通じてデベロッパーのエクスペリエンスを簡素化しています。

会話の結果、プラットフォームの形をなさないフィードバックが得られることもありました。たとえば、機能フラグやダークローンチなどのコンセプト、あるいはレガシーシステムとの依存関係を解消するのに役立つソフトウェア設計オプションをチームが理解できるよう支援することなどです。John Lewis のプラットフォームチームには、経験豊富なエンジニアが配置されています。このようなやり取りに大いに貢献できる、ソフトウェア開発の経験があるエンジニアが理想的です。

ここで重要なのは、チームがどれだけ効果的に本番環境に移行できたかを測定することで、誰に話を聞くべきかを特定し、対処すべき問題について必要なフィードバックを明らかにできることです。テナントが全体像を把握していない（または他の優先事項がある）場合にテナントが自らこれを考えることを期待するだけでは、効果はほとんどありません。

その後、アンケートの実施やネットプロモータースコアの利用など、より従来的なアプローチと組み合わせることで、プロダクトの人気を高めることができました。その結果はたいてい非常にポジティブなものであり、マインドシェアの獲得に利用できました。特に、プロダクトチームが社内の技術会議などでポジティブな経験について話すことに抵抗がない場合は、その効果が大きくなります。

チームのパフォーマンスを把握できるようにする

プラットフォームを運用してから数年経つと、重視する点が変わり始めました。プラットフォームの価値を証明する必要性は低くなり、ビジネス部門とエンジニアは満足していました。そのため、「いかに早く本番環境に移行できるか」から「いかにして日常業務で迅速さを維持しつつ、摩擦を減らすことができるか」へと焦点を移しました。これが DORA 指標につながりました。

DORA の最初の実装では、変更とインシデントに関する記録システムから情報をマイニングし、すでに成熟していた可用性データ用のオブザーバビリティスタックで補完しました。また、クラウド監査ログなどのイベントも取得しました。このためのソフトウェアを構築して BigQuery に保存し、自社開発のサービスカタログツールでデータを可視化できるようにしました。その後、これを Grafana ダッシュボードに移行し、現在も使用しています。

このデータからパターンを探した結果、構築に役立つ他の機能を発見できました。この 2 つの大きな例は、変更への対応と運用準備です。

JLP のサービス管理プロセスは、複数の大規模なシステムやチームにわたる複雑なリリースプロセスを処理することを目的としていましたが、マイクロサービスを採用することでアーキテクチャを根本的に変更しました。これにより、チームは必要に応じて独立してリリースできるようになり、変更の失敗による影響を自分たちで管理できるようになりました。変更時の障害率と小規模なリリースの頻度について収集したデータを使用して、別のアプローチを正当化しました。テナントが CI / CD パイプラインの一部として変更を自動的に発生させて終了できるようにするアプローチです。サービス管理チームにこのアプローチを承認してもらった後、チームがパイプライン内で使用できる CLI ツールを開発しました。これには、より扱いにくいデータソースをスクレイピングするのではなく、リリース時に有用なデータを取得できるというメリットもありました。自動変更の「アメ」は非常に人気があり、広く採用されました。これにより、承認ポイントはリリースプロセスの後半ではなく、pull リクエストの段階に移行しました。この結果、時間の無駄、変更セットのサイズ、衝突のリスクが軽減されました。

同じような事例として、独自のサービスを運用するチームが増えたことで、サイト全体の運用チームを中央に置く必要性が低下しました。指標から、「You Build It, You Run It（自ら開発し、自ら運用する）」を実践しているチームはインシデントが少なく、インシデントの解決もはるかに迅速であることがわかりました。これを根拠として、インシデントへの迅速な対応に役立つツールを導入し、集中型の運用チームをこれらのプロセスから切り離しました。これにより、レガシーシステムに集中できるようになったチームもあれば、サービス自体が不要になったチームもあります（後者の場合、個々のプロダクトチームのオンコールが増えたにもかかわらず、大幅な費用削減につながりました）。これに加えて、オブザーバビリティ / アラートツールをサポートするものはすべて、前回の記事で説明したプラットフォームの「Paved Road」パイプラインを通じて構成されました。

DORA の指標は、アーキテクチャの面でも役立ちました。運用データから、サードパーティサービスと従来のサービスの脆弱性が明らかになり、その結果、レジリエンスエンジニアリングや代替ソリューションへの投資が拡大しました。構築と購入の意思決定を再評価することになったケースもありました。

測定対象を選択する

何を測定するかを賢く選択することは非常に重要です。この分野の専門家（Laura Tacho 氏など）から、見栄えのよい指標は避け、収集した指標の解釈には慎重になるようアドバイスを受けました。さらに、指標がターゲットオーディエンスにとって意味のあるものであり、それに応じて提示されることも重要です。

たとえば、費用や脆弱性についてチームとコミュニケーションをとりますが、その形式はターゲットオーディエンスの役割によって異なります。たとえば、新しい脆弱性や費用の急増は、プロダクトチームのコラボレーションチャネルに直接送信します。これは、エンジニアがこれらの脆弱性を確認することで、より迅速な対応が可能になることが経験からわかっているためです。一方、コンプライアンスレポートやチームリーダーによるレビューでは、対応が必要な領域を要約するためにはレポートの方が効果的です。「ポリシー外の脆弱性」ダッシュボードのリーダーになりたい人はいないことは、よく知っています。

それまで、インシデントの数や頻度などの指標を調べることは珍しくありませんでした。しかし、高度に自動化された対応システムの世界では、アラートは簡単に複製できるため、これは落とし穴となります。数値を重視しすぎると、間違った行動につながる可能性があります。最悪の場合、インシデントの登録を意図的に避けることさえあります。代わりに、親インシデントの影響と復旧にかかった時間に焦点を当てる方がはるかに良いでしょう。もう一つの例は、脆弱性の数の報告です。分散システム内の多くのコンポーネントで広く使用されているパッケージがあるとします。パッケージに脆弱性があることを開示すると、ベースイメージにパッチを適用すればすぐに問題に対処できる場合でも、影響の範囲が実際より大きく誤認される可能性があります。代わりに、重大度に基づく事前合意済みのポリシーよりも、対応のスピードを重視することをおすすめします。これは、チームが行動を起こすうえでより効果的かつ合理的な指標であるため、エンゲージメントが向上します。

データを示す際には、できるだけ多くのコンテキストを伝えることが非常に重要です。そうすることで、正しい結論を導き出すことができます。特に、意思決定者がレポートを見る場合はなおさらです。それを踏まえて、可視化できる未加工の指標と、それに関するユーザーの意見を組み合わせました。これにより、欠けていたコンテキストが明らかになりました。変更時の障害率が高いチームは、リリースプロセスやバッチサイズにも苦労しているのでしょうか？脆弱性に迅速に対処していないチームは、機能の開発に時間をかけすぎて、運用上の問題にも十分な時間をかけられていないと報告していますか？そこで、このような情報を活用するために、別のツールである DX を使用することにしました。続編の記事では、これをどのように行ったかと、その結果テナントに関する収集データの拡大がどのように促されたかについて詳しく説明します。今後の情報にご注目ください。

Google Cloud でのプラットフォームエンジニアリングを活用したシフトダウンについて、詳しくはこちらをご覧ください。

- アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

- John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

プラットフォーム使用の落とし穴（パート 2）: 意味のあるモニタリング指標を選択する

Fri, 13 Feb 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 2 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

この記事のパート 1 では、John Lewis Partnership の Alex Moss 氏が、同社がデベロッパープラットフォームの価値を測定するために使用している指標について説明しました。ここでは、あらゆる測定戦略の重要な側面である、測定対象の適切な選択について説明します。膨大なデータの中に迷い込んだり、見栄えはするものの、実際にはプラットフォームの健全性やデベロッパーのエクスペリエンスを反映していない指標に注目したりしがちです。ここでは、意味のある指標を選択し、適切な会話と行動を促す方法で提示することにより、データを常に可能な限り多くのコンテキストとともに提示するという John Lewis の理念について、Alex 氏が説明します。- Darren Evans

この記事の前半で詳しく説明したソリューションは非常にうまく機能しましたが、客観的な指標のみに頼ることには、いくつかの落とし穴があります。誤解されやすいため、時間を無駄にしたり（「チームは現在別のプロダクトに取り組んでいる」）、正しい情報を伝えられなかったり（「インシデントは適切にクローズされなかった」）します。その結果、スケーリングの課題が生じます。少数のチームと話して状況を把握することはできます。しかし、プロダクトを構築しようとしているのが 1 つの小さなチームしかなく、数十のチームとやり取りする必要がある場合は、そう簡単ではありません。

エンジニアの主観的なフィードバックを収集する

当社は、主観的なフィードバックを収集する方法を必要としていました。できれば、客観的な DORA やその他のサービス指標と比較して可視化できる形式です。

この最初の試みとして、サービス運用性評価を作成しました。これは、テナントが四半期ごとに記入するアンケートです。サービス運用性評価は、チームがサービスの実行に関する優れたプラクティスに従っているかどうかを調べることを目的とした、示唆に富んだ一連の質問で構成されています。これは、さらに質問を掘り下げて、重要なフィードバックとアクションを引き出すことができる経験豊富なファシリテーター（通常はシニアプラットフォームエンジニア）がいる場合には有効でした。しかし、ご想像のとおり、この方法ではスケーリングの課題が生じました。最終的に、このプロセスは完全にセルフサービスで処理されるようになりました。これは完璧なシステムではありません。多くのチームは、前の四半期の回答をコピー＆ペーストするだけで満足しているからです。その回答が現実を反映しているかどうかはわかりません。

その後、DX プラットフォームと呼ばれるツールについて知りました。このツールは、この問題への取り組み方を大きく変え、現在ではエンジニアリングコミュニティ全体で使用されています。3 か月ごとに数分間、チームではなく個々のエンジニアにアンケートを実施します。質問は、DORA やその他の類似のフレームワークの創設者によって裏付けられた DX の調査に基づいて厳選されます。結果をさまざまな方法で分析できるのは非常に便利でした。プラットフォーム全体にわたる領域を調べることも、特定のチームを詳しく調べることもできます。後者の場合、DORA データと組み合わせれば、充実した会話が生まれます。たとえば、DX ツールでは、大きな影響を及ぼすインシデントを最近経験したチームは「本番環境のデバッグ」に関する懸念を登録した可能性がある一方、リリース頻度が大幅に低下したチームは「変更の信頼性」や「リリースの容易さ」に関する懸念を登録した可能性があります。この時点で、プラットフォームチームは、チームが抱えている問題に対処するために、アドバイスを提供したり、新しい機能を実装したりできます。

DX の事前構築されたドライバとレポートは非常に便利ですが、当社では、現在の重点分野を把握するため、独自のカスタムクエリも追加しています。たとえば、プラットフォームとそのポータル（Backstage）の顧客満足度（CSAT）を測定したり、新入社員が pull リクエストの送信を開始するまでにかかる時間をデータとして収集したり、オンボーディングプロセスについてどのように感じたかを尋ねたりしています。さらに、最近では、AI コーディングアシスタントの有効性に関するエンジニアの意見を評価し始めました。これは、市場の分析情報に頼るだけでなく、AI コーディングアシスタントへのさらなる投資を正当化するためです。

このアプローチが役立った例として、ドキュメント化があります。具体的には、Backstage デベロッパーポータルに機能を組み込み、コンテンツを自動的に公開して見つけやすくするパイプラインを通じて、チームが互いのドキュメントを簡単に閲覧できるようにしました。

サービスの健全性 - 機能の導入とそれ以降

DORA や DX などから生成される分析情報以外にも、最近では、プラットフォーム自体に価値があるかどうかだけでなく、テナントがプラットフォームから期待される価値を得ているかどうかについても調べ始めています。つまり、プラットフォーム機能の導入結果の測定を効果的に始めたのです。

これを実現するため、社内で「技術的健全性」機能と呼んでいるものを構築しました。これは、カスタムプラグインの形で Backstage デベロッパーポータルと統合されています。このプラグインは、測定対象に関する情報を収集する多数の小規模なジョブから得られたデータを明らかにする社内 API をクエリします。これらのジョブはそれぞれ独立してリリースできるため、比較的迅速にスケールアップできました。

現在、4 つのカテゴリの健全性指標を収集しています。

技術的健全性: 現在、17 の「技術的」指標があります。たとえば、各チームが独自のリソースを「Terraform 化」するのではなく、当社の「Paved Road（舗装された道路）」パイプラインとカスタムマイクロサービス CRD（以前の記事 1 と 2 を参照）を使用しているかどうか、推奨される Kubernetes プラクティス（リソースのサイズ設定、中断予算、ライフサイクルプローブなど）に従っているかどうか、ベースイメージを最新の状態に保っているかどうかを測定することなどが挙げられます。また、変更を反映するためにパイプラインを十分な頻度で実行しているか（チームでは実行していません）、運用性評価を確認しているか、Git ブランチを最新の状態に保っているかなど、「よりソフトな」技術的対策も含まれます。
運用準備: 次に、運用面の健全性に関する 18 の指標があります。たとえば、プリフライト構成が整っているか、ランブックが作成されているか、ドキュメントが公開されているかなどです。これは、数年前の運用準備チェックリストの進化版です（当時はデリバリーチームと運用チームが分かれていたため、このようなチェックは「引き渡し」に必須でした）。このチェックリストは、一般的なリストではなく、チームが高い運用性を実現するのに役立つプラットフォームの特定の機能に合わせて調整されています。さらに、適切なプラクティスに従っていることをサービス管理チームが確信できるようになり、手動レビューの実施時に摩擦が生じることもなくなりました。
移行: プラットフォーム自体に変更があった場合、テナントはその変更に対応するために随時作業を行う必要があります。この典型的な例として、チームに非推奨の Kubernetes API バージョンに対処してもらうことが挙げられます。これには、古いやり方を排除するために、より強力に推進したいさまざまな機能を導入することも含まれます（たとえば、より安全な方法を優先するなど）。プラットフォームが成長するにつれて、チームが実行する必要がある移行作業が長期間にわたって続くことがわかりました。その結果、プロダクトマネージャーとデリバリーリードがチームのワークロードに優先順位を付けやすくなりました。
エンジニアリングプラクティスの拡大: 最近、この機能の使用範囲を広げ、他のチーム（この場合はエンジニアリングリーダーシップ）が独自の指標を組み込めるようにしました。たとえば、チームがデザインシステムのバージョンを最新の状態に保っているかどうかや、JL デジタルプラットフォームだけでなく、より広範なエンジニアリングプラクティスに従っているかどうかなどです。

このデータは、集計ビュー（下の例を参照）や個々のタスク、より広範なリーダーボードを通じて提示されます。これらはすべて、チームの優先事項に影響力を持つ人々の目に留まるように設計されています。エンジニアが信号を青に変えたいという欲求は、ドキュメントや発表に頼るよりもはるかに効果的な、強力なモチベーターになることがわかりました。

このテクノロジーは、Backstage ポータル用に構築したカスタムプラグインを通じて機能します。各「ヘルスチェック」は、それ自体が独自のマイクロサービス（多くの場合、ジョブとして実行される）であり、該当するシステムを調べて、測定基準が満たされているかどうかを判断します。たとえば、あるマイクロサービスは、Kubernetes に直接クエリを実行して PodDisruptionBudget が作成されていることを確認します。別のマイクロサービスは、コンテナイメージのレイヤを検査して、distroless のベースイメージが使用されているかどうかを確認します。新しい指標を作成するためのテンプレートが用意されているため、エンジニアは新しい指標を簡単に作成できます。プラットフォームチーム以外のエンジニアも同様です。結果は BigQuery に保存されます。Backstage プラグインの開発を簡素化する API も用意されています。

このような対策を導入した場合の現実として、プロダクトチームの作業量が増えることが挙げられます。そのためには、組織文化がこの変化に対応できることが重要です。プラットフォームの初期段階でこれらの対策を導入していた場合、製品の認識に影響が及んでいた可能性があります。たとえば、厳格すぎるとか、ガードレールによって変化のペースが阻害されるといった認識です。これは、全体的な導入に悪影響を及ぼす可能性があります。これらの機能を後から導入したことで、プラットフォームを非常に価値あるものとすでに認識していた多くのテナントの恩恵を受けることができました。さらに、適切な対策を選択し、一貫性のある方法で適用できるという自信も得られました。とはいえ、この取り組みを開始した後、プラットフォームの CSAT はわずかに低下しました。プロダクトチームが作業を吸収する時間を確保できるよう、各指標を導入するペースに配慮し、チームが自分たちに関係のない指標を抑制する手段を提供しています。たとえば、テナントがパフォーマンス上の理由で Pod の自動スケーリングを使用しないことを意図的に選択したり、当社のマイクロサービス CRD を使用できない機能上の理由が存在していたりする場合があります。

テナントの行動に関するこのような保証対策の導入は、プラットフォームの成熟度を反映しています。初期の頃は、高度なスキルを持つチームが、正しいことを迅速に行うことを期待していました。しかし、時間が経つにつれて、さまざまなスキルや能力、サービス所有権の移行が組み合わさったことで、適切な成果を上げるための手法を導入する必要に迫られました。これは、プラットフォーム自体が複雑になっていることも原因です。多くの新機能が追加されたため、新しいチームの認知負荷が以前よりもはるかに高くなっています。チームが「Paved Road（舗装された道路）」から外れないように、道路の端に沿ってライトを設置する必要がありました。

この進化の過程で、ビジネス自体の主な成果（つまり、当社はお客様が望むことを今も行っているか？）について報告し続けてきました。そのため、「迅速にチームを支援する」（正直なところ、これはほぼ解決済みの問題と見なされています）から「安全に実行し、技術的負債を管理する」へと自然に移行しました。

プラットフォームは期待に応えている？重要ポイント

要するに、デベロッパープラットフォームに価値があるかどうかという問題は複雑であり、それに答える方法はさまざまです。独自のデベロッパープラットフォームの構築と定量化に着手するにあたり、最後に留意すべき点をいくつかご紹介します。

測定は目的地ではなく道のりである: 関係者にとって意味のあるものを測定することから始めましょう。ただし、プラットフォームの進化に合わせて適応する準備もしておきましょう。最初は、プロダクトへのさらなる投資を優先してもかまいませんが、プラットフォームがチームにどのように役立っているかを実際に測定することをおすすめします。プラットフォームの実現可能性を最初に実証したときに重要だったことは、数年後に機能が成熟し、優先事項が変わったときには重要ではなくなっている可能性があります。
人間の声に耳を傾ける: プラットフォームが使用されているからといって、価値を生み出しているとは限りません。最も効果的な指標は、多くの場合、定性的なものです。エンジニアがツールを使用したいと思っていることや CSAT は重要なシグナルですが、どのように使用しているかを質問することで、どう改善できるかに関するより深い分析情報を得ることができます。測定だけでは、何が効果的で何がそうでないかを把握するのは困難です。
データはレポート作成だけでなく、チームの能力向上にも役立てる: グラフを経営陣に見せるだけでなく、分析情報をチームの改善に役立てましょう。さらに、行動の根拠となった具体的なデータを明確に示しましょう。たとえば、特定のチームのリリース頻度が低下していることがわかったら、それを問題として指摘するだけでなく、そのデータを使って潜在的な障害について話し合うきっかけにしましょう。そうすることで、リーダーシップとテナントの両方から信頼と好意を得て、プラットフォームを前進させ続けることができます。

John Lewis Partnership の測定戦略の進化は、説得力のあるケーススタディとして役立ちます。基本的なリードタイム追跡から、DORA の指標とデベロッパーからの定性的なフィードバックを組み合わせた包括的なモデルに移行することで、プラットフォームの真の成功は、単に導入率ではなく、プラットフォームが生み出す真の価値によって定義されることを実証しました。

Google Cloud のプラットフォームエンジニアリングについて詳しくは、他の記事をご覧ください（プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1、パート 2、プラットフォームエンジニアリングに関する 5 つの誤解: プラットフォームエンジニアリングとは一体なのか、プラットフォームエンジニアリングにまつわるさらなる 5 つの誤解）。また、App Hubについてもお読みになることをおすすめします。これは、組織全体でアプリケーション中心のガバナンスを管理するための基盤となるツールです。

- アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

- John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

スマートな投資: DORA で改善の文化を構築した FINRA の事例

Mon, 19 Jan 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 1 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

米国金融取引業規制機構（FINRA）は、テクノロジーの運用において常に最高水準の成果を目指しています。米国の金融ブローカーディーラーを監督する FINRA は、ソフトウェア開発ライフサイクルを改善するために、Google のコンサルタントを起用し、エンジニアリングプラクティスに指標主導の手法を適用するための助力を仰ぎました。

DORA（DevOps Research and Assessment）は広く利用されているフレームワークであり、デプロイの頻度、変更のリードタイム、変更時の障害率、デプロイ失敗時の復旧時間という 4 つの主要指標を通じてソフトウェアデリバリーのパフォーマンスを測定するというものです。

FINRA は DORA を社内で導入するための準備を始めていましたが、Google の実地経験を活かすことで、導入を加速できる可能性があるという認識に至りました。

Google は、技術系のリーダーとともに調査を実施し、改善機会を特定しました。その後の提案は、継続的な改善にこれまで以上に注力すること、ソフトウェア開発にユーザー中心のアプローチを導入すること、部門内で創造的文化をさらに醸成することなどで構成されていました。

導入自体には意図的に柔軟性を持たせました。Google は、画一的なアプローチを推奨するのではなく、FINRA が個々のチームの目標に合わせて行動を調整できるよう支援しました。プロダクトの価値を優先するチームはリードタイムとデプロイ頻度の指標に、安定性を重視するチームは変更障害率と平均復旧時間に着目しました。

導入の最初の 1 年間で、エンジニアリングチームは DORA の指標全体で継続的な改善を示し、デベロッパー 1 人あたりの生産性が 9% 向上して、デベロッパーエクスペリエンスに関するフィードバックも概ね良好でした。

スプリントの速度も 5% 向上し、小規模なエンジニアリングチームでもビジネスに大きなプロダクト付加価値を提供できるようになりました。純粋な指標だけでなく、チームはデリバリーパフォーマンスの透明性が高まり、標準化された測定手法を高く評価しているとも報告しています。

今後、FINRA は、大局的な DORA 測定と結び付いたより詳細な指標を提供して、開発者のエクスペリエンスをより重視し、プロダクト指標とソフトウェアデリバリーのパフォーマンス指標を関連付けることで、DORA の取り組みを成熟させていく予定です。

AI が政府機関、非営利団体、その他の公共部門の組織にどのような価値をもたらすのか関心がある方は、2 月 5 日に開催される Gemini for Government ウェブセミナーにぜひご登録ください。公共部門全体にわたるイノベーションの次の波を支える変革的なテクノロジーについて詳しくご説明します。

- Google Cloud コンサルティング、delta チーム、10X リード、Eric Maxwell

- Google Cloud コンサルティング、delta チーム、10X リード、Vivian Hu

導入から成果まで: DORA AI 機能モデルの活用

Wed, 17 Dec 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 12 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

2025 年「AI 支援型ソフトウェア開発の現状」レポートでは、重要な事実が明らかになりました。AI は増幅器のように機能し、パフォーマンスの高い組織の強みと、苦戦している組織の機能不全を拡大しています。

AI の導入はほぼ当たり前となり、90% のデベロッパーが日々のワークフローで AI を使用していますが、必ずしも成功が保証されているわけではありません。約 5,000 人の技術専門職を対象としたクラスタ分析により、チームのパフォーマンスには大きなばらつきがあることが明らかになりました。AI を導入しても、誰もが同じ成果を得られるわけではないのです。

このことから、AI の使い方が成功を左右する重要な要素であることがわかります。チームがよい成果を達成するために必要な機能と条件を把握したいと考え、DORA AI 機能モデルのレポートを作成しました。

2025 年 DORA レポートに付随するこのガイドは、新たな世界で生き残っていく一助になります。テクノロジーリーダーが AI を活用できる環境を構築できるよう、実用的な戦略、実装戦術、測定フレームワークを提供します。

成果を増幅させる 7 つの要因

AI を効果的に使用するには、技術的環境と文化的環境を整える必要があります。2025 年の DORA アンケートに参加した回答者を分析し、組織のパフォーマンスに対する AI のプラスの効果を増幅させる 7 つの基盤的要因を特定しました。

明確で周知された AI ポリシー: 曖昧さはリスクを生み出します。ポリシーを明確にすることで、開発者が効果的に挑戦するための心理的安全性が確保されます。
健全なデータエコシステム: AI の品質は入力するデータの質によって決まります。高品質でアクセスしやすく、統合された内部データに投資することで、AI のメリットが大幅に増幅されます。
AI がアクセス可能な社内データ: 単純なプロンプトを超え、「コンテキストエンジニアリング」によって AI ツールを社内のドキュメントやコードベースに安全に接続することが求められます。
強固なバージョン管理プラクティス: AI によってコード生成の量と速度が増加するにつれて、バージョン管理が重要なセーフティネットとなります。頻繁な commit と堅牢なロールバック機能は、AI を活用した世界で安定性を維持するために不可欠です。
小規模バッチでの作業: AI は大量のコードブロックを簡単に生成できますが、そのレビューやテストは容易ではありません。小規模バッチの規律を徹底することで、このリスクを軽減し、開発速度の向上が不安定さではなくプロダクトの性能改善につながるようにします。
ユーザー中心の視点: 間違った方向に進んでいれば、スピードは意味を持ちません。ユーザー中心の視点が欠けているチームが AI ツールを導入すると、かえって悪影響を受ける可能性があります。常にユーザーのニーズを指針とすることが、AI を活用した開発を導くうえで不可欠です。
質の高い社内プラットフォーム: プラットフォームを通じ、自動化された安全な環境を提供することで、AI のメリットを組織全体に拡大できます。これにより、個々の生産性向上が下流工程のボトルネックによって失われることを防ぎます。

DORA AI 機能モデルは、具体的な成果に対する AI の導入効果を増幅させる要因を明らかにします。

導入の第一歩: チームの評価

AI の導入プロセスは組織によって異なります。このレポートでは、優先順位付けに役立つよう、クラスタ分析から導き出された 7 種類のチーム類型を紹介しています。パフォーマンスとウェルビーイングの両方に優れた「調和のとれた高パフォーマンス」チームから、「基盤的課題」に直面するチーム、不安定なシステムにより士気が低下する「レガシーのボトルネック」に陥っているチームまで、プロファイルは多岐にわたります。

自分のチームに最も合致するプロファイルを把握することで、最も効果的な介入策を特定できます。たとえば、「成果は大きいが回転率は悪い」チームの場合は安定性向上のために自動化を優先する、「プロセスに制約がある」チームの場合は AI ポリシーを改善して摩擦を減らす、といった対策が考えられます。

バリューストリームマッピングで詳細に分析

チームのプロファイルを把握したら、どこに力を注げばよいでしょうか。レポートには、バリューストリームマッピング（VSM）演習を実施するための段階的なファシリテーションガイドが含まれています。

VSM は AI の効果を増幅させる役割を果たし、アイデアから顧客までのフローを可視化することで、作業の停滞や摩擦が生じている部分を特定します。これにより、AI による効率向上が、下流工程で作業を滞留させるだけの局所的な最適化にとどまらず、システム全体の制約解消に向けて活用されるようになります。

継続的な改善の基盤を築く

AI の導入は組織の変革です。最大の成果は、ツール自体からではなく、それを支える基盤システムへの投資によって得られます。

レポート全文をダウンロードする
DORA コミュニティに参加する

-DORA リーダー Nathen Harvey

-シニアプロダクトマーケティングマネージャー、Allison Park

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

Mon, 27 Oct 2025 01:30:00 +0000

※この投稿は米国時間 2025 年 10 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

エンジニアであれば誰でも、完璧な復元力を持つシステムを夢見ます。完璧にスケーリングし、優れたユーザーエクスペリエンスを提供し、決してダウンしないシステムです。このような復元力のあるシステムを構築する鍵が、障害を回避することではなく、意図的に障害を引き起こすことだとしたらどうでしょうか。カオスエンジニアリングの世界へようこそ。ここでは、管理された環境でシステムにカオス（障害）を導入して、システムにストレステストを行います。ダウンタイムが数百万ドルの損失につながり、評判が瞬く間に失墜する時代において、最も革新的な企業としては、災害が起こるのをただ待っているだけではいけません。災害を意図的に引き起こし、その結果として生じる障害から学び、本番環境で混乱が起こる前に混乱に対する免疫を獲得して行くのです。

カオスエンジニアリングはあらゆる種類のシステムに役立ちますが、特にクラウドベースの分散システムに有効です。最新のアーキテクチャは、モノリシックなシステムからマイクロサービスベースのシステムへと進化し、多くの場合、数百から数千のサービスで構成されています。このように複雑なサービス依存関係は、複数の障害点をもたらします。また、従来のテスト方法では、あらゆる障害モードを予測することは、不可能ではなくても、困難です。これらのアプリケーションをクラウドにデプロイすると、複数のアベイラビリティゾーンとリージョンにデプロイされます。クラウド環境は分散性が高く、多数のサービスが共存しているため、障害の発生する可能性が高くなっています。

良くある誤解ですが、クラウド環境ではアプリケーションには自ずと復元力があるので、テストは不要であるというものがあります。クラウドプロバイダは、クラウドプロダクトに対してさまざまなレベルの復元力と SLA を提供していますが、これだけではビジネスアプリケーションが保護されるとは限りません。アプリケーションがフォールトトレラントになるように設計されていない場合や、クラウドサービスが常に利用可能であることを前提としている場合、依存している特定のクラウドサービスが利用できなくなると、アプリケーションは動作しなくなります。

手短に言えば、カオスエンジニアリングは、担当者にとって最悪の「もしも」のシナリオを想定し、それに対する対応を十分にリハーサルできるようにします。カオスエンジニアリングは、システムを破壊すること（いわばカオスなエンジニアリング）ではありません。カオスエンジニアリングは、管理された条件下とはいえ、すでにカオスを乗り切った経験から得られる冷静な自信を持って本番環境のインシデントに対処できるチームを構築することです。

Google Cloud の Professional Service Organization（PSO）エンタープライズアーキテクチャチームは、アプリケーション開発、クラウド移行、エンタープライズアーキテクチャなど、お客様のクラウド変革の取り組みについてコンサルティングを行い、実践的な専門知識を提供しています。また、クラウド環境向けの復元力のあるアーキテクチャの設計についてアドバイスする際には、カオスエンジニアリングの原則とプラクティス、およびサイト信頼性エンジニアリング（SRE）のプラクティスを定期的に紹介しています。

シリーズの最初になるこのブログ投稿では、カオスエンジニアリングの基本、つまりカオスエンジニアリングとは何か、そのコアとなる原則と要素について説明します。次に、クラウドで分散アプリケーションを実行しているチームにとって、カオスエンジニアリングが特に役立ち、重要である理由を説明します。最後に、これを活用開始する方法と、その他のリソースについて説明します。

カオスエンジニアリングについて

カオスエンジニアリングは、Netflix が 2010 年に考案した手法です。AWS 環境の複雑度が上がる中、より復元力と信頼性が高いシステムを構築する必要性に対処するため、「Chaos Monkey」を作り出し、普及させました。同じ頃、Google は障害復旧テスト（DiRT）を導入しました。これにより、Google のビジネス、システム、データの継続的て、自動的な障害対策、対応、復旧が可能になりました。Google Cloud の PSO チームでは、お客様が SRE プラクティスの一環として DiRT を実装できるよう、さまざまなサービスを提供しています。これらのサービスには、Google Cloud で動作するアプリケーションやシステムで DiRT を実行する方法に関するトレーニングも含まれています。中心となるコンセプトは単純です。管理された障害を意図的にシステムに導入して、脆弱性を特定し、その復元力を評価し、全体的な信頼性を高めるというものです。

予防的な手法であるカオスエンジニアリングにより、組織はシステム内の弱点を、大規模なサービス停止や障害につながる前に特定できます。ここで言うシステムには、技術的なコンポーネントだけでなく、組織の人員やプロセスまでも含まれます。カオスエンジニアリングでは、管理された、実際の停止状態を導入することで、システムの堅牢性、復元可能性、フォールトトレランスをテストできます。このアプローチによって担当者は潜在的な脆弱性を発見できるため、システムは予期しないイベントに対処し、ストレス下でもスムーズに機能し続けることができます。

カオスエンジニアリングの原則と実践

カオスエンジニアリングは、これを実施すべき理由に関する一連の基本原則によって導かれ、また実践は実施すべき内容を定めます。

カオスエンジニアリングの原則は次のとおりです。

定常状態に関する仮説を立てる: 停止を引き起こすアクションを開始する前に、システムにとっての「正常」な状態がどのようなものかを決定する必要があります。これは一般に「定常状態仮説」と呼ばれます。
現実世界の状況を再現する: カオステストでは、本番環境でシステムが遭遇する可能性のある現実的な障害シナリオをエミュレートします。
本番環境でテストを実行する: カオスエンジニアリングは、実際のトラフィックと、依存関係の両方がある本番環境でのみ復元力の正確な全体像を把握できるという信念にしっかりと根ざしています。これが、カオスエンジニアリングと従来のテストの違いです。
テストの自動化: 復元力テストを、一度限りのテストではなく、継続的なプロセスの一部にします。
影響範囲を特定する: 本番環境システムへの悪影響を最小限に抑えるために、テストは綿密に設計する必要があります。そのためには、テストが顧客や他のアプリケーション、サービスに与える影響に基づいて、アプリケーションとサービスをさまざまな階層に分類する必要があります。

これらの原則を確立したら、カオスエンジニアリングのテストを実施する際に次の手法に従います。

定常状態を定義する: 注目する特定の指標（レイテンシ、スループットなど）を特定し、それらのベースラインを確立します。
仮説を立てる: これは、テスト可能な単一のステートメントを作成する手法です。たとえば、「このコンテナ Pod を削除しても、ユーザーのログインには影響しない」などです。仮説は通常、お客様のユーザージャーニーを特定し、そこからテストシナリオを導き出すことで作成されます。
管理された環境を使用する: カオスエンジニアリングの原則の一つに、テストは本番環境で実行する必要があるというものがありますが、まずは小規模に始め、非本番環境でテストを実行し、学び、調整してから、徐々に本番環境に範囲を拡大するようにしてください。
障害の注入: これは、システムに直接（VM の削除、データベースインスタンスの停止など）または環境に間接的に（ネットワークルートの削除、ファイアウォールルールの追加など）障害を注入して、停止状態を引き起こす手法です。
テストの実行を自動化する: カオスエンジニアリングを再現可能でスケーラブルなプラクティスとして確立するには、自動化が不可欠です。これには、障害注入に自動ツールを使用すること（CI/CD パイプラインの一部にするなど）や、自動ロールバックメカニズムを使用することが含まれます。
行動につながるインサイトを導き出す: カオスエンジニアリングを使用する主な目的は、システムの脆弱性に関するインサイトを導き出し、それによって復元力を高めることです。これには、テスト結果の厳密な分析、弱点と改善すべき点の特定、関連チームへのテスト結果の周知が含まれ、これによってその後のテスト設計とシステム強化を行います。

つまり、カオスエンジニアリングは、単にシステムを壊すことが目的ではなく、システムの限界を理解し、それらに事前に対処することで、より復元力の高いシステムを構築することが目的です。

カオスエンジニアリングの要素

カオスエンジニアリングテストで使用するコア要素は、次の 5 つの原則から導き出されます。

テスト: カオステストは、システムに障害を発生させてその応答を確認する、意図的で事前に計画された手順で構成されます。
定常状態仮説: 定常状態仮説は、評価対象のシステムのベースラインとなる運用状態、つまり「正常」な動作を定義します。
アクション: アクションは、テスト対象のシステムに対して実行される具体的なオペレーションを表します。
プローブ: プローブは、テスト中にシステム内で定義された条件を観察するメカニズムを提供します。
ロールバック: テストでは、テスト中に実装された変更を元に戻すように設計された一連のアクションが組み込まれる場合があります。

カオスエンジニアリングを開始する

カオスエンジニアリングと、クラウド環境でカオスエンジニアリングを使用する理由について理解を深めたら、次のステップとして、独自の開発環境で実際に試してみましょう。

市場には複数のカオスエンジニアリングソリューションがあります。有料のプロダクトもあれば、オープンソースのフレームワークもあります。すぐに始めるには、Chaos Toolkit をカオスエンジニアリングフレームワークとして使用することをおすすめします。

Chaos Toolkit は、Python で記述されたオープンソースのフレームワークです。モジュール式のアーキテクチャが提供されており、他のライブラリ（「ドライバ」とも呼ばれます）をプラグインして、カオスエンジニアリングのテストを拡張できます。たとえば、Google Cloud、Kubernetes、その他多くのテクノロジーの拡張ライブラリがあります。Chaos Toolkit は Python ベースの開発者ツールであるため、まず Python 環境を構成します。Chaos Toolkit のテストの優れた例と、その手順については、こちらをご覧ください。

最後に、Google Cloud のお客様とエンジニアがアプリケーションにカオステストを導入できるように、特に Google Cloud のための一群のカオスエンジニアリングレシピを作成しました。各レシピには、特定の Google Cloud サービスにカオスを導入する特定のシナリオを収めています。たとえば、あるレシピでは Google Cloud の内部または外部アプリケーションロードバランサの背後で実行されているアプリケーション/サービスにカオスを導入し、また別のレシピでは ToxiProxy という別の Chaos Toolkit 拡張機能を利用して、Cloud Run で実行されているアプリケーションと Cloud SQL データベースに接続するアプリケーション間のネットワーク停止をシミュレートします。

Google Cloud 環境にカオスエンジニアリングを導入する方法を学ぶための、手順ガイド、スクリプト、サンプルコードを含むレシピの完全なコレクションは、GitHub にあります。今後の投稿では、Google Cloud 環境に障害を導入する方法など、カオスエンジニアリングの手法を取り上げますので、ご期待ください。

-Parag Doshi、キーエンタープライズアーキテクト

2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状

Wed, 08 Oct 2025 01:20:00 +0000

※この投稿は米国時間 2025 年 9 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状を発表しました。本レポートは、100 時間を超える定性データと、世界中の約 5,000 人の技術専門家からのアンケート回答から得られた分析情報に基づいています。

レポートでは、重要なインサイトが明らかになっています。AI はチームを修正するのではなく、すでに存在するものを増幅するのです。優れたチームは AI を活用して、さらに優れた、より効率的なチームになります。一方、苦戦しているチームでは、AI が既存の問題を浮き彫りにして悪化させるだけだと感じるでしょう。最大の成果は、AI ツール自体からではなく、社内プラットフォームの品質、ワークフローの明確さ、チームの連携に戦略的に焦点を当てることで得られます。

AI は偉大な増幅器

2024 年のレポートと、今年公開された特別レポート「Impact of Generative AI in Software Development」で明らかになったように、組織は AI の導入を積極的に進めており、重要な成果において大きなメリットを得ています。また、これらのツールをワークフローにうまく統合するための学習の証拠もあります。昨年とは異なり、ソフトウェアデリバリースループットとプロダクトパフォーマンスの両方で、AI の導入と正の相関関係が認められました。AI が最も役立つ場所、タイミング、方法を、人、チーム、ツールが学習しているようです。ただし、AI の導入は、引き続きソフトウェアデリバリーの安定性と負の相関関係にあります。

これは、AI がソフトウェア開発を加速するものの、その加速によって下流で弱点が露呈する可能性があるという、Google の中心的な理論を裏付けるものです。強力な自動テスト、成熟したバージョン管理プラクティス、迅速なフィードバックループなどの堅牢な制御システムがない場合、変更量の増加は不安定につながります。フィードバックループが高速な疎結合アーキテクチャで作業するチームは成果を上げますが、密結合システムと遅いプロセスに制約されるチームはほとんど、またはまったくメリットがありません。

2025 年レポートの主な調査結果

この中心的なテーマ以外にも、今年の調査では、最新のソフトウェア開発について以下のことが明らかになりました。

AI の導入はほぼ普遍的: アンケート回答者の 90% が、仕事で AI を使用していると回答しており、そのうち 80% 以上が生産性の向上を実感しています。しかし、AI が生成したコードをほとんど、またはまったく信頼していないと回答した人が 30% にも上り、依然として懐疑的な見方が残っています。この割合は昨年よりわずかに低いものの、注目すべき重要な傾向です。
ユーザー中心主義は AI の成功の前提条件: AI は、明確な問題に焦点を当てたときに最も有用になります。ユーザー中心主義は、その重要な方向性を提供します。Google のデータによると、この重点的な取り組みにより、チームのパフォーマンスに対する AI のプラスの影響が拡大しています。
プラットフォームエンジニアリングは基盤: Google のデータによると、90% の組織が少なくとも 1 つのプラットフォームを採用しており、高品質な内部プラットフォームと組織が AI の価値を引き出す能力の間には直接的な相関関係があります。そのため、プラットフォームエンジニアリングは成功に不可欠な基盤となります。

7 つのチームのアーキタイプ

単純なソフトウェアデリバリー指標だけでは十分ではありません。何が起こっているかはわかっても、その理由がわからないからです。パフォーマンスデータとエクスペリエンスを結び付けるために、クラスタ分析を実施しました。その結果、7 つの一般的なチームプロファイルまたはアーキタイプが明らかになりました。それぞれが、パフォーマンス、安定性、ウェルビーイングの独自の相互作用を示しています。このモデルでは、リーダーがチームの健全性を診断し、適切な介入を適用する方法を提供します。

「基本的な課題」グループは、サバイバルモードに陥っており、プロセスと環境に大きなギャップがあるため、パフォーマンスが低く、システムの安定性が高く、燃え尽き症候群や摩擦のレベルが高い状態です。「調和のとれた高パフォーマンス」は、チームのウェルビーイング、プロダクトの成果、ソフトウェアデリバリーなど、複数の分野で優れた成果を上げています。

各アーキタイプの詳細については、レポートの「ソフトウェアデリバリーのパフォーマンスを理解する: 7 つのチームプロファイル」の章をご覧ください。

「DORA AI 機能モデル」で AI の価値を引き出す

今年は、AI の影響を特定するだけでなく、AI 支援技術の専門家が最良の結果を実現する条件を調査しました。AI の価値は、ツール自体ではなく、それを取り巻く技術的慣行と文化的環境によって引き出されます。

Google の調査では、組織における AI のプラスの効果を拡大することが示されている 7 つの能力を特定しました。

リーダーが最初に取り組むべきこと

今年の調査から得られた重要なインサイトの一つは、AI の価値は、AI が存在する仕事のシステムを再構築することで引き出されるということです。テクノロジーリーダーは、AI の導入を組織の変革として捉える必要があります。

まずは以下から始めることをおすすめします。

AI ポリシーを明確化して周知する
AI を社内のコンテキストに接続する
基本的なプラクティスを優先する
セーフティネットを強化する
社内プラットフォームに投資する
エンドユーザーに焦点を当てる

DORA 調査プログラムは、AI を活用した重要な変革期を乗り切るための指針として、チームや組織に役立つよう努めています。新しいチームプロフィールと DORA AI 機能モデルが、AI を単に導入するだけでなく、チームと人材に投資して AI の価値を引き出すための明確なロードマップとなることを願っています。これらの分析情報をどのように活用されるか、楽しみにしております。詳細を確認する方法:

レポート全文をダウンロードする。
DORA コミュニティに参加する
同僚とこの概要を共有する

-DORA リーダー、Nathen Harvey

-リサーチャー、Derek DeBellis

Google Cloud の設定のご紹介: 安全なクラウド基盤へのガイド付きパスウェイ

Mon, 01 Sep 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 8 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud の力を活用する準備はできていますか？環境を効果的に設定する方法についてガイダンスが必要ですか？クラウド初心者の方も、重要なワークロードの移行を検討している経験豊富なチームの一員の方も、基盤となるインフラストラクチャを適切に構築することが成功の鍵となります。そこで役立つのが Google Cloud の設定です。これは、安全なクラウド基盤を構築し、Google Cloud をすぐに使い始めるためのガイド付きのパスウェイです。

Google Cloud の設定では、Google Cloud が推奨するベストプラクティスを迅速に実装できます。Google の目標は、不要な構成作業を行うことなく、ワークロードを迅速かつ簡単にデプロイできるようにすることです。これは、重要な最初のステップをガイドするエキスパートのようなものです。これにより、お客様は真に重要なこと、つまり革新的なアプリケーションやサービスの迅速なデプロイに集中できます。金銭的な障壁なく使用を開始できるように、セットアッププロセスで有効にしたすべてのコンポーネントとサービス統合は無料であるか、ある程度の無料アクセスが含まれています。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbeff2ac0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ニーズに合ったファンデーションを選びましょう

Google は、すべての組織とプロジェクトに固有の要件があることを理解しています。そのため、Google Cloud の設定では、3 つの異なるガイド付きフローから選択できます。

概念実証: Google Cloud を探索し、初期テストやサンドボックスワークロードを実行するための軽量環境をセットアップしたいユーザー向けに設計されています。このフローでは、迅速に開始するための最小限の構成に焦点を当てています。
本番環境: このフローは、セキュリティとスケーラビリティを考慮して、プロダクションレディなワークロードをサポートする場合に推奨されます。Google Cloud のベストプラクティスに沿っており、本番環境ワークロードの基本的な基盤インフラストラクチャをセットアップする管理者に合わせて調整されています。
セキュリティ強化（プレビュー版）: 高度なセキュリティとコンプライアンスの要件がある組織、リージョン、ワークロード向けに設計されたフローです。デフォルトでより高度なセキュリティ管理が適用され、厳格な要件を満たすのに役立ちます。この高度な基盤でも、一定の使用量上限までは永続的な無料枠が提供されます。

強固な基盤を構築するための構成要素

Google Cloud の設定では、一連のオンボーディング手順が案内され、Google Cloud のベストプラクティスに裏付けられたデフォルトが提示されます。このプロセス全体を通して、組織の保護と成長の準備に役立つ主な機能も紹介します。

Cloud KMS AutoKey: 顧客管理の暗号鍵（CMEK）のプロビジョニングと割り当てを自動化します。
Security Command Center: オープンポートやアクセス制御の構成ミスなどのセキュリティ上の問題について、プロジェクトの自動スキャンを含む Google Cloud デプロイのセキュリティポスチャー管理を提供します。
一元化されたロギングとモニタリング: システムの健全性とパフォーマンスを一元的なロケーションからモニタリングするインフラストラクチャを簡単に設定できます。これは、監査ログのコンプライアンスとプロジェクト全体の指標の可視化に不可欠です。
共有 VPC ネットワーク: 複数のプロジェクトにわたって一元化されたネットワークを確立し、Google Cloud リソース間の安全かつ効率的な通信を可能にします。
ハイブリッド接続: Google Cloud 環境をオンプレミスインフラストラクチャや他のクラウドプロバイダに接続しやすくします。これは、ワークロードの移行において重要なステップとなることがよくあります。
サポートプラン: Google Cloud のエキスパートのサポートを受けて問題をすばやく解決できます。

ガイド付きフローの最後で、Google Cloud コンソールから直接構成をデプロイするか、Terraform 構成ファイルをダウンロードして、他の Infrastructure as Code（IaC）メソッドを使用して後でデプロイできます。

クラウドをより迅速かつスマートに活用

Google Cloud の設定エクスペリエンスを使用する組織には、以下のようなメリットがあります。

アプリケーションのデプロイを迅速化: 初期設定を簡素化することで、アプリケーションをより迅速に稼働させ、クラウドへの移行を加速できます。
セットアップの労力を削減: 合理化されたフローにより、手動の手順が大幅に削減され、少ない労力で基本的な基盤を確立できます。
Google Cloud の可能性を最大限に活用: 強固な基盤を迅速に確立することで、幅広い Google Cloud サービスをより簡単に探索して活用し、進化するニーズに対応して、より大きな価値を引き出すことができます。

Google Cloud の利用を開始する準備はできましたか？Google Cloud の設定にアクセスして、安全なクラウド基盤への合理化されたパスを今すぐご確認ください。イノベーションと成長に集中できるよう、初期手順をご案内します。

詳細については、以下のページをご確認ください。

Google Cloud の設定のドキュメント
Google Cloud の設定の概要（ログインが必要）

ーエンジニアリングマネージャー、Stacie Buckingham

ーシニアプロダクトマネージャー、Vladimir Andral

Cloud Hub の最適化と Cost Explorer を使用してクラウド費用を最適化する

Wed, 20 Aug 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 8 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションオーナーがクラウド費用の最適化を検討する際に求めているのは、次の 3 つです。

最も費用のかかるリソースはどれですか？
今週または今月、どのリソースの費用が上がっているか？
利用率が低いリソースはどれか？

これらの質問にすばやく簡単に回答できるように、Google は Google Cloud Next 2025 で、プライベートプレビュー版の Cloud Hub Optimization と Cost Explorer を発表しました。そしてこのたび、Cloud ハブの最適化と費用エクスプローラの両方が公開プレビュー版で利用可能になりました。

アプリケーションの費用と使用率

アプリのオーナーとして、主な目標はアプリケーションを常に健全な状態に保つことです。しかし、数十のプロジェクトにまたがる可能性のあるアプリケーションの個々のコンポーネントをすべてモニタリングするのは、非常に大変な作業です。AppHub アプリケーションを使用すると、アプリケーションを中心にクラウドを再編成し、必要な情報と制御をすぐに利用できます。

Cloud Hub Optimization と Cost Explorer は、Google Cloud プロジェクトをサポートするだけでなく、App Hub アプリケーションを活用して、アプリケーションのワークロードとサービスの費用対効果を即座に表示します。これは、GPU などの貴重なリソースを無駄にしている可能性のある、GKE クラスタで実行されているデプロイを特定しようとする場合などに最適です。

単なる費用ダッシュボードではありません

Cloud Hub Optimization を表示すると、最も費用がかかっているリソースと、その費用の変化率をすぐに確認できます。このきめ細かい費用情報により、費用を特定のリソースやリソース所有者に帰属させ、費用の変化について推論できるようになりました。

さらに、Cloud Billing の詳細な費用データと Cloud Monitoring のリソース使用率データを統合し、費用効率を包括的に把握できるようにしました。これには、プロジェクトの平均 vCPU 使用率が含まれます。これにより、数百の Google Cloud プロジェクトの中から、最も有望な最適化候補を見つけることができます。

Cost Explorer ダッシュボードでは、プロダクトレベルで論理的に整理された費用も表示されるため、費用の説明がさらに容易になります。Compute Engine の総額費用ではなく、Google Kubernetes Engine（GKE）クラスタ、永続ディスク、Cloud Load Balancing など、個々のプロダクトの正確な費用を確認できるようになりました。

シンプルが故の力強さ。

これらの新しいツールを試したお客様は、表示される情報とインターフェースのシンプルさを気に入っています。

「私のチームは、数十の事業部門と数百人の開発者のクラウド費用を監視する必要があります。Cloud Hub の最適化と費用エクスプローラダッシュボードは、費用削減の可能性や最適化の機会を探す場所を教えてくれるため、チームの能力を何倍にも高めてくれます。」 - メジャーリーグベースボール、プリンシパルクラウドアーキテクト、Frank Dice 氏

お客様は、追加のセットアップなしですぐに利用できる幅広いプロダクトカバレッジと、これらの機能を使用しても追加料金が発生しないことを特に高く評価しています。

次のステップ

組織がクラウド費用管理を「左シフト」するにつれて、Google はアプリケーションオーナーと開発者がクラウド費用を理解して最適化できるよう支援しています。Cloud Hub Optimize と費用エクスプローラはこちらからお試しいただけます。

Google Cloud Next 2025 の講演「Maximize Your Cloud ROI」では、Cloud Hub Optimization と Cost Explorer を使用して、使用率の低い GKE クラスタを数秒で特定する方法のライブデモもご覧いただけます。

^{メジャーリーグベースボールの商標および著作権は、メジャーリーグベースボールの許可を得て使用されています。MLB.com をご覧ください。}

ープロダクトマネージャー Gobind Johar

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

Thu, 17 Jul 2025 03:00:00 +0000

※この投稿は米国時間 2025 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、次世代の AI アプリケーションとエージェントアプリケーションをできるだけシームレスに構築、デプロイできるように取り組んでいます。このたび、Google はDocker とのコラボレーションにより、デプロイワークフローを大幅に簡素化し、高度な AI アプリケーションをローカル開発から Cloud Run に簡単に移行できます。

compose.yaml を Cloud Run に直接デプロイ

以前は、開発環境と Cloud Run などのマネージドプラットフォームのギャップを埋めるには、インフラストラクチャを手動で変換して構成する必要がありました。MCP サーバーと自己ホスト型モデルを使用するエージェントアプリケーションは、さらに複雑さを増しました。

オープンソースの Compose Specification は、開発者がローカル環境で複雑なアプリケーションをイテレーションする最も一般的な方法の一つであり、Docker Compose の基盤となっています。そして、gcloud run compose up によって、Docker Compose のシンプルさが Cloud Run にもたらされ、このプロセス全体が自動化されます。現在限定公開プレビュー版のこの機能を使用すると、既存の compose.yaml ファイルを単一のコマンドで Cloud Run にデプロイできます。これには、ソースからのコンテナのビルドや、データ永続化のための Cloud Run のボリュームマウントの活用も含まれます。

Cloud Run で Compose Specification をサポートすることで、ローカルとクラウドのデプロイを簡単に移行できます。同じ構成形式を維持できるため、一貫性が確保され、開発サイクルが加速します。

「Docker Compose は最近、エージェントアプリケーションをサポートするように進化しました。GPU を利用した実行をサポートする Google Cloud Run にもそのイノベーションが広がったことを嬉しく思います。Docker と Cloud Run を使用することで、開発者はローカルでイテレーションを行い、1 つのコマンドでインテリジェントエージェントを本番環境に大規模にデプロイできるようになりました。これは、AI ネイティブな開発をアクセス可能で構成可能なものにするための大きな一歩です。Google Cloud との緊密なコラボレーションを継続し、開発者が次世代のインテリジェントアプリケーションを構築、実行する方法を簡素化できることを楽しみにしています」- Docker、エンジニアリングおよびプロダクト担当エグゼクティブバイスプレジデント Tushar Jain 氏

AI アプリケーションのホーム、Cloud Run

Cloud Run には、Compose Specification のサポート以外にも、AI に適したイノベーションが備わっています。Google は最近、Cloud Run GPU の一般提供を発表しました。これにより、AI ワークロードに GPU を利用したい開発者にとって、導入の大きな障壁が取り除かれました。Cloud Run は、秒単位の課金、ゼロへのスケーリング、迅速なスケーリング（gemma3:4b モデルの場合、最初のトークンまでの時間は約 19 秒）を備えており、LLM のデプロイとサービングに最適なホスティングソリューションです。

また、Cloud Run は Docker が最近発表した OSS MCP Gateway と Model Runner の強力なソリューションでもあり、開発者は AI アプリケーションをローカルからクラウドのプロダクションにシームレスに移行できます。Docker が最近オープンな Compose Specification に「モデル」を追加したことをサポートすることで、これらの複雑なソリューションを 1 つのコマンドでクラウドにデプロイできます。

まとめ

上記のデモの compose ファイルを確認しましょう。これは、ソースから構築され、ストレージボリューム（volumes で定義）を利用するマルチコンテナアプリケーション（services で定義）で構成されています。また、新しい models 属性を使用して、AI モデルと、使用するランタイムイメージを定義する Cloud Run 拡張機能を定義します。

code_block: <ListValue: [StructValue([('code', 'name: agent\r\nservices:\r\n webapp:\r\n build: .\r\n ports:\r\n - "8080:8080"\r\n volumes:\r\n - web_images:/assets/images\r\n depends_on:\r\n - adk\r\n\r\n adk:\r\n image: us-central1-docker.pkg.dev/jmahood-demo/adk:latest\r\n ports:\r\n - "3000:3000"\r\n models:\r\n - ai-model\r\n\r\nmodels:\r\n ai-model:\r\n model: ai/gemma3-qat:4B-Q4_K_M\r\n x-google-cloudrun:\r\n inference-endpoint: docker/model-runner:latest-cuda12.2.2\r\n\r\nvolumes:\r\n web_images:'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fabb8570730>)])]>

AI の未来を築く

Google は、オープンスタンダードを採用し、さまざまなエージェントフレームワークをサポートすることで、デベロッパーに最大限の柔軟性と選択肢を提供することに尽力しています。 Cloud Run と Docker に関する今回のコラボレーションは、デベロッパーがインテリジェントアプリケーションを構築、デプロイするプロセスを簡素化するという Google の目標を達成するためのもう一つの例です。

Compose Specification のサポートは、信頼できるユーザー様にご利用いただけます。限定公開プレビュー版にこちらからご登録ください。

-Cloud Run 担当プロダクトマネージャー、Justin Mahood

-Google Cloud、エンジニアリング担当ディレクター、Yunong Xiao

プラットフォームエンジニアリングを駆使してデベロッパーエクスペリエンスを簡素化 - パート 2

Thu, 17 Jul 2025 01:04:00 +0000

※この投稿は米国時間 2025 年 6 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

前回の記事では、John Lewis Digital Platform と、プラットフォームエンジニアリングと「舗装道路」機能を通じてデベロッパーエクスペリエンスを簡素化するアプローチを紹介し、Google Cloud でのリソース作成や、専用のテナント環境内でのプラットフォームの運用機能とセキュリティ機能のデプロイをプラットフォームエンジニアリングによって実現する方法に焦点を当てました。この記事では、そのコンセプトを基に、プラットフォームによってコンポーネント（通常はマイクロサービス）レベルでもビルドと実行を簡素化する方法について、さらに詳しく説明します。

わずか 1 年ほどで、John Lewis Digital Platform は完全に製品レベルに進化しました。当社のプラットフォームを使用するチームは約 25 チームで、本番環境で実行されている johnlewis.com の小売ウェブサイトの主要な部分でも使用されています。チームが Google Cloud でリソースをプロビジョニングできるようにセルフサービス機能を構築し、プラットフォームの基盤が Google Kubernetes Engine（GKE）上にあることを明確にしました。しかし、最近のチームからは、Kubernetes の習得に時間がかかるという声が聞こえてきました。これは想定されていたことでした。チームが独自のサービスを構築して実行するという文化変革を推進していたため、アプリケーション開発者が独自のソフトウェアをサポートするのに Kubernetes のスキルが必要になることは予想できていたのです。とはいえ、私たちのビジョンは開発者の負担を軽減することであり、彼らのフィードバックは明確でした。優れたドキュメントがあるにもかかわらず、チームが推奨する手順に従っていないケースがいくつか見られました。たとえば、ワークロードが障害に耐えられるように支援するアンチアフィニティルールや PodDisruptionBudgets を使用していませんでした。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbd78ec40>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

2017 年に Kelsey Hightower は次のように書いています。「Kubernetes はプラットフォームを構築するためのプラットフォームです。これはより良いスタート地点であって、最終目標ではありません。」

Kelsey の言葉に触発された私たちは、行動を起こしました。Kubernetes を使用する開発者のインタラクションポイントを簡素化するために、独自のカスタムコントローラを作成するというアイデアが浮かんだのです。私たちが好むアプローチに沿って John Lewis 固有の抽象化を行うのです。こうして JL Microservice が誕生しました。

これを行うために、開発者が設定する必要があると思われるフィールドのみを含む簡略化された仕様で Kubernetes CustomResourceDefinition を宣言しました。たとえば、テナントがアプリケーションを自ら構築して運用することを想定しているため、レプリカの数や必要なリソース量などの属性は、開発者自身に任せるのが最適です。しかし、ノード間で Pod を分散する方法を定義するルールを彼らがカスタマイズできるようにする必要は本当にあるのでしょうか。Deployment を参照する Service を変更することはどのくらいの頻度で必要になるでしょうか。詳しく調べてみると、重複が非常に多いことがわかりました。当時の分析では、開発者が作成した YAML ファイルの内容のうち、アプリケーションに関連するものは約 33% にすぎませんでした。これは、簡素化の対象が豊富にあるということです。

この機能を構築するにあたり、Kubebuilder を選択し、それを使用して CustomResourceDefinition を宣言し、コントローラ（MicroserviceManager と命名）を構築しました。これは有益な決定でした。最初のプロトタイピングは迅速に行われ、数か月後に機能がリリースされ、非常に好評を博しました。チームは Go プログラミング言語のスキルアップが必要でしたが、Kubebuilder がもたらすメリットを考えると、このトレードオフは価値があると感じました。それ以来、他のソフトウェアエンジニアリングにも役立っています。

最初の実装では、エンジニアが Deployment と Service を理解して完全に構成する必要がなくなり、代わりに、変更する必要があるフィールドのみを含む、はるかに短い YAML ファイルを適用すればよくなりました。同一のフィールドの直接変換（たとえば、image と replicas は、Deployment にあるものと同等）だけでなく、Kubernetes API で行われる選択を簡素化することもできました。John Lewis では、その機能の一部は必要なかったからです。たとえば、writablePaths: [] はエンジニアが理解しやすいコンセプトです。その裏では、コントローラがこれをより複雑な Volume と VolumeMount の組み合わせに変換しています。同様の例として、visibleToOtherServices: true は Kubernetes NetworkPolicy とのやり取りを簡素化します。チームがリソースに正しくラベルを付けるためにドキュメントを読んで必要な構文を理解する必要はなく、コントローラがそれらの規則を理解して処理します。

Microservice リソースの基本コンセプトが確立されたことで、さらに機能を追加して付加価値を高めることができました。すぐに拡張して Prometheus のスクレイピング構成を定義し、さらに、チームが Google Cloud Endpoints を使用することを宣言できるようにするなどの複雑な機能を追加しました。これにより、コントローラは必要なサイドカーコンテナを Deployment に挿入し、Service に接続できます。機能を追加するにつれて、既存のテナントはこの仕様を使用するように変更され、現在ではプラットフォームで宣言されたワークロードの大部分を占めています。

プラットフォームの境界を移動する

MicroserviceManager を構築する動機は、開発者の作業を楽にすることにありました。しかし、当初は予想していなかったさらなるメリットがあることがわかりました。それは、プラットフォーム内でも大きなメリットが得られるということです。テナントを巻き込むことなく、バックグラウンドで変更を加えることができるようになったことで、テナントのトイルが減り、プロダクトの改善が容易になりました。これは少し予想外でしたが、非常に大きなメリットでした。テナントとプラットフォームの間で確立された契約を変更することは一般的に困難ですが、このような抽象化を作成することでより多くのものを我々の管理下に置くことができ、これはすべてのユーザーにとってメリットとなります。

その一例として、johnlewis.com のライブ負荷テストで、特定のワークロードが数百の Pod までバーストしたことがありました。これは、クラスタで実行していた通常のノード数を上回る数です。これにより、新しいノードが作成され、Pod の自動スケーリングが遅くなり、ビンパッキングが不十分になりました。Kubernetes の運用経験が豊富な方なら、ここで何が起こったかはお察しいただけるでしょう。デフォルトのアンチアフィニティルールは、復元力を最適化するように設定されており、特定のノードには 1 つのレプリカしか許可されていませんでした。ただし、幸運なことにワークロードは Microservice Manager の制御下にあり、関連する YAML をデプロイにコピーするようテナントに指示する必要がなかったため、アンチアフィニティルールをより新しい podTopologyConstraints に置き換えるのは簡単でした。これにより、特定のレプリカ数を超えるワークロードについて、ノードにスタックできるレプリカ数をカスタマイズできるようになりました。テナントによる操作は一切必要ありませんでした。

より複雑な例としては、サービスメッシュをロールアウトしたときが挙げられます。我々はコントロールプレーンコンポーネントの実行の複雑さの処理を Google Cloud に任せたいと基本的に考えていたので、Google の Cloud Service Mesh プロダクトを使用することにしました。しかし、それでも、常に使用されているビジネスクリティカルなプラットフォームにメッシュをロールアウトするには、リスクが伴います。Microservice Manager では、Microservice リソースのフィーチャートグルを使用して、ワークロードをメッシュに登録する頻度を制御できます。まず、プラットフォームが所有するワークロードでロールアウトを開始してアプローチをテストし、その後、先行ユーザーが Cloud Service Mesh の一部の機能を検証して利用できるように、テナントにフラグを通知します。ロールアウトを拡大する際には、ビジネス上の重要度に基づいて段階的にリリースするようにフラグを操作し、必要に応じてオプトアウトメカニズムを提供します。これにより、実装が大幅に簡素化されました。プロダクトチームがやるべきことはほとんどなく、数百のマイクロサービスを実行している約 40 のチームに適切な構成変更を依頼する必要もありませんでした。フィーチャートグルを活用するこの手法は、独自のテストをサポートするために幅広く活用しています。

マイクロサービスを超えて

Microservice Manager を構築したことで、Kubernetes ネイティブな方法が考えられるようになりました。カスタムリソース + コントローラというコンセプトは強力な手法であり、これを使用して他の機能も構築しました。たとえば、外部接続の必要性を Istio リソースに変換して、下り（外向き）ゲートウェイ経由でルーティングするコントローラです。Istio は非常に強力なプラットフォーム機能ですが、活用する際にユーザー側に求められる知識やスキルは少なくありません。したがってこれは、プラットフォームエンジニアリングがチームの代わりに管理し、チームがその機能を活用できるようにするのに最適な例と言えます。テクノロジーに対する信頼が高まった今、この分野でさまざまなアイデアが生まれています。

まとめると、John Lewis Partnership は Google Cloud とプラットフォームエンジニアリングを活用して、e コマースの運用とデベロッパーエクスペリエンスをモダナイズしました。マルチテナントアーキテクチャで「舗装道路」アプローチを実装することで、開発チームを強化し、デプロイサイクルを加速させ、カスタムの Microservice CRD を使用して Kubernetes のインタラクションを簡素化しました。この戦略により、運用効率を維持し、エンジニアリングチームを効果的にスケールしながら、複雑さを軽減することで、効果的なスケールとデベロッパーエクスペリエンスの向上を実現できました。

Google Cloud でのプラットフォームエンジニアリングの詳細については、プラットフォームエンジニアリングに関する 5 つの誤解: プラットフォームエンジニアリングとは一体なのか、プラットフォームエンジニアリングにまつわるさらなる 5 つの誤解、道を照らす: プラットフォームエンジニアリング、ゴールデンパス、セルフサービスのパワーなどの記事をご覧ください。

-アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans
-John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1

Thu, 17 Jul 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 6 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: この投稿は記事のパート 1 です。読み終えたらパート 2 へお進みください。

2017 年、年間 25 億ポンドものオンライン売上高を誇る英国の大手小売業者 John Lewis は、モノリシックな e コマースプラットフォームの課題に悩まされていました。この時代遅れのアプローチは、チーム間の依存関係の増大や煩雑で頻度の低いリリース（せいぜい月 1 回）、過剰な手動テストの原因となり、複雑なオンプレミスインフラストラクチャによってさらに状況が悪化していました。そこで必要とされたのは、迅速かつ大幅な変革を推進するための大胆な決断です。

John Lewis のエンジニアたちはより良い方法があることを知っていました。エンジニアたちは Google Cloud と連携し、e コマース事業をモダナイズするために Google Kubernetes Engine を採用しました。フロントエンドから始まったこのプロジェクトは、すぐに成果を上げ始めました。わずか数か月でフロントエンドが Google Cloud に移行され、フロントエンドのブラウザへのリリースが毎週行われるようになったことから、同社は他の分野への拡大に乗り出しました。

同時に、チームはより広範な戦略を考えていました。それは、プラットフォームエンジニアリングのアプローチを採用して、従来のコマースエンジンの機能に取って代わる独自のマイクロサービスを構築するためのプロダクトチームを多く立ち上げるとともに、顧客向けのまったく新しいエクスペリエンスを作成するというものです。

こうして、John Lewis Digital Platform が誕生しました。そのビジョンは、開発チームを強化し、迅速なリリースのために必要なツールとプロセスを提供して、チームごとのビジネスサービスに関して完全に責任を持たせることでした。チームのモットーは、「自分で作る。自分で運営する。自分で責任を持つ」です。このように開発と運用の責任を分散することで、チームの規模を拡大することも可能になります。

この記事では、John Lewis がプラットフォームエンジニアリングにより業務のモダナイズと合理化を進める過程で得た戦略、プラットフォームの構築、主な教訓について、プリンシパルプラットフォームエンジニアの Alex Moss 氏が詳しく説明してくれます。プラットフォームエンジニアリングを自社組織にどのように適用できるかを検討するきっかけとなるはずです。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabb81245b0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ステップ 1: モノリシックからマルチテナントへ

この実現のために、John Lewis はマルチテナントアーキテクチャを採用する必要がありました。ビジネスサービスごとに 1 つのテナントを割り当て、各所有チームが他のチームにリスクを与えることなく独立して作業できるようにすることで、プラットフォームチームは各チームに大きな自由度を与えられるようになりました。

会社の主な目標がプロダクトチームの数を大幅に増やすことであるとわかっていたため、初期のデザイン思考に反映させました。テナントは少数でしたが、多くの独立したチームをサポートできるように体制を整えることができました。

この基本的な設計は非常にうまく機能し、7 年経った今でもほとんど変更されていません。マルチテナントコンセプトの中核を成すのは、私たちが「サービス」と呼ぶものです。これは論理的なビジネスアプリケーションを指し、通常は複数のマイクロサービスとデータを保存するためのコンポーネントで構成されます。

自社のプラットフォームは、主に「自分でコンテナを持ち込む」としていますが、特に状態の処理に関しては、他の Google Cloud サービスも活用することをチームに推奨しています。Firestore や Pub/Sub などのサービスを採用することで、プラットフォームチームが対応しなければならない複雑さを軽減できます。特に、レジリエンスや障害復旧などの分野で効果を発揮します。また、私たちは、Cloud Run などのコンピューティングプロダクトよりも Kubernetes を優先して利用しています。Kubernetes は開発チームの自由度を高めつつ、プラットフォームで特定の動作を実行できる適切なバランスを実現しているからです（たとえば、過度の摩擦が生じることなく、適切なレベルのガードレールを設定できます）。

当社のプラットフォームでは、プロダクトチーム（テナント）が独自の名前空間とプロジェクトをかなり細かく制御できるようになっています。これにより、他チームに依存することなくワークロードのプロトタイピング、構築、最終的な運用が可能になります。これはスケールの実現に欠かせない要素です。

プラットフォームの進化にあたり、先行チームの存在は非常に有益でした。彼らは、機能の不足を認めて独自のソリューションを開発する意欲を示し、ニーズを満たすものを構築しているかどうかについてたくさんのフィードバックを提供してくれました。

このプラットフォームを最初に採用したチームは、johnlewis.com の検索機能を再構築し、市販のソリューションに置き換えました。このチームは、最新のソフトウェア開発とマイクロサービスベースのアーキテクチャの利点に精通した経験豊富なエンジニアで構成されており、アプリケーションでデータを保存し、コンポーネント間で非同期通信を行うためのサポートサービスが必要であることをすぐに特定しました。また、プラットフォームチームと協力して選択肢を検討し、自社でデータベースやメッセージングの運用をせずに Google Cloud のネイティブサービスを活用したいという当社の意向に賛同してくれました。その結果、Google Kubernetes Engine 以外の最初の拡張機能として Cloud Datastore と Pub/Sub を採用することになりました。

すべての道が成功への道

チームの自律性が非常に高いプラットフォームでは、テクノロジーの選択や実装パターンの面でやや無秩序になりやすいというリスクがあります。デベロッパー中心の姿勢を維持しながらこの問題に対処するために、「Golden Path」に似た「Paved Road」（舗装道路）というコンセプトを採用しました。

「Paved Road」アプローチにより、次の点が容易になりました。

デベロッパーが迅速かつ安全に作業を進められる便利なプラットフォーム機能を構築する
アプローチや手法を共有し、エンジニアがチーム間を移動できるようにする
チームが必須の実践事項に従っていることを組織全体に示す（これは、リリースで制限するのではなく、保証機能を構築することで実現します）

「Paved Road」というコンセプトは、プラットフォームで構築するほとんどの部分に浸透しており、John Lewis Digital の領域を超えて、John Lewis Partnership の他の領域にも影響を与えています。

当社の「Paved Road」は、チームの簡素化を実現する 2 つの主要な機能によって支えられています。

Paved Road パイプライン: これはサービス全体で動作し、Google Cloud リソースのプロビジョニングやオブザーバビリティツールなどの機能を提供します。
マイクロサービス CRD: その名が示すように、これはマイクロサービスレベルの抽象化のことです。ここでの主なメリットは、チームが Kubernetes をより簡単に扱えるようになることです。

どちらの機能も開発者の利便性を念頭に置いて作成されましたが、プラットフォームチームにも多くのメリットがあることがわかりました。

Paved Road パイプラインは構成ファイル（もちろん yaml 形式）によって駆動します。この構成ファイルを「サービス定義」と呼びます。これにより、テナンシーを所有するチームは、推論が容易な構成を通じてプラットフォームに提供してほしい機能を記述できます。関連ドキュメントとサンプルは、何が実現できるのかをチームメンバーが理解するのに有用です。このファイルに push すると、プラットフォームが所有する多数のジョブ（「プロビジョナー」と呼んでいます）の CI / CD パイプラインが実行されます。これらのプロビジョナーはマイクロサービスと同様に、独立してリリース可能であり、一般的に 1 つのタスクを適切に実行することに重点を置いています。以下に、プロビジョナーの例とその機能を説明します。

各チームのプロジェクトに Google Cloud リソースを作成する。例: バケット、Pub/Sub、Firestore など。
ゴールデンシグナルと自己計測指標に基づいて、プラットフォーム提供のダッシュボードとカスタムダッシュボードを構成する
特定のマイクロサービスの SLO に合わせてアラート構成を調整し、それらのアラートに対するインシデント対応の動作を調整する

これにより、プロダクトチームが Google Cloud リソースのプロビジョニングの仕組みや、そのための Infrastructure as Code（IaC）ツールについて深く理解する必要がなくなります。推奨テクノロジーとベストプラクティスは当社のエキスパートが厳選したものであり、デベロッパーはプロビジョニングする内容とタイミングを完全に制御しながら、ビジネスに差別化をもたらすソフトウェアの構築に集中できます。

先ほど述べたように、このアプローチには、プラットフォームチームが独自の機能を構築するために利用できるというメリットがあります。チームがサービス用に更新した構成は、チームに関するメタデータと組み合わせて、API 経由または Pub/Sub に公開されたイベントを通じて表示できます。これにより、インシデント対応やセキュリティツール、事前プロビジョニングされたドキュメントリポジトリなど、他の機能のアップデートも促進されます。これは、当初はチームが独自の IaC を記述する手間を省く手段として意図されていたものが、プラットフォーム機能の構築を容易にし、付加価値をさらに高めるためにも活用できることを示した一例です。デベロッパーがそのことを意識する必要もありません。

このアプローチは、チームが使用できるように事前構築された Terraform モジュールを提供するよりもスケーラブルであると考えています。Terraform モジュールのアプローチではチームが Terraform に精通している必要があり、バージョニングや依存関係の複雑さがメンテナンス作業の面でプラットフォームエンジニアの負担になる可能性があります。代わりに、理解しやすい API を提供し、プラットフォームチームに意図的に負担をかけることで、チームに必要なすべての機能をサービスが提供できるようにしています。この抽象化により、必要に応じて大幅なリファクタリングを選択することもできます。

このアプローチを採用することで、プラットフォーム全体でテクノロジーの一貫性を広く維持できます。たとえば、プラットフォームで Pub/Sub のリソースを簡単に作成できるのに、チームがわざわざ Kafka を実装する必要はあると思いますか？これは、機能するビジネスサービスに組み立てられるランタイムコンポーネントだけでなく、そのソフトウェアを運用するためのすべての付随的なニーズ（レジリエンスエンジニアリング、モニタリングとアラート、インシデント対応、セキュリティツール、サービス管理など）にも及ぶことを考えると、エンジニアの生産性に大きな増幅効果をもたらします。これらの要素はすべて、John Lewis Digital Platform 上で完全な「Paved Road」機能を備えており、チームがニーズを認識して適切なオプションを特定し、それらを使用するためのテクノロジーやプロセスを実装する際の認知負荷を軽減してくれます。
とはいえ、私たちが「Paved Road」のコンセプトを特に気に入っている理由の一つは、チームの「オフロードに挑む」という選択肢を排除しない点です。「Paved Road」は必須ではありませんが、エンジニアが他の方法を選びたくならないような、説得力のあるものであるべきです。他のアプローチの使用を禁止すると、イノベーションを阻害し、「これで十分だ」と構築した機能に甘んじてしまうリスクがあります。「Paved Road」は、デベロッパーの変化するニーズに応え続けられるようプロダクトを改善し続けるという課題をプラットフォームエンジニアに課しています。同様に、開発チームが独自の道を歩もうとしても、強力なプラットフォーム機能を複製する際に伴う負担の増加がそれを思いとどまらせます。

エンジニアのニーズは一定ではなく、Google Cloud ももちろん新しい機能をリリースし続けています。そのため、この例えを拡張して「Dusty Path」（ほこりっぽい道）というコンセプトを追加することにしました。これは、私たちが望むほど機能が豊富ではない（セルフサービスプロビジョニングやすぐに使えるオブザーバビリティが欠けているなど）新しいプラットフォーム機能を表しています。チームには、さまざまなオプションを試して、まだ整備されていない Google Cloud プロダクトを活用することが求められています。このテストを可能にするのが「Paved Road パイプライン」です。このテストプロセスを「スノーフレーク（実験的利用の意味）」と呼んでいます。そして、ここに非公式の「3 つのルール」を設けています。少なくとも 3 つのチームが同じ機能をリクエストしていることが確認された場合、その機能のセルフサービス化を進めるというものです。

かたや、もう一方の極端ではチームが完全に単独で作業することもあります（「クレイジーペイビング（「非標準実装の意味）」と呼んでいます）。これは、大胆なテストのサポートや、プラットフォームの安全な運用の要件に応えられないワークロードへの対応に必要となる場合があります。この分野のソリューションは一般的に長続きしません。

この記事では、John Lewis がプラットフォームエンジニアリングにマルチテナントの「Paved Road」アプローチを採用することで、e コマース事業に変革を起こした事例を紹介しました。この戦略によって開発チームをどのように強化し、Google Cloud リソースのプロビジョニングや運用機能とセキュリティ機能のデプロイをどのように合理化したかを検証しました。

このシリーズのパート 2 では、John Lewis がマイクロサービス CRD を導入することで開発者の利便性をさらに強化させた方法について詳しく説明します。この独自の Kubernetes 抽象化により、コンポーネントレベルでの Kubernetes 操作の複雑さが大幅に軽減され、開発サイクルの短縮と運用効率の向上につながった仕組みについて解説します。

Google Cloud でのプラットフォームエンジニアリングを活用したシフトダウンについて、詳しくはこちらをご覧ください。Google Kubernetes Engine（GKE）の堅牢かつインテリジェントなフルマネージド Kubernetes Service によって、コンテナ化されたアプリケーションのデプロイ、スケール、管理をデベロッパーが簡単に実行できるようにする方法については、こちらから詳細をご確認いただけます。

-アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

-John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

インシデント対応に AI を活用する: Personalized Service Health と Gemini Cloud Assist のインテグレーション

Tue, 03 Jun 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 5 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドインシデントが発生した場合、誰もがそのクラウドプロバイダからの迅速かつ明確なコミュニケーションを望み、その情報を効果的に活用したいと考えます。Google Cloud コンソールの Personalized Service Health は、Google Cloud サービスの中断について、透明性と関連性の高い実用的な通知を迅速に提供するものであり、お客様特有のフットプリントに合わせてカスタマイズされています。これにより、問題の原因をすばやく特定し、「Google 側の問題か、それとも自社の問題か」という疑問に答えることができます。そして、この情報をインシデント対応ワークフローに統合して、インシデントをより効率的に解決できます。

このたび、Personalized Service Health を活用して、進行中のインシデントに関するリアルタイム情報を Gemini Cloud Assist に引き出してもらうことができるようになりました。これにより、検出、影響評価、復旧などのインシデント管理を効率化できます。Gemini のガイダンスと Personalized Service Health の分析情報、最新情報を組み合わせることにより、影響範囲を評価し、トラブルシューティングを開始できます。これらはすべて、AI を活用した Gemini Cloud Assist チャット内で行うことができます。さらに、この種のインシデント検出は、コンソール内の任意の場所から開始できるため、ワークフローを中断することなく、関連するインシデントをすぐに確認できます。また、プロジェクトに影響する進行中のインシデントを確認して、その範囲の詳細と最新の更新情報を Personalized Service Health から直接収集することもできます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbe30cd00>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

Gemini Cloud Assist で Personalized Service Health を活用する

Gemini Cloud Assist は、ユーザーフレンドリーなレイアウトと整理された情報構造を備えています。動的なタイムライン、最新情報、症状、回避策など、Personalized Service Health から直接取得された重要な詳細情報がコンソールに表示されるようになり、会話形式でのフォローアップが可能になりました。Gemini Cloud Assist は、Personalized Service Health の重要な分析情報を強調できるため、調査対象を絞り込んでインシデントの影響を把握するのに役立ちます。

このインテグレーションの利点を示すために、次のデモでは、Gemini と Personalized Service Health の機能を組み合わせて活用した、一般的なインシデント対応ワークフローをご紹介します。

インシデントの検出とトリアージインシデントの重要な最初の瞬間に、Gemini Cloud Assist が「Google 側の問題か、それとも自社の問題か」という疑問に答えます。Gemini Cloud Assist は、Personalized Service Health のデータに直接アクセスし、Google Cloud インシデントの影響を受けるプロジェクトとロケーションに関するフィードバックを提供することで、トリアージプロセスを迅速化します。

このプロセスを開始する方法を理解するために、Gemini Cloud Assist に次のような質問をしてみてください。

私のプロジェクトは Google Cloud インシデントの影響を受けている？
現在、Google Cloud に影響を与えているインシデントはある？

影響の調査と評価関連する Google Cloud インシデントを特定したら、Gemini Cloud Assist を使用して情報をさらに掘り下げ、自身の環境への影響を評価できます。さらに、フォローアップの質問をすることにより、Gemini Cloud Assist は、インシデントの進展に応じて Personalized Service Health から最新情報を取得できます。その後、報告されたインシデントの影響を受けるアプリやプロジェクトを、ロケーションも含めて正確に特定するよう Gemini にリクエストし、さらに調査を進めることができます。

Gemini Cloud Assist に質問するプロンプトの例を以下に示します。

進行中のインシデント ID [X] について教えて。（[X] はインシデント ID に置き換える）
[X] は影響を受けている？（[X] は特定のロケーションまたは Google Cloud プロダクトに置き換える）
インシデント ID [X] の最新情報を教えて。
インシデント ID [X] の詳細を教えて。
[影響を受けている Google Cloud プロダクト] のトラブルシューティング手順を教えて。

軽減と復旧最後に、Gemini Cloud Assist は復旧フェーズでインテリジェントなアシスタントとして機能し、実用的なガイダンスを提示します。Gemini Cloud Assist を使用すると、関連するログやモニタリングデータにアクセスして、より効率的に問題を解決できます。さらに、Gemini Cloud Assist は、Personalized Service Health から潜在的な回避策を浮き彫りにし、プロジェクトやアプリケーションを復元するために必要なツールや情報に誘導します。プロンプトの例は以下のとおりです。

インシデント ID [X] の回避策を教えて。（[X] はインシデント ID に置き換える）
アプリケーションを実行し続けるための一時的な解決策を提案して。
この影響を受けているプロジェクトのログを探すにはどうすればいい？

Gemini はこれらのプロンプトに従って Personalized Service Health から関連する情報を取得し、（進行中のイベントと最長で過去 1 年間のインシデントの両方について）Google Cloud 環境の正常性に関するパーソナライズされた分析情報を提示します。これは、インシデントを調査してその影響を絞り込み、復旧を支援する際に役立ちます。

次のステップ

今後は、Gemini Cloud Assist と Personalized Service Health を活用して、より詳細な分析情報と包括的なインシデント管理を提供することで、AI を活用したこれらの機能を単一のプロジェクトビュー以外にも拡張していく予定です。Gemini Cloud Assist と Personalized Service Health の利用を開始しましょう。

Personalized Service Health の詳細情報をご覧になるか、Google のアカウント担当者に依頼して、この機能を有効にしてください。
Gemini Cloud Assist の使用を開始します。プロンプトを調整して、特定のリージョンや Google Cloud プロダクトについて質問し、インシデントをプロアクティブに管理するためにどのように役立つかを試してみてください。

プロダクトマネージャー、Sam Jalali

シニアスタッフ UX デザイナー、Luca Paulina

Google Cloud の KCC を使用して Waze を Infrastructure as Code に移行

Tue, 13 May 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 4 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

2023 年、Waze のプラットフォームエンジニアリングチームは、Google Cloud の Config Connector（KCC）を使用して Infrastructure as Code（IaC）に移行し、それ以来大きな成果を上げてきました。Waze では、オープンソースの Kubernetes アドオンである Config Connector を採用し、Kubernetes を介して Google Cloud リソースを管理しています。また、管理を効率化するために、Google Kubernetes Engine（GKE）上で Config Connector のホスト型バージョンである Config Controller を活用し、Policy Controller と Config Sync を組み込んでいます。この移行により、インフラストラクチャ管理が大幅に改善され、将来のインフラストラクチャの基盤が築かれました。

Config Connector への移行

Waze は以前、特にデュアルクラウド環境における VM ベースのフェーズでは、リソース管理に Terraform を使用していました。しかし、状態の維持や調整作業が困難であり、構成の一貫性の欠如や、管理オーバーヘッドの増加が発生していました。

そこで、2023 年に Config Connector を採用し、Google Cloud インフラストラクチャを GKE クラスタ内の Kubernetes Resource Modules（KRM）に変換することにしました。このアプローチにより、Terraform で発生していた調整の問題が解決しました。また、Config Sync と Config Connector を組み合わせることで、ソースリポジトリからライブ GKE クラスタへの KRM の自動同期が可能になりました。このマネージドソリューションにより、カスタム調整システムの構築や保守が不要になりました。

この移行により、Waze のインフラストラクチャチームにおける、以下の 3 種類の主要なユーザーのニーズを満たすことができました。

インフラストラクチャの利用者: 基盤となるリソースの保守や複雑さについて心配することなく、インフラストラクチャを簡単にデプロイしたいアプリケーション開発者。
インフラストラクチャオーナー: Google Cloud 上の Waze 全体でリソースの作成方法に関するベストプラクティスの定義や標準化に取り組む、特定のリソースタイプ（Spanner、Google Cloud Storage、ロードバランサなど）の専門家。
プラットフォームエンジニア: インフラストラクチャオーナーがベストプラクティスを体系化および定義するシステムを構築し、インフラストラクチャの利用者にシームレスな API を提供するエンジニア。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud コンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7fabbe2ceee0>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/marketplace/product/google/container.googleapis.com'), ('image', None)])]>

最初のステップ: Config Connector

Google Cloud インフラストラクチャ全体を Google Cloud サービス内の KRM として定義するのは循環的に思えるかもしれませんが、KRM は既存の IaC ツールとは異なり、実際には Waze のインフラストラクチャを表現するのに適しています。

Terraform の調整の問題（状態のずれ、バージョン管理、帯域外の変更）は、重大な課題です。Config Connector には、Config Sync を通じてすぐに使用できる調整機能が備わっており、これは理想的なマネージドソリューションでした。テンプレート機能は KRM と Terraform のどちらにもありますが、KCC のマネージド機能は Google Cloud ネイティブソリューションへの移行に適しており、メンテナンスの負担も軽減します。

インフラストラクチャの複雑さは、ツールに関係なく一般化する必要があります。これは、以下のように、Spanner に対する Waze の要件を見れば明らかです。

すべての Spanner データベースの一貫したバックアップが必要。
各 Spanner データベースは、専用の Cloud Storage バケットとサービスアカウントを使用して DDL ジョブの実行を自動化する。
一貫性のある監査可能なアクセス制御を確保するために、Spanner インスタンス、データベース、Cloud Storage バケットのすべての IAM ポリシーをコードで定義する。

これらのリソースを定義するために、さまざまなテンプレートツールとレンダリングツールを評価した結果、Kubernetes 向けの堅牢な CNCF パッケージ管理システムである Helm を選択することにしました。その強力なオープンソースコミュニティ、豊富なテンプレート機能、ネイティブなレンダリング機能は、Waze にごく自然に適合できました。現在では、バンドルされたインフラストラクチャ構成を「チャート」と呼んでいます。その後、KRO が登場して、同様の目的を達成できるようになりましたが、上述の選定プロセスは、KRO がリリースされる前のものです。

仕組み

このシステムがどのように機能し、どのように Waze に価値をもたらしているのかを詳しく見ていきましょう。

Waze のインフラストラクチャオーナーが Waze 独自のインフラストラクチャを Helm チャートで汎用的に定義します。
インフラストラクチャの利用者が、これらのチャートを使用して、シンプルな入力でインフラストラクチャを生成します（デモ）。
インフラストラクチャのコードがリポジトリに保存され、検証と送信前のチェックが可能になります。

コードは Artifact Registry にアップロードされ、ここで、Config Sync と Config Connector が Google Cloud インフラストラクチャをコード定義に合わせます。

この図は、バインドされたサービス、データベース、ネットワーク、データのコレクションである単一の「データドメイン」を表しています。現在のテクノロジー組織の多くは、本番、QA、ステージング、開発などの環境で構成されています。

目標へのアプローチ

では、なぜこれが重要なのでしょうか。このアプローチを採用することで、Infrastructure as Code から Infrastructure as Software に移行することができました。各チャートをソフトウェアコンポーネントとして扱うことで、インフラストラクチャ管理は単なるコード宣言を超えたものになります。現在では、チャートと構成がバージョン管理され、高度なリリース管理、自動ロールバック、詳細な変更追跡など、さまざまなソフトウェアプラクティスを活用できるようになっています。

これを実践したのが、冗長性を最小限に抑える構成継承モデルです。Resource チャートは Project から設定を継承し、Project は Bootstrap から設定を継承します。この 3 つはすべてチャートとして定義されています。このため、Bootstrap の構成はすべての Project に適用され、Project の構成はすべての Resource に適用されます。

既存のインフラストラクチャの変更から新しいリソースタイプのロールアウトまで、インフラストラクチャに対するあらゆる変更をソフトウェアのロールアウトのように扱うことができます。

インフラストラクチャ全体がソフトウェアのように扱われるようになったことで、システム全体にどのような効果があるかを確認できます。

目標の達成

まとめると、Config Connector と Config Controller により、Waze は真の Infrastructure as Software を実現し、インフラストラクチャのニーズに応える堅牢でスケーラブルなプラットフォームの他にも、以下のような多くのメリットを得ることができました。

インフラストラクチャの利用者は、バージョン管理されたアップデートを通じて最新のベストプラクティスを入手できるようになりました。
インフラストラクチャオーナーはイテレーションにより、インフラストラクチャを安全に改善できるようになりました。
プラットフォームエンジニアとセキュリティチームは、リソースが監査可能でコンプライアンスを確保していると確信できるようになりました。
Config Connector で Google のマネージドサービスが利用されているため、運用上のオーバーヘッドが削減されました。

-Waze、スタッフサイト信頼性エンジニア Tyler Reid 氏

MLOps パイプラインで ML システムを最適化するための SRE ガイド

Wed, 12 Mar 2025 01:01:00 +0000

※この投稿は米国時間 2025 年 2 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

想像してみてください。あなたは、会社の機械学習（ML）サービスを支えるシステムの責任を負うサイト信頼性エンジニア（SRE）です。信頼性のある ML サービスを確保するために何をすべきでしょうか。自分がうまくやっているかを知るにはどうすればよいでしょうか。そしてこれらのサービスをサポートする強固なシステムをどのように構築しますか。

AI が広く普及するにつれて、その機能、特に ML は SRE にとってますます重要になってきます。それは ML が生産ソフトウェアシステムで使用されるインフラストラクチャの一部であると同時に、ソフトウェア自体の重要な機能にもなるからです。

抽象的には、ML はそのパイプラインに依存しています。そしてあなたはすでにその管理方法を知っています。まずはパイプラインの管理から始め、その後、ML サービスを強化するための他の要素、トレーニング、モデルの新鮮さ、そして効率性などに目を向けていきます。以下のリソースでは、これらのパイプラインが持つ ML 特有の性質を、運用で考慮すべきポイントとして見ていきます。そして、Google の SRE の経験を活かして、コアとなる SRE スキルをどのように ML パイプラインの運用、管理に適用するかをお伝えします。

ML モデルのトレーニング

ML モデルのトレーニングは、特定のタイプのデータにパイプラインの概念を適用し、しばしば特殊なハードウェアで実行されます。パイプラインに関して考慮すべき重要な側面は以下のとおりです。

どれくらいのデータを取り込んでいるか
データがどれくらい新鮮でなければいけないか
システムがどのようにモデルをトレーニングしデプロイするのか
システムが上記の 3 つの要素をどれほど効率的に処理しているか

この基調講演では、ML システムのコンポーネントに信頼性の原則を適用する価値について、SRE の視点を紹介します。ML システムが製品にとってなぜ重要であり、SRE がそれらについてどのように考えるべきかについての洞察を提供します。ML システムが抱える課題には、キャパシティ計画、リソース管理、モニタリングが含まれます。また、ML システムのコストを全体の運用環境の一部として把握することも課題の一つです。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7faba1a91ac0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ML の新鮮さとデータ量

あらゆるパイプラインベースのシステムと同様、こうしたシステムを理解するうえで大きい比重を占めるのは、通常どれくらいのデータを取り込み、処理するかを把握することです。SRE ワークブックのデータ処理パイプラインの章では、パイプラインの運用を自動化することでレジリエンスを持たせ、無人で運用できるようにするという、基本的な考え方を示しています。

パイプラインの健全性を測定するために、特にデータの新鮮さ（モデルが顧客への推論を行うために使用しているデータがどれほど最近取得されたか）に関して、サービスレベル目標（SLO）の設定が重要です。新鮮さを把握することは、ML システムの健全性を測るための重要な指標となります。データが古くなると、推論の質が低下し、ユーザーにとって最適でない結果を生む可能性があるからです。例えば、天気予報システムのように、データが非常に新鮮である必要がある場合（数分前や数秒前のものなど）、またはスペルチェッカーのように、数日、あるいはそれ以上の遅延を許容する場合もあります。新鮮さの要件は製品によって異なるため、何を構築しているのか、そしてその使用方法がどのように期待されているのかを把握することが重要です。

このように、新鮮さは SRE ワークブックで詳述されているクリティカルユーザージャーニーの一部であり、カスタマーエクスペリエンスの 1 つの側面を示しています。パイプラインシステムのコンポーネントとしてのデータの新鮮さについては、Google SRE の記事 Reliable Data Processing with Minimal Toil でご覧いただけます。

高品質なデータを確保するためには新鮮さだけではなく、モデルトレーニングパイプラインの定義方法も重要です。A Brief Guide To Running ML Systems in Production では、この分野の基本的な要素を紹介しており、コンテキスト指標を使用して新鮮さやスループットを把握する方法、入力データの品質を把握するための手法についても触れています。

提供効率

2021 年の SRE のブログ投稿、Efficient Machine Learning Inference は、本番環境におけるモデルのパフォーマンスを改善する方法について学ぶための貴重なリソースです。（そして、ML サービスにおいて、トレーニングと本番環境は決して同じではないことを忘れないでください！）

ML の推論提供を最適化することは、実際の運用で非常に重要です。この記事では、共有 VM からのマルチモデル提供について書かれています。現実的なユースケースをカバーし、コスト、利用率、モデル応答レイテンシの間におけるトレードオフをどのように管理するかについて説明しています。モデルの VM への割り当てを変更し、プロセッサ、GPU、RAM のサイズと種別を変えることにより、モデル提供のコスト効率を改善できます。

費用対効果

これらの AI パイプラインがしばしば特殊なハードウェアに依存していることに触れました。では、そのハードウェアを効率的に使用しているかどうかをどのように確認するのでしょうか。SREcon EMEA 2023 での Todd Underwood の講演、Artificial Intelligence: What Will It Cost You? では、この特殊なハードウェアを運用するコストがどれくらいか、そして効率的に使用するためのインセンティブを提供する方法について理解することができます。

スケールのための自動化

この Google SRE チームの記事では、手作業やトイルを最小限に抑えつつ、信頼性の高いデータ処理を確保するための戦略を説明しています。重要なポイントの一つは、パイプラインに可能な限り既存の標準プラットフォームを使用することです。結局のところ、ビジネス目標はデータと ML モデルの提供に関する革新に集中すべきであり、パイプライン自体に関するものではありません。この記事では、自動化、モニタリング、インシデント対応について説明し、これらの概念を使用してレジリエンスのあるデータパイプラインを構築する方法に焦点を当てています。失敗をスムーズに処理できるデータシステムを設計し、チームの運用負担を軽減するためのベストプラクティスを紹介しています。この記事は、データエンジニアリングや運用に関わるすべての人にとって必読の資料です。トイルの詳細については、SRE ワークブック（https://sre.google/workbook/eliminating-toil/）でご覧いただけます。

次のステップ

成功する ML デプロイメントには、システムが信頼性が高く持続可能であるための慎重な管理とモニタリングが必要です。つまり、データパイプライン、トレーニング経路、モデル管理、検証といった要素を、モニタリングや精度の指標とともに実装する包括的なアプローチが求められます。詳細は、AI オーケストレーションに GKE を使用する方法に関するガイドをご覧ください。

-Google Cloud、デベロッパーリレーションエンジニア、Max Saltonstall
-Google、テクニカルプログラムマネージャー、Salim Virji

新しい Google Cloud Trace エクスプローラのご紹介

Fri, 28 Feb 2025 01:03:00 +0000

※この投稿は米国時間 2025 年 2 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

分散トレースは、オブザーバビリティスタックの重要な部分であり、アプリケーションのレイテンシやエラーをトラブルシューティングできます。Google Cloud Observability の一部である Cloud Trace は、Google Cloud のネイティブトレーシングプロダクトです。新しい分析バックエンドに加えて、Trace エクスプローラの UI に多くの改善を加えました。

新しい Trace エクスプローラページには、次の情報が表示されます。

Google Cloud プロジェクトベースのトレーススコープ、すべてのスパン / ルートスパン、カスタム属性フィルタを選択できるオプションがあるフィルタバー。
OpenTelemetry の規則に基づいてよく使用されるフィルタを表示する、ファセットスパンフィルタペイン。
一致するスパンの可視化。インタラクティブなスパン期間ヒートマップ（デフォルト）、スパンレートの折れ線グラフ、スパン期間のパーセンタイルグラフなどがあります。
一致するスパンの一覧。ヒートマップで対象のセルを選択することでさらに絞り込むことができます。

新しい Trace エクスプローラの概要

では、これらの新機能と、アプリケーションのトラブルシューティングに役立つ使い方を詳しく見ていきましょう。あなたが、小売ウェブストアアプリケーションの checkoutservice に携わっている開発者だとしましょう。進行中のインシデントがあるため、呼び出しを受けました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbcff3d90>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

このアプリケーションは OpenTelemetry を使用して計測され、トレースデータを Google Cloud Trace に送信します。そのため、Google Cloud コンソールの Trace エクスプローラページに移動し、コンテキストを checkoutservice をホストする Google Cloud プロジェクトに設定します。

調査を開始する前に、管理者から、ウェブショップアプリ全体の本番環境の問題を調査するときは webstore-prod トレーススコープを使用するように勧められていたことを思い出しました。このトレーススコープを使用すると、調査に関連する他の Google Cloud プロジェクトに保存されているスパンを確認できます。

トレーススコープを webstore-prod に設定すると、このトレーススコープに含まれるすべてのプロジェクトのスパンがクエリに含まれるようになります。

[スパンフィルタ] で checkoutservice（1）を選択すると、ページに次の更新が読み込まれます。

[スパンフィルタ] ペインの [スパン名] （2）などの他のセクションは、サービス名で行った選択を考慮した数と割合で更新されます。これにより、検索条件を絞り込んでより具体的にすることができます。
スパンフィルタ バー（3）が更新され、アクティブなフィルタが表示されます。
ヒートマップ可視化（4）が更新され、直近 1 時間の checkoutservice からのスパンのみが表示されます（デフォルト）。期間は、期間選択ツール（5）を使用して変更できます。ヒートマップの X 軸は時間、Y 軸はスパン期間です。色の濃淡で各セルのスパンの数が表示され、対応する範囲を示す凡例も示されます。
[スパン] テーブル（6）が更新され、一致するスパンが期間で並べ替えられます（デフォルト）。
切り替え可能な他の [グラフビュー]（7）も、適用されたフィルタで更新されます。

ヒートマップを見れば、100 を超える範囲のスパンがいくつかあることがわかります。これは異常で、問題があります。しかし、まず、checkoutservice によって処理される呼び出しのトラフィックと対応するレイテンシについて調べることにしました。

スパンレートの折れ線グラフに切り替えると、サービスで処理されるトラフィックを確認できます。X 軸は時間、Y 軸は 1 秒あたりのスパン数です。過去の経験から、1.5～2 スパン/秒がごく普通であることがわかっているため、サービスで処理されるトラフィックは正常に見えます。

スパン期間パーセンタイルグラフに切り替えると、50 / 90 / 95 / 99 パーセンタイルのスパン期間の傾向が表示されます。50 パーセンタイルは問題ないように見えますが、90 パーセンタイル台の期間がサービスに対する想定よりも長くなっています。

ヒートマップグラフに戻り、外れ値のセルを選択して詳細を確認します。このセルには、期間が 2 分を超える、2 つの一致するスパンが含まれています。これは問題です。

完全なトレースを表示してこれらのスパンの一つを調査したところ、orders publish スパンがこのリクエストの処理にかかる時間の大部分を占めていることがわかりました。そのため、checkoutservice がこのような呼び出しの処理に問題を抱えているという仮説を立てます。仮説を検証するために、rpc.method 属性が PlaceOrder であることをメモし、X ボタンを使用してこのトレースを終了します。

フィルタバーを使用して、キー: rpc.method、値: PlaceOrder の属性フィルタを追加すると、サービスで処理される PlaceOrder 呼び出しに明らかなレイテンシの問題があることがわかります。この問題を以前に経験しており、この問題に対処するランブックがあることを知っているので、インシデントを軽減するために取るべき適切なアクションを SRE チームに警告します。

[フィードバックを送信] ボタンからフィードバックをお寄せください。

舞台裏

この新しいエクスペリエンスは、ログ分析の基盤となるものと同じプラットフォームを使用して、BigQuery を活用しています。このプラットフォームを最大限に活用する新しい機能（SQL クエリ、柔軟なサンプリング、エクスポート、リージョンストレージ）をリリースする予定です。

まとめると、新しい Cloud Trace エクスプローラを使用して、トレースデータの高度なクエリと可視化を行い、サービス指向の調査を実行できます。これにより、開発者と SRE は、本番環境のインシデントを効果的にトラブルシューティングし、通常の運用を復元するための緩和策を特定できます。

新しい Cloud Trace エクスプローラはすべてのユーザーに一般提供されています。ぜひお試しいただき、[フィードバックを送信] ボタンからフィードバックをお寄せください。

-プロダクトマネージャー Sujay Solomon
-エンジニアリングマネージャー Punya Biswal

原則に基づく適切な設計のフレームワークを活用したクラウド導入の加速

Wed, 26 Feb 2025 01:02:00 +0000

※この投稿は米国時間 2025 年 2 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今の絶えず変化するデジタル環境において、セキュリティ、信頼性、コスト効率、パフォーマンスに優れたクラウドソリューションを構築して運用することは容易ではありません。企業はクラウド導入の複雑さに立ち向かっていますが、多くの場合、ビジネスニーズ、技術的な実装、運用体制の間のギャップを埋めるのに苦労しています。ここで出番となるのが、Google Cloud アーキテクチャフレームワークです。このフレームワークは、お客様が効率性、セキュリティ、レジリエンス、パフォーマンス、費用対効果に優れ、セキュリティ要件とコンプライアンス要件を満たす Google Cloud トポロジを、設計、開発、デプロイ、運用できるよう包括的なガイダンスを提供するものです。

このアーキテクチャフレームワークの対象ユーザー

このアーキテクチャフレームワークは、幅広いクラウドの専門家を対象としています。クラウドアーキテクト、開発者、IT 管理者、意思決定者、その他の実務担当者の方に、Google 社内と業界で長年にわたり培われてきた対象分野の専門知識からメリットを引き出していただけます。この膨大な専門知識は精査され、簡単に利用できる一連の推奨事項として提示されます。

アーキテクチャフレームワークの推奨事項は、ビジネスに焦点を当てた 5 つの柱に分類されます。

Google は最近、アーキテクチャフレームワークのすべての柱と視点におけるガイダンスを見直し、一定の設計原則を推奨事項の中核に据えました。

効果的な運用	セキュリティ、プライバシー、コンプライアンス	信頼性	費用の最適化	パフォーマンスの最適化
運用体制インシデント管理リソースの最適化チェンジマネジメント継続的な改善	安全性を重視した設計ゼロトラストシフトレフトセキュリティプリエンプティブなサイバー防御安全性を備えた責任ある AI セキュリティのための AI 規制、プライバシー、コンプライアンスのニーズ	ユーザー重視の目標現実に即したターゲット冗長性による HA 水平方向のスケーリングオブザーバビリティグレースフルデグラデーション復旧テスト徹底的な事後検証	ビジネス価値に沿った支出コスト意識の組織文化リソースの最適化継続的な最適化	リソース割り当て計画の策定弾力性モジュール式の設計継続的な改善

このアーキテクチャフレームワークでは、上述の柱に加え、柱の枠を超えた視点から、AI と ML といった特定の領域、業種、テクノロジーに関する推奨事項も提示しています。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbd690730>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

アーキテクチャフレームワークを導入するメリット

アーキテクチャフレームワークは、設計や運用に関する推奨事項の単なる寄せ集めではありません。このフレームワークは、原則に基づく体系的な設計手法を提供し、以下のような多くのメリットをもたらします。

セキュリティ、プライバシー、コンプライアンスの強化: クラウドではセキュリティが非常に重要です。アーキテクチャフレームワークには業界をリードするセキュリティ対策が組み込まれており、お客様がクラウドアーキテクチャでセキュリティ、プライバシー、コンプライアンスの要件を満たせるよう支援します。
費用の最適化: アーキテクチャフレームワークは、コスト意識の組織文化を醸成し、リソースの最適化に重点を置き、Google Cloud のコスト削減機能を活用することで、コスト効率に優れたクラウドソリューションの構築と運用を可能にします。
レジリエンス、スケーラビリティ、柔軟性: ビジネスニーズの進化に伴い、アーキテクチャフレームワークは、需要の変化に合わせてスケーリングでき、高可用性を維持できる、災害や障害に強いクラウドデプロイメントの設計を支援します。
効果的な運用: アーキテクチャフレームワークは、運用、モニタリング、メンテナンスが容易で、運用面で安定したアーキテクチャの設計を促進します。
各ワークロードに特化した予測可能なパフォーマンス: アーキテクチャフレームワークは、ワークロードごとのニーズに基づいて予測可能なパフォーマンスを実現するワークロードの構築、デプロイ、運用に役立つガイダンスを提供します。
アーキテクチャフレームワークには、AI と ML など、特定の領域、業種、テクノロジーに対する、柱の枠を超えた視点も含まれています。

Google Cloud アーキテクチャフレームワークの原則と推奨事項は、Google のサイト信頼性エンジニアリング（SRE）プラクティス、DORA の特性、ユーザー重視の指標のための Google HEART フレームワーク、FinOps フレームワーク、ソフトウェアアーティファクトのためのサプライチェーンレベル（SLSA）、Google のセキュア AI フレームワーク（SAIF）など、Google および業界のベストプラクティスと合致しています。

ぜひ、アーキテクチャフレームワークを導入して Google Cloud のさらなる活用にお役立てください。セキュリティ、信頼性、コスト、パフォーマンス、運用に関する包括的なガイダンスに加え、AI や ML といった特定の業種や領域に特化した推奨事項も提供しています。詳しくは、Google Cloud アーキテクチャフレームワークをご覧ください。

-クロスプロダクトソリューションデベロッパー Kumar Dhanagopal

kro で Kubernetes のデベロッパーエクスペリエンスをシンプルに

Wed, 12 Feb 2025 01:05:00 +0000

※この投稿は米国時間 2025 年 1 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Kube Resource Orchestrator（kro、発音は crow と同じ）に関する Google Cloud、AWS、Azure のコラボレーションを発表できることを嬉しく思います。kro は、クラウドに依存しない Kubernetes ネイティブな方法で Kubernetes リソースのグループ化を定義するものです。kro を使用すると、アプリケーションとその依存関係を単一のリソースとしてグループ化でき、エンドユーザーが簡単に利用できるようなります。

Kubernetes リソースのオーケストレーションにおける課題

プラットフォームチームや DevOps チームは、アプリケーションチームによるワークロードのデプロイ方法を定義することを望んでおり、こうした基準を作成し、適用するためのプラットフォームとして Kubernetes を使用したいと考えています。各サービスは、リソースの作成、セキュリティの構成、モニタリングの設定、エンドユーザーインターフェースの定義など、あらゆることを処理する必要があります。クライアントサイドのテンプレートツール（Helm、Kustomize など）を利用することもできますが、エンドユーザーが利用するリソースのカスタムグループを作成する場合、Kubernetes にはプラットフォームチームが利用できるネイティブな方法がありません。

そのため、プラットフォームチームは、Kubernetes カスタムコントローラの構築や、Helm のようなパッケージングツールを使用するカスタムソリューションに投資する必要がありましたが、いずれも Kubernetes のカスタムリソース定義（CRD）のメリットを活用できないものでした。こうしたアプローチは構築、維持、トラブルシューティングに費用がかかり、Kubernetes の専門家以外にとっては扱いが困難でした。これは多くの Kubernetes ユーザーが直面する問題です。Google Cloud は、すべての Kubernetes ユーザーが K8s API をよりシンプルに利用できるように、ベンダー固有のソリューションを開発するのではなく、Amazon および Microsoft と協力することを選択しました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud コンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7faba1703bb0>), ('btn_text', '無料で始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/marketplace/product/google/container.googleapis.com'), ('image', None)])]>

kro がデベロッパーエクスペリエンスを簡素化する仕組み

kro は、Kubernetes ネイティブなフレームワークであり、複数のリソースを単一のユニットとしてデプロイするための再利用可能な API を作成できます。Kubernetes Deployment とその依存関係をカプセル化し、単一の API にまとめることで、Kubernetes に詳しくないアプリケーションチームでも利用できるようになります。kro を使用すると、エンドユーザーが参照するパラメータのみを公開するカスタムのインターフェースを作成できるため、エンドユーザーは Kubernetes やクラウドプロバイダの API の複雑さを感じずに利用できます。

kro は、ResourceGraphDefinition というコンセプトを導入することでこれを実現しています。ResourceGraphDefinition は、標準的な Kubernetes のカスタムリソース定義（CRD）を Kubernetes リソースのセットに拡張する方法を指定します。エンドユーザーは単一のリソースを定義し、kro はそれを CRD で定義されたカスタムリソースに拡張します。

kro は、Kubernetes リソースのグループ化や管理のために使用できます。ACK、KCC、ASO などのツールは、Kubernetes からクラウドプロバイダのリソースを管理するための CRD を定義します（これらのツールにより、ストレージバケットなどのクラウドプロバイダのリソースを Kubernetes リソースとして作成および管理できるようになります）。kro は、これらのツールのリソースを他の Kubernetes リソースとともにグループ化でき、アプリケーションのデプロイ全体と、それに依存するクラウドプロバイダのリソースを定義するためにも使用できます。

サンプルユースケース

以下では、Google Cloud での kro の使用例をいくつか紹介します。その他の例については、kro のウェブサイトをご覧ください。

例 1: GKE クラスタの定義

この例では、プラットフォーム管理者が、組織内のエンドユーザーに GKE クラスタの作成をセルフサービスで許可するとします。プラットフォーム管理者は、必要な Kubernetes リソースを定義する GKEclusterRGD という名前の kro ResourceGraphDefinition と、エンドユーザーが構成できるオプションのみを公開する GKEcluster という名前の CRD を作成します。クラスタの作成に加えて、プラットフォームチームは、ポリシーやエージェントなどの管理ワークロードをクラスタがデプロイすることも望んでいます。ResourceGraphDefinition は以下のリソースを定義し、KCC を使用して K8s CRD から Google Cloud API へのマッピングを提供します。

GKE クラスタ、コンテナノードプール、IAM サービスアカウント、IAM ポリシーメンバー、サービス、ポリシー

次に、プラットフォーム管理者は、エンドユーザーインターフェースを定義し、CRD のインスタンスを作成することで新しいクラスタを作成できるようにします。CRD では以下のことを定義します。

クラスタ名、ノードプール名、最大ノード数、ロケーション（us-east1 など）、ネットワーク（省略可）

ポリシー、サービスアカウント、サービスアクティベーション（および、これらのリソース間の関係）に関連する情報はいずれもエンドユーザーに表示されないため、エクスペリエンスが簡素化されます。

例 2: ウェブ アプリケーションの定義

この例では、DevOps エンジニアがウェブアプリケーションとその依存関係の再利用可能な定義を作成するとします。WebAppRGD という名前の ResourceGraphDefinition を作成し、WebApp という名前の新しい Kubernetes CRD を定義します。この新しいリソースは、ウェブアプリケーション環境に必要なすべてのリソースをカプセル化します。リソースには以下のものが含まれます。

デプロイ、サービス、サービスアカウント、モニタリングエージェント、クラウドリソース（オブジェクトストレージバケットなど）

WebAppRGD ResourceGraphDefinition は、デフォルト構成を設定できるほか、デプロイ時にエンドユーザーが設定できるパラメータを定義することもできます（kro を使用することで、変更不可とするものと、エンドユーザーが構成できるものを柔軟に決定できます）。次に、開発者はユーザー向けのパラメータを入力して、WebApp CRD のインスタンスを作成します。その後、kro が必要な Kubernetes リソースをデプロイします。

kro の主なメリット

kro は、プラットフォームエンジニアリングチームにとって大きな前進であり、以下のような多くのメリットをもたらします。

Kubernetes ネイティブ: Kubernetes カスタムリソース定義（CRD）を活用して Kubernetes を拡張でき、あらゆる Kubernetes リソースと連携して、既存の Kubernetes ツールやワークフローと統合できます。
シンプルなエンドユーザー エクスペリエンスを実現: Kubernetes リソースの複雑なグループに対してエンドユーザーインターフェースを簡単に定義できるため、Kubernetes の専門家でなくても Kubernetes に構築されたサービスを利用しやすくなります。
アプリケーション チーム向けに標準化されたサービスを実現: kro のテンプレートは、さまざまなプロジェクトや環境で再利用できるため、整合性が促進され、作業の重複を軽減できます。

kro を使ってみる

kro は、GitHub のオープンソースプロジェクトとして利用できます。GitHub の組織は現在、Google、AWS、Microsoft の各チームが共同で所有しており、コミュニティからの貢献を歓迎しています。また、こちらのウェブサイトでは、kro のインストールや使用に関するドキュメント、使用例、ユースケースなどを提供しています。kro は初期段階のプロジェクトであるため、まだ本番環境での使用には適していませんが、ぜひお客様の Kubernetes 開発環境でテストしてみてください。

-シニアクラウドデベロッパーアドボケイト、Abdelfettah Sghiouar
-プロダクトマネージャー、Nic Slattery

2025 年に向けたプラットフォームの準備: プラットフォームエンジニアリングに関する新たな調査で成功の秘訣が明らかに

Wed, 05 Feb 2025 01:15:00 +0000

※この投稿は米国時間 2025 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

Gartner の 2024 年の戦略的テクノロジーのトレンド、トップ 10 の一つであるプラットフォームエンジニアリングは、ソフトウェアデリバリーの迅速化や開発者の生産性向上を求める企業にとって不可欠なものとして急速に注目を集めています。プラットフォームエンジニアリングはどのようにしてそれを実現するのでしょうか？プラットフォームエンジニアリングは、開発者にかかる認知負荷を最小限に抑えながら、効率的でスケーラブルなソフトウェアの開発、デプロイ、管理を可能にする適切なインフラストラクチャ、ツール、プロセスを提供します。

プラットフォームエンジニアリングを成功させる秘訣を紐解くために、Google Cloud は Enterprise Strategy Group（ESG）と協力して、正式なプラットフォームエンジニアリングチームを持つ、従業員が 500 人以上の組織で働いている世界中の IT プロフェッショナルやアプリケーション開発者 500 人を対象に、包括的な研究調査を行いました。その目標は、プラットフォームエンジニアリングを導入しているかどうか、導入している場合は、それが企業のソフトウェアデリバリー能力にどのような影響を与えているかを把握することでした。

調査結果のレポート「Building Competitive Edge With Platform Engineering: A Strategic Guide（プラットフォーム エンジニアリングで競争力を高める: 戦略ガイド）」では、課題を克服し、プラットフォームエンジニアリングを最大限に活用するための一般的なパターン、予想されること、実践的なベストプラクティスを明らかにしています。このブロク投稿では、調査で得られた特に有用な分析情報をいくつか取り上げてご紹介します。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbd3dd970>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

プラットフォームエンジニアリングはもはや必須

調査では、プラットフォームエンジニアリングがもはや生まれたばかりの概念ではないことが明らかになりました。調査への参加を依頼したグローバル組織の 55% がすでにプラットフォームエンジニアリングを導入していました。そのうち 90% は、より多くの開発者に向けてその対象範囲を広げることを計画しています。さらに、プラットフォームエンジニアリングを導入している企業の 85% が、開発者はプラットフォームに頼って成功していると報告しています。これらの数字は、プラットフォームエンジニアリングがもはや単なるトレンドではなく、クラウドや IT への投資の可能性を最大限に引き出して競争上の優位性を獲得することを求めている組織にとって、必要不可欠な戦略となりつつあることを示しています。

図 1: 調査した 900 社以上のグローバル組織の 55% がプラットフォームエンジニアリングをすでに導入

プラットフォームエンジニアリングを成功に導く 3 つの鍵

レポートでは、成熟したプラットフォームエンジニアリングリーダーの成功の核となる 3 つの重要な要素を特定しています。

プラットフォーム エンジニアと他のチーム間の密接なコラボレーションを促進して足並みを揃える
「プロダクトとしてのプラットフォーム」アプローチを採用し、開発者プラットフォームに明確なロードマップ、伝達価値、緊密なフィードバックループを設ける
デプロイ頻度、障害復旧時間、変更のリードタイムなど、明確な指標を使用してパフォーマンスを測定することで成功を定義する

注目すべき点は、多くの組織がプラットフォームエンジニアリングの導入に取り組んでいる一方で、上記の 3 つの重要な要素を手法に完全に組み込んでいるのはわずか 27% にすぎないことです。これは、さらに改善できる大きなチャンスがあることを示しています。

AI: プラットフォームエンジニアリングの新たなパートナー

このレポートで示された最も説得力のある分析情報の一つは、プラットフォームエンジニアリングと AI のシナジー関係です。驚くべきことに、回答者の 86% が、AI のビジネス価値を最大限に発揮するにはプラットフォームエンジニアリングが不可欠だと確信しています。同時に、大多数の企業は、AI がプラットフォームエンジニアリングを推進する触媒になるとみなしていて、企業の 94% がプラットフォームエンジニアリングの将来には AI が「不可欠」または「重要」であると認識しています。

スピードだけにとどまらない: プラットフォームエンジニアリングの主な利点

また、この調査では、前述したプラットフォームエンジニアリングを成功に導く 3 つの主要な要素を採用しているかどうか、またどの程度採用しているかに基づいて、プラットフォームエンジニアリングの導入組織を 3 つのグループ（新興、確立済み、先進的）に分類しています。調査では、先進的な導入組織がスピード、効率性、生産性の面でより多くのメリットを得ていることを示しています。また、この調査は、新興の導入組織や確立済みの導入組織に対して、プラットフォームエンジニアリングの全体的な成熟度を高めて、より多くのメリットを得るためのガイダンスを提供しています。

レポートでは、プラットフォームエンジニアリングの次のような他のメリットにも言及しています。

従業員の満足度の向上、人材の獲得と維持: 成熟したプラットフォームにより、良好な開発者エクスペリエンスが育まれ、それが企業文化に直接影響を及ぼします。成熟した開発者プラットフォームを持つ組織で働く開発者や IT プロフェッショナルは、自分の職場を知人にすすめる可能性がはるかに高くなります。
製品化までの時間を短縮: 成熟したプラットフォームエンジニアリングの導入組織は、製品化までの時間を大幅に短縮しています。プラットフォームエンジニアリングの先進的な導入組織の 71% が、製品化までの時間が大幅に短縮されたと回答しています。これに対して、成熟度の低い導入組織では 28% でした。

独力で行わない

調査した組織の大多数（96%）は、オープンソースツールを活用して開発者プラットフォームを構築しています。さらに、ほとんどの組織（84%）が、外部ベンダーと提携してオープンソース環境の管理とサポートを行っています。サードパーティやクラウドパートナーとプラットフォームを共同管理することで、より高度なイノベーションを実現できるというメリットがあります。プラットフォームを共同管理している組織では、開発者の生産時間の平均 47% をイノベーションと試験運用に割り当てています。これに対して、プラットフォームを社内スタッフで管理する組織では、わずか 38% です。

成功に向けた準備としてレポート全文を読む

このブロク投稿では、調査で得られた主な結果を簡単に紹介しました。レポート全文では、時代の先端を行くために役立つプラットフォームエンジニアリングの主要な戦略や手法をさらに詳しく紐解いています。レポートをダウンロードして、以下のような他のトピックもご覧ください。

集中型および分散型プラットフォーム エンジニアリング チームの戦略に関する考慮事項
プラットフォーム エンジニアリングへの投資の背後にある主な推進要因
開発者のニーズに沿ったプラットフォームの導入を推進するための最優先事項
プラットフォームエンジニアリングの成功への道のりにおいて、予測し、乗り越えるべき主な課題
プラットフォームエンジニアリングで組織全体にわたって生産性、パフォーマンス、イノベーションを高める方法
競争上の優位性を獲得するうえでのプラットフォーム エンジニアリングにおけるオープンソースの戦略的重要性
AI 導入の増加に伴う AI / ML ワークロードに対するプラットフォーム エンジニアリングの革新的役割
適切なプラットフォーム エンジニアリング戦略を構築してスケーラビリティとイノベーションを促進する方法

レポート全文をダウンロードしてお読みください。

-Google、プロダクトマーケティングマネージャー Ning Ge
-Google、シニアプロダクトマネージャー Dave Bartoletti

Cloud Deploy の新機能を使用した、より安全な自動デプロイ

Thu, 30 Jan 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Deploy は、アプリケーションの配信を自動化する、フルマネージド継続的デリバリープラットフォームです。既存の自動化機能に加えて、お客様からは、本番環境を信頼性の高い最新の状態に維持するためにデプロイを自動化する他の方法もほしいというご要望をいただいていました。

このたび、それを可能にする 3 つの新機能（すべてプレビュー版）をリリースいたしました。

1. 修復ロールアウト

新しい修復ロールアウト自動化ルールを使用すると、エラーが発生したときに、失敗したデプロイを再試行したり、過去に成功したリリースに自動的にロールバックしたりすることができます。このようなエラーは、デプロイ前の SQL 移行、GKE クラスタとの通信時に検出される構成ミス、デプロイ検証ステップの一部としてなど、あらゆるデプロイフェーズで発生する可能性があります。いずれの場合でも、修復ロールアウト自動化により、失敗したステップを、構成可能な回数再試行できるため、結果が安定しないこともあるエンドツーエンドのテストにも最適です。再試行が成功すると、ロールアウトは続行されます。再試行が失敗した場合（または再試行が設定されていない場合）、修復ロールアウト自動化により、過去に成功したリリースにロールバックすることもできます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fabbc17f100>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

2. デプロイポリシー

デプロイの自動化は便利ですが、自動化にいくらかの制約を設けることが重要となる場合もあります。新しいデプロイポリシー機能は、これらの自動化機能（またはユーザー）が行える操作を制限することを目的としています。まず、夜間、週末、重要なイベント中などにデプロイを禁止できる時間枠ポリシーをリリースしました。ポリシーオーバーライダーロールを持つオンコール担当者がこれらのポリシーを回避するために「ブレークグラス」を行うことはできますが、大規模なデモの途中で自動デプロイがロールアウトをトリガーすることはできません。

3. 時間指定プロモーション

リリースが正常にロールアウトされた後に、次の環境に自動的にデプロイすることも可能です。以前の自動プロモート機能では、指定した期間が経過した後にリリースをプロモートすることができました（例: ステージングに移行してから 12 時間後に本番環境に移行する）。しかし、多くの場合、プロモーションは経過時間に基づいてではなくスケジュールに従って行うのが理想的です。たとえば、Google 社内では通常、毎週木曜日に開発環境からステージング環境にプロモートし、月曜日の朝に本番環境へのプロモートを開始することを推奨しています。新しい時間指定プロモーション自動化機能により、Cloud Deploy は、スケジュール設定されたプロモーションを自動で処理できます。

今後の計画

包括的で使いやすく、費用対効果に優れた DevOps ツールは、効率的なソフトウェアデリバリーのために重要な存在です。Cloud Deploy が、完全な CI / CD パイプラインの実装を実現するうえで皆様のお役に立てば幸いです。今後数か月にわたって Cloud Deploy に魅力的な機能を導入してまいりますので、引き続きご注目ください。

こうした新機能を活用して既存のパイプラインを今すぐアップデートしてみませんか？方法については、プロダクトページ、ドキュメント、クイックスタート、チュートリアルをご参照いただけます。最後に、Cloud Deploy に関するご意見やご感想があれば、ぜひフォーラムの会話に参加してお聞かせください。皆様からのご意見やご感想をお待ちしております。

DevOps & SRE

Unified Maintenance: Google Cloud 全体のメンテナンスを管理するための新たな統合ソリューション

次のステップ

プラットフォーム使用の落とし穴（パート 1）: アクティビティの多さが必ずしも価値の高さを示すとは限らない理由

最初の測定: プラットフォームの価値に焦点を当てる

チームのパフォーマンスを把握できるようにする

測定対象を選択する

プラットフォーム使用の落とし穴（パート 2）: 意味のあるモニタリング指標を選択する

エンジニアの主観的なフィードバックを収集する

サービスの健全性 - 機能の導入とそれ以降

プラットフォームは期待に応えている？重要ポイント

スマートな投資: DORA で改善の文化を構築した FINRA の事例

導入から成果まで: DORA AI 機能モデルの活用

成果を増幅させる 7 つの要因

導入の第一歩: チームの評価

バリュー ストリーム マッピングで詳細に分析

継続的な改善の基盤を築く

Google Cloud でのカオス エンジニアリング: 原則、実践、開始方法

カオス エンジニアリングについて

カオス エンジニアリングの原則と実践

カオス エンジニアリングの要素

カオス エンジニアリングを開始する

2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状

AI は偉大な増幅器

7 つのチームのアーキタイプ

「DORA AI 機能モデル」で AI の価値を引き出す

リーダーが最初に取り組むべきこと

Google Cloud の設定のご紹介: 安全なクラウド基盤へのガイド付きパスウェイ

ニーズに合ったファンデーションを選びましょう

強固な基盤を構築するための構成要素

クラウドをより迅速かつスマートに活用

Cloud Hub の最適化と Cost Explorer を使用してクラウド費用を最適化する

アプリケーションの費用と使用率

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

プラットフォーム エンジニアリングを駆使してデベロッパー エクスペリエンスを簡素化 - パート 2

プラットフォームの境界を移動する

マイクロサービスを超えて

プラットフォーム エンジニアリングを駆使して開発者の利便性を強化 - パート 1

ステップ 1: モノリシックからマルチテナントへ

すべての道が成功への道

インシデント対応に AI を活用する: Personalized Service Health と Gemini Cloud Assist のインテグレーション

Personalized Service Health の一般提供を開始: 今すぐ始めましょう

Google Cloud の KCC を使用して Waze を Infrastructure as Code に移行

Config Connector への移行

最初のステップ: Config Connector

仕組み

目標へのアプローチ

目標の達成

MLOps パイプラインで ML システムを最適化するための SRE ガイド

ML モデルのトレーニング

ML の新鮮さとデータ量

提供効率

費用対効果

スケールのための自動化

次のステップ

新しい Google Cloud Trace エクスプローラのご紹介

新しい Trace エクスプローラの概要

舞台裏

原則に基づく適切な設計のフレームワークを活用したクラウド導入の加速

このアーキテクチャ フレームワークの対象ユーザー

アーキテクチャ フレームワークを導入するメリット

kro で Kubernetes のデベロッパー エクスペリエンスをシンプルに

Kubernetes リソースのオーケストレーションにおける課題

kro がデベロッパー エクスペリエンスを簡素化する仕組み

サンプル ユースケース

kro の主なメリット

kro を使ってみる

2025 年に向けたプラットフォームの準備: プラットフォーム エンジニアリングに関する新たな調査で成功の秘訣が明らかに

プラットフォーム エンジニアリングはもはや必須

プラットフォーム エンジニアリングを成功に導く 3 つの鍵

AI: プラットフォーム エンジニアリングの新たなパートナー

スピードだけにとどまらない: プラットフォーム エンジニアリングの主な利点

独力で行わない

成功に向けた準備としてレポート全文を読む

Cloud Deploy の新機能を使用した、より安全な自動デプロイ

1. 修復ロールアウト

2. デプロイ ポリシー

3. 時間指定プロモーション

今後の計画

-ソフトウェア エンジニア Minna Howell-ソフトウェア エンジニア Katie Zhang

バリューストリームマッピングで詳細に分析

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

カオスエンジニアリングについて

カオスエンジニアリングの原則と実践

カオスエンジニアリングの要素

カオスエンジニアリングを開始する

プラットフォームエンジニアリングを駆使してデベロッパーエクスペリエンスを簡素化 - パート 2

プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1

このアーキテクチャフレームワークの対象ユーザー

アーキテクチャフレームワークを導入するメリット

kro で Kubernetes のデベロッパーエクスペリエンスをシンプルに

kro がデベロッパーエクスペリエンスを簡素化する仕組み

サンプルユースケース

2025 年に向けたプラットフォームの準備: プラットフォームエンジニアリングに関する新たな調査で成功の秘訣が明らかに

プラットフォームエンジニアリングはもはや必須

プラットフォームエンジニアリングを成功に導く 3 つの鍵

AI: プラットフォームエンジニアリングの新たなパートナー

スピードだけにとどまらない: プラットフォームエンジニアリングの主な利点

2. デプロイポリシー

-ソフトウェアエンジニア Minna Howell
-ソフトウェアエンジニア Katie Zhang