このセクションでは、デベロッパー プラットフォームで使用される管理設定について説明します。
プラットフォームの ID、ロール、グループ
Google Cloud サービスにアクセスするには、Google Cloud ID が必要です。このブループリントは、フリートの Workload Identity を使用して、Kubernetes サービス アカウント（Pod の ID として使用される）を Google Cloud サービス アカウント（Google Cloud サービスへのアクセスを制御する）にマッピングします。環境間のエスカレーションに対処できるように、各環境には Workload Identity アカウント用の個別の ID プール（信頼できる一連の ID プロバイダ）があります。
プラットフォームのペルソナ
ブループリントをデプロイするときには、デベロッパー プラットフォーム チーム、アプリケーション チーム（アプリケーションごとに 1 チーム）、セキュリティ運用チームの 3 種類のユーザー グループを作成します。
デベロッパー プラットフォーム チームは、デベロッパー プラットフォームの開発と管理を担当します。このチームのメンバーは、次のとおりです。
- デベロッパー プラットフォーム開発者: ブループリントを拡張して既存のシステムに統合するチームメンバーです。このチームは、新しいアプリケーション テンプレートも作成します。
- デベロッパー プラットフォーム管理者: このチームは、次のことを担当します。
- 新しいテナントチームの作成の承認。
- 複数のテナントに影響する、スケジュール設定済みタスクとスケジュールされていないタスクの実行。次のようなタスクがあります。
- 非本番環境と本番環境へのアプリケーションの昇格を承認する。
- インフラストラクチャの更新を調整する。
- プラットフォーム レベルの容量計画を作成する。
デベロッパー プラットフォームのテナントは、単一のソフトウェア開発チームと、そのソフトウェアの運用担当者です。テナントチームは、アプリケーション デベロッパーとアプリケーション オペレーターの 2 つのグループで構成されています。テナントチームの 2 つのグループの職務は次のとおりです。
- アプリケーション デベロッパー: アプリケーション コードの記述とデバッグを行います。ソフトウェア エンジニアやフルスタック デベロッパーとも呼ばれます。その職務内容は次のとおりです。
- アプリケーション コンポーネントを開発環境にデプロイする際に、そのコンポーネントに対してテストと品質保証を行う。
- 開発環境でのアプリケーション独自のクラウド リソース（データベースやストレージ バケットなど）を管理する。
- アプリケーションで使用するデータベースやストレージのスキーマを設計する。
- アプリケーション オペレーターまたはサイト信頼性エンジニア（SRE）: このチームは、本番環境で実行されているアプリケーションの信頼性を管理し、アプリケーション デベロッパーによって変更された内容が本番環境に安全に移行されるように管理します。サービス オペレーター、システム エンジニア、システム管理者と呼ばれることもあります。その職務内容は次のとおりです。
- アプリケーション レベルの容量のニーズを計画する。
- アラート ポリシーを作成し、サービスのサービスレベル目標（SLO）を設定する。
- アプリケーションに固有のログと指標を使用して、サービスの問題を診断する。
- アラートとページに対応する（サービスが SLO を満たしていない場合など）。
- アプリケーション デベロッパーのグループと連携する。
- 本番環境への新しいバージョンのデプロイを承認する。
- 非本番環境と本番環境でアプリケーション独自のクラウド リソースを管理する（バックアップやスキーマの更新など）。
プラットフォームの組織構造
エンタープライズ アプリケーション ブループリントには、エンタープライズ基盤ブループリントによって提供される組織構造が使用されます。次の図は、エンタープライズ アプリケーション ブループリントのプロジェクトがエンタープライズ基盤ブループリントの構造内でどのような位置を占めるかを示しています。
プラットフォームのプロジェクト
次の表に、基盤ブループリントで提供されるプロジェクト以外に、アプリケーション ブループリントでリソース、構成、アプリケーションをデプロイするために必要な追加のプロジェクトを示します。
| フォルダ | プロジェクト | 説明 |
|---|---|---|
|
|
テナントのインフラストラクチャをデプロイするマルチテナント インフラストラクチャ パイプラインが含まれています。 |
|
アプリケーション ファクトリーが含まれています。これは、単一テナント アプリケーション アーキテクチャと、継続的インテグレーションおよび継続的デプロイ（CI / CD）パイプラインの作成に使用されます。このプロジェクトには、GKE クラスタ構成に使用される Config Sync も含まれています。 |
|
|
アプリケーションの CI / CD パイプラインが含まれています。これらのパイプラインは、開発チームを分離できるように独立したプロジェクトに置かれます。アプリケーションごとに 1 つのパイプラインがあります。 |
|
|
|
デベロッパー プラットフォーム用の GKE クラスタと、フリート管理にクラスタを登録するために使用されるロジックが含まれています。 |
（ |
アプリケーション チームが使用するデータベースやその他のマネージド サービスなどの単一テナント アプリケーション サービスが含まれています。 |
プラットフォームのクラスタ アーキテクチャ
このブループリントは、開発環境、非本番環境、本番環境の 3 つの環境にアプリケーションをデプロイします。各環境はフリートに関連付けられています。このブループリントでは、フリートは 1 つ以上のクラスタを含むプロジェクトです。ただし、フリートでは複数のプロジェクトをグループ化することもできます。フリートにより、管理制御の論理的なセキュリティ境界が提供されます。フリートを使用すると、Kubernetes クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になります。
次の図は、アプリケーションをデプロイするために各環境に作成される 2 つの GKE クラスタを示しています。2 つのクラスタが 2 つの異なるリージョンで同一の GKE クラスタとして機能することで、マルチリージョンの復元力が実現します。このブループリントでは、フリートの機能を活用するために、Namespace オブジェクト、Service、ID にわたって同一性のコンセプトが使用されます。
エンタープライズ アプリケーション ブループリントでは、コントロール プレーンへの Private Service Connect アクセスとプライベート ノードプールを介して有効にされる、プライベート空間を持つ GKE クラスタを使用して、インターネットからの潜在的な攻撃対象領域を排除します。クラスタノードとコントロール プレーンにはパブリック エンドポイントはありません。クラスタノードは Container-Optimized OS を実行して攻撃対象領域を制限します。また、シールドされた GKE ノードを使用して、攻撃者によるノードのなりすましを防ぎます。
GKE クラスタへの管理者権限は、Connect ゲートウェイを介して有効になります。ブループリントの Deployment の一部として、環境ごとに 1 つの Cloud NAT インスタンスを使用して、Pod と Config Sync が GitHub などのインターネット上のリソースにアクセスするメカニズムを提供します。GKE クラスタへのアクセスは、GKE 用 Google グループに基づく Kubernetes ロールベース アクセス制御（RBAC）認証によって制御されます。グループを使用すると、ID 管理者が管理する一元的な ID 管理システムを使用して ID を管理できます。
プラットフォームの GKE Enterprise コンポーネント
デベロッパー プラットフォームでは、GKE Enterprise コンポーネントを使用して、アプリケーションのライフサイクルを構築、提供、管理できます。ブループリントの Deployment で使用される GKE Enterprise コンポーネントは次のとおりです。
- コンテナ管理のための GKE
- Policy Controller（ポリシーの管理と適用）
- Anthos Service Mesh（サービス管理）
- Binary Authorization（コンテナ イメージの証明書）
- GKE Gateway Controller（GKE クラスタ用のマルチクラスタ Gateway Controller）
プラットフォームのフリート管理
フリートを使用すると、複数の GKE クラスタを単一の統合された方法で管理できます。フリートチーム管理により、プラットフォーム管理者はデベロッパー プラットフォーム テナントのインフラストラクチャ リソースをより簡単にプロビジョニングし、管理できます。テナントにより、アプリケーション、ログ、指標など、独自の Namespace 内のリソースがスコープに基づいて制御されます。
フリート リソースのサブセットをチームごとにプロビジョニングするには、管理者はチームスコープを使用します。チームスコープを使用すると、チームごとにフリート リソースのサブセットを定義できます。各チームスコープは、1 つ以上のフリート メンバー クラスタに関連付けられます。
フリート Namespace を使用すると、フリート内の特定の Namespace に誰がアクセスできるかを制御できます。アプリケーションは 1 つのフリートにデプロイされる 2 つの GKE クラスタを使用します。クラスタには 3 つのチームスコープがあり、各スコープには 1 つのフリート Namespace があります。
次の図は、ブループリントによって実装される、環境内のサンプル クラスタに対応するフリートとスコープのリソースを示しています。
プラットフォームのネットワーキング
ネットワーキングについては、GKE クラスタは、エンタープライズ基盤ブループリントの一環として作成される共有 VPC にデプロイされます。GKE クラスタでは、開発環境、非本番環境、本番環境で複数の IP アドレス範囲を割り当てる必要があります。ブループリントで使用される各 GKE クラスタには、ノード、Pod、Service、コントロール プレーンに個別の IP アドレス範囲を割り振る必要があります。AlloyDB for PostgreSQL インスタンスには、個別の IP アドレス範囲も必要です。
次の表に、ブループリントのクラスタをデプロイするためにさまざまな環境で使用される VPC サブネットと IP アドレス範囲を示します。アプリケーションの GKE クラスタ リージョン 2 の開発環境では、2 つの開発 GKE クラスタに割り振られた IP アドレス空間がある場合でも、ブループリントは 1 つの IP アドレス空間のみをデプロイします。
| リソース | IP アドレス範囲のタイプ | 開発環境 | 非本番環境 | 本番環境 |
|---|---|---|---|---|
アプリケーションの GKE クラスタ リージョン 1 |
プライマリ IP アドレス範囲 |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Pod IP アドレス範囲 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Service IP アドレス範囲 |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
GKE コントロール プレーンの IP アドレス範囲 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
アプリケーションの GKE クラスタ リージョン 2 |
プライマリ IP アドレス範囲 |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Pod IP アドレス範囲 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Service IP アドレス範囲 |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
GKE コントロール プレーンの IP アドレス範囲 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB for PostgreSQL |
データベースの IP アドレス範囲 |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
独自の IP アドレス割り振りスキームを設計する必要がある場合は、GKE での IP アドレス管理と GKE の IPv4 アドレスの計画をご覧ください。
プラットフォームの DNS
このブループリントは、GKE 向け Cloud DNS を使用して Pod と Kubernetes Service の DNS 解決を提供します。GKE 向け Cloud DNS は、クラスタでホストされる DNS プロバイダを必要としないマネージド DNS です。
ブループリントでは、Cloud DNS が VPC スコープ用に構成されています。VPC スコープを使用すると、プロジェクト内のすべての GKE クラスタ内の Service が単一の DNS ゾーンを共有できます。単一の DNS ゾーンを使用すると、クラスタ間で Service を解決でき、クラスタ外の VM または Pod は、クラスタ内の Service を解決できます。
プラットフォームのファイアウォール
GKE は、GKE クラスタ、GKE Service、GKE Gateway ファイアウォール、GKE Ingress ファイアウォールの作成時に、自動的にファイアウォール ルールを作成します。これにより、使用環境でクラスタの運用が可能になります。自動的に作成されるファイアウォール ルールの優先度はすべて 1000 です。エンタープライズ基盤ブループリントには、共有 VPC 内のトラフィックをブロックするデフォルト ルールがあるため、これらのルールが必要になります。
プラットフォームの Google Cloud サービスへのアクセス
ブループリント アプリケーションは限定公開クラスタを使用するため、限定公開の Google アクセスによって Google Cloud サービスにアクセスします。
プラットフォームの高可用性
ブループリントは、ゾーンとリージョンの両方の停止に対して復元性を実現するように設計されています。アプリケーションの実行を継続するために必要なリソースは 2 つのリージョンに分散されます。ブループリントをデプロイしたいリージョンを選択します。ロードの処理と応答のクリティカル パスにないリソースは、1 つのリージョンのみのリソースであるか、グローバルなリソースです。次の表に、リソースとそれらがデプロイされる場所を示します。
ロケーション |
リージョン 1 |
リージョン 2 |
グローバル |
|---|---|---|---|
このロケーションにリソースがある環境 |
|
|
|
このロケーションにリソースがあるプロジェクト |
|
|
|
このロケーションのリソースタイプ |
|
|
|
次の表に、さまざまなコンポーネントがリージョンの停止またはゾーンの停止にどのように対応するか、またその場合の影響を軽減する方法を示します。
障害の範囲 |
外部サービスへの影響 |
データベースへの影響 | ビルドとデプロイへの影響 | Terraform パイプラインへの影響 |
|---|---|---|---|---|
リージョン 1 のゾーン |
使用可能 |
使用可能 スタンバイ インスタンスが RPO ゼロでアクティブになります。 |
使用可能。手動による変更が必要になる場合があります。 進行中だった |
使用可能。手動による変更が必要になる場合があります。 進行中だった |
リージョン 2 のゾーン |
使用可能 |
使用可能 |
使用可能 |
使用可能。手動による変更が必要になる場合があります。 進行中だった |
リージョン 1 |
使用可能 |
手動による変更が必要です。 オペレーターは手動でセカンダリ クラスタをプロモートする必要があります。 |
使用不可 |
使用不可 |
リージョン 2 |
使用可能 |
使用可能 |
使用可能。手動による変更が必要になる場合があります。 ビルドは引き続き使用可能です。新しいビルドを手動でデプロイする必要がある場合があります。既存のビルドは正常に完了しない可能性があります。 |
使用可能 |
クラウド プロバイダのサービス停止はダウンタイムの原因の一つにすぎません。高可用性を実現するには、間違いが発生しにくいようなプロセスと運用も重要です。次の表に、高可用性に関連してブループリントに反映されたすべての意思決定とその理由を示します。
| ブループリントでの決定 | 可用性への影響 |
|---|---|
チェンジ マネジメント |
|
GitOps と IaC の使用。 |
変更のピアレビューと、以前の構成に迅速に戻すことをサポートします。 |
環境を通して段階的に変化を促進。 |
ソフトウェアや構成のエラーによる影響を軽減します。 |
非本番環境と本番環境を似た状態にする。 |
相違によってエラーの検出が遅れることがないようにします。どちらの環境もデュアルリージョンです。 |
複製されたリソースの変更を環境内でリージョンごとに行う。 |
段階的な適用で検出されない問題が及ぼす影響を、ランタイム インフラストラクチャの半分に留めます。 |
Service を変更する場合、1 つの環境内の 1 つのリージョンで一度に 1 つずつとする。 |
段階的な適用で検出されない問題が及ぼす影響範囲が、Service レプリカの半分に留まるようにします。 |
複製されたコンピューティング インフラストラクチャ |
|
リージョン クラスタ コントロール プレーンの使用。 |
リージョン コントロール プレーンは、アップグレード時とサイズ変更時に使用できます。 |
マルチゾーン ノードプールの作成。 |
1 つのクラスタ ノードプールには 3 つ以上のノードがあり、それらが 3 つのゾーンに分散されます。 |
共有 VPC ネットワークの構成。 |
共有 VPC ネットワークは 2 つのリージョンをカバーします。リージョン障害は、障害が発生したリージョンのリソースとの間のネットワーク トラフィックにのみ影響します。 |
イメージ レジストリの複製。 |
イメージは Artifact Registry に保存されます。Artifact Registry は複数のリージョンに複製されるように構成し、クラウド リージョンが停止しても、存続しているリージョンでアプリケーションをスケールアップできるようにします。 |
Service の複製 |
|
Service レプリカを 2 つのリージョンにデプロイ。 |
1 つのリージョンが停止しても、Kubernetes Service は本番環境と非本番環境で引き続き使用できます。 |
リージョン内での Service 変更にローリング アップデートを使用。 |
ローリング アップデートによるデプロイ パターンを使用して Kubernetes Service を更新すると、リスクやダウンタイムが軽減されます。 |
Service ごとに 1 つのリージョンに 3 つのレプリカを構成。 |
1 つの Kubernetes Service に少なくとも 3 つのレプリカ（Pod）を設定することで、本番環境と非本番環境でのローリング アップデートをサポートします。 |
Deployment の Pod を複数のゾーンに分散させる。 |
Kubernetes Service は、アンチアフィニティ スタンザを使用して、異なるゾーンの VM に分散されます。単一ノードの停止やゾーン全体の停止の場合に、依存関係のある Service 間でクロスリージョンのトラフィックを追加発生させることなく許容できます。 |
複製されたストレージ |
|
マルチゾーン データベース インスタンスのデプロイ。 |
AlloyDB for PostgreSQL はリージョン内で高可用性を提供します。プライマリ インスタンスの冗長ノードは、リージョンの 2 つの異なるゾーンに配置されます。アクティブ ゾーンで問題が発生すると、プライマリ インスタンスはスタンバイ ゾーンへの自動フェイルオーバーをトリガーすることで、リージョンの可用性を維持します。Regional Storage を利用すると、1 つのゾーンが失われた場合でもデータの耐久性を確保できます。 |
データベースのクロスリージョン レプリケーション。 |
AlloyDB for PostgreSQL は、クロスリージョン レプリケーションを使用して障害復旧機能を提供します。データベースは、プライマリ クラスタのデータを別の Google Cloud リージョンにあるセカンダリ クラスタに非同期で複製します。 |
運用 |
|
予想の 2 倍のロードに対応するようアプリケーションをプロビジョニング。 |
1 つのクラスタで障害が発生した場合（リージョンでの Service 停止など）、残りのクラスタで実行される Service の部分でロードを完全に吸収できます。 |
ノードの自動修復。 |
クラスタはノードの自動修復を有効にして構成されます。ノードの連続するヘルスチェックが長期間にわたって繰り返し失敗すると、GKE はそのノードの修復プロセスを開始します。 |
ノードプールのアップグレードをアプリケーション対応にする。 |
Deployment では、 |
デッドロックが発生した Service の自動再起動。 |
Service をサポートする Deployment で、デッドロックしたプロセスを識別して再起動する livenessProbe を定義します。 |
レプリカの準備ができているかを自動的に確認。 |
Service をサポートする Deployment で、起動後にアプリケーションの処理準備が整ったことを識別する readinessProbe を定義します。readinessProbe を使用すると、ローリング アップデート中やノードプールのアップグレード中に手動でチェックしたり一定時間待機したりする必要がなくなります。 |
リファレンス アーキテクチャは、ゾーンとリージョンの高可用性要件があるアプリケーション用に設計されています。高可用性を実現するには、スタンバイのための費用やクロスリージョン レプリケーション費用などの費用が発生します。別の方法のセクションでは、これらの費用を削減するいくつかの方法について説明しています。
プラットフォームの割り当て、パフォーマンスの上限、スケーリングの上限
デベロッパー プラットフォームでは、リソースの割り当て、パフォーマンス、スケーリングを制御できます。次のようなことを考慮してください。
- ベース インフラストラクチャには多数のプロジェクトが必要で、追加のテナントごとに 4 つのプロジェクトが必要になります。デプロイする前やテナントを追加する前に、プロジェクト割り当ての追加リクエストが必要になる場合があります。
- MultiClusterGateway リソースには、プロジェクトごとに 100 個の上限があります。デベロッパー プラットフォーム上のインターネットに接続する Kubernetes Service ごとに、1 つの MultiClusterGateway が必要です。
- Cloud Logging では、1 つのプロジェクトのバケット上限は 100 個です。ブループリントのテナントごとのログへのアクセスは、各テナントのバケットに依存します。
- 20 個を超えるテナントを作成するには、スコープとスコープの Namespace リソースに対するプロジェクトの割り当ての増加をリクエストします。割り当てを確認する手順については、割り当ての表示と管理をご覧ください。フィルタを使用して、割り当てタイプ
gkehub.googleapis.com/global-per-project-scopesとgkehub.googleapis.com/global-per-project-scope-namespacesを見つけます。
次のステップ
- サービスのアーキテクチャ（このシリーズの次のドキュメント）を確認する。