T最新テックトレンド

Shopifyが開発者を解き放つ！サーバーレスツールキット「Prodkit」で実現する高速・安全なCloud Runデプロイメントの舞台裏

Google Cloud Tech
0:00--:--

テクノロジーの世界は常に進化し、企業はより迅速に、より安全に、そしてより効率的にアプリケーションを展開する方法を模索しています。eコマースの巨頭であるShopifyも例外ではありません。同社は、数百万のマーチャントを支え、年間数十億ドルの取引を処理する膨大な規模を誇ります。その複雑なシステムランドスケープの中で、開発者の生産性を最大化し、イノベーションを加速させるための新たなアプローチが求められていました。

この記事では、ShopifyがGoogle Cloud Run上で開発者のためのサーバーレスツールキット「Prodkit」を構築し、いかにしてインフラストラクチャの複雑さから開発者を解放し、セキュリティとオブザーバビリティを標準化しながら、かつてないスピードと安定性でアプリケーションをデプロイできるようになったのかを、詳細かつ専門的に解説します。これは単なる技術導入の物語ではなく、開発者体験の変革、エンタープライズレベルのセキュリティの再定義、そしてオブザーバビリティの新たな基準を打ち立てる壮大なジャーニーです。

導入：eコマースの最前線で求められるスピードと安定性

Shopifyは、世界中の大小さまざまなマーチャントにeコマースプラットフォームを提供するリーディングカンパニーです。年間89億ドルを超える収益と、数兆ドル規模のグローバルコマースを支えるその裏側には、高度に洗練された技術スタックが存在します。長年にわたり、ShopifyはGoogle Kubernetes Engine (GKE) とKubernetesを深く活用し、その上で多くの高機能なツールを構築してきました。これらのツールは、同社の「ビッグビジネスムーバー」と呼ばれる最も洗練されたアプリケーションを支える「プラットフォームの中のプラットフォーム」として機能し、その複雑さと機能性は時間とともに増してきました。

しかし、この高度に最適化されたKubernetesプラットフォームは、Shopifyのすべてのアプリケーションに最適なわけではありませんでした。特に、小規模でそれほど複雑ではないアプリケーションにとっては、既存のプラットフォームツールが「オーバースペック」であると感じられることも少なくありませんでした。そこで目を向けられたのが、登場したばかりのサーバーレスコンテナプラットフォーム「Cloud Run」です。

Cloud Runは、サーバーレスのシンプルさとコンテナの柔軟性を兼ね備え、開発者がインフラ管理の心配なくコードのデプロイに集中できるという大きな魅力を持っていました。しかし、単に開発者に「Cloud Runを使って楽しんでください」と伝えるだけでは、Shopifyの求める基準には届きません。データベース設定、ロードバランシング、キャッシング、サービス間の通信、そして何よりもエンタープライズレベルのセキュリティといった「退屈な作業（Toil）」が依然として残っていました。Shopifyは、これらの手作業を自動化し、開発者が本来の創造的な作業に集中できる環境を構築することを決意しました。これが、サーバーレスツールキット「Prodkit」誕生の背景です。

Prodkitは、開発者がCloud Run上でアプリケーションを迅速、安全、かつ効率的にデプロイ・管理できるよう、インフラストラクチャのセットアップ、管理、そして継続的デプロイを自動化することを目的に開発されました。この記事では、Prodkitがどのようにして開発者の「苦役」を解消し、Shopifyの技術的進化を支えているのかを深掘りしていきます。

セクション1: なぜ今、サーバーレスか？ShopifyがProdkitを構築した背景

ShopifyがProdkitを開発するに至った道のりは、同社の技術的成熟と、開発者体験への深いコミットメントを示しています。彼らがKubernetesとGKEに長年投資し、その上で洗練されたプラットフォームを構築してきたことは疑いようがありません。しかし、その成功の裏で、新たな課題が浮上していました。

ShopifyのKubernetes活用と「プラットフォームの中のプラットフォーム」の課題

Shopifyは6年以上にわたりGKEとKubernetesを深く活用し、その分野で高い専門性を培ってきました。彼らが開発したツール群は、主要なビジネスロジックを担う大規模で複雑なアプリケーションを安定稼働させるための強固な基盤となっています。しかし、この「プラットフォームの中のプラットフォーム」は、時間とともにその機能と複雑性を増していきました。

例えば、新しいアプリケーションをデプロイする際、開発者は多岐にわたる設定や調整を行う必要がありました。これには、KubernetesのYAMLファイルの記述、Helmチャートの管理、CI/CDパイプラインの構築、ネットワークポリシーの定義、セキュリティ設定、モニタリングの統合などが含まれます。これらの作業は、Kubernetesの専門知識を持つプラットフォームチームにとっては日常ですが、コアアプリケーションロジックに集中したい開発者にとっては、学習曲線が急で、時間と労力を要する「オーバーヘッド」となることがありました。

特に、以下のようなケースで既存のKubernetesプラットフォームの「オーバースペック感」が顕著になりました。

  • 小規模な内部ツールやスクリプト: 数人の開発者が利用するような小規模なサービスや、特定のタスクを処理するためのバックグラウンドジョブなど。これらのアプリケーションは、高可用性や複雑なスケーリング要件を必要としない場合が多い。
  • プロトタイプや実験的なプロジェクト: 新しいアイデアを迅速に検証したい場合。インフラ設定に時間をかけるよりも、コードの実装と検証に集中したい。
  • ステートレスなAPIサービス: リクエスト/レスポンスのみを処理し、永続的な状態を持たないアプリケーション。Kubernetesの高度なオーケストレーション機能が必ずしも必要ではない。

このようなアプリケーションに対して、既存のKubernetesプラットフォームを適用することは、開発者がアプリケーションの本質的な価値創造から遠ざかる原因となりかねませんでした。

Cloud Runの登場と開発者体験向上への期待

そんな中、Google Cloud Runが登場しました。Cloud Runは、コンテナ化されたアプリケーションをフルマネージドなサーバーレス環境で実行できるサービスです。その最大の魅力は、以下の点にありました。

  • シンプルさ: コンテナイメージをデプロイするだけでよく、サーバーやクラスタの管理が一切不要。
  • 従量課金: リクエストがないときはコンテナがゼロにスケールされ、実行されたリソースに対してのみ課金されるため、コスト効率が高い。
  • 高速スケーリング: 必要に応じて瞬時にスケールアウト・スケールインが可能。
  • 任意の言語・フレームワーク: コンテナイメージなので、任意のプログラミング言語やライブラリを使用できる。

これらの特徴は、Shopifyの直面していた課題に対する潜在的な解決策として大きな可能性を秘めていました。特に、小規模なサービスやAPI、バックグラウンドジョブといったユースケースにおいて、Cloud Runはインフラ管理のオーバーヘッドを劇的に削減し、開発者の生産性を向上させる強力なツールとなり得ると考えられました。

「手作業」の自動化：Prodkitの使命

しかし、Cloud Runが提供する「シンプルさ」も、エンタープライズ環境で要求されるすべての要件を自動的に満たすわけではありません。Shopifyのような大規模組織では、アプリケーションのデプロイには以下のような付随作業が常に伴います。

  • データベースのプロビジョニングと接続設定: Cloud SQLのようなマネージドデータベースインスタンスの作成、接続情報の設定、認証。
  • ロードバランシングとネットワーク設定: 外部からのアクセスをルーティングするためのロードバランサーのセットアップ、VPCコネクタやVPC Egressの設定。
  • キャッシング層の統合: Redisなどのインメモリキャッシュのプロビジョニングとアプリケーションからの利用設定。
  • セキュリティ設定: IAMポリシーの適用、シークレット管理、イメージの署名と検証、ネットワークセキュリティグループの構成。
  • モニタリングとアラート: メトリクス、ログ、トレースの収集と、異常検知時のアラート設定。

これらの作業を個々の開発者がCloud Runを利用するたびに行うことは、やはり大きな負担となります。Shopifyは、長年のKubernetes運用で培った「可能な限り自動化する」という哲学をCloud Runにも適用することを決意しました。開発者がこれらの「手作業」に煩わされることなく、純粋にビジネスロジックの実装に集中できる環境を提供すること。これが、Prodkitの最も重要な使命となりました。

Prodkitは、Cloud Runのシンプルさを最大限に引き出しつつ、Shopifyのエンタープライズ要件（セキュリティ、オブザーバビリティ、スケーラビリティ）を自動的に満たすための抽象化レイヤーとして設計されました。それは、開発者がより速く、より安全に、より安心して価値を創造するための「生産性向上ツールキット」であり、Shopifyの技術的フットプリントを多様化し、将来の成長を加速させるための戦略的な一手だったのです。

セクション2: Prodkitの核心 - シンプルなインフラ管理とデプロイメントの自動化

Prodkitは、開発者がCloud Run上でアプリケーションをデプロイし、そのライフサイクルを管理するための包括的なソリューションです。その核心には、インフラストラクチャのセットアップと管理、そして継続的なデプロイメントの自動化という二つの主要な機能があります。

Prodkitの主要コンポーネントと開発者向けインターフェース

Prodkitは、複数のコンポーネントが連携して動作することで、開発者にシームレスな体験を提供します。

  1. Prod CLI (Command Line Interface): 開発者がProdkitとインタラクションするための主要なツールです。シンプルなコマンドを通じて、インフラの初期化、プロビジョニング、デプロイ、アプリケーションの起動など、一連の操作を実行します。
  2. GitHub Actions Workflow: ShopifyのCI/CDパイプラインの中心を担います。開発者がコードをGitHubリポジトリにプッシュすると、このワークフローがトリガーされ、コンテナイメージのビルド、テスト、そしてCloud Runへのデプロイが自動的に行われます。
  3. Terraform Modules: インフラストラクチャをコードとして定義し、管理するためのコア技術です。Prodkitは、Shopifyの標準化されたCloud Runインフラストラクチャを抽象化し、再利用可能なTerraformモジュールとして提供します。

これらのコンポーネントは、以下の図のような形で連携し、開発者の操作をインフラストラクチャの変更へと変換します。

[開発者] --(Prod CLI)--> [GitHub Actions Workflow] --(Terraform Changes)--> [インフラ]
      ^                                      |
      |                                      v
      +---(Git Push/Merge)-------------------+

開発者は、主にProd CLIコマンドとGit操作を通じてProdkitとインタラクションします。

prod.ymlの威力：カスタムYAMLがTerraformを生成する魔法

Prodkitの最も革新的な側面の一つは、カスタムYAML形式であるprod.ymlファイルの使用です。これは、開発者がアプリケーションに必要なインフラストラクチャを、非常にシンプルかつ高レベルな方法で定義するためのインターフェースとなります。Prodkitは、このprod.ymlを読み込み、Shopifyの標準に準拠したTerraform構成へと変換します。

具体的なデモフローとprod.ymlの役割

Prodkitでのアプリケーション開発とデプロイの典型的なフローは以下のようになります。

  1. prod initによる初期化: 開発者は、既存のGitリポジトリ（例：Railsアプリケーション）内でprod initコマンドを実行します。これにより、リポジトリ内にいくつかのファイルが生成されますが、特に重要なのはprod.ymlとGitHub Actionsワークフローファイルです。 prod.ymlは、次のようなシンプルな形式でアプリケーションの要件を記述します。

    # prod.ymlの例
web:
  port: 8080
  min_instances: 1
  max_instances: 10
  cpu: 1
  memory: 512Mi
database:
  type: cloudsql_postgres
  version: 14
cache:
  type: memory_store_redis

    このファイルは、このアプリケーションが「ウェブプロセス」「PostgreSQLデータベース」「Redisキャッシュ」を必要とすることを、ごく簡潔に示しています。開発者は、詳細なクラウドプロバイダ固有の構成を記述する必要はありません。

  2. prod upによるインフラプロビジョニング: prod initの後、開発者はprod upコマンドを実行します。このコマンドは、prod.ymlの内容に基づいてTerraformプランを生成し、実行します。

    • Prod CLIはprod.ymlを読み込みます。
    • 内部で、このYAML定義がShopifyが用意したTerraformモジュールを呼び出すための具体的なTerraformコードに変換されます。
    • Terraformは、このコードを基にCloud Runサービス、Cloud SQLインスタンス、Memorystore for Redisインスタンスなどの必要なGCPリソースをプロビジョニングまたは更新します。

    開発者は、Terraformが作成・変更するリソースのリストを確認し、承認することで、数分で必要なインフラストラクチャをクラウド上に構築できます。

  3. prod deployまたはGitプッシュによるアプリケーションデプロイ: インフラが整ったら、アプリケーションコードをデプロイします。

    • 開発者がコードをGitリポジトリのmainブランチにプッシュするか、プルリクエストをマージすると、GitHub Actionsワークフローが自動的にトリガーされます。
    • このワークフローは、アプリケーションのコンテナイメージをビルドし、Artifact Registryなどのコンテナレジストリにプッシュします。
    • その後、Cloud Runサービスに新しいリビジョンとしてデプロイされます。
    • あるいは、prod deployコマンドを明示的に実行して、デプロイプロセスを開始することも可能です。

  4. prod openによるアプリケーションアクセス: デプロイが完了すると、prod openコマンドでデプロイされたアプリケーションのURLをブラウザで開くことができます。これにより、開発者はすぐに自分のアプリケーションが本番環境で動作していることを確認できます。

この一連のフローは、開発者がインフラの複雑さに煩わされることなく、迅速にコードをデプロイし、テストできることを示しています。

Prodkitに至るまでの変遷：抽象化への道のり

Prodkitのprod.ymlモデルは、Shopifyがいくつかの異なるアプローチを試行錯誤した結果として生まれました。この道のりは、開発者体験と運用効率のバランスを追求する上で貴重な教訓を提供しています。

1. G-Cloud CLIとClickOps (初期アプローチ)

当初、Prodkitはgcloud CLIコマンドの長いリストを直接実行する形でインフラをプロビジョニングしていました。開発者がprod upを実行すると、Cloud RunサービスやCloud SQLインスタンスを作成するgcloudコマンドがツール内部で実行されます。

メリット:

  • GCPプラットフォームの学習: 開発者が生のGCPリソースとインタラクションする機会が多く、GCPの仕組みを理解するのに役立ちました。
  • シンプルなメンテナンス: 基本的にはコマンドの羅列であるため、ツールの初期開発は比較的容易でした。

課題:

  • 再現性の欠如: gcloud CLIのバージョンアップや、ラッパーコードの変更によって、prod upを実行するたびに異なる結果が生じる可能性がありました。これは「インフラストラクチャの不変性」というIaC (Infrastructure as Code) の原則に反します。
  • Terraformの劣化版: コードの多くが、現在の状態と望ましい状態を比較し、差分を調整するという、Terraformが既に行っている作業の模倣になっていました。これは非効率的であり、エラーの温床となる可能性がありました。

このアプローチは、学習フェーズには役立ちましたが、エンタープライズレベルでの信頼性と管理性には不十分でした。

2. 直接Terraformファイル (prod.tf) の利用 (第二段階)

G-Cloud CLIアプローチの課題を認識したShopifyは、IaCのベストプラクティスに従いTerraformへの移行を決定しました。開発者のリポジトリにprod.tfというTerraformファイルを配置し、Shopifyが提供するTerraformモジュールを参照する形式を採用しました。

メリット:

  • IaCの恩恵: インフラストラクチャの定義がコードとして管理され、バージョン管理、レビュー、再現性が確保されました。

  • モジュール化による簡素化: 開発者は、Shopifyが提供する高レベルなモジュール（例：Cloud Runモジュール、Cloud SQLモジュール）を参照するだけでよく、複雑なTerraformの記述を避けることができました。

    # prod.tfの例 (モジュール参照)
module "web_app" {
  source = "git::ssh://git@github.com/shopify/prodkit-modules.git//cloudrun-service?ref=v1.0.0"
  project_id = var.project_id
  service_name = "my-web-app"
  # ... その他のCloud Run設定
}

module "database" {
  source = "git::ssh://git@github.com/shopify/prodkit-modules.git//cloudsql-postgres?ref=v1.0.0"
  project_id = var.project_id
  instance_name = "my-db"
  # ... その他のCloud SQL設定
}

課題:

  • Cloud Runの急速な進化への追従: 当時、Cloud Runは比較的新しいサービスであり、機能追加や変更が頻繁に行われていました。これにより、ShopifyのプラットフォームチームがTerraformモジュールを更新するたびに、開発者は自分のリポジトリ内のprod.tfファイルを更新する必要がありました。
  • 開発者負担の再燃: 開発者は、自身のアプリケーションの機能とは直接関係のない、基盤インフラストラクチャの変更のためにprod.tfを頻繁に修正しなければなりませんでした。これは、Terraform導入の目的であった「開発者負担の軽減」と矛盾しました。

この「パイプドリーム」は、Terraformのリジッドさ、特にAPI変更への対応という点で、現実の壁にぶつかりました。

3. prod.ymlへの集約と高レベル抽象化 (現在のProdkit)

上記の課題を克服するために、Shopifyは現在のprod.ymlモデルにたどり着きました。これは、開発者向けのインターフェースと、基盤となるインフラ実装を完全に分離する「高レベル抽象化」の概念に基づいています。

メリット:

  • 開発者の解放: 開発者は、prod.ymlという簡潔な形式でアプリケーションの要件を定義するだけでよく、基盤となるTerraformモジュールやCloud RunのAPI変更について心配する必要がなくなりました。プラットフォームチームがTerraformモジュールを更新しても、prod.ymlは変更されないため、開発者の「苦役」が劇的に減少しました。
  • 基盤チームの自由度: プラットフォームチームは、prod.ymlで定義された「開発者が求めるもの」（例：Webアプリ、データベース、キャッシュ）という契約を守る限り、基盤となるTerraformの実装を自由に改善・変更できるようになりました。
  • 分かりやすいインターフェース: どのリポジトリを見てもprod.ymlを読めば、そのアプリケーションがどのようなインフラリソースを利用しているかが一目で理解できます。

この進化の過程は、開発者の生産性を最大化し、かつ運用チームが効率的にインフラを管理するという、エンタープライズ組織におけるプラットフォーム構築の理想形を示しています。Prodkitは、開発者がインフラの複雑さから解放され、本来の価値創造に集中できる環境を実現したのです。

セクション3: 開発者の自由とエンタープライズセキュリティの両立 - Prodkitの強固な守り

Cloud Runへの移行は、開発者に大きな自由と生産性をもたらす一方で、Shopifyのような大規模組織にとっては新たなセキュリティ上の課題を提起しました。従来のKubernetes環境で培ってきた包括的なセキュリティ制御を、新しいサーバーレスパラダイムにどのように適応させるか、あるいは再構築するかが重要なミッションとなりました。Shopifyのスタッフインフラセキュリティエンジニアであるオーウェン・カミングス氏は、開発者がセキュリティの心配なくコードを出荷できる「安全なグリーンパス」を構築するために、多岐にわたる対策を講じました。

サーバーレス環境におけるセキュリティの新たな課題

Cloud RunはGoogleによってフルマネージドされているため、基盤となるインフラストラクチャ（VM、OS、ネットワークなど）の多くはGoogleが責任を持ちます。これにより、Shopifyはインフラ層のセキュリティについて心配する必要がなくなります。しかし、アプリケーション層やそのデプロイプロセス、データアクセスに関しては、依然としてShopify自身の責任範囲となります。具体的には、以下の問いに対する回答が必要でした。

  • 誰がコンテナをビルドしたのか？どのような依存関係があるのか？
  • 誰がCloud Runインスタンスにアクセスできるのか？
  • サービスのIDにはどのような権限が付与されているのか？
  • シークレットはどのように安全に渡されているのか？
  • ランタイムでコンテナは適切に振る舞っているか？

これらの問いに対応するため、Shopifyは以下の主要なセキュリティ領域で対策を講じました。

3.1. ソフトウェアサプライチェーンの保護

コンテナのビルドからデプロイまでのプロセスは、攻撃者が悪意のあるコードを注入する機会となり得るため、このサプライチェーン全体を保護することが不可欠です。

  • SBOM (Software Bill of Materials) の生成と脆弱性スキャン: Shopifyは、ビルドする全てのコンテナイメージに対してSBOMを生成します。SBOMは、イメージに含まれるパッケージ、バージョン、ハッシュ、導入された場所などの詳細情報を提供します。これは、セキュリティチームが特定の脆弱性を持つパッケージが企業内のどこで実行されているかを迅速に特定し、対応するために非常に有用です。さらに、SBOM情報と組み合わせた脆弱性スキャンツールを使用することで、デプロイ前に既知の脆弱性を検出します。

  • バイナリ認証 (Binary Authorization) の役割: バイナリ認証は、デプロイポリシーを定義し、強制する強力なメカニズムです。Shopifyは、Googleと協力してこのサービスを開発した経験があり、その有効性を熟知しています。 バイナリ認証の仕組みは以下の通りです。

    1. イメージのビルドとプッシュ: 開発者がコンテナイメージをビルドし、Artifact Registryなどのレジストリにプッシュします。
    2. アテステーション（証明）: バックグラウンドでVoucherなどのテスターが動作し、イメージに対して定義されたチェック（例：SBOMが存在するか、特定の脆弱性がないか、Shopifyによってビルドされたか）を実行します。これらのチェックが成功すると、イメージに対して暗号学的に署名された「アテステーション」が作成されます。
    3. デプロイ時のポリシーチェック: 開発者がCloud Runアプリケーションをデプロイしようとすると、バイナリ認証が介入します。Cloud Runがイメージをプルする際、バイナリ認証は設定されたポリシー（例：「Shopifyによって署名されたイメージのみをデプロイする」「特定のCVEを持つイメージはブロックする」）をチェックし、アテステーションがポリシーに準拠している場合にのみデプロイを許可します。
    • ドライランモード: ポリシー違反があってもデプロイをブロックせず、警告のみを発するドライランモードは、新しいポリシーの導入や、開発者が誤ってポリシーに違反していないかを早期に検出するのに役立ちます。

この組み合わせにより、Shopifyはサプライチェーン全体で信頼できるイメージのみが本番環境にデプロイされることを保証します。

3.2. 堅牢なIDとアクセス管理 (IAM)

最小権限の原則はセキュリティの基本であり、人間およびマシンのIDに対して適切な権限のみを付与することが重要です。

  • 安全なグリーンパスの構築: Prodkitは、開発者がインフラストラクチャを安全に操作できるよう、「安全なグリーンパス」を設計しています。これにより、開発者はセキュリティに影響を与える可能性のある設定を直接変更する必要がなくなり、人為的ミスのリスクが軽減されます。セキュリティに影響するような変更は、明確に定義され、文書化されたゲートウェイ（承認プロセスや専用ツール）を通じてのみ実行可能です。

  • Google Cloud Load Balancerを介したID認識プロキシ: Cloud Runアプリケーションへのアクセス制御は、Google Cloud Load Balancer (GCLB) をID認識プロキシとして活用することで実現されます。GCLBは、多数のアクセスパターンをサポートし、URLマップを通じて様々なバックエンドサービス（Cloud Runサービス）にトラフィックをルーティングします。

    • 人間認証: エンドユーザー（Shopifyの従業員など）からのリクエストに対しては、GCLBはまずリクエストがShopifyのメールアドレスを持つユーザーからのものであるかをチェックします。その後、Cloud Runインスタンスに対するcloud invoker権限を持つかどうかをIAMで検証し、承認されたユーザーのみがアプリケーションにアクセスできるようにします。

    • 公開アプリケーションの制限とprod publish: Cloud Runアプリケーションをインターネットに公開することは、厳格な制御下で行われます。開発者がprod publishコマンドを使用すると、アプリケーションをインターネットに公開することを明確に警告し、公開するパスをカスタマイズできます。しかし、この変更は開発者が直接GCLBの設定を変更するのではなく、Shopifyの内部インフラ管理ツールに提出され、承認と自動更新プロセスを経て反映されます。これにより、意図しない公開や不適切な設定を防ぎます。GCLBを使用することで、Shopifyはmyapp.shopify.comのようなカスタムドメインを柔軟に利用できます。

    • ロボット認証（サービス間通信）: サービス間認証には、Googleが署名した短期的なIDトークンが利用されます。リクエストがAuthorizationヘッダーにIDトークンを含んでいる場合、GCLBのURLマップはIAMチェックをバイパスし、Cloud Runサービスに直接ルーティングします。Cloud Runは、このトークンを検証する能力を持っているため、サービス間の安全かつ効率的な認証を実現します。これは、Basic認証や複雑なシークレット管理を実装する必要がないため、非常に理想的な「グリーンパス」となります。

3.3. シークレット管理のベストプラクティス

アプリケーションがデータベース接続文字列やAPIキーなどの機密情報を安全に扱うことは、セキュリティの要です。

  • Google Secret Managerへの移行: ShopifyはこれまでEJSONというツールでシークレットを管理していましたが、Prodkitの導入に伴い、Google Secret Managerへの移行を決定しました。Google Secret Managerは、シークレットのライフサイクル管理のオーバーヘッドを削減し、ワークロードにシークレットを安全にロードする手段を提供します。

  • prod secrets createとデプロイ時の安全なシークレット注入: 開発者はprod secrets create <key> <value>コマンドを使用して、Google Secret Managerにシークレットを安全に作成できます。Prodkitは、prod initなどでデータベースなどのインフラストラクチャを作成する際にも、必要なシークレット（例：データベースURL）を自動的にSecret Managerに生成します。 これらのシークレットは、Cloud Runアプリケーションがデプロイされる際に、CIパイプラインの途中で復号化されることなく、直接Cloud Runサービスに注入されます。

    1. GitHub CI/CDプロセスがデプロイをトリガーします。
    2. CIプロセスは、プロジェクト内のGoogle Secret Managerシークレットを検索し、アプリケーションに公開すべきラベルやアノテーションを持つものを特定します。
    3. Cloud Runデプロイリクエストが作成される際、これらのシークレットへの参照（実際の値ではない）が挿入されます。
    4. Cloud Runが実際にサービスをデプロイする際、これらの参照に基づいてSecret Managerからシークレットを安全にプルし、アプリケーションに環境変数として提供します。 この方法により、CIログなどにシークレットが漏洩するリスクをゼロに抑えることができます。

3.4. 継続的なセキュリティ監視と防御

セキュリティ対策は一度行ったら終わりではありません。継続的な監視と監査を通じて、安全対策が適切に機能していることを確認し、違反を迅速に検出する必要があります。

  • Security Command CenterとSecurity Health Analytics: Shopifyは、Google Cloud Security Command Centerを活用し、インフラストラクチャを継続的にスキャンしています。Security Health Analyticsのカスタムモジュールを使用することで、「Cloud Runインスタンスが特定の望ましくない設定を持っている場合に通知する」といった独自のポリシーを定義できます。GoogleのAsset Inventoryデータを利用して、全リソースのメタデータを収集し、それらをスキャンすることで、ポリシー違反を検出します。

  • 組織ポリシー (Organization Policies) とドライランモード: より権威的な制御が必要な場合、Google Cloudの組織ポリシーを活用します。これは、組織レベルで特定のサービスやリソースに対する設定を強制するものです（例：Cloud Runインスタンスのイングレス設定を制限する、IAMポリシーで特定のプリンシパルを許可しない）。開発者の行動を完全にブロックすることを避けるため、組織ポリシーを「ドライランモード」で実行し、違反を検出するのみにとどめることも可能です。これにより、開発者の自律性を尊重しつつ、セキュリティ上のリスクを可視化できます。

3.5. ランタイムセキュリティモニタリングの進化

デプロイされたアプリケーションが予期せぬ悪意ある振る舞いをしないか、ランタイムでの監視も重要です。

  • Cloud Run Threat Detectionの実現: GKE環境では、Falcoのようなツールを使用してeBPFでシステムコールをインターセプトし、疑わしい活動を検出することが可能でした。しかし、Cloud Runのようなフルマネージドサーバーレス環境では、ノードへのアクセスができないため、このようなアプローチは直接適用できません。 Shopifyは、この課題を解決するためにGoogleのエンジニアリングチームと2年間もの期間をかけて協力し、ついに「Cloud Run Threat Detection」という新しいサービスを実現しました。これは、Cloud Run向けのマネージドランタイムセキュリティモニタリングサービスであり、主に高クリティカル度の検出（例：インスタンス内のマルウェア、リバースシェル）に焦点を当てています。 例えば、リモートポートやIPアドレスへのストリームリダイレクトが検出された場合、それはリバースシェル攻撃の兆候としてアラートが発せられます。これにより、ShopifyはCloud Runで実行される非常に重要なワークロードが侵害された場合に、迅速に検知し対応できるようになったのです。

Prodkitにおけるセキュリティは、単なるツールの導入に留まらず、ソフトウェアサプライチェーン全体からランタイムまでをカバーする、多層的かつ統合的なアプローチとして構築されています。開発者は「セキュリティの汗をかく」ことなく、Prodkitという安全なレールの上で、迅速にイノベーションを進めることができるようになったのです。

セクション4: 見える化の力 - Prodkitがもたらすオブザーバビリティの恩恵

アプリケーションが本番環境で稼働している以上、その健全性を常に把握し、問題発生時には迅速に診断・解決できることが不可欠です。しかし、サーバーレス環境、特にCloud Runでは、従来のVMベースのシステムとは異なる課題が存在します。SSHでVMにログインしてログを確認したり、システムリソースを直接監視したりすることができません。この「見えない」環境で、いかにしてシステムの状態を理解し、信頼性を確保するかが大きな課題となります。

Shopifyのアーキテクトであるアーチー・ラトノフ氏は、Prodkitがアプリケーションのオブザーバビリティをいかに標準化し、開発者が問題を迅速に特定・解決できる環境を構築したかについて詳述しています。

サーバーレス環境におけるトラブルシューティングの難しさ

従来のシステムでは、問題が発生した場合、システム管理者は以下のような手順を踏むことが一般的でした。

  • VMにSSH接続し、システムログ（/var/log/messagesなど）を確認する。
  • topやhtopコマンドでCPUやメモリの使用状況をリアルタイムで確認する。
  • netstatでネットワーク接続状況を調べる。
  • アプリケーションの特定のディレクトリに配置されたカスタムログファイルを確認する。

しかし、Cloud Runのようなサーバーレスコンテナ環境では、これらの直接的なアクセス手段が提供されません。Googleが基盤となるVMやネットワークインフラを管理しているため、開発者はその内部に立ち入ることができません。これにより、アプリケーションが遅い、エラーが発生している、といった問題に直面した際、「これはアプリケーションの問題なのか、それともクラウドインフラの問題なのか？」という切り分けが困難になることがよくあります。

アプリケーションのダウンタイムやユーザー体験の低下は、Shopifyのようなeコマース企業にとって、収益の損失だけでなく、ブランドの評判低下にも直結する重大な問題です。そのため、サーバーレス環境においても、システムの状態を明確に「見える化」するオブザーバビリティの仕組みは必要不可欠でした。

オブザーバビリティの定義とGoogle Cloud Observabilityツール

オブザーバビリティとは、システムの外部信号（メトリクス、ログ、トレース）を分析することで、その内部状態を理解し、問題を診断し、システムの信頼性を確保する能力を指します。Shopifyは、この目的のためにGoogle Cloudが提供する強力なオブザーバビリティツール群を活用しています。

  • Cloud Logging: アプリケーションログやシステムログを一元的に収集・保存・分析するためのサービス。
  • Cloud Monitoring: アプリケーションやインフラのメトリクスを収集・可視化し、アラートを設定するためのサービス。
  • Cloud Trace: 分散システムにおけるリクエストのライフサイクルを追跡し、パフォーマンスのボトルネックを特定するためのサービス。
  • Google Cloud Managed Service for Prometheus (GMP): Prometheus形式のメトリクスをフルマネージドで収集・保存・クエリできるサービス。

さらに、Shopifyはこれらを自社の中央集約型オブザーバビリティプラットフォームである「Shopify Observe」と統合しています。Shopify Observeは、Grafana、Prometheus、Thanosといったクラウドネイティブなプロジェクトをベースに構築されており、開発者はGKEとCloud Runのどちらで稼働しているアプリケーションであっても、すべてのメトリクスを「Observe Metric Explorer」という単一の場所で探索し、アラートやダッシュボードを作成できます。

Cloud Run UIの直感的なオブザーバビリティ機能

Cloud Run自体も、その管理UI内でアプリケーションのオブザーバビリティを支援する機能を組み込んでいます。これにより、開発者は別のツールにジャンプすることなく、Cloud Runコンテキスト内でトラブルシューティングを開始できます。

  • Metricsタブ: アプリケーションの稼働時間チェックとアラートを設定できます。Cloud Run固有の主要メトリクス（リクエスト数、レイテンシ、エラー率、CPU/メモリ使用率など）やダッシュボードにアクセスできます。
  • Logsタブ: Cloud Runのシステムログとアプリケーションログ（標準出力/エラー出力に書き込まれたログ）をリアルタイムで確認し、フィルタリングや検索を行えます。
  • SLOs (Service Level Objectives) タブ: 開発者がSRE (Site Reliability Engineering) のプラクティスを実践できるよう、稼働時間、レイテンシに対するサービスレベル目標を設定し、ターゲット予算（エラーバジェット）を管理できます。

これらの機能は、Cloud Runアプリケーションの基本的な健全性を監視し、問題の兆候を早期に捉えるための強力な出発点となります。

カスタムアプリケーションメトリクスの収集戦略：Sidecarの導入

Cloud Runの組み込みメトリクスは有用ですが、アプリケーション固有のビジネスロジックに関するメトリクス（例：カートに追加されたアイテム数、支払い処理時間、ユーザーログイン数）を収集するには、「カスタムメトリクス」の仕組みが必要です。Shopifyは、これを実現するためにKubernetesでの経験をCloud Runに適用しました。

Kubernetesでのメトリクス収集パターン

Kubernetesでは、アプリケーションメトリクスを収集するために主に二つのパターンが用いられます。

  1. Prometheus形式またはOpenTelemetryによるアプリケーションのインストゥルメンテーション: アプリケーションコード自体にライブラリを組み込み、メトリクスを生成します。

    • Prometheus形式: 広く普及しており、10年以上の実績があります。シンプルなテキスト形式でメトリクスを公開します。
    • OpenTelemetry: 比較的新しい標準ですが、非常に注目されています。メトリクス、ログ、トレースを一元的にインストゥルメンテーションでき、相互に関連付けられるため、包括的なオブザーバビリティを実現するための業界標準となりつつあります。

  2. コレクターへのメトリクス送信: インストゥルメンテーションされたアプリケーションからメトリクスを収集し、オブザーバビリティプラットフォームに送信するコレクターが必要です。

    • DaemonSetパターン: Kubernetesノード上でオブザーバビリティエージェント（例：Prometheus Node Exporter, Fluentd）をDaemonSetとして実行し、同じノード上のアプリケーションからメトリクスをフェッチして送信します。これはKubernetesで最も一般的なパターンです。
    • Sidecarパターン: メインのアプリケーションコンテナと同じPod内に、追加のコンテナ（サイドカー）をデプロイします。このサイドカーは、メインアプリケーションのロジックを変更することなく、その機能を拡張します（例：ログ収集、メトリクス収集、プロキシ）。

Cloud Runへの適応：Sidecarの導入とGoogleとの協業

Cloud Runのようなサーバーレスプラットフォームには「ノード」の概念がないため、DaemonSetパターンは適用できません。そこでShopifyは、Sidecarパターンに注目しました。

Shopifyは、Cloud Runエンジニアリングチームと協力し、Cloud RunがSidecarをサポートするように機能拡張を進めました。この機能がShopify向けに有効化されたことで、彼らはOpenTelemetry Collector Sidecar（CNCFプロジェクトの一部）をデプロイし、メトリクス、ログ、トレース情報をShopify Observeプラットフォームに送信できるようになりました。

  • OpenTelemetry Collector: メトリクス、ログ、トレースの収集、処理、エクスポートを柔軟に行うための汎用的なコレクターです。Sidecarとしてデプロイすることで、メインアプリケーションからのデータを取得し、Shopify Observeなどのバックエンドに送信できます。

もしShopify Observeのような独自のプラットフォームがない場合でも、Googleは二つのオプションを提供しています。

  • GoogleビルドのOpenTelemetry Collector: OpenTelemetryでインストゥルメンテーションされたメトリクスを収集するために利用できます。
  • Managed Service for Prometheus Collector Sidecar: Prometheusインストゥルメンテーションを使用している場合、Googleが管理するPrometheusコレクターをSidecarとして利用できます。

Cloud Run Jobsでの課題克服とSidecarサポートの最新情報

当初、Cloud Run Jobs（長時間実行されるバッチ処理などに利用）ではSidecarサポートが提供されていませんでした。Shopifyは、店舗管理アプリケーションのデータ処理にCloud Run Jobsを広く利用しており、これらの本番システムからアプリケーションメトリクスを収集する必要がありました。

  • 一時的な回避策: Sidecarサポートがないため、ShopifyはOpenTelemetryをコンテナ内の「子プロセス」として実行するという非推奨のワークアラウンドを採用しました。これは一時的な対応でしたが、生産システムでのメトリクス収集を可能にしました。

  • 最新情報：Cloud Run JobsでのSidecarサポート: 幸いなことに、Googleはその後、Cloud Run Jobsに対するSidecarサポートをリリースしました。これにより、Cloud Run ServicesとCloud Run Jobsの両方でSidecarパターンを利用して、アプリケーションメトリクスを効率的に収集できるようになりました。

Prodkitは、これらの技術的課題を解決し、Cloud Run上で稼働するすべてのShopifyアプリケーションに対して、メトリクス、ログ、トレースの収集を自動的に設定します。これにより、開発者は「コードを書くこと」に集中し、アプリケーションの健全性に関する深い洞察を、手間なく得られるようになったのです。オブザーバビリティはもはや後回しにされるものではなく、Prodkitによって「最初から組み込まれた」機能となったと言えるでしょう。

セクション5: 実践と成果 - ShopifyのCloud Run移行事例とBFCMの成功

Prodkitは、単なる概念実証にとどまらず、Shopifyの実際の生産環境で数百ものアプリケーションのデプロイを支え、目覚ましい成果を上げています。その活用事例は多岐にわたり、Cloud Runがエンタープライズレベルのワークロードに耐えうることを証明しています。

Prodkitが支える多様なアプリケーションと未来の可能性

Prodkitは、Shopifyの様々な種類のアプリケーションに活用されています。

  • 高スケーラブルなAPIサービス: ステートレスなリクエスト処理に優れるCloud Runの特性を活かし、ShopifyのコアAPIの一部がProdkitを通じてデプロイされています。
  • マルチテナントWebアプリケーション: 複数のマーチャントにサービスを提供するWebアプリケーションも、その柔軟なスケーリング能力によりCloud Run上で稼働しています。
  • 内部サービス: 社内ツールやバックエンドマイクロサービスなど、比較的独立した機能を持つサービスがProdkitによって迅速に展開されています。
  • 軽量なデータ処理（Cloud Run Jobs）: 定期的なバッチ処理やイベント駆動型のデータ変換など、比較的短時間で完了するデータ処理タスクにCloud Run Jobsが利用されています。
  • GPUサポートによる機械学習推論: 最近、Cloud RunがGPUサポートを追加したことで、機械学習モデルの推論ワークロードをCloud Run上で実行する候補として検討されています。これにより、ShopifyはAI/ML活用をさらに加速させる可能性があります。
  • マルチリージョンデプロイメント: 複数のGoogle Cloudリージョンに同じアプリケーションをデプロイする必要がある場合、各リージョンにGKEクラスタをデプロイする代わりに、Cloud RunとProdkitを活用することで、クラスタ管理なしで迅速にマルチリージョンデプロイメントを実現しています。

これらの活用事例の中でも、特に注目すべきは、Shopifyの顧客行動APIチームがCloud Runに移行した事例です。この移行は、Prodkitが開発者の生産性、アプリケーションの安定性、そしてビジネスへの貢献においていかに重要な役割を果たしたかを具体的に示しています。

顧客行動APIチームのケーススタディ：Ruby on RailsからRust、そしてCloud Runへ

Shopifyの顧客行動APIチームは、年間最大のショッピングイベントであるBFCM (Black Friday Cyber Monday) で、システムが度々「炎上」する課題に直面していました。彼らは、この課題を解決するために、ProdkitとCloud Runへの移行を決断しました。チームのスタッフ開発者であるダニエル・ウィリアムズ氏がその道のりを語っています。

既存システムの課題：Ruby on RailsとGKEの限界

顧客行動APIは、当初Ruby on Railsで構築されており、ピーク時には毎分200万～400万リクエストを処理する高スループットなサービスでした。しかし、この構成には深刻な課題がありました。

  • メモリ問題と不安定性: 使用していたgRPC gemに未解決のメモリリークバグがあり、コンテナが際限なくメモリを消費し、プロセス管理によって頻繁に再起動されていました。
  • GKEクラスタへの悪影響: 頻繁な再起動と大規模なリソース要求により、顧客行動APIはGKEクラスタの「悪い隣人」となっていました。他のアプリケーションの信頼性を損ない、クラスタ全体の安定性を低下させていました。
  • Ruby on Railsの特性: Railsは素晴らしいフレームワークですが、ガベージコレクションと単一スレッドVMの特性上、並行処理やメモリ管理において特定の限界がありました。

これらの問題は、BFCMのような極限の負荷がかかる時期には、システムの信頼性を脅かす重大なリスクとなっていました。

解決策：Rustへの移行、Prodkitの採用、Cloud Runへのデプロイ

チームは、これらの課題を抜本的に解決するために、以下の戦略を立案しました。

  1. Rustへの移行: アプリケーションをRuby on RailsからRustへリライトすることを決定しました。Rustは、メモリ安全性、優れた並行処理プリミティブ、そして低レベルでのリソース制御を可能にする言語であり、メモリリークの問題を解決し、パフォーマンスを向上させるための理想的な選択でした。

  2. Prodkitの採用: インフラ管理の負担を軽減し、開発速度を向上させるため、Prodkitの採用を決定しました。これにより、チームはインフラ設定やセキュリティ設定に煩わされることなく、アプリケーションロジックの開発に集中できるようになりました。

  3. GKEからCloud Runへの移行: アプリケーションのホスティング環境をGKEからCloud Runへ移行しました。Cloud Runは、各アプリケーションに専用のリソースを提供し、他のアプリケーションとの「隣人問題」を解消できるだけでなく、リソースのサイジングを柔軟に制御できる利点がありました。

開発者への影響：インフラとセキュリティからの解放

顧客行動APIチームは、インフラやセキュリティの専門知識が豊富なNathanやOwenのようなメンバーではなく、アプリケーション開発に特化したチームでした。Prodkitの導入は、彼らにとってまさに「ゲームチェンジャー」となりました。

  • 迅速なイテレーション: Prodkitがネットワーキング、ロードバランシング、セキュリティなど、インフラの複雑な側面をすべて処理したため、チームは迅速にアプリケーションを開発・イテレーションできました。
  • 数日でインフラ準備完了: 従来、インフラのプロビジョニングには数週間かかることもありましたが、Prodkitのコマンドを実行するだけで、数日以内に本番環境と複数のステージング環境のインフラが準備できました。これにより、チームはアプリケーションのテストとデプロイをすぐに開始できました。

直面した課題と解決策

移行プロセスは常に順風満帆ではありませんでした。いくつかの「成長の痛み」に直面し、それを乗り越える必要がありました。

  • Rustの学習曲線とSDKの不足: Rustへの移行は、メモリ管理に関する新たなパラダイムシフトを伴い、学習曲線は急でした。また、Google APIにはネイティブのRust SDKが提供されていなかったため、チームはProtobufファイルから独自のクライアントを生成し、リトライや指数バックオフなどの機能を自前で実装する必要がありました。

  • Rails Active Jobの代替: RailsのActive Jobのような便利なジョブフレームワークが利用できなくなったため、チームはPub/Subメッセージを監視する独自のプルベースコンシューマを構築する必要がありました。

  • VPCコネクタからDirect VPC Egressへの移行: 当初、Cloud RunとCloud SQLやMemorystoreなどの内部サービスとの接続にはVPCコネクタを使用していました。しかし、VPCコネクタはボトルネックとなり、接続損失やリクエストレイテンシの急増を引き起こすことがありました。この問題を解決するため、チームはCloud Runサービスを直接VPC内に配置するDirect VPC Egressに移行しました。これにより、IPアドレスの消費は増加しましたが、パフォーマンスと安定性が大幅に向上しました。

  • Prodkitの提供範囲を超えるニーズ: システムには、長時間実行されるバッチ処理（高リソース消費）と、低レイテンシで高速スループットが求められるオンライン処理という2種類のワークロードが存在しました。Prodkitの基本的な設定だけではこれらを効率的に分離できなかったため、チームはロードバランサーのパスベースルーティングを変更し、リクエストを異なるCloud Runサービスにルーティングすることで、ワークロードの干渉を防ぎました。この際も、Prodkitによって確立されたセキュリティコントロールを逸脱しないよう細心の注意を払いました。

Cloud Runでのジョブ実行：課題と最適化

ジョブの実行に関しても、Cloud Runの特性を理解し、最適化する必要がありました。

  • スケジュールされたジョブ: Cloud SchedulerとCloud Run Jobsの組み合わせにより、スケジュールされたタスク（ hourly, daily cron jobsなど）を効率的に実行できました。
  • イベント駆動型ジョブ（プルベースコンシューマの課題）： Pub/Subキューを監視し、メッセージを処理するプルベースコンシューマは、当初、Webサービスとして（トラフィックなしで）実行されていました。しかし、Cloud Runのスケーリングメトリクス（同時HTTPリクエスト数やCPU使用率）が、トラフィックがないために機能せず、コンテナがスケールしないという問題に直面しました。
    • 手動スケーリングによる回避策: チームは、Pub/Subキューのイベント数を監視するアラートを設定し、キューが滞留し始めたら手動でCloud Runサービスのリビジョンを編集し、コンテナ数を増やすことで対応しました。
    • より良い選択肢: 将来的には、Pub/Subのネイティブプッシュキュー機能（Cloud RunサービスにHTTPリクエストを送信）や、Kafkaコンシューマ向けにCPU使用率のみに基づいてスケールする新しいワーカープール機能、あるいはCloud Runの手動スケーリング設定（リビジョンを再デプロイせずにコンテナ数を増減できる）やmin instances設定を利用することで、この課題はさらに最適化されるでしょう。

BFCM (Black Friday Cyber Monday) での圧倒的な成功

顧客行動APIチームの取り組みは、2023年秋のBFCM期間中にその真価を発揮しました。BFCMはShopifyにとって年間で最も重要なショッピングイベントであり、通常の数倍のトラフィックが集中します。

  • 綿密な準備と負荷テスト: チームは数ヶ月前からBFCMの準備に取り掛かりました。Apache Flinkを使用して、本番環境の入力ソースを5倍に増強したデータをステージング環境に流し込み、毎分2000万リクエストという途方もない負荷テストを実施しました。
  • Cloud Runの完璧なスケーリング: このテストにおいて、Cloud Runは何の問題もなくスケールし、チームは本番環境でのスケーリング能力に絶対的な自信を得ました。
  • 本番環境での成功: BFCM期間中、顧客行動APIは毎分700万リクエストを超えるピークトラフィックを問題なく処理しました。結果として、BFCM期間中に一度もアラートが発動せず、前年のシステム「炎上」とは対照的に、システムは完璧に稼働しました。

この成功は、ProdkitとCloud Runの組み合わせが、Shopifyのような大規模でミッションクリティカルなワークロードを、いかに安定かつ効率的に処理できるかを明確に示しています。開発者はインフラの心配から解放され、より高品質なコードとビジネス価値の創造に集中できた結果、ビジネスにとって最も重要な時期に最高のパフォーマンスを発揮できたのです。

セクション6: まとめと展望 - Prodkitが示すサーバーレス開発の未来

ProdkitとCloud Runの導入は、Shopifyのソフトウェア開発と運用に大きな変革をもたらしました。これは、単なる技術ツールの導入に留まらず、開発者体験、セキュリティ、オブザーバビリティの新たな標準を確立する取り組みでした。最後に、Prodkit開発からの教訓、得られた具体的な成果、そしてCloud Runが示すサーバーレス開発の未来について考察します。

Prodkit開発からの教訓：Cloud Runの得意不得意

Cloud Runは非常に強力なツールですが、万能ではありません。Prodkitの開発を通じて、ShopifyはCloud Runが特に得意とするユースケースと、そうでないユースケースについて明確な知見を得ました。

Cloud Runが得意なこと

  • ステートレスなアプリケーション: リクエストごとに状態を持たないWebサービスやAPIは、Cloud Runのスケールアウト/スケールインの特性と非常に相性が良いです。
  • イベント駆動型サービス: Pub/SubやCloud Storageなどのイベントソースからトリガーされる機能やマイクロサービス。
  • データ処理: 軽量なバッチ処理や、非同期処理を伴うデータ変換タスク（Cloud Run Jobs）。
  • APIサービス: 高いスループットと低レイテンシが求められるAPIエンドポイント。

Cloud Runが不向きなこと、あるいは注意が必要なこと

  • 常時稼働 (Always-on) のアプリケーション: Cloud Runの大きな売りは「スケール・トゥ・ゼロ」であり、リクエストがないときにインスタンスが停止し、課金されない点です。しかし、常にインスタンスを稼働させておく必要があるアプリケーション（例：WebSocketサーバー、長時間アイドル状態を維持するサービス）では、スケール・トゥ・ゼロのメリットを享受できず、むしろコストが高くなる可能性があります。このような場合は、min instancesを設定することでウォームスタートは可能ですが、コスト効率のメリットは薄れます。

  • 高いステートフル性を持つアプリケーション: 大規模なユーザーセッションや、インスタンス間で永続的な状態を維持する必要があるアプリケーションは、Cloud Runのコンテナが頻繁に破棄・再生成される特性と相性が悪い場合があります。状態を管理するには、Cloud SQLやMemorystoreなどの外部サービスに依存する必要がありますが、その設計と実装には注意が必要です。

  • バックグラウンドジョブにおけるHTTPモデルのミスマッチ: Cloud Runは基本的にHTTPリクエスト駆動型であるため、厳密にHTTPリクエストをトリガーとしない長時間実行されるバックグラウンドジョブ（例：キューをポーリングし続けるワーカー）では、スケーリングが最適化されにくいという課題がありました（セクション5のプルベースコンシューマの課題参照）。最近の機能改善（Pub/Sub push subscriptions, Worker Pools）により改善されつつありますが、設計段階での考慮が必要です。

Prodkit開発プロセスで得られた知見

Prodkit自体の開発は、多くの技術的、組織的な教訓をもたらしました。

  • 自律性とデバッグ性のバランスの難しさ: 開発者に高い自律性を提供する一方で、問題発生時のデバッグやトラブルシューティングの手段を確保することは、常に課題でした。一部の開発者は、与えられた自由を最大限に活用しましたが、一方で新しいツールや学習ギャップに苦しむ開発者もいました。
  • Terraformのラッピングの難しさ: Terraformは強力ですが、その「リジッドさ」ゆえに、高レベルな抽象化レイヤーで完全にラッピングすることは容易ではありませんでした。Terraformはインフラの「所有権」を持つことを好むため、その上に別のレイヤーを構築する際には、抽象化の境界と、基盤となるTerraformの更新が上層に与える影響について慎重な設計が必要でした。
  • 目立たないセキュリティの難しさ: セクション3で詳述したように、開発者の作業を妨げずに、エンタープライズレベルのセキュリティを実装することは、非常に複雑で多岐にわたる努力を要しました。Prodkitは、開発者がセキュリティの「汗をかく」ことなく、デフォルトで安全なアプリケーションをデプロイできる環境を目指しましたが、その裏側にはOwen氏のようなセキュリティエキスパートによる綿密な設計と実装がありました。
  • ネットワーキングの難しさ: クラウド環境におけるネットワーキング、特にVPC、ロードバランシング、サービス間通信の設計とトラブルシューティングは、依然として複雑な領域であり、多くの時間と専門知識を必要としました。

しかし、これらの困難にもかかわらず、驚くべきことにProdkitの大部分はわずか2人（ネイサン氏とガブリエル・ペレス氏）で構築されました。これは、Cloud Runの基盤が提供する抽象化レベルが高く、フレームワークの構築が比較的容易であることを示唆しています。彼らの成功は、「Cloud Runを活用すれば、同様のフレームワークを構築することはそれほど難しくなく、多くの企業が挑戦すべきだ」というメッセージを投げかけています。

Prodkitがもたらした具体的なビジネスインパクトと将来性

Prodkitは、Shopifyのビジネスと開発文化に以下の具体的なインパクトをもたらしました。

  • デプロイ時間の劇的な短縮: これまで数週間かかっていたクラウドアプリケーションのデプロイが、Prodkitによってわずか数時間で完了するようになりました。これにより、Shopifyは市場への投入時間を大幅に短縮し、より迅速にイノベーションを実現できるようになりました。
  • セキュリティとオブザーバビリティの標準化: Prodkitを通じてデプロイされるアプリケーションは、最初からShopifyのベストプラクティスに従ったセキュリティ制御と、包括的なオブザーバビリティ設定が施されています。これにより、開発者は個別にこれらの側面について心配する必要がなくなり、全体の品質と信頼性が向上しました。
  • 大規模スケーリングとBFCMの成功: Cloud Runは、Shopifyのアプリケーションを毎秒数百万リクエストという規模で容易にスケールさせ、BFCMのような極限の負荷イベントを大きな問題なく、そしてページャーアラートなしで乗り切ることを可能にしました。これは、ビジネスの最も重要な時期における売上と顧客体験の安定に直結します。
  • 運用負担の軽減: GKEクラスタの運用、アップグレード、トラブルシューティングといった煩雑な作業が不要になり、運用チームはより戦略的なタスクに集中できるようになりました。

GKEとCloud Runの適切な使い分けと、Cloud Runが新しい標準となる可能性

Shopifyは現在、GKEとCloud Runの両方を大規模に活用しています。どちらのサービスもGoogleが提供する優れたコンテナ実行環境ですが、それぞれに最適なユースケースがあります。

  • GKE (特に Autopilot モード): 任意の複雑性を持つアプリケーション（ステートフル、ステートレス両方）をデプロイするのに適しています。Kubernetesの高度な制御と柔軟性が必要な場合、あるいは複雑なネットワーク要件や特定のストレージ統合が必要な場合に強力な選択肢となります。しかし、Kubernetesの学習曲線は急であり、GKE Autopilotでさえクラスタの管理（アップグレードなど）は依然として残ります。

  • Cloud Run: サーバーレスコンテナの実行に特化しており、極めて簡単なデプロイと管理の不要性を提供します。特に、ステートレスなAPI、Webサービス、イベント駆動型ファンクション、軽量なデータ処理には最適な選択肢です。

Shopifyの事例が示すように、**もし今日からクラウドアプリケーションのジャーニーを開始するのであれば、Cloud Runから始めることを強く推奨します。**そのシンプルさ、使いやすさ、そしてProdkitのようなツールキットと組み合わせることで、シームレスかつ再現性のあるデプロイを実現できます。

一部ではベンダーロックインへの懸念も指摘されますが、Cloud Runはコンテナ標準に基づいており、GKEと基盤となるAPIを共有しているため、将来的にCloud RunからGKEへアプリケーションを移行することも比較的容易です。これは、Google Cloudの柔軟なエコシステムを物語っています。

ShopifyとGoogle Cloudチームの協力関係は、Cloud Runの機能を継続的に改善し、エンタープライズ顧客の厳しい要件に応えるための重要な推進力となっています。Prodkitの成功は、開発者中心のアプローチと、最新のサーバーレス技術を組み合わせることで、いかにして企業がデジタルトランスフォーメーションを加速できるかを示す強力な事例です。

結び

ShopifyのProdkitは、単なるサーバーレスデプロイツールではありません。それは、開発者の生産性を最大化し、セキュリティとオブザーバビリティを標準化し、ビジネスの成長を加速させるための、戦略的なプラットフォーム構築の物語です。Cloud Runのシンプルさとスケーラビリティを最大限に引き出し、同時にエンタープライズ級の要件を満たすそのアプローチは、多くの企業にとって貴重な示唆を与えるでしょう。

この記事を通じて、ShopifyがProdkitというサーバーレスツールキットをいかにして構築し、開発者をインフラの複雑さから解放し、高速で安全なCloud Runデプロイメントを実現したのか、その全貌を理解いただけたことと信じています。あなたの組織でも、Prodkitのようなアプローチを採用することで、開発者の能力を解き放ち、次なるイノベーションを加速させる道が見つかるかもしれません。Cloud Runと、それを最大限に活用するツールキットの力を、ぜひご自身の目で確かめてみてください。

← 一覧に戻る