フリートの例

このページの例では、フリート(旧称 environ)を使用する架空のシナリオを示し、このガイドのコンセプトとベスト プラクティスをいくつか紹介します。このガイドでは、フリートの概要フリートの要件とベスト プラクティスを読み、コンセプトを理解していることを前提としています。

例 1: フリートで本番環境、ステージング環境、開発環境のリソースを使用する

最初の例では 4 つのクラスタがあります。2 つのクラスタは本番環境用(冗長性のために 2 つのリージョンに配置)、1 つはステージングとテスト用、1 つは開発用です。すべてのクラスタがプラットフォーム チームによって所有、管理されています。この簡単な例では、frontendbackend の 2 つのサービスを使用していますが、より複雑なシナリオでは、サービスとクラスタの数が多くなります。

本番環境、ステージング環境、開発環境のリソースを使用するシステムの図
本番環境、ステージング環境、開発環境のリソースを使用するシステム

方法 1: 本番環境、ステージング、開発のフリートを分離する

1 つの方法は、本番環境、ステージング、開発用のリソースに独自のフリートを作成することです。

この場合、3 つのフリート ホスト プロジェクトを作成し、これらのプロジェクトにリソースを配置します。オンプレミス開発クラスタの場合は、クラスタを example-dev プロジェクトに登録します。この例では、名前空間やサービスの同一性の問題に対処する必要はありませんが、prod-east クラスタと prod-west クラスタの名前空間が適切に正規化されている必要があります。

この方法の利点は、両方のフリート間に強固な分離があることです。その反面、3 つの異なるフリートを管理しなければならないため、本番環境、ステージング環境、開発環境で一貫性を持たせることが難しくなります。開発チームから見ると、ステージング サービスの開発が難しくなります。

本番環境、ステージング環境、開発環境のリソース用に分かれたフリートを示す図
本番環境、ステージング環境、開発環境のリソース用に分かれたフリート

方法 2: すべてのリソースに 1 つのフリートを作成する

この方法では、すべてのリソースに対して 1 つのフリートを作成します。

この場合、example プロジェクトにリソースを残し、そのプロジェクトにフリートを作成します。本番環境とステージング環境のリソースを別々のフリート ホスト プロジェクトに配置し、共有 VPC を利用することもできますが、説明を簡単にするため、この方法は選択しません。

この方法では、Environ 全体で名前空間とサービスが正規化されている必要があります。たとえば、本番環境のクラスタとステージング環境のクラスタのそれぞれで、汎用の frontendfrontend-prodfrontend-staging という名前に変更しています。開発用の名前空間の元の名前をそのまま維持することも可能ですが、開発環境の名前空間であることを示すため、より明確な名前(frontend-dev-alice など)を使用します。

この方法では、管理の容易さと分離がトレードオフになります。不要なサービス間通信を防ぐためにサービス メッシュの承認を使用していますが、この 1 つのフリートを使用してシステム全体を簡単に管理できます。このように配置することで、すべてのリソースにポリシーを適用できるようになり、開発環境と本番環境を近いものにすることができます。

本番環境、ステージング環境、開発環境のリソースがある単一のフリートを表す図
本番環境、ステージング環境、開発環境のリソースがある単一のフリート

方法 3: 本番環境と非本番環境でフリートを分離する

この方法は、前の 2 つの折衷案で、ステージング環境と開発環境のリソースを非本番環境のフリートに統合し、本番環境を別のフリートに配置します。

この場合、2 つのフリート ホスト プロジェクトを作成し、1 つを本番環境に、もう 1 つを非本番環境に使用します。また、これらのプロジェクトにリソースを直接配置し、オンプレミスの dev クラスタを非本番環境のフリートに登録します。明確にするため、ステージング環境と開発環境のリソースの間で名前空間とサービスを正規化する必要があります。たとえば、ステージング環境のクラスタで frontend の名前を frontend-staging に変更します。

このアプローチの利点は、本番環境が非本番環境から分離されている点です。たとえば、開発サービスを有効にしてステージング サービスと通信できるようにすることで、サービスの開発中に、デベロッパー(Alice)の frontend がステージングされた backend と通信できるようになります。

本番環境のフリートと非本番環境のフリートを表す図
本番環境フリートと非本番環境フリート

概要

例 1 で説明したアプローチはいずれも有効な方法です。組織でどのアプローチを選択するかは、分離と整合性(管理の容易性)、つまり、リソースタイプ間で必要な分離の度合いとリソースタイプ間で必要な整合性の程度によって決まります。フリートの数を少なくすると、整合性が高くなります。3 番目の方法は中間的なアプローチですが、本番環境を完全に分離しながら、デベロッパーがステージング サービスを操作できます。

例 2: リソース オーナーが異なるフリートを使用する

この例では、team-a と team-b という 2 つのチームがあります。これらのチームは独自のクラスタを所有し、管理しています。どちらのサービスも、作成するサービスの名前空間として frontendbackend を使用しています。ただし、team-a の frontendbackend は、team-b のものと同じではありません。2 つのチームは、お互いのサービス間でやり取りができるように、サービス メッシュを作成したいと考えています。

2 つのチームのリソースが存在するシステムの図
2 つのチームのリソースが 1 つのシステムに存在している

このままでは、これらのクラスタを同じメッシュの一部にすることはできません。手始めに、一元化されたプラットフォーム チームにクラスタの所有権を移行し、それらのクラスタ間の信頼関係を確立することをおすすめします。team-a と team-b が相互に信頼している場合は、その信頼関係を調整することもできます。次の手順では、この 2 つのチームのクラスタで frontendbackend が過負荷にならないように、名前空間の使用を正規化します。これにより、すべてのリソースに対して単一のフリートを確立し、サービス メッシュを作成できます。

1 つのフリートに存在する 2 つのチームのリソースを表す図
1 つのフリートに 2 つのチームのリソースが存在する

このレベルの信頼関係を確立できない場合は、異なるフリート ホスト プロジェクトを使用する 2 つの別々のフリートに team-a と team-b を配置します。この方法の欠点は、メッシュの連携が必要になり、単一メッシュの場合よりも管理が難しくなる点です。その反面、どちらのチームもデプロイされる名前空間とサービスを正規化する必要がありません。また、明示的に承認された通信のみが許可されます。

別々のフリートにある 2 つのチームのリソースを表す図
別々のフリートにある 2 つのチームのリソース