一般的には、できるだけ少ないクラスタを使用することがベスト プラクティスですが、実際にはさまざまな理由から、技術的目標およびビジネス目標を満たすために複数のクラスタをデプロイすることが考えられます。少なくとも、ほとんどの組織では、サービスを配置するクラスタを別にすることで、非本番環境と本番環境のサービスを分離しています。より複雑なシナリオでは、ティア、ロケール、チーム、インフラストラクチャ プロバイダ間でサービスを分離するために複数のクラスタが採用されます。
複数のクラスタを導入する理由のほとんどは、次の 3 つの要件に分類されます。
- 分離: 主に信頼性の向上やセキュリティのニーズを満たすため、サービスのコントロール プレーンとデータプレーンを分離する
- ロケーション: 可用性、レイテンシ、局所性のニーズに対応するために、特定のロケーションにサービスを配置する
- スケーリング: 特に Kubernetes クラスタのコンテキストで、単一クラスタで生じる制限を超えるサービスをスケーリングする
これらの点については、以降のセクションで詳しく説明します。
多くの場合、組織はいくつかの要件を同時に調整する必要があります。ご自身の組織について考えてみるときに、使用する組織の数をできる限り少なくすることをおすすめします。マルチクラスタに関するニーズのうち、組織にとって優先度が最も高く、セキュリティが侵害されていないものを特定し、マルチクラスタ アーキテクチャの作成で適切なトレードオフを行います。
組織でサービスモデルごとのクラスタや cluster-per-team モードの使用を検討している場合は、そうしたシステムのオペレーターに生じる管理の負荷を考慮してください。フリートと、それをサポートする Google Cloud のコンポーネントおよび機能は、複数のクラスタを可能な限り簡単に管理できるようにしますが、クラスタの数が増加すると、常になんらかの形で管理の複雑さも増加します。
分離
ここでの分離は、コントロール プレーンとデータプレーンの分離を意味します。これらは、複数のクラスタを実行して実現できます。ただし、この分離がデータプレーンの分離にも適用される場合があります。分離は通常、以下の点を考慮します。
環境
多くの場合、組織は複数のクラスタで開発、ステージング / テスト、本番環境サービスを実行し、さまざまなネットワークやクラウド プロジェクトも運用しています。分離は、本番環境サービスの偶発的な中断と、開発またはテストでの機密データへのアクセスを防ぐための措置として行われます。ワークロードの階層化
複雑なアプリケーションを多く持つ組織は、多くの場合サービスを階層化し、より重要なサービスを他のサービスとは異なるクラスタ上で実行しています。このような環境では、より重要なサービスとクラスタはアクセス、セキュリティ、アップグレード、ポリシーなどに関して特別な検討事項として扱われます。この階層化の一例は、ステートレス サービスとステートフル サービスを別々のクラスタに配置することです。障害による影響の軽減
組織は、オペレーターの誤り、クラスタ障害、関連するインフラストラクチャの障害による影響を制限するため、複数のクラスタにサービスを分割できます。アップグレード
組織がインプレース アップグレードで発生しうる課題（アップグレード自動化の失敗、アプリケーションの不安定さ、ロールバック能力など）を検討している場合、新しいクラスタにサービスのコピーをデプロイできます。この方法でアップグレードするには、事前に計画または自動化して、アップグレード プロセス中にトラフィック管理と状態のレプリケーションに対処する必要があります。セキュリティや規制の分離
組織はさまざまな理由でサービスを分離できます。たとえば、機密性の低いワークロードと規制要件の厳しいワークロードを分離するため、サードパーティ（信頼性の低い）サービスをファーストパーティ（信頼性の高い）サービス（クラスタ）と別のインフラストラクチャで実行するためなどです。テナントの分離
テナントの複数のクラスタへの分離は、セキュリティの分離、パフォーマンスの分離、費用計算、オーナー権限など、さまざまな理由で行われます。
ロケーション
レイテンシ
特定のサービスでは、特定のロケーション（または地理的位置）にワークロードを物理的に配置することで満たされるレイテンシ要件があります。これは、アップストリーム サービスまたはエンドユーザーがレイテンシの影響を受けやすい場合に必要になることがあります。また、ワークロード自体がダウンストリーム サービスのレイテンシの影響を受けやすい場合にも必要になります。可用性
単一のクラウド プロバイダ（または複数のプロバイダ）で複数のアベイラビリティ ゾーンにまたがって同じサービスを実行することで、全体的な可用性が向上します。地域の適用法令
データ所在地に関する要件やその他の法的な要件を満たすため、特定のリージョンでコンピューティングとストレージを行わなければならないことがあります。その場合、複数のデータセンターまたはクラウド プロバイダにインフラストラクチャをデプロイする必要が生じます。データ グラビティ
大規模なデータコーパス（場合によっては特定のデータベース インスタンス）は単一のクラウド プロバイダまたはリージョンに統合することが難しく、また得策でない場合があります。処理とサービス提供の要件によっては、アプリケーションをデータの近くにデプロイすることを検討できます。レガシー インフラストラクチャ/サービス
データと同様、レガシー インフラストラクチャもクラウドへの移行が難しいことがあります。これらのレガシー サービスは不変ですが、新しいサービスを開発するための追加のクラスタをデプロイすることで、組織は開発速度を上げることができます。デベロッパーによる選択
使用するクラウドマネージド サービスの選択肢をデベロッパーに提供するのは有効です。選択できるようにすることで、チームで最適なツールを使用して迅速に作業を進められます。各プロバイダに割り当てられた追加リソースを管理する必要もなくなります。ローカル / エッジ コンピューティングのニーズ
倉庫、工場、小売店などの従来の作業環境でアプリケーションのモダナイゼーションを採用しようとすると、より多くのインフラストラクチャでより多くのワークロードを管理する必要が生じます。
スケーリング
GKE はクラスタを 5,000 ノード以上にスケーリングできるため、クラスタの制限が複数のクラスタのオペレーションを行う理由となることはまずありません。多くの場合、組織はクラスタがスケーラビリティの上限に達する前に、複数のクラスタにサービスを分散することを決定します。スケーラビリティの上限に達したクラスタの場合、アプリケーションを複数のクラスタにまたがって実行すると、いくつかの課題を解決できますが、複数クラスタの管理の複雑さが伴います。