マルチテナント ソリューションのコントロール プレーンのアーキテクチャに関するアプローチ
コントロール プレーンは、サービスとしてのソフトウェア (SaaS) およびマルチテナント ソリューションの重要な部分であり、特に大規模にソリューションを管理する場合に重要です。 通常、コントロール プレーンを構成するのは以下の 2 つの主要なコンポーネントです。
- テナント カタログは、テナントに関する以下のような重要な情報を保存します。
- テナント構成。
- テナント リソース用にデプロイされた SKU。
- どのデプロイ スタンプにテナントが割り当てられているか。
- テナント ライフサイクル イベントによってトリガーされる環境への変更を管理するためのプロセス。 たとえば、テナントのオンボード、テナントのオフボード、何らかの必要な定期的メンテナンスなどです。
コントロール プレーン自体が 1 つのアプリケーションです。 コントロール プレーンを慎重に検討し、ソリューションの他の部分で使用するのと同じ厳格さと注意を払ってこれを設計する必要があります。 コントロール プレーンとは何か、コントロール プレーンを使用するべき理由、およびコントロール プレーンの設計に関する考慮事項の詳細については、「マルチテナント コントロール プレーンの考慮事項」を参照してください。
この記事では、コントロール プレーンの設計および作成のために検討できるいくつかのアプローチについて説明します。 ここで説明されるアプローチのリストは包括的なものではありません。 これらのアプローチはすべて有効ですが、他にも有効なアーキテクチャがあります。
考慮すべきアプローチとパターン
次の表は、コントロール プレーン用に検討できるいくつかのアプローチの違いをまとめたものです。 手動、ローコード、カスタムのアプローチが比較されています。
| 考慮事項 | 手動 | ローコード | Custom |
|---|---|---|---|
| 運用上のオーバーヘッド | 高 | 低から中 | 低 |
| アプローチが適しているライフサイクル イベントの頻度 | レア | 時々から頻繫 | 頻繁に |
| 実装するための時間と複雑さ | 低 | Medium | 高 |
| コントロール プレーンのメンテナンスの責任 | 低 | Medium | 高 |
| Testability | 低 | Medium | 高 |
| 不整合のリスク | 高 | 中から低 | 低 |
手動プロセス
完全に自動化されたコントロール プレーンを構築することがいつでも必須なわけではありません。特に、始めたばかりの頃でテナントの数が少ない場合はそうです。
テナント カタログは、チームがアクセスできる場所に保存されている Excel ブックや JSON ファイル内など、どこかに一元的に配置できます。 形式はなんであれ、プログラムを使用してデータを簡単に操作できるように、構造化された方法で情報を保存するのが良い考え方です。
Note
手動コントロール プレーンは、マルチテナント アプリケーションの管理を開始するための優れた方法ですが、少数のテナント (5 から 10 未満) にのみ適しています。 手動でテナントをオンボードする度に管理オーバーヘッドと不整合のリスクは増大します。 このアプローチは、テナントが少数で、自動またはセルフサービスのオンボードが不要な場合にのみ使用するべきです。
テナント オンボーディングなどのプロセスやメンテナンス アクティビティのために:
- 手動で実行するとしても、可能な限りスクリプトや自動パイプラインを作成します。 スクリプトやパイプラインを使用することで、手順が各テナントに対して一貫して実行されるようにします。
- 最初からスクリプト化できないタスクに対しては、そのプロセスを徹底的かつ詳細がわかりやすいように文書化します。 "方法" だけでなく "理由" も文書化します。 誰かが将来タスクを自動化することになった場合、その人物はこれら両方について十分に理解している必要があります。
次の図は、初期のコントロール プレーンに手動プロセスを使用する 1 つの方法を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
手動アプローチの利点
- 軽量: ドキュメント、スクリプト、パイプラインは簡単に開発および変更できます。 これらは素早く反復処理して改善できるため、この利点によって、これらはプロセスを把握するときに適切となります。
- 低コスト: 手動アプローチの保守と実行は安価です。
- プロセスの検証: 最終的にはより自動化されたアプローチを使用する予定である場合でも、概念実証として手動アプローチから始めることは、より堅牢な自動化の開発に時間を投資する前にメンテナンス戦略を検証する良い方法です。
手動アプローチの欠点
- 制御の欠如: このアプローチは、すべての関係者に依存して正しいことを行います。 誰かが誤って、または意図的に、規定されたプロセスから逸脱する可能性があります。 プロセス内のどんな変更も、環境内の不整合のリスクを高め、継続的な管理を非常に困難にします。
- アクセス制御の課題: このアプローチを使用する場合は、通常、ソリューションを運用する誰かに広いスコープで非常に権限の大きいアクセス権を付与する必要があります。これにより、アクセスのセグメント化に関するベスト プラクティスに従うのが困難になります。
- スケーラビリティ: 手動プロセスの実行に必要な作業は、管理する必要があるテナントの数に応じて大きくなります。
- テスト容易性: 手動プロセスは検証とテストが困難です。
手動アプローチからの移行を検討するべきタイミング
- チームがアプリケーションの保守のために行う必要がある作業量に対応できない場合。 たとえば、テナントの数が限界点 (これはほとんどのチームにとって 5 から 10 テナントの間にあります) を超えて多くなった場合。
- テナントの限界数を超えるテナントの増加が予想され、その数のテナントの管理に関連する作業に備える必要がある場合。
- 不整合のリスクを軽減する必要がある場合。 たとえば、誰かがプロセスに正しく従っていなかったり、プロセスにあいまいさが多すぎるために、いくつかの間違いが発生しているのに気付く場合があります。 通常、手動でオンボーディングされるテナントが増えるにつれて、また、チームが成長するにつれて、不整合のリスクが高まります。
ローコード コントロール プレーン
ローコードまたはノーコードのコントロール プレーンは、ビジネス プロセスの自動化と情報の追跡を目的として設計されたプラットフォーム上に構築されます。 カスタム コードを記述せずにこれらのタスクを実行できるプラットフォームは多数あります。
Microsoft Power Platform は、これらのプラットフォームの 1 つの例です。 Power Platform を使用する場合は、Dynamics 365、Dataverse、または Microsoft 365 内にテナント カタログを保持できます。 最初からすべてを自動化する必要がない場合は、手動プロセスで使用しているのと同じテナント カタログを保持することも検討できます。
テナントのオンボーディングとメンテナンスでは、Power Automate を使用して、テナントの管理、テナントの構成、パイプラインまたは API 呼び出しのトリガーなどを行うワークフローを実行できます。 Power Automate がアクセスできる場所にデータがある場合は、Power Automate を使用してテナント カタログに対する変更を監視できます。 手動テナント カタログを使用する場合は、Power Automate ワークフローを手動でトリガーすることもできます。 チームの誰かが何かを検証したり完全に自動化できない追加手順を実行したりする必要がある場合は、ワークフローに手動の承認手順を含めるようにすることができます。
この方法では、Web アプリケーションが人間の介入なしにテナント カタログに直接レコードを追加できるようにすることで、顧客にセルフ サービス サインアップを提供することもできます。
次の図は、Microsoft Power Platform を使用することでセルフサービス サインアップを備えたコントロール プレーンを作成する方法を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
ローコード アプローチの利点
- 軽量: ローコードで一連のワークフローを作成し、周囲のシステムに接続するのは、多くの場合、迅速かつ低コストです。
- プラットフォーム ツールの使用: ネイティブ プラットフォーム機能を使用してデータを保存し、チームが使用する管理ポータルを作成し、実行時にワークフローを監視することができます。 ネイティブのプラットフォーム機能を使用することで、多くのコンポーネントを自分で構築する必要がなくなります。
- カスタマイズ可能: より多くのカスタマイズが必要な場合は、通常、カスタム コードおよびプロセスを使用してワークフローを拡張できます。 たとえば、Power Automate を使用して GitHub Actions のデプロイ ワークフローをトリガーしたり、Azure Functions を呼び出して独自のコードを実行したりできます。 これは段階的な実装を容易にするのにも役立ちます。
- 低オーバーヘッド: ローコード サービスは通常、フル マネージドであるため、インフラストラクチャを管理する必要がありません。
ローコード アプローチの欠点
- 専門知識の必要性: ローコード プラットフォームを使用してプロセスを作成し、これらのプラットフォームを効果的に使用するには、通常、専門知識が必要です。 多くの組織は既にこれらのツールを使用しているため、チームには必要な専門知識が既にあるかもしれませんが、そうでない場合もあります。 これらのプラットフォームを効果的に使用するためにチームをトレーニングする必要があるかどうかを検討する必要があります。
- 管理: 大量のローコード構成の管理を行うのは困難な場合があります。
- テスト容易性: コントロール プレーンへの変更をテストして昇格させる方法を検討します。 マネージド プラットフォームでは、変更が通常はコードを通してではなく構成を通して行われるため、変更のテストおよび昇格のための一般的な DevOps プロセスを作成することはより困難です。
- 設計: セキュリティや信頼性などの非機能要件を満たす方法を慎重に検討します。 これらの要件は、多くの場合、ローコード プラットフォームで自動で管理されます。
ローコード アプローチからの移行を検討するタイミング
- 最終的には、要件が非常に複雑になり、要件をローコード ソリューションに適切に組み込むことができなくなる場合があります。 ニーズを満たすためにツールの制限を回避する必要が生じている場合、おそらくマネージド ソリューションから離れてカスタム コントロール プレーンに移行することが理にかなっています。
カスタム コントロール プレーン
独自の完全にカスタマイズされたコントロール プレーンの作成を検討することもできます。 この選択肢は、最大の柔軟性とパワーを提供しますが、最も多くの作業が必要でもあります。 通常、テナント カタログはデータベースに保存されます。 この場合はカタログを直接操作するのではなく、管理インターフェイスを通してそれを管理します。管理インターフェイスは、カスタム アプリケーションや、組織の顧客関係管理 (CRM) アプリケーションのようなシステムである可能性があります。
通常、すべてのテナント管理機能を中心に設計されたコントロール プレーン コンポーネントのセットを作成します。 これらのコンポーネントには、管理ポータルまたはその他のユーザー インターフェイス、API、およびバックグラウンド処理コンポーネントが含まれる場合があります。 テナント ライフサイクル イベントが発生したときにコードやインフラストラクチャのデプロイなどを行う必要がある場合は、デプロイ パイプラインによってコントロール プレーンが構成される場合もあります。
実行時間の長いすべての処理が適切なツールを使用するようにします。 たとえば、テナントのオンボードまたはデプロイのオーケストレーションを行うコンポーネント、または外部システムと通信する必要があるコンポーネントには、Durable Functions または Azure Logic Apps を使用できます。
ローコード アプローチと同様に、このアプローチでは、Web アプリケーションが人間の介入なしにテナント カタログにレコードを直接追加できるようにすることで、顧客にセルフサービス サインアップを提供できます。
次の図は、セルフサービス サインアップを提供する基本的なカスタム コントロール プレーンを作成する 1 つの方法を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
カスタム アプローチの利点
- 完全な柔軟性とカスタマイズ性: コントロール プレーンが行うことを完全に制御するので、要件が変化した場合にそれを変更できます。
- テスト容易性: コントロール プレーン アプリケーションに標準のソフトウェア開発ライフサイクル (SDLC) を使用して、メイン アプリケーションに対して行うのと同様に、テストとデプロイの通常のアプローチを実装できます。
カスタム アプローチの欠点
- メンテナンスの責任: このアプローチでは、すべてを自分で作成する必要があるため、より多くのメンテナンス オーバーヘッドが必要です。 コントロール プレーンは、アプリケーションの他の部分と同じくらい重要です。 コントロール プレーンの信頼性とセキュリティを確保するには、開発、テスト、運用に細心の注意を払う必要があります。
ハイブリッド アプローチ
ハイブリッド アプローチの使用を検討することもできます。 手動システムと自動システムを組み合わせて使用することも、Microsoft Power Platform などのマネージド プラットフォームを使用してカスタム アプリケーションでそれを拡張することもできます。 カスタム コントロール プレーンのカスタマイズ性が必要だが、完全なカスタム システムの構築と維持は望まない場合は、ハイブリッド アプローチの実装を検討してください。 ある時点で、手動プロセスまたはマネージド プラットフォームに対する自動化されたカスタマイズは、完全にカスタマイズされたシステムと同じくらい複雑になる可能性があることに注意してください。 転換点は組織によって異なりますが、ハイブリッド アプローチの維持が煩雑になる場合は、完全なカスタム システムへの移行を検討する必要があります。
段階的な実装
コントロール プレーンを最終的に自動化する必要があることがわかっている場合でも、必ずしもそのアプローチから始める必要はありません。 アプリケーションの作成の初期段階における一般的なアプローチは、手動コントロール プレーンから始めることです。 アプリケーションが進化し、より多くのテナントをオンボードするようになったら、ボトルネックの領域を特定し、必要に応じてそれらを自動化することを開始し、ハイブリッド アプローチに移行する必要があります。 自動化が増えながら最終的には完全に自動化されたコントロール プレーンが得られます。
回避すべきアンチパターン
- あまりにも長く手動プロセスに頼ること。 始めたばかりのときやテナントの数が少なくて必要な管理がかなり少ない場合は手動プロセスを使用するのが妥当ですが、成長に合わせて自動化されたソリューションにスケーリングする方法を計画する必要があります。 手動プロセスの需要に対応するためにチーム メンバーを追加雇用する必要があるなら、それはコントロール プレーンの一部を自動化し始めるべき良いタイミングだと考えられます。
- 実行時間の長いワークフローに不適切なツールを使用すること。 たとえば、Azure Resource Manager デプロイやマルチステップ オーケストレーションなどの実行時間の長い操作を実行するために、標準 Azure 関数、同期 API 呼び出し、または実行時間の制限があるその他のツールを使用することは防ぎます。 代わりに、Azure Logic Apps や Durable Functions など、実行時間の長いワークフローや一連の操作を実行できるツールを使用します。 詳細については、「Azure Functions のパフォーマンスと信頼性」および「非同期要求応答パターン」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Landon Pierce | カスタマー エンジニア
その他の共同作成者:
- Mick Alberts | テクニカル ライター
- Bohdan Cherchyk | シニア カスタマー エンジニア
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア