次の方法で共有

Azure での SaaS ワークロードのリソースの編成

  • [アーティクル]

サービスとしてのソフトウェア (SaaS) ソリューションを作成する場合、Azure リソースを編成する方法は、運用プロセス、セキュリティ、規制基準への準拠に大きく影響する可能性があります。

この記事では、リソースに適した Azure リージョンを選択し、SaaS ソリューションの成長と進化をサポートするリソースの編成戦略を開発する方法について説明します。

リージョンの選択と複数リージョンのソリューション

アーキテクチャを計画する最初の手順は、環境が存在するリージョンを選択することです。 Azure リソースは、Azure データセンターの物理的な場所であるリージョンにデプロイされます。 顧客のデータ所在地の要件、およびパフォーマンス、サービスの可用性、スケーリングのニーズを満たすリージョンを選択してください。 グローバルな顧客をサポートし、回復性を強化するために、SaaS ソリューションを複数のリージョンにデプロイすることを検討してください。

設計上の考慮事項

  • 運用に最適なリージョンを評価します。 一部の Azure リージョンは、その他のリージョンよりも多くのサービスを提供しています。 また、多くの Azure リージョンは、データセンターの障害に耐えるために可用性ゾーンをサポートしています。これは、回復性戦略の重要な部分です。 可用性ゾーンがあるリージョンを使用し、運用コンポーネントを複数の可用性ゾーン内にデプロイする必要があります。 各リージョンで利用可能なサービスを確認するには、「リージョン別の利用可能な製品」を参照してください。

    「RE:05 可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

  • データ所在地の要件を設計します。 データ主権に関する法律のため、たいていは、顧客データを格納できる場所に関する要件が存在する場合があります。 要件は、ヨーロッパなどの広範な地理的領域から特定の国や地域まで、多岐にわたる場合があります。 Azure では、地政学的境界に基づいて地域を定義します。通常は、定義された地域内の任意のリージョンを使用して、データ所在地の要件を満たすことができます。

    Azure リージョンのサポートについては、｢Azure の地域」を参照してください。

  • 待機時間の最小化。 顧客とユーザーに近いリージョン選択します。 グローバルな顧客の場合は、異なるリージョンに複数のインスタンスをデプロイします。 また、グローバル ロード バランサーを使用して、ユーザーに近いリージョンにトラフィックをルーティングし、ネットワーク トラフィックを高速化します。 Azure Front Door は、これらのシナリオにおける一般的な選択肢です。

  • 複数のリージョンにまたがってデプロイします。 複数リージョンにデプロイすると、回復性が高まり、グローバルな顧客に対して低遅延の接続がサポートされます。 また、この設計は、複雑なデータ所在地の要件を満たすのにも役立ちます。

    トレードオフ: 複数リージョンの設計は、リージョン間の冗長性のため、複雑でコストがかかる場合があります。 また、運用コストも増加します。

設計の推奨事項

推奨 特長
デプロイには、Azure が推奨するリージョンを使用します。 新しいリソースを作成するときに、推奨リージョンが Azure portal に一覧表示されます。

使用するリージョンが可用性ゾーンをサポートしていることを確認します。		 よりスケーラブルで回復性の高いソリューション設計をサポートできるようになります。
ニーズを満たすために必要なリージョンの最小数から開始し、必要に応じてデプロイします。 このアプローチは、設計と運用が過度に複雑にならないようにするのに役立ちます。
顧客のデータ所在地のニーズを早期に明確にします。 新しいリージョンへのデプロイには時間がかかる場合があります。 顧客から課される制約を把握するのが早いほど、そのニーズを満たす可能性が高くなります。

リソースの編成

Azure リソースは、さまざまな方法で編成できます。 リソース グループ、サブスクリプション、管理グループ、Microsoft Entra テナントの組み合わせを使用して、リソースをグループ化または分離できます。 リソースの編成戦略が異なると、管理の容易性、複雑さ、セキュリティ、その他多くの要因に関するさまざまなトレードオフが生じます。 SaaS ソリューションを作成する場合、リソースを編成する方法を検討する必要があります。 この決定には、テナント モデルから十分な情報が適用されます。 リソースの編成はおそらく、SaaS ソリューションの適切な設計、デプロイ、管理の最も基本的な部分です。

Azure リソースを編成する方法の詳細については、「Azure 基礎の概念」を参照してください。

設計上の考慮事項

  • ランディング ゾーンについて理解します。 ランディング ゾーンは、クラウドの占有領域の基本的な構成です。 これには、アクセス制御、課金戦略、ガバナンス手順が含まれています。 SaaS ソリューションは、ニーズの変化に応じて簡単に調整できるように、柔軟かつスケーラブルで、サブスクリプション間で一貫して構成されている必要があります。

    Azure ランディング ゾーンは、Azure 環境の推奨基本構成です。 独立系ソフトウェア ベンダー (ISV) 組織に固有のランディング ゾーンに関する推奨事項については、「Azure ランディング ゾーン の ISV に関する考慮事項」を参照してください。

  • 共有するリソースを決定します。 共有するコンポーネントと、顧客向けに個別にデプロイするコンポーネントを決定します。 リソースを共有すると、コストと管理労力が削減されますが、分離、セキュリティ、パフォーマンスのトレードオフにつながる可能性があります。 一般的には、共有コンポーネントと顧客ごとのコンポーネントを混在させます。 少なくとも、ID コンポーネントと課金コンポーネントは通常、顧客間で共有されます。

    トレードオフ: リソースを共有すると、コストと管理労力が削減されますが、分離、セキュリティ、パフォーマンスのトレードオフが生じる可能性があります。

    運用前のステージと環境では、共有運用リソースを使用しないでください。 運用環境でリソースを共有する場合でも、リソースの編成戦略では、リソースの並列デプロイに対応する必要があります。

  • Azure リソース クォータに対応可能な計画を立てます。 サブスクリプションまたはリージョンごとのリソースの数や時間枠内の要求制限など、Azure リソースのクォータと制限について理解します。 これらの制限に近づいている場合は、リソースの編成を適応させる戦略を選択します。

    Azure クォータおよび SaaS ソリューションに対するその影響の詳細については、「リソース制限」を参照してください。

  • デプロイ スタンプ パターンを適用します。 デプロイ スタンプ パターンは、さまざまな点で役立ちます。 デプロイ スタンプ パターンを使用すると、特定の顧客に専用のリソースをデプロイできるようになります。 また、デプロイ スタンプ パターンを使用して、顧客固有であるか共有であるかを問わず、複数の Azure リージョンに同じリソースをデプロイすることもできます。 さらに、スタンプを使用すると、顧客独自の Azure 環境にリソースをデプロイできます。これは、顧客がリソースを所有する必要がある場合に便利です。 この種のデプロイは、Azure Marketplace 経由でテンプレート化されたリソースを使用して実現します。

  • 運用プロセスをサポートします。 効果的なリソースの編成は、チームの運用に影響します。 たとえば、一貫した名前付けおよびタグ付け戦略は、診断、リソース管理、コスト管理に役立ちます。 適切な名前付けおよびタグ付け戦略は、特定の顧客に使用されるリソースをすばやく検索し、運用環境と非運用環境を区別するのに役立ちます。

    SaaS ソリューションには、新しい顧客のオンボーディングや去る顧客のオフボーディングなど、厳格な顧客ライフサイクル管理が必要です。 リソースの編成戦略では、顧客リソースの簡単な作成と削除および共有リソースの再構成を促進する必要があります。

  • Azure Marketplace を介して公開します。 ビジネス モデルとオファリングに Azure Marketplace との互換性がある場合は、そこでソリューションを公開することを検討します。 既存の SaaS ソリューションがあるか、シングルテナント ソリューションをマルチテナント SaaS に変換するかとは関係なく、Azure Marketplace を使用できます。

    Azure Marketplace では、課金、オンボーディング、オフボーディングがサポートされており、管理とアプリケーションへの顧客のアクセスが簡素化されます。 Azure Marketplace を使用する場合、機密性の高い課金情報や支払いプロバイダーを管理する必要はありません。

    顧客環境にデプロイする場合、Azure Marketplace を使用して Managed Applications をデプロイできます。これには、顧客の Azure サブスクリプション内でリソースをデプロイおよび管理できるさまざまな機能が用意されています。

設計の推奨事項

推奨 特長
デプロイするリソースの Azure クォータおよび制限を確認します。 制限に近づいている場合は、追加のリソースのデプロイ、ビン パッキング ガイダンスへの準拠、複数の Azure サブスクリプションの使用など、成長を続けるための戦略を選択します。 このアプローチを使用すると、制限内にどどまりながらスケーリングと拡張を行うことができます。
リソースの有効期間とライフサイクルを定義します。 共有リソースと顧客固有のリソースを区別します。 この戦略を使用すると、プロセスを事前に定義することで運用効率を向上させ、不要になったリソースを削除することでコスト効率を上げることができます。
特にソリューションを顧客環境にデプロイする場合は、Azure Marketplace を使用して公開することを検討してください。 Azure Marketplace には、課金の管理などの幅広いサービスが用意されています。
Mona for SaaS などのツールを利用して、Azure Marketplace との統合を最適化します。 再利用可能なコード モジュールとテンプレートを使用すると、デプロイと統合に必要な時間と労力を削減できます。 これらのツールを使用すると、Azure Marketplace で利用可能なソリューションを管理するのに役立ちます。

その他のリソース

マルチテナント機能は、SaaS ワークロードを設計するための主要なビジネス手法です。 次の記事では、リソースの編成について詳しく説明されています。

次のステップ

SaaS ワークロード環境での ID およびアクセス管理に関する設計上の考慮事項について説明します。

設計領域: Azure での SaaS ワークロードの ID およびアクセス管理