マルチテナント アーキテクチャの設計

このドキュメントでは、次のアプローチのいずれかを選択できるようにすることで、Google Cloud でマルチテナント アーキテクチャの計画、設計、実装を行う際に役立つ情報を提供します。

  1. 複数のテナントで同じランタイム環境。
  2. テナント ドメインごとに 1 つのランタイム環境。
  3. テナントド メインごとに 1 つのリソース コンテナ。

これらのアプローチは、テナント間の分離の昇順で並べられていますが、必ずしも相互に排他的ではありません。さまざまなワークロード クラスに対して異なるオプションを選択するハイブリッド アプローチを実装できます。たとえば、複数のテナント ドメインの共有ランタイム環境をテナントのセットに提供したり、テナント ドメインごとにランタイム環境を別のテナントのセットに提供したりできます。

このドキュメントは、Google Cloud でマルチテナント アーキテクチャをプロビジョニングして構成する必要があり、単一の管理エンティティでマルチテナント アーキテクチャを管理したい場合に便利です。たとえば、インフラストラクチャのさまざまな事業部門、チーム、ユーザーを分離する必要があります。また、アプリケーションを完全には書き直さずに、既存のアプリケーションをデプロイする必要があります。このドキュメントでは、マルチテナント アーキテクチャとは、アプリケーション レベルではなく、インフラストラクチャ レベルでのマルチテナンシーを指します。たとえば、テナントごとに 1 つのインスタンスを持つ、複数のインスタンスをデプロイするアプリケーションがあります。

また、このドキュメントでは、単一の管理エンティティが管理するマルチテナント アーキテクチャの設計を検討していて、外観を確認したい場合にも役立ちます。複数の選択から 1 つのオプションを選択すると、いくつかの要因が左右されます。他のオプションより本質的に優れたオプションはありません。どのオプションにも独自の強みと弱みがあります。オプションの選択は、次の手順に沿って行います。

  1. マルチテナント アーキテクチャの計画、設計、実装に必要なさまざまなオプションを評価するための一連の基準を確立します。
  2. 評価基準に照らして各オプションを評価します。
  3. ニーズに最適なオプションを選択してください。

用語

以下の用語は、Google Cloud でマルチテナント アーキテクチャを設計、計画、実装する方法を理解するうえで重要です。

  • ランタイム環境は、ワークロードをデプロイする環境です。
  • リソース コンテナは、フォルダ リソースまたはプロジェクト リソースです。
  • テナントは、1 つ以上のランタイム環境で関連するワークロードのセットを操作するエンティティです。
  • テナント ドメインは、テナントに属するリソースとワークロードが他のテナントに属するリソースと明確に区別できる環境です。
  • 管理上の分離により、テナント ドメインに属するリソースから他のテナント ドメインに属するリソースを論理的に分離できます。
  • リソース消費の分離は、各テナント ドメインへのリソースの公平な割り当てを保証し、テナントによるリソースの過剰消費を防止します。リソース消費の分離は、管理上の分離を意味します。
  • ランタイム環境の分離により、各テナント ドメインのランタイム環境が、他のテナント ドメインのランタイム環境から確実に分離されます。テナント ドメインのランタイム環境を変更しても、他のテナント ドメインのランタイム環境には影響しません。ランタイム環境の分離とは、リソース消費量の分離を意味します。

マルチテナント アーキテクチャの評価基準を確立する

マルチテナント アーキテクチャのオプションを評価するための基準を確立するには、これらのアーキテクチャで最も重要な機能を考慮します。最も必要な機能に関する情報を収集するには、ワークロードを評価します。ワークロードの評価について詳しくは、Google Cloud への移行: ワークロードの評価と検出をご覧ください。コンテナ化された環境を評価する必要がある場合は、コンテナを Google Cloud に移行する: はじめにをご覧ください。

