Azure でマルチテナント ソリューションを設計および構築するためのチェックリスト

Azure でマルチテナント ソリューションを構築するときは、考慮する必要がある要素がいくつもあります。 このチェックリストを出発点として使用し、マルチテナント ソリューションの設計と構築に役立ててください。 このチェックリストは、 Azure でのマルチテナント ソリューションの設計 に関する記事シリーズの関連リソースです。 チェックリストは、ビジネス面と技術面での考慮事項と、 Azure Well-Architected フレームワークの 5 つの柱を中心に構成されています。

ヒント

このチェックリストを確認した後、 SaaS 体験レビュー を通じて、マルチテナント アーキテクチャと、SaaS 運用のベスト プラクティスとの整合性に関する理解を分析して、お使いの SaaS 製品を評価してください。

ビジネスに関する考慮事項

• 企業間 (B2B)、企業-消費者間 (B2C)、エンタープライズ ソフトウェアなど、作成しているソリューションの種類、および テナントとユーザーの違いについて理解します。
• テナントを定義します。 最初にサポートするテナントの数と、成長計画について理解します。
• 価格モデルを定義 し、 テナントによる Azure リソースの消費と位置していることを確認します。
• テナントを異なる レベルに分ける必要があるかどうかを把握します。 レベルには、価格、機能、パフォーマンスの保証、地理的な場所などの違いがある場合があります。
• 顧客の要件に基づいて、ソリューションのさまざまな部分に適した テナント モデル を決定します。
• 準備ができたら、 Microsoft コマーシャル マーケットプレースを使って B2B マルチテナント ソリューションを販売します。

信頼性に関する考慮事項

• すべてのワークロードに適用される Azure Well-Architected の信頼性のチェックリストを確認します。
• うるさい隣人のアンチパターンを理解します。 個々のテナントが他のテナントのシステムの可用性に影響を与えないようにします。
• 予想される成長のレベルに対応するマルチテナント ソリューションを設計 します。 ただし、非現実的な成長に対応する過剰な設計にならないようにします。
• ソリューションのサービスレベルの目標 (SLO) と、必要に応じてサービス レベル アグリーメント (SLA) を定義します。 SLA と SLO は、テナントの要件に基づく必要があります。
• ソリューションの スケーリング をテストします。 すべてのレベルの負荷の下で適切に動作すること、およびテナント数の増加に応じて正しくスケーリングされることを確認します。
• カオス エンジニアリングの原則 を適用して、ソリューションの信頼性をテストします。

セキュリティに関する考慮事項

• ソリューションのすべてのレイヤーに、 ゼロ トラスト と最小特権の原則を適用します。
• テナントに ユーザー要求を正しくマップできる ことを確認します。 ID システムの一部として、またはアプリケーション レベルのテナント認可などの別の手段を使って、テナントのコンテキストを含めることを検討します。
• テナントの分離に対応するように設計します。 継続的に 分離モデルをテストします。
• アプリケーションのコードでテナント間のアクセスまたはデータ漏えいが防止されていることを確認します。
• 継続的な侵入テストとセキュリティ コード レビューを実施します。
• データ所在地および満たす必要のあるコンプライアンスや規制の基準など、テナントの コンプライアンス要件を把握します。
• 正しく ドメイン名を管理 し、 ダングリング DNS やサブドメイン乗っ取り攻撃などの脆弱性を回避します。
• マルチテナントに関する サービス固有のガイダンス に従います。

コストの最適化に関する考慮事項

• すべてのワークロードに適用される Azure Well-Architected のコスト最適化のチェックリストを確認します。
• 適切に テナントごとの使用量を測定 し、それを インフラストラクチャのコストと関連付けることができることを確認します。
• アンチパターンを回避します。 アンチパターンには、コストの追跡の失敗、不要な精度でのコストの追跡、リアルタイム測定、課金用の監視ツールの使用が含まれます。

オペレーショナル エクセレンスに関する考慮事項

• オートメーションを使用して、オンボード、 デプロイ、プロビジョニング、構成などの、 テナントのライフサイクルを管理します。
• マルチテナント ソリューションの コントロール プレーン とデータ プレーンの違いを理解します。
• サービスの更新プログラムのデプロイに関して適切なバランスを見つけます。 テナントの要件と独自の運用要件の両方を考慮します。
• システム全体と各テナントの正常性を監視します。
• 特定のテナントで問題が発生したとき、または使用制限を超えたときに通知するアラートを構成してテストします。
• 分離とスケーリングのために Azure リソースを整理 します。
• デプロイと構成のアンチパターンを回避します。 アンチパターンには、テナントごとに異なるバージョンのソリューションの実行、テナント固有の構成やロジックのハードコーディング、手動でのデプロイが含まれます。

パフォーマンスの効率に関する考慮事項

• すべてのワークロードに適用される Azure Well-Architected のパフォーマンスの効率のチェックリストを確認します。
• 共有インフラストラクチャを使用する場合は、 うるさい隣人 の問題を軽減する方法を計画します。 1 つのテナントが他のテナントのシステムのパフォーマンスを低下させることができないようにします。
• コンピューティング、 ストレージ、 ネットワーク、および他の Azure リソースをテナントの需要に合わせてスケーリングする方法を決定します。
• 各 Azure リソースのスケーリング制限を考慮します。 リソース組織のアンチパターンを回避するため、適切にリソースを整理 します。 たとえば、非現実的なスケーリング要件で動作するようにソリューションを過剰に設計することがないようにします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Arsen Vladimirskiy | プリンシパル カスタマー エンジニア
• Bohdan Cherchyk | シニア カスタマー エンジニア

その他の共同作成者:

• John Downs | プリンシパル ソフトウェア エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• マルチテナント ソリューションのアーキテクチャに関する考慮事項を確認します。
• マルチテナントのアーキテクチャ アプローチを確認します。
• マルチテナントに関するサービス固有のガイダンスを確認します。
• その他の マルチテナント ソリューションの設計者と開発者向けのリソースを確認します。