マルチテナント ソリューションには複数の "プレーン" があり、それぞれに独自の役割があります。 "データ プレーン" では、エンド ユーザーとクライアントがシステムと対話できます。 "コントロール プレーン" は、プラットフォーム管理者のタスクをサポートするためのアクセス制御、プロビジョニング、システム メンテナンスなど、すべてのテナントにわたる上位レベルのタスクを管理するコンポーネントです。
この記事では、コントロール プレーンの役割と、ニーズを満たすコントロール プレーンを設計する方法について説明します。
たとえば、財務記録を管理するための経理システムを考えてみましょう。 複数のテナントで、財務記録をシステムに格納します。 エンド ユーザーがシステムにアクセスして財務記録を表示したり入力したりするとき、データ プレーンが使用されます。 データ プレーンは、ソリューションの主要なアプリケーション コンポーネントである可能性があります。 テナントでは、おそらくこれがシステムの意図した使い方だとみなされます。 コントロール プレーンは、新しいテナントをオンボードし、テナントごとにデータベースを作成し、その他の管理操作とメンテナンス操作を実行するコンポーネントです。 システムにコントロール プレーンがない場合、管理者は多くの手動プロセスを実行することが必要になることがあります。 あるいは、データ プレーンとコントロール プレーンのタスクが混じり合い、ソリューションが複雑になることもあります。
多くの複雑なシステムには、コントロール プレーンが含まれます。 たとえば、Azure コントロール プレーンである Azure Resource Manager は、Azure リソースのデプロイと構成を担当する一連の API、ツール、バックエンドのコンポーネントです。 Kubernetes コントロール プレーンでは、ワーカー ノードへの Kubernetes ポッドの配置など、多くのタスクが管理されます。 ほぼすべてのサービスとしてのソフトウェア (SaaS) ソリューションには、テナント間のタスクを処理するためのコントロール プレーンがあります。
マルチテナント ソリューションを設計する場合は、コントロール プレーンについて考慮する必要があります。 次のセクションでは、コントロール プレーンのスコープの設定と設計に必要な詳細について説明します。
コントロール プレーンの役割
コントロール プレーンやその役割についての唯一のテンプレートはありません。 ソリューションの要件とアーキテクチャによって、コントロール プレーンで何を行う必要があるかが決まります。 一部のマルチテナント ソリューションでは、コントロール プレーンには幅広い役割があり、それ自体が複雑なシステムです。 他のマルチテナント ソリューションでは、コントロール プレーンには基本的な役割しかありません。
一般に、コントロール プレーンには、次の主要な役割の多くが含まれる場合があります。
- システムがワークロードに対応するために必要なシステム リソース (テナント固有のリソースを含む) をプロビジョニングおよび管理します。 コントロール プレーンでは、デプロイを担当するデプロイ パイプラインを呼び出して調整したり、デプロイ操作自体を実行したりする場合があります。
- 新しいテナントを認識するように共有リソースを再構成します。 たとえば、コントロール プレーンでは、受信トラフィックが正しいテナントのリソースにマップされるようにネットワーク ルーティングを構成する場合があります。また、リソース容量のスケーリングが必要になることもあります。
- 各テナントの構成を格納して管理します。
- テナントのオンボード、移動、オフボーディングなどのテナントのライフサイクル イベントを処理します。
- 各テナントによる機能の使用とシステムのパフォーマンスを追跡します。
- システムのリソースに対する各テナントの消費量を測定します。 消費量のメトリックは、課金システムに通知されたり、リソース ガバナンスに使用されたりする場合があります。
完全なマルチテナントのテナント モデルを使用し、テナント固有のリソースをデプロイしない場合、基本的なコントロール プレーンでは、テナントとそれに関連付けられているメタデータだけが追跡されることもあります。 たとえば、新しいテナントからサービスへのサインアップが行われるたびに、コントロール プレーンではデータベース内の適切なレコードを更新して、システムの残りの部分が新しいテナントの要求に対応できるようにすることができます。
これに対し、ソリューションで、 自動化されたシングルテナント モデルのようなテナント固有のインフラストラクチャを必要とするデプロイ モデルが使用されているとします。 このシナリオでは、新しいテナントをオンボードするたびに Azure インフラストラクチャのデプロイや再構成を行うなど、コントロール プレーンに追加の役割が必要になる場合があります。 ソリューションのコントロール プレーンでは、Azure Resource Manager や Kubernetes のコントロール プレーンなど、ユーザーが使用しているサービスとテクノロジのコントロール プレーンとの対話がおそらく必要になります。
より高度なコントロール プレーンでは、より多くの役割を担う可能性があります。
- 自動メンテナンス操作の実行。 一般的なメンテナンス操作には、古いデータの削除またはアーカイブ、データベース インデックスの作成と管理、シークレットと暗号化証明書のローテーションが含まれます。
- テナントを既存のデプロイまたはスタンプに割り当てます。これは "テナント配置" と呼ばれることもあります。
- デプロイ スタンプ間で既存のテナントを再調整します。
- Microsoft Dynamics 365 などの外部の顧客管理ソリューションと統合して、顧客のアクティビティを追跡します。
コントロール プレーンのスコープ設定
ソリューションのためのコントロール プレーンの構築にどれだけの労力を費やすかを慎重に検討する必要があります。 コントロール プレーン自体では顧客の価値がすぐには得られないため、高品質のコントロール プレーンの設計と構築にエンジニアリングの労力を費やすことを正当化することは簡単ではない可能性もあります。 ただし、システムが成長して規模が拡大するのに伴い、成長に対応するために自動化された管理と運用がますます必要になります。
状況によっては、完全なコントロール プレーンが必要ない場合があります。 この状況は、システムのテナントが 5 つ未満の場合に当てはまることがあります。 その場合、コントロール プレーンの役割をチームが引き受け、手動の操作とプロセスを使ってテナントのオンボードと管理を行うことができます。 ただし、テナントとその構成を追跡するためのプロセスと一元的な場所がやはり必要です。
ヒント
完全なコントロール プレーンを作成しないことにした場合でも、管理手順について体系的にしておくことをお勧めします。
- プロセスを詳細に文書化します。
- 可能な限り、管理操作用のスクリプトを作成して再利用します。
今後プロセスを自動化する必要がある場合は、そのドキュメントとスクリプトによってコントロール プレーンの基礎を形成することができます。
少数のテナントから増加していくにつれて、各テナントを追跡し、リソースとテナント全体を監視する方法を持つことからメリットが得られるようになるでしょう。 また、チームがテナント管理に費やす時間と労力が増えることにも気付くかもしれません。 または、チーム メンバーが管理タスクを行う方法に不整合があるため、バグや運用上の問題に気付くこともあります。 このような状況が発生した場合は、これらの役割を引き受けるために、より包括的なコントロール プレーンを構築することを検討する価値があります。
注意
セルフサービスのテナント管理を行う場合は、工程の早い段階でコントロール プレーンが必要です。 基本的なコントロール プレーンを作成し、最も一般的に使用される機能の一部のみを自動化することもできます。 時間の経過とともに機能を徐々に追加できます。
コントロール プレーンを設計する
コントロール プレーンの要件とスコープを決定したら、それを設計して構築する必要があります。 コントロール プレーンは重要なコンポーネントです。 システムの他の要素を計画する場合と同様に、慎重に計画する必要があります。
適切に設計されたコントロール プレーン
コントロール プレーンは独自のシステムであるため、設計するときは、Azure Well-Architected Framework の 5 つの柱すべてを考慮することが重要です。 次のセクションでは、注目すべき特定の領域について説明します。
[信頼性]
多くの場合、コントロール プレーンはミッション クリティカルなコンポーネントです。 コントロール プレーンに必要な回復性と信頼性のレベルを計画することが不可欠です。
コントロール プレーンが使用できない場合に何が起きるかを検討してください。 極端なケースでは、コントロール プレーンが停止すると、ソリューション全体が使用できなくなる可能性があります。 コントロール プレーンが単一障害点でない場合でも、障害が発生すると、次のような影響が生じる可能性があります。
- システムで新しいテナントをオンボードできないため、売上とビジネスの成長に影響するおそれがある。
- システムで既存のテナントを管理できないため、サポート チームの呼び出しが増える。
- テナントの使用量の測定や使用量に対する課金ができないため、収益が失われる。
- テナントの無効化や再構成によってセキュリティ インシデントに対応することができない。
- メンテナンス負債が蓄積され、システムへの長期的な損害が生じる。 たとえば、ソリューションで古いデータを夜間にクリーンアップする必要がある場合、ディスクがいっぱいになり、パフォーマンスが低下する可能性があります。
可用性ターゲット、目標復旧時間 (RTO)、目標復旧ポイント (RPO) など、コントロール プレーンのサービス レベルの目標を定義します。 コントロール プレーンに設定する目標は、顧客に提供する目標とは異なる場合があります。
コントロール プレーンを含め、システム全体で信頼性の高いソリューションを構築するための Azure Well-Architected フレームワークのガイダンスに従ってください。
セキュリティ
多くの場合、コントロール プレーンは高い特権を持つシステムです。 コントロール プレーン内のセキュリティの問題は、致命的な結果をもたらすおそれがあります。 設計と機能によっては、コントロール プレーンは次のようなさまざまな種類の攻撃に対して脆弱になる可能性があります。
- コントロール プレーンでは、すべてのテナントのキーとシークレットにアクセスできる場合があります。 コントロール プレーンにアクセスできる攻撃者は、テナントのデータまたはリソースにアクセスできる可能性があります。
- 多くの場合、コントロール プレーンでは新しいリソースを Azure にデプロイできます。 攻撃者はコントロール プレーンを悪用して独自のリソースをサブスクリプションにデプロイし、多額の料金を発生させることができる可能性があります。
- 攻撃者がコントロール プレーンをオフラインにすることに成功した場合、システムとビジネスに緊急の損害と長期的な損害が生じる可能性があります。 コントロール プレーンが使用できない場合の結果の例については、「信頼性」を参照してください。
コントロール プレーンを設計して実装するときは、セキュリティのベスト プラクティスに従い、ソリューションの潜在的な脅威とセキュリティの問題を文書化して軽減するための包括的な脅威モデルを作成することが不可欠です。 詳細については、安全なソリューションを構築するための Azure Well-Architected フレームワークのガイダンスを参照してください。
オペレーショナル エクセレンス
コントロール プレーンは重要なコンポーネントであるため、運用環境での展開と運用方法を慎重に検討する必要があります。
ソリューションの他の部分と同様に、コントロール プレーンの非運用インスタンスをデプロイして、その機能を十分にテストできるようにする必要があります。 コントロール プレーンでデプロイ操作を行う場合は、非運用のコントロール プレーンが Azure 環境とどのように相互作用するのか、および非運用リソースをどの Azure サブスクリプションにデプロイするのか検討してください。
また、コントロール プレーンへのチームのアクセスを管理する方法も計画する必要があります。 チーム メンバーが職務を遂行するために必要なアクセス許可のみ付与するベスト プラクティスに従います。 このアプローチはセキュリティ インシデントを回避するのに役立つだけでなく、誤った構成の影響を軽減するのに役立ちます。
コンポーネント
コントロール プレーンの唯一のテンプレートはなく、設計して構築するコンポーネントは要件によって異なります。 一般に、コントロール プレーンは API とバックグラウンド ワーカー コンポーネントで構成されます。 一部のソリューションでは、コントロール プレーンにユーザー インターフェイスが含まれる場合もあります。
コントロール プレーンをテナント ワークロードから分離する
コントロール プレーンのリソースを、テナントのデータ プレーンへの提供に使用されるリソースから分離することをお勧めします。 たとえば、データベース サーバー、アプリケーション サーバー、Azure App Service プラン、およびその他のコンポーネントを別々に使用することを検討してください。 多くの場合、コントロール プレーンのリソースは、テナント固有のリソースを含むものとは別の Azure リソース グループに保持することをお勧めします。
テナントのワークロードからコントロール プレーンを分離することで、いくつかの利点が得られます。
- スケーリングを別々に構成できます。 たとえば、コントロール プレーンのリソース要件は一貫していて、テナントのリソースはニーズに応じて弾力的に拡大縮小する場合があります。
- コントロール プレーンとデータ プレーンの間にはバルクヘッドがあり、うるさい隣人の問題がソリューションのプレーンをまたいで広がらないようにするのに役立ちます。
- コントロール プレーンは通常、高レベルのアクセス権を有する高い特権を持つシステムです。 コントロール プレーンをデータ プレーンから分離することで、セキュリティの脆弱性により、攻撃者がシステム全体でアクセス許可を昇格させる可能性が低くなります。
- 別々のネットワーク構成とファイアウォール構成をデプロイできます。 データ プレーンとコントロール プレーンでは通常、異なる種類のネットワーク アクセスが必要です。
実行時間の長い操作のシーケンスを調整する
コントロール プレーンが実行する操作は、多くの場合で実行時間が長く、複数のシステム間の調整が必要です。 操作には、複雑な障害モードが含まれることもあります。 コントロール プレーンを設計するときは、実行時間の長い操作やワークフローを調整するための適切なテクノロジを使用することが重要です。
たとえば、新しいテナントをオンボードするとき、コントロール プレーンで次のアクションが順番に実行されるとします。
- 新しいデータベースをデプロイする。 このアクションは、Azure のデプロイ操作です。 これは完了までに数分かかる場合があります。
- テナント メタデータ カタログを更新する。 このアクションでは、Azure SQL データベースにコマンドを実行することが必要な場合があります。
- 新しいテナントにウェルカム メールを送信する。 このアクションでは、電子メールを送信するサードパーティの API が呼び出されます。
- 新しいテナントへの請求書を準備するために課金システムを更新する。 このアクションでは、サードパーティの API が呼び出されます。 断続的に失敗することがわかります。
- 新しいテナントを追跡するためにカスタマー リレーションシップ マネジメント (CRM) システムを更新する。 このアクションでは、サードパーティの API が呼び出されます。
シーケンスのいずれかの手順が失敗した場合、次のような処理を検討する必要があります。
- 失敗した操作を再試行します。 たとえば、手順 2 の Azure SQL コマンドが一時的なエラーで失敗した場合は、再試行できます。
- 次の手順に進みます。 たとえば、営業チームが手動で顧客を追加するため、課金システムの更新が失敗した場合は許容できると判断される場合もあります。
- ワークフローを破棄し、手動の回復プロセスをトリガーします。
また、障害シナリオごとにユーザー エクスペリエンスがどのようになるかを考慮する必要があります。
共有コンポーネントの管理
コントロール プレーンでは、特定のテナント専用のコンポーネントではなく、共有されているコンポーネントを認識する必要があります。 コンポーネントの中には、スタンプ内のすべてのテナント間で共有されるものもあれば、 リージョン内のすべてのスタンプ間で共有されるものもあります。さらに、すべてのリージョンおよびスタンプ間でグローバルに共有されるものもあります。 テナントがオンボード、再構成、またはオフボードされるたびに、コントロール プレーンでは、これらの共有コンポーネントを使用して何をすべきかを把握する必要があります。
一部の共有コンポーネントでは、テナントが追加または削除されるたびに再構成が必要になる場合があります。 たとえば、グローバルに共有されている Azure Front Door プロファイルがあるとします。 カスタム ドメイン名を持つテナントを追加する場合、コントロール プレーンでプロファイルの構成を更新して、そのドメイン名の要求を正しいアプリケーションにルーティングすることが必要になる場合があります。 同様に、テナントがオフボードされている場合は、サブドメイン乗っ取り攻撃を回避するために、コントロール プレーンで Azure Front Door プロファイルからカスタム ドメイン名を削除することが必要になる場合があります。
共有コンポーネントには、コントロール プレーンで従う必要のある複雑なスケーリング ルールが含まれる場合があります。 たとえば、ビン パッキングのアプローチに従ってテナントのデータベースをデプロイするとします。 新しいテナントがオンボードされたら、そのテナント用の新しい Azure SQL データベースを追加してから、それを Azure SQL エラスティック プールに割り当てます。 データベースを 10 個追加するごとに、プールに割り当てられたリソースを増やす必要があると判断したことがあるかもしれません。 テナントを追加または削除する際は、コントロール プレーンでプールの構成を再評価し、プールのリソースを変更するかどうかを決定する必要があります。 単一のエラスティック プールに割り当てられるデータベースの最大数に達したら、新しいプールを作成して、そのプールを新しいテナント データベースに使用する必要があります。 コントロール プレーンに求められる責務は、これらの共有コンポーネントのそれぞれを管理し、何かが変更されるたびにそれらをスケーリングおよび再構成することです。
コントロール プレーンで共有コンポーネントを管理する場合に重要なのは、複数の操作が並列で行われる場合に発生する可能性がある競合状態に注意することです。 たとえば、別のテナントにオフボードするのと同時に新しいテナントをオンボードする場合は、最終的な終了状態に一貫性があり、スケーリング要件が満されていることを確認する必要があります。
複数のコントロール プレーンを使用する
複雑な環境では、複数のコントロール プレーンを使用し、それぞれに異なる役割領域を持たせることが必要な場合もあります。 多くのマルチテナント ソリューションでは、デプロイ スタンプ パターンと複数のスタンプにわたるテナントのシャード化に従います。 このパターンを使用する場合、グローバルとスタンプの役割に対して別々のコントロール プレーンを作成することがあります。
ヒント
複数のコントロール プレーン間での調整は複雑なため、構築するコントロール プレーンの数を最小限に抑えるようにしてください。 ほとんどのソリューションでは、必要なコントロール プレーンは 1 つだけです。
グローバル コントロール プレーン
グローバル コントロール プレーンは通常、テナントの全体的な管理と追跡を担当します。 グローバル コントロール プレーンには、次の役割があります。
- テナントの配置。 グローバル コントロール プレーンでは、テナントで使用されるスタンプが決定されます。 この決定は、テナントのリージョン、各スタンプの容量使用率、テナントのサービス レベルの要件などの要因に基づいて下される場合があります。
- テナントのオンボードとライフサイクル管理。 これらの役割には、すべてのデプロイにわたるすべてのテナントの追跡が含まれます。
スタンプ コントロール プレーン
スタンプ コントロール プレーンは、各デプロイ スタンプにデプロイされ、そのスタンプに割り当てられたテナントとリソースを担当します。 スタンプ コントロール プレーンには、次の役割があります。
- データベースやストレージ コンテナーなど、スタンプ内でのテナント固有のリソースの作成と管理
- 共有リソースの使用量の監視や最大容量に近づいている場合の新しいインスタンスのデプロイなどの、共有リソースの管理
- データベース インデックス管理やクリーンアップ操作など、スタンプ内でのメンテナンス操作の実行
各スタンプのコントロール プレーンは、グローバル コントロール プレーンと連携しています。 たとえば、新しいテナントがサインアップするとします。 グローバル コントロール プレーンは最初に、テナントのリソースのスタンプを選択する役割を担います。 次に、グローバル コントロール プレーンでは、テナントに必要なリソースを作成するようにスタンプのコントロール プレーンに求めます。
次の図は、2 つのコントロール プレーンが 1 つのシステムに共存する方法の例を示しています。
テナント コントロール プレーン
テナントでは、独自の論理リソースまたは物理リソースを管理するために、テナント レベルのコントロール プレーンを使用する場合があります。 テナント コントロール プレーンには、次の役割があります。
- ユーザー アクセスなど、テナント固有の構成の管理
- データのバックアップや以前のバックアップのダウンロードなど、テナントによって開始されるメンテナンス操作
- アプリケーションに対する独自の更新を制御できるようテナントに許可する場合は、更新管理
次の図は、グローバル コントロール プレーン、スタンプ コントロール プレーン、および各テナントのコントロール プレーンを持つ複雑なシステムを示しています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
その他の共同作成者:
- Mick Alberts | テクニカル ライター
- Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
- Landon Pierce | FastTrack for Azure のカスタマー エンジニア
- Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。