以下の評価基準と、一覧表示された順序は一例です。ワークロードを評価して、ご自身とワークロードにとって重要な基準のリストを作成し、重要度に応じて順序を並べ替えることをおすすめします。たとえば、ワークロードの評価後、次の評価基準について検討できます。

  1. ワークロードに必要な分離のタイプ。 どの分離保証をサポートするが必要があるか。ワークロードにどのような種類の分離が必要か。管理の分離、リソース消費分離、ランタイム環境の分離から選択します。
  2. テナント ドメインがテナント ドメインに対して持つ与える制御の程度。テナントにはいくつのカスタマイズ オプションが必要か。テナントがテナント ドメインを管理するために必要な自由度はどれくらいか。各テナント ドメインで、厳密に管理する必要があるか。
  3. 予想されるテナント数。多数のテナント ドメインを管理する必要があるか。できるだけ多くのメンテナンス作業を自動化できるリソースや専門知識がない場合、アーキテクチャの複雑さはテナント ドメインの数とともに増加する可能性があります。
  4. 費用のアトリビューション。テナントのリソース消費量をテナントに請求する必要があるか、または、マルチテナント アーキテクチャを担当するエンティティに起因するコストか。各テナントのリソース消費量を正確に考慮する必要がある場合、環境の一部(コントロール プレーンなど)を環境間で共有できない場合があります。
  5. フェデレーション IDテナントには、連携する必要がある独自の ID プロバイダがあるか、それとも一元化された ID プロバイダを提供しているか。
  6. テナント間でのコンテンツまたはリソースの共有。テナント間でのコンテンツやリソースの共有は必要か。テナントはどのような種類のコンテンツとリソースを共有する必要があるか。コンテンツとリソースを共有するために、テナントは環境とインフラストラクチャからどのようなサポートを必要とするか。
  7. サポートするインフラストラクチャの制限。マルチテナント アーキテクチャをサポートするインフラストラクチャでは、消費できるリソースに制限を適用できるか。たとえば、Google Cloud ではリソース使用量に割り当てが適用されます。これらの割り当ての増加を適用することはできますが、他の割り当ては固定されていて、引き上げることはできません。

マルチテナント アーキテクチャ オプションの評価

Google Cloud には、マルチテナント アーキテクチャを実装するためのさまざまなオプションがあります。ワークロードに最適なオプションを選択するには、まず確立した評価基準に照らして評価します。オプションごとに、任意に順序付けしたスケールのスコアを評価基準に割り当てます。たとえば、各評価基準に照らして 1~10 のスケールを各オプションに割り当てることができます。

複数のテナントに同じランタイム環境

複数のテナント ドメインで同一のランタイム環境を使用する場合、それらのドメインをホストするランタイム環境の機能を使用してテナント ドメインを分離します。たとえば、Google Kubernetes Engine(GKE)クラスタと、クラスタ内の各テナント ドメインに対して名前空間をプロビジョニングできます。Compute Engine インスタンスをプロビジョニングし、オペレーティング システムを使用してテナント ドメインを分離することもできます。

次のリストを使用して、以前に確立した基準に照らしてこのオプションを評価します。

  1. ワークロードに必要な分離のタイプ。 ワークロードが管理上の分離のみを必要とする場合、またはリソース消費の分離が必要な場合は、このオプションを使用できます。たとえば、Kubernetes は、管理上の分離のための Namespaces とリソース消費の分離のためのリソース割り当てをサポートしています。ランタイム環境の分離が必要な場合は、他のオプションのいずれかを選択することをおすすめします。
  2. テナント ドメインがテナント ドメインに対して持つ与える制御の程度。このオプションは、テナント ドメインでの厳密な制御の適用に関連付けられています。たとえば、テナント ドメインが推奨される構成とステータスに従うようにします。
  3. 予想されるテナント数。同じランタイム環境内で多数のテナント ドメインを管理すると、ランタイム環境の構成を変更するたびに複数のテナントが影響を受けるリスクの可能性があります。たとえば、ランタイム環境のコントロール プレーンに問題がある場合、そのランタイム環境内で複数のテナント ドメインに影響を及ぼす可能性があります。ただし、同じランタイム環境を使用することで、テナント ドメインのプロビジョニングと構成を自動化する複雑さが軽減されることがあります。たとえば、GKE クラスタをマルチテナント ドメインのランタイム環境として使用する場合、新しいテナント ドメインのプロビジョニングで必要となるのは、新しい Namespace とリソース割り当ての適用のみである場合があります。
  4. 費用のアトリビューション。複数のテナントが同じランタイム環境を共有している場合、テナントにコストを帰属させることが難しくなる場合があります。コントロール プレーンなどの環境の一部はテナント間で共有されるため、テナント間でコストを適切に分散するのは困難です。また、テナントに適切な課金を行うため、リソースの使用量に関する指標を収集する包括的なモニタリング システムが必要です。各テナント ドメインで厳密なコストのアトリビューションと課金が必要な場合は、他のいずれかの方法を選択することをおすすめします。
  5. フェデレーション IDテナントが連携する独自の ID プロバイダを使用している場合は、ランタイム環境がこのような統合に適しているかどうかを評価する必要があります。また、テナントが独自の ID 管理システムを使用して管理できるようにするかどうかも評価する必要があります。テナント ドメインの構造を厳密に制御する必要がある場合は、一元化された ID 管理システムを使用できます。共有ランタイム環境での ID 管理システムのプロビジョニングと構成は難易度の高いチャレンジです。テナントがこのような統合を必要とする場合は、他のオプションのいずれかを選択することをおすすめします。
  6. テナント間でのコンテンツまたはリソースの共有。テナントが異なるテナント ドメイン間でリソースやコンテンツを共有する必要がある場合は、このオプションを使用することで、各テナント ドメインが同じランタイム環境内にあるため、共有メカニズムの実装を簡素化できます。ランタイム環境の機能を利用して異なるテナント ドメイン間の通信を可能にするため、異なるテナント ドメイン間で安全な通信チャネルを作成する必要はありません。コンテンツ共有のユースケースに対応する必要がある場合は、このオプションを選択してください。
  7. サポートするインフラストラクチャの制限。このオプションは、ランタイム環境内で使用できるものを制限するため、テナントにリソースに対する均一な要件がある場合に適しています。たとえば、テナントが要求できるのは、ランタイム環境が提供するリソースだけです。

