このページでは、フリートを使用するサンプル シナリオを例にして、ガイドのコンセプトとベスト プラクティスをいくつか紹介します。このガイドでは、フリートの概要とフリートの要件とベスト プラクティスを読み、コンセプトを理解していることを前提としています。
例 1: フリートで本番環境、ステージング環境、開発環境のリソースを使用する
最初の例では 4 つのクラスタがあります。2 つのクラスタは本番環境用（冗長性のために 2 つのリージョンに配置）、1 つはステージングとテスト用、1 つは開発用です。すべてのクラスタがプラットフォーム チームによって所有、管理されています。この簡単な例では、frontend と backend の 2 つのサービスを使用していますが、より複雑なシナリオでは、サービスとクラスタの数が多くなります。
アプローチ 1: 本番環境、ステージング環境、開発環境を分離する
一つのアプローチとして、本番環境、ステージング環境、開発環境のリソースに独自のフリートを作成する方法があります。
この場合、3 つのフリートホスト プロジェクトを個別に作成し、これらのプロジェクトにリソースを配置します。オンプレミス開発クラスタの場合は、クラスタを example-dev プロジェクトに登録します。この例では、名前空間やサービスの同一性の問題に対処する必要はありませんが、prod-east クラスタと prod-west クラスタの名前空間が適切に正規化されている必要があります。
このアプローチの利点は、それぞれのフリート間が強固に分離されていることです。その反面、3 つの異なるフリートを管理しなければならないため、本番環境、ステージング環境、開発環境で整合性を持たせることが難しくなります。開発チームから見ると、ステージング済みサービスを対象とした開発が難しくなります。
アプローチ 2: すべてのリソースに 1 つのフリートを作成する
このアプローチでは、すべてのリソースに対して 1 つのフリートを作成します。
この場合、example プロジェクトにリソースを残し、同じプロジェクト内にフリートを作成します。本番環境とステージング環境のリソースを別々のフリートホスト プロジェクトに配置し、共有 VPC を利用することもできますが、説明を簡単にするため、この例では使用しません。
このアプローチでは、フリート全体で名前空間とサービスが正規化されている必要があります。たとえば、本番環境のクラスタとステージング環境のクラスタのそれぞれで、汎用の frontend を frontend-prod、frontend-staging という名前に変更しています。開発用の名前空間の元の名前をそのまま維持することも可能ですが、開発環境の名前空間であることを示すため、より明確な名前（frontend-dev-alice など）を使用します。
このアプローチでは、管理の容易さと分離がトレードオフになります。不要なサービス間通信を防ぐためにサービス メッシュの認可を使用していますが、この 1 つのフリートを使用してシステム全体を簡単に管理できます。このように配置することで、すべてのリソースにポリシーを適用できるようになり、開発環境と本番環境を近いものにすることができます。
アプローチ 3: 本番環境と非本番環境でフリートを分離する
このアプローチは前の 2 つの折衷案で、ステージング環境と開発環境のリソースを非本番環境のフリートに統合し、本番環境を別のフリートに配置します。
この場合、2 つのフリートホスト プロジェクトを作成し、一方を本番環境に、もう一方を非本番環境に使用します。また、これらのプロジェクトにリソースを直接配置し、オンプレミスの dev クラスタを非本番環境のフリートに登録します。明確にするため、ステージング環境と開発環境のリソースの間で名前空間とサービスを正規化する必要があります。たとえば、ステージング環境のクラスタで frontend の名前を frontend-staging に変更します。
このアプローチの利点は、本番環境が非本番環境から分離されている点です。たとえば、開発サービスを有効にしてステージング サービスと通信できるようにすることで、サービスの開発中に、デベロッパー（Alice）の frontend がステージング済みの backend と通信できるようになります。
まとめ
例 1 で説明したアプローチはいずれも有効な方法です。組織でどのアプローチを選択するかは、分離と整合性（管理の容易性）、つまり、リソースタイプ間で必要な分離の度合いとリソースタイプ間で必要な整合性の程度によって決まります。フリートの数を少なくすると、整合性が高くなります。3 番目の方法は中間的なアプローチですが、本番環境を完全に分離しながら、デベロッパーがステージング済みのサービスを操作できます。
例 2: リソース オーナーが異なるフリートを使用する
この例では、team-a と team-b という 2 つのチームがあります。これらのチームは独自のクラスタを所有し、管理しています。どちらのチームも、作成するサービスの名前空間として frontend と backend を使用しています。ただし、team-a の frontend と backend は、team-b のものと同じではありません。2 つのチームは、お互いのサービス間でやり取りができるように、サービス メッシュを作成したいと考えています。
このままでは、これらのクラスタを同じメッシュの一部にすることはできません。手始めに、一元化されたプラットフォーム チームにクラスタの所有権を移行し、それらのクラスタ間の信頼関係を確立することをおすすめします。team-a と team-b が相互に信頼している場合は、その信頼関係を調整することもできます。次に、この 2 つのチームのクラスタで frontend と backend がオーバーロードされないように、名前空間の使用を正規化します。これにより、すべてのリソースに対して単一のフリートを確立し、サービス メッシュを作成できます。
このレベルの信頼関係を確立できない場合は、異なるフリートホスト プロジェクトを使用する 2 つの別々のフリートに team-a と team-b を配置します。この方法の欠点は、メッシュの連携が必要になり、単一メッシュの場合よりも管理が難しくなる点です。その反面、どちらのチームもデプロイされる名前空間とサービスを正規化する必要がありません。また、明示的に承認された通信のみが許可されます。
