ブループリントをデプロイする

すでに CI / CD パイプラインがある。

アプリケーションのビルドとデプロイに異なるプロダクトが使用されている場合でも、ブループリントのフリート アーキテクチャとクラスタ アーキテクチャを使用できます。少なくとも、2 つのリージョンにイメージをミラーリングすることをおすすめします。

エンタープライズ基盤ブループリントと一致しない既存の組織構造がある。

より安全に順次デプロイを行うために、少なくとも 2 つの環境を用意することをおすすめします。環境を別々の共有 VPC やフォルダにデプロイする必要はありません。ただし、異なる環境に属するワークロードを同じクラスタにデプロイしないでください。

IaC を使用していない。

現在のアプリケーション デプロイ プロセスで IaC を使用していない場合は、Google Cloud での Terraform の成熟度モデルで準備状況を評価できます。このブループリントと同様に構成され、マルチテナント パイプラインとテナントごとのパイプラインが分離されている別の Terraform プロジェクトに既存のリソースをインポートします。新しいクラスタを作成するには、Google Cloud 向け Terraform モジュールを使用します。

クラスタが同じ環境内の複数のプロジェクトに分散している。

複数のプロジェクトのクラスタをフリートにグループ化できます。同じフリート内で名前空間が一意の意味を持つことを確認します。フリートにクラスタを追加する前に、アプリケーションを一意の名前（たとえば default ではない）を使用した名前空間に移動するようチームに依頼してください。

これにより、名前空間をスコープにグループ化できます。

クラスタが単一のリージョンに存在している。

ブループリントを採用するために、本番環境と非本番環境で複数のリージョンを使用する必要はありません。

環境にさまざまなセットが存在している。

ブループリントは、3 つ以上の環境をサポートするように変更できます。

クラスタの作成は、アプリケーション デベロッパー チームまたはアプリケーション オペレーター チームに委任される。

最も安全で一貫性のあるデベロッパー プラットフォームを実現するために、クラスタの所有権をアプリケーション チームからデベロッパー プラットフォーム チームに移行できます。それができない場合でも、ブループリントのプラクティスの多くを採用できます。たとえば、異なるアプリケーション チームが所有するクラスタをフリートに追加できます。ただし、独立した所有権を持つクラスタを組み合わせる場合は、Workload Identity または Anthos Service Mesh を使用しないでください。誰がどのワークロード ID を表明できるかを十分に制御できないためです。代わりに、カスタム組織ポリシーを使用して、チームが GKE クラスタでこれらの機能を有効にしないようにしてください。

クラスタがフリートにグループ化されている場合でも、ポリシーを監査、適用できます。カスタム組織ポリシーを使用すると、クラスタのプロジェクトが存在する環境フォルダに対応するフリート内にクラスタの作成を要求できます。フリートのデフォルト構成を使用すると、新しいクラスタでポリシー制御の使用を必須にできます。

すべてのアプリケーションは、同じ 5 つのクラスタセットで実行される。

このブループリントでは、5 つのクラスタのセットを使用します（本番環境に 2 つ、非本番環境に 2 つ、開発環境に 1 つ）。ブループリントを変更して、5 つのクラスタの追加セットを作成できます。

アプリケーションを 5 つのクラスタのセットに割り当てます。アプリケーションのスコープまたはフリートの名前空間を他のセットのクラスタにバインドしないでください。次のようなアクティビティを完了するために、アプリケーションを異なるクラスタセットに分離することをおすすめします。

• 特別な規制上の懸念事項（PCI-DSS など）を持ついくつかのアプリケーションをグループ化する。
• クラスタのアップグレード中に特別な処理が必要なアプリケーション（たとえば、永続ボリュームを使用するステートフル アプリケーションなど）を分離する。
• リスクの高いセキュリティ プロファイルを使用してアプリケーションを分離する（たとえば、メモリ安全でない言語でユーザー提供のコンテンツを処理するなど）。
• GPU、コスト感度、パフォーマンス感度を必要とするアプリケーションを分離する。
• ノード数の GKE クラスタの上限（15,000 ノード）に近づいている場合は、新しいクラスタセットを作成できる。
• VPC Service Controls の境界内で実行する必要があるアプリケーションには、別の共有 VPC を使用する。たとえば、境界にクラスタセットを 1 つ、境界外にクラスタを 1 つ作成する。

次のいずれかの状況が発生する可能性があるため、アプリケーションまたはテナントごとに新しいクラスタセットを作成しないでください。

• 使用可能な最小インスタンス タイプであっても、最小クラスタサイズ（3 VM × 2 リージョン）が十分に活用されていないアプリケーション。
• さまざまなアプリケーションをビンパッキングすることによるコスト削減の可能性の損失。
• 計画が各アプリケーションに対して個別に適用されたことによる、面倒で不確実な容量増加計画。容量の予測は、広範なアプリケーションに対して集計すると、より正確になります。
• 新しいテナントまたはアプリケーション用の新しいクラスタの作成の遅延。これにより、プラットフォームに対するテナントの満足度が低下します。たとえば、組織によっては必要な IP アドレスの割り振りに時間がかかり、追加の承認が必要になることがあります。
• VPC ネットワーク内の限定公開クラスタの上限に達する。

本番環境と非本番環境では、2 つのリージョンにクラスタがある。

複数のリージョンのエンドユーザーのレイテンシを低くするには、本番環境と非本番環境のワークロードを 2 つ以上のリージョンにデプロイできます（たとえば、本番環境用に 3 つのリージョン、非本番環境用に 3 つのリージョン、開発用に 1 つのリージョンなど）。このデプロイ戦略では、追加のリージョンでリソースを管理するコストとオーバーヘッドが増加します。

すべてのアプリケーションの可用性要件が低い場合、本番環境と非本番環境のワークロードを 1 つのリージョン（1 つの本番環境、1 つの非本番環境、1 つの開発環境）にデプロイできます。この戦略は費用の削減には役立ちますが、デュアルリージョン アーキテクチャやマルチリージョン アーキテクチャと同じレベルの可用性は保護されません。

アプリケーションの可用性要件が異なる場合は、アプリケーションごとに異なるクラスタセットを作成できます（たとえば、2 つの本番環境、2 つの非本番環境、1 つの開発環境を使用した cluster-set-1、1 つの本番環境、1 つの非本番環境、1 つの開発環境を使用した cluster-set-2 など）。

ハブアンドスポーク トポロジは、共有 VPC よりも要件に一致する。

ブループリントは、ハブアンドスポーク構成でデプロイできます。この構成では、各環境（開発環境、本番環境、非本番環境）が独自のスポークでホストされます。ハブアンドスポーク トポロジでは、環境の分離が促進される可能性があります。詳細については、ハブアンドスポーク ネットワーク トポロジをご覧ください。

アプリケーションごとに個別の Git リポジトリがあります。

複数のリポジトリではなく、すべてのソースコードに単一の Git リポジトリ（monorepo）を使用している組織もあります。monorepo を使用している場合は、ブループリントのアプリケーション ファクトリー コンポーネントを変更すると、リポジトリをサポートできます。次の手順に沿って操作します。

• 新しいアプリケーションごとに新しいリポジトリを作成するのではなく、既存のリポジトリにサブディレクトリを作成します。
• 新しいリポジトリのオーナー権限をアプリケーション デベロッパー グループに付与する代わりに、既存のリポジトリに対する書き込み権限を付与し、新しいサブディレクトリに対する変更の審査者としてアプリケーション デベロッパー グループを指定します。CODEOWNERS 機能とブランチ保護を使用します。