テナント ドメインごとに 1 つのランタイム環境。

テナント ドメインごとに 1 つのランタイム環境を使用する場合は、ランタイム環境をホストするプラットフォームによって提供される機能を使用して、ドメインを分離します。たとえば、テナント ドメインごとに GKE クラスタをプロビジョニングすることも、テナント ドメインごとに Compute Engine インスタンスまたはインスタンス グループをプロビジョニングすることもできます。

次のリストを使用して、以前に確立した基準に照らしてこのオプションを評価します。

  1. ワークロードに必要な分離のタイプ。 ワークロードでランタイム環境の分離が必要な場合、このオプションを使用します。たとえば、各テナント ドメインに GKE クラスタを使用することで、ランタイム環境とそのコントロール プレーンを相互に分離できます。
  2. テナント ドメインがテナント ドメインに対して持つ与える制御の程度。このオプションを使用すると、各テナントがランタイム環境をカスタマイズできます。ランタイム環境は、各テナントがランタイム環境を管理するようなセルフマネージド型にすることも、すべてのランタイム環境を管理する専用のチームを持つこともできます。どちらを選択するかは、テナントに提供するカスタマイズの程度によって決まります。たとえば、GKE を使用している場合、テナントにクラスタを自己管理させることができます。このオプションを使用すると、さまざまなランタイム環境のタイプをサポートできます。たとえば、GKE を使用している場合は、さまざまな種類のノードプールをプロビジョニングできます。1 つは、GPU リソースを提供し、もう 1 つは Cloud TPU リソースを提供します。
  3. 予想されるテナント数。多数のテナント ドメインを計画している場合、各テナント ドメインでランタイム環境のプロビジョニングと構成を行うのは簡単ではない場合があります。また、テナントがランタイム環境のリソースを完全に使用しない可能性があるため、このオプションは単一ランタイム環境を用意する場合ほど効率的にならない場合があります。効率性とリソース使用率の向上を目指している場合は、他のいずれかのオプションを選択することをおすすめします。たとえば、GKE を使用している場合、クラスタにデプロイされたワークロードがクラスタのリソースを完全に消費しないことがあります。
  4. 費用のアトリビューション。テナントに独自のランタイム環境がある場合、費用のアトリビューションがより簡単にできます。ランタイム環境をサポートするインフラストラクチャによって提供されるモニタリング ツールと請求ツールを使用して、リソース消費を正確に測定し、各テナントに費用を割り当てることができます。たとえば、Google Cloud では、各ランタイム環境の費用を分析するための請求レポートを設定できます。
  5. フェデレーション IDランタイム環境がこのような統合に適しているかどうかを判断し、テナントが独自の ID 管理システムを使用して管理できるようにするかどうかを評価します。テナント ドメインの構造をきめ細かく管理したい場合は、一元化された ID 管理システムを使用することをおすすめします。テナントがこのような統合を必要とする場合は、テナント ドメインごとに専用のランタイム環境を用意することで、他のテナント ドメインへの影響を回避できます。
  6. テナント間でのコンテンツまたはリソースの共有。異なるランタイム環境間でコンテンツを共有するには、追加のインフラストラクチャ、プロビジョニング、構成が必要です。たとえば、異なるランタイム環境間においてテナント ドメイン間でコンテンツを共有するように認証および認可システムを設定できます。
  7. サポートするインフラストラクチャの制限。マルチテナント アーキテクチャをサポートしているインフラストラクチャにより、プロビジョニングできるランタイム環境の数が制限されることがあります。テナント ドメインとランタイム環境間の 1 対 1 のマッピングにより、これらの制限はサポートできるテナント ドメインの数に大きな影響を与えます。たとえば、GKE では特定のゾーンまたはリージョンで作成できるクラスタの数に制限があります

テナントド メインごとに 1 つのリソース コンテナ。

テナント ドメインごとに 1 つのリソース コンテナを使用する場合は、ランタイム環境をホストするプラットフォームによって提供される機能を使用して、テナント ドメインを分離します。たとえば、テナント ドメインごとに Google Cloud プロジェクトまたはフォルダをプロビジョニングできます。フォルダを使用すると、テナント ドメインの分離プロパティに影響する可能性がありますが、この設定によりマルチテナント アーキテクチャをサポートするインフラストラクチャの管理が容易になります。アーキテクチャのコンポーネントの再利用、重複排除、論理的な分離を促進できます。

次のリストを使用して、以前に確立した基準に照らしてこのオプションを評価します。

  • ワークロードに必要な分離のタイプ。 ワークロードでランタイム環境の分離が必要な場合、このオプションを使用します。たとえば、テナント ドメインを互いに完全に分離するように、テナント ドメインごとに Cloud プロジェクトを作成します。
  • テナント ドメインがテナント ドメインに対して持つ与える制御の程度。このオプションを使用すると、各テナントはランタイム環境とリソース階層をカスタマイズできます。また、単一のテナント ドメインで複数のランタイム環境を結合することもでき、異種混合のランタイム環境をサポートできます。テナントがテナント ドメインごとに複数のランタイム環境を必要とする場合、このオプションが適しています。たとえば、GKE を使用している場合、テナント ドメイン内のワークロードの要件を満たすために各テナント ドメインに複数のクラスタをプロビジョニングできます。
  • 予想されるテナント数。多数のテナント ドメインを計画している場合は、テナント ドメインごとに複数のランタイム環境のプロビジョニングと構成を行うのは簡単ではないことがあります。このオプションは、テナント間で単一のランタイム環境を共有する場合や、各テナントのランタイム環境を共有する場合ほど効率的ではない場合があります。テナントにより、ランタイム環境のリソースが完全に使用されない場合があります。効率性とリソース使用率の向上を目指している場合は、他のいずれかのオプションを選択することをおすすめします。たとえば、GKE を使用している場合、クラスタにデプロイされたワークロードはそれらのクラスタ内のリソースを完全に消費できません。
  • 費用のアトリビューション。テナントに独自のリソース コンテナがある場合、費用のアトリビューションが容易になります。ランタイム環境をサポートするインフラストラクチャによって提供されるモニタリング ツールと請求ツールを使用して、リソース消費を正確に測定し、各テナントに費用を割り当てることができます。たとえば、Google Cloud では、各ランタイム環境の費用を分析するための請求レポートを設定できます。
  • フェデレーション IDテナントは、テナント ドメインに独自のソリューションをプロビジョニングして構成することができるため、複雑な ID 連携要件に対応できます。独自のソリューションのプロビジョニングと構成を行っても、一元化されたソリューションとの統合を妨げることはありません。
  • テナント間でのコンテンツまたはリソースの共有。異なるリソース コンテナ間でコンテンツを共有するには、追加のインフラストラクチャ、プロビジョニング、構成が必要です。たとえば、共有可能なコンテンツを配置するために、異なるテナント ドメインからアクセスできるスペースを設定する必要がある場合などが考えられます。
  • サポートするインフラストラクチャの制限。マルチテナント アーキテクチャをサポートしているインフラストラクチャでは、プロビジョニング可能なリソース コンテナの数に制限を課すことができます。テナント ドメインとリソース コンテナ間の 1 対 1 のマッピングであるため、これらの制限はサポートできるテナント ドメインの数に大きく影響します。たとえば、GKE では特定のゾーンまたはリージョンで作成できるクラスタの数に制限があります

移行先の環境に適したオプションを選択する

前のセクションでは、各オプションのすべての基準に値を割り当てました。各オプションの合計スコアを計算するには、基準に基づいてそのオプションのすべての評価を追加します。たとえば、オプションの分離基準のタイプに対して 10 のスコアを付け、テナント ドメイン基準で各テナントに許可する制御の程度に対して 6 のスコアを付けた場合、その環境の合計スコアは 16 になります。

また、各評価基準のスコアに異なる重みを割り当てて、各評価基準の重要度を表すこともできます。たとえば、評価でテナント ドメイン上の各テナントに許可する制御の程度よりも分離のタイプの方が重要になる場合は、それを反映する乗数を定義できます。分離のタイプの乗数は 1.0、評価でテナント ドメインの核テナントに許可する制御の程度の乗数 0.7 とします。次に、これらの乗数を使用して、オプションの合計スコアを計算します。

評価した各オプションの合計スコアを計算した後、合計スコアの降順によってオプションを整理します。オプションとしてスコアが最も高いオプションを選択します。

このデータを表現する方法は複数あります。たとえば、レーダー チャートのような多変量データを表すグラフを使用して結果を可視化できます。

次のステップ