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

※この投稿は米国時間 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 氏が詳しく説明してくれます。プラットフォーム エンジニアリングを自社組織にどのように適用できるかを検討するきっかけとなるはずです。

ステップ 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 つの主要な機能によって支えられています。

1. Paved Road パイプライン: これはサービス全体で動作し、Google Cloud リソースのプロビジョニングやオブザーバビリティ ツールなどの機能を提供します。

2. マイクロサービス 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 氏