デプロイ スタンプ パターンは、複数のワークロードまたはテナントをホストおよび運用するためのリソースのグループをプロビジョニング、管理、監視します。 個々のコピー はスタンプと呼ばれ、 サービス ユニット、 スケール ユニット、 セルと呼ばれることもあります。 マルチテナント環境では、各スタンプは定義済みの数のテナントを提供します。 ソリューションをほぼ直線的にスケーリングし、増加するテナントにサービスを提供するために、複数のスタンプをデプロイします。 このアプローチにより、ソリューションのスケーラビリティを向上させ、複数のリージョンにインスタンスをデプロイし、顧客データを分離することができます。
注
詳細については、「 Azure でのマルチテナント ソリューションの設計」を参照してください。
コンテキストと問題
クラウドでアプリケーションをホストする場合は、アプリケーションのパフォーマンスと信頼性を考慮してください。 ソリューションの 1 つのインスタンスをホストする場合、次の制限が適用される場合があります。
スケールの制限: アプリケーションの 1 つのインスタンスが自然なスケーリング制限に達する可能性があります。 たとえば、使用するサービスでは、受信接続、ホスト名、伝送制御プロトコル (TCP) ソケット、またはその他のリソースの数が制限される場合があります。
非線形スケーリングまたはコスト: ソリューションのコンポーネントの一部は、要求の数やデータ量に比例してスケーリングされない場合があります。 代わりに、パフォーマンスが低下したり、しきい値を満たした後にコストが急増したりする可能性があります。 たとえば、データベースに容量を追加したり、スケールアップしたりすると、非常にコストがかかり、スケールアウトのコスト効率が高くなる場合があります。
顧客の分離: ある顧客のデータを別の顧客のデータから分離することが必要になる場合があります。 また、他のシステム リソースよりも多くのシステム リソースを消費するお客様がいる場合もあります。 それらをさまざまなインフラストラクチャ セットでグループ化できます。
シングルテナント インスタンスとマルチテナント インスタンス: 大規模な顧客によっては、ソリューションの独自の独立したインスタンスが必要になる場合があります。 小規模な顧客は、マルチテナントデプロイを共有できます。
複雑なデプロイ要件: 管理された方法でサービスに更新プログラムをデプロイし、異なる時間に顧客ベースのさまざまなサブセットにデプロイすることが必要になる場合があります。
更新頻度: 一部のお客様は頻繁な更新を許容しますが、リスクを嫌うお客様は、要求を処理するシステムの更新を頻繁に行う必要があります。 これらの顧客は、分離された環境にデプロイできます。
地理的または地政学的な制限: 待機時間を短くしたり、データ主権要件に準拠したりするために、一部の顧客を特定のリージョンにデプロイできます。
多くの場合、これらの制限は、サービスとしてのソフトウェア (SaaS) を構築するソフトウェア開発会社に適用されます。これらは通常、マルチテナントとして設計されます。 他のシナリオにも、同じ制限が適用される場合があります。
ソリューション
これらの問題を回避するには、 リソースをスケール ユニット にグループ化し、 スタンプの複数のコピーをプロビジョニングすることを検討してください。 各スケール ユニットは、テナントのサブセットをホストし、サービスを提供します。 スタンプは互いに独立して実行され、個別にデプロイおよび更新できます。 1 つの地理的リージョンに、リージョン内で水平方向にスケールアウトする 1 つのスタンプまたは複数のスタンプが含まれている場合があります。 各スタンプは顧客の特定のサブセット向けに作られています。
デプロイ スタンプは、ソリューションでサービスとしてのインフラストラクチャ (IaaS) またはサービスとしてのプラットフォーム (PaaS) コンポーネントを使用するか、またはその両方を組み合わせて使用するかを適用できます。 通常、IaaS ワークロードではスケーリングにより多くの介入が必要になるため、このパターンは IaaS 負荷の高いワークロードのスケールアウトに役立ちます。
スタンプを使用して 、展開リングを実装できます。 異なる顧客が異なる頻度でサービス更新プログラムを必要としている場合は、それらを異なるスタンプにグループ化し、異なる間隔で各スタンプに更新プログラムをデプロイします。
スタンプは個別に実行されるため、データは暗黙的に シャード されます。 1 つのスタンプは、内部でさらにシャーディングを利用してスケーリングを行い、柔軟性を維持することができます。
同じコンポーネントの同じコピーをデプロイするのは複雑であるため、DevOps の優れたプラクティスが重要です。 各スタンプのデプロイが予測可能で反復可能になるように、インフラストラクチャをコードとして記述します。
デプロイ スタンプは< c0 >geodesに関連していますが、異なるものです。 デプロイ スタンプ アーキテクチャでは、システムの各独立したインスタンスが、顧客とユーザーのサブセットにサービスを提供します。 geode アーキテクチャでは、すべてのインスタンスが任意のユーザーからの要求を処理できますが、通常、このアプローチは設計と構築がより複雑になります。 1 つのソリューション内で 2 つのパターンを組み合わせることもできます。 この記事で後述する トラフィック ルーティングアプローチ は、このようなハイブリッド シナリオの例です。
問題と考慮事項
このパターンを実装する方法を決定するときは、次の点を考慮してください。
デプロイ プロセス: 複数のスタンプをデプロイする場合は、デプロイ プロセスを自動化して完全に繰り返します。 Bicep または Teraform モジュールを使用して、スタンプを宣言的に定義し、定義の一貫性を保ちます。
クロススタンプ操作: ソリューションを複数のスタンプに個別にデプロイする場合、すべてのスタンプにまたがって顧客の数を判断するのは困難な場合があります。 場合によっては、各スタンプに対してクエリを実行し、結果を集計する必要があります。 統合レポートのために、すべてのスタンプのデータを一元化されたデータウェアハウスに発行することもできます。
スケールアウト ポリシー: スタンプには有限の容量があります。これは、スタンプにデプロイできるテナントの数など、プロキシ メトリックを使用して定義できます。 各スタンプの使用可能な容量と使用容量を監視し、新しいテナントをそれらに誘導するために、より多くのスタンプを事前にデプロイします。
スタンプの最小数: デプロイ スタンプ パターンを使用する場合は、ソリューションの少なくとも 2 つのスタンプをデプロイします。 1 つのスタンプのみをデプロイする場合、スケールアウトする際に適用されない仮定をコードや構成にハードコーディングしてしまうことがあります。
コスト： デプロイ スタンプ パターンでは、インフラストラクチャ コンポーネントの複数のコピーがデプロイされるため、ソリューションの運用コストが大幅に増加します。
スタンプ間の移動: 各スタンプは個別に実行されるため、スタンプ間でのテナントの移動が困難な場合があります。 アプリケーションには、顧客の情報を別のスタンプに送信し、元のスタンプからテナントの情報を削除するためのカスタム ロジックが必要です。 このプロセスでは、スタンプ間の通信にバックプレーンが必要になる場合があるため、ソリューションの複雑さが増します。
トラフィック ルーティング: この記事で既に説明したように、特定の要求に対してトラフィックを正しいスタンプにルーティングするには、テナントをスタンプに解決する追加のコンポーネントが必要になる場合があります。 このコンポーネントは、高可用性が必要な場合もあります。
スタンプ間の可観測性: スタンプの数が増えると、全体的な正常性を理解し、インシデントをすばやく検出することが困難になります。 Azure Monitor を使用して、すべてのスタンプのメトリック、ログ、トレース、アラートを収集して関連付けます。 このデータを使用して、異常なスタンプを特定し、問題を診断します。
リージョンの障害への影響: スタンプは個別に実行されますが、リージョン間で本質的に冗長ではありません。 1 つ以上のスタンプをホストするリージョンが使用できなくなった場合、それらのスタンプのテナントは、リージョンが復旧するか、テナントを別のリージョンのスタンプに移行するまでアクセスできなくなります。 このシナリオを計画するには、復旧手順を文書化し、テナントの期待を設定し、重要なテナントについて地理的冗長性を持たせたスタンプ配置が必要かどうかを検討します。
共有コンポーネント: スタンプ間で共有できるコンポーネントがある場合があります。 たとえば、すべてのテナントの共有シングルページ アプリがある場合は、それを 1 つのリージョンにデプロイし、Azure Front Door エッジ キャッシュを使用してグローバルにレプリケートします。
ガバナンスと構成の誤差: スタンプの数が増えるにつれて、セキュリティ ポリシー、ロールベースのアクセス制御 (RBAC) の割り当て、ネットワーク制御、監視設定、およびサービス構成の一貫性を維持することが困難になります。 Azure Policyを使用してガバナンスをコードとして扱い一貫性のない動作とコンプライアンスのギャップを防ぐために、各スタンプの誤差を継続的に検証します。
このパターンを使用する場合
このパターンは次の状況で使用します。
ソリューションには、スケーラビリティに自然な制限があります。 たとえば、一部のコンポーネントが特定の数の顧客や要求を超えてスケールすべきでない、またはスケールできない場合は、スタンプを利用してスケールアウトします。
特定のテナントを他のテナントから分離する必要があります。 セキュリティ上の問題によって、一部の顧客をマルチテナント スタンプにデプロイできなくなる場合は、それらを独自の分離スタンプにデプロイします。
ソリューションの異なるバージョンで一部のテナントを同時にホストする必要があります。
各テナントのデータとトラフィックを特定のリージョンに転送する必要があるマルチリージョン アプリケーションを構築します。
停止中に回復性を実現する必要がある。 スタンプは個別に動作するため、1つのスタンプに停止が発生した場合、他のスタンプにいるテナントは影響を受けません。 この分離には、インシデントまたは停止の 爆発半径 が含まれます。
このパターンは、次の場合に適さない場合があります。
ソリューションはシンプルであり、高度にスケーリングする必要はありません。
アプリケーション 層のサイズを大きくしたり、データベースとストレージ層の予約容量を増やしたりすることで、1 つのインスタンス内でシステムをスケールアウトまたはスケールアップできます。
デプロイされたすべてのインスタンスにデータをレプリケートする必要があります。 このシナリオの Geode パターン について考えてみましょう。
スケールする必要があるのは一部のコンポーネントのみで、他のコンポーネントはスケーリングする必要はありません。 たとえば、すべてのソリューション コンポーネントの新しいコピーをデプロイするのではなく、 データ ストアをシャーディング してソリューションをスケーリングできるかどうかを検討します。
ソリューションは、フロントエンド JavaScript アプリケーションなどの静的コンテンツのみで構成されます。 コンテンツ配信ネットワークでこの コンテンツを配信します。
ワークロード設計
ワークロードの設計でデプロイ スタンプ パターンを使用して、Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。
| 支柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| 信頼性設計の決定は、故障に対するワークロードの回復性を高め、障害の発生後にワークロードを完全な機能状態に回復させるために役立ちます。 | スタンプは独立して動作するため、1 つのスタンプの障害は分離され、他のスタンプのテナントには影響しません。 リージョン間で複数のスタンプをデプロイすると、冗長性と復旧計画の基盤も提供され、リージョンの停止の爆発半径が減少します。 - RE: 05冗長性 - RE:07 自己保護 |
| オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 | このパターンは、不変のインフラストラクチャ目標、高度な導入モデルをサポートし、安全な導入方法を容易に実現します。 - OE:05コードとしてのインフラストラクチャ - OE:11 安全な配備の実践 |
| パフォーマンス効率 は、スケーリング、データ、およびコードの最適化を通じて、ワークロード の需要を効率的に満たすのに役立ちます。 | 多くの場合、このパターンはワークロードで定義されているスケール ユニットに合わせて調整されます。 1 つのスケール ユニットで提供される容量よりも多くの容量が必要な場合は、スケールアウトするために別のスタンプをデプロイします。 - PE:05 スケーリングとパーティショニング |
このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。
例
次のアーキテクチャ例では、Azure Front Door、Azure API Management、およびAzure Cosmos DBを使用して、一連のリージョン固有のスタンプにトラフィックをグローバルにルーティングします。
ユーザーがニューヨークにいるとします。 スタンプ 3 は、米国東部リージョンにデータを格納します。
ユーザーがカリフォルニアに移動してシステムにアクセスした場合、システムは接続を米国西部 2 リージョン経由でルーティングします。これは、そのリージョンが要求を行うときに最も近いためです。 ただし、スタンプ 3 はデータを格納するため、最終的に要求を処理する必要があります。 トラフィック ルーティング システムは、要求を正しいスタンプにルーティングします。
デプロイメント
Bicep または Teraform を使用して、インフラストラクチャをコードとして記述します。 この方法により、各スタンプのデプロイが予測可能で繰り返し可能になります。 また、不注意によるスタンプ間の構成の不一致などの人為的なミスの可能性も低減されます。
更新プログラムは、すべてのスタンプに自動的に並列で展開できます。
デプロイについては、Azure サブスクリプションとリソース グループのトポロジを慎重に検討してください。
通常、サブスクリプションには 1 つのソリューションのすべてのリソースが含まれているため、すべてのスタンプに 1 つのサブスクリプションを使用することを検討してください。 ただし、一部のAzure サービスでは、サブスクリプション全体のクォータが適用されます。 このパターンを使用して高度なスケールアウトを許可する場合は、さまざまなサブスクリプションにスタンプをデプロイすることが必要になる場合があります。
リソース グループには、通常、同じライフ サイクルを共有するコンポーネントが含まれます。 すべてのスタンプに対する更新プログラムを同時にデプロイする予定の場合は、すべてのスタンプのすべてのコンポーネントを含む 1 つのリソース グループを使用できます。 リソースの名前付け規則とタグを使用して、各スタンプに属するコンポーネントを識別します。 または、各スタンプに対する更新プログラムを個別にデプロイする場合は、各スタンプを独自のリソース グループにデプロイできます。
能力計画
ロード テストとパフォーマンス テストを使用して、特定のスタンプが対応できるおおよその負荷を測定します。 読み込みメトリックは、1 つのスタンプが対応できる顧客またはテナントの数、またはスタンプ内のサービスが出力するメトリックに基づく場合があります。 各スタンプをインストルメント化して、容量に近づくタイミングを測定し、新しいスタンプを迅速にデプロイして需要に対応できるようにします。
トラフィックのルーティング
デプロイ スタンプ パターンは、各スタンプに個別に対処する場合に適切に機能します。 たとえば、Contoso が複数のスタンプに同じ API アプリケーションをデプロイする場合、Contoso はドメイン ネーム システム (DNS) を使用して、関連するスタンプにトラフィックをルーティングできます。
-
unit1.aus.myapi.contoso.comはオーストラリア リージョン内のスタンプunit1にトラフィックをルーティングします。 -
unit2.aus.myapi.contoso.comはオーストラリア リージョン内のスタンプunit2にトラフィックをルーティングします。 -
unit1.eu.myapi.contoso.comでは、ヨーロッパ リージョン内のスタンプunit1にトラフィックをルーティングします。
Azureでは、これらのレコードを Azure DNS でホストし、リージョンとスタンプごとに一貫したサブドメイン規則を使用できます。 このアプローチでは、予測可能なルーティングと操作が維持されます。
クライアントは、正しいスタンプへの接続を担当します。
ソリューションですべてのトラフィックに 1 つのイングレス ポイントが必要な場合は、トラフィック ルーティング サービスを使用して、特定の要求、顧客、またはテナントのスタンプを解決できます。 トラフィック ルーティング サービスは、(たとえば、HTTP 302 応答状態コードを返すことによって) スタンプの関連 URL にクライアントを誘導するか、リバース プロキシとして機能し、クライアントが認識せずに関連するスタンプにトラフィックを転送します。
特に、ソリューションが複数のリージョンで実行される場合、一元化されたトラフィック ルーティング サービスは、設計が複雑なコンポーネントになる可能性があります。 スタンプをホストするすべてのリージョンを含む可能性がある複数のリージョンにトラフィック ルーティング サービスをデプロイし、テナントをスタンプにマップするデータ ストアを同期することを検討してください。 トラフィック ルーティング コンポーネント自体が Geode パターンのインスタンスである可能性があります。
たとえば、 API Management をデプロイして、トラフィック ルーティング サービスとして機能させることができます。 API Management は、テナントとスタンプ間のマッピングを格納する Azure Cosmos DB コレクション内のデータを検索することによって、要求に適したスタンプを決定します。 その後、API Management は 、バックエンド URL を 関連するスタンプの API サービスに動的に設定します。
トラフィック ルーティング サービスに対して要求を geo 分散し、geo 冗長性を提供するには、複数のリージョンに API Management をデプロイしAzure Front Door を使用して、最も近い API Management ゲートウェイにトラフィックを転送します。 このトポロジでは、Azure Front Door がオリジン グループ、ヘルス プローブ、適切なルーティング方法を使用して、異常な API Management リージョン ゲートウェイから要求をルートします。 その後、API Management は、必要に応じてスタンプ エンドポイント間のフェールオーバー 規則を含む、テナント間マッピングとそのバックエンド構成 (またはバックエンド プール) を使用して、適切なスタンプにルーティングします。 アプリケーションが HTTP または HTTPS 経由で公開されていない場合は、cross-region Azure ロード バランサーを使用して、着信呼び出しをリージョン Azure ロード バランサーに配布できます。 Azure Cosmos DB の global 分散機能 を使用して、各リージョン間でマッピング情報を更新します。
ソリューションにトラフィック ルーティング サービスが含まれている場合は、 それがゲートウェイ として機能し、トークンの検証、調整、承認など、他のサービスに対して ゲートウェイ オフロード を実行できるかどうかを検討します。
次の手順
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要著者:
- John Downs | プリンシパルソフトウェアエンジニア, Azure パターン＆プラクティス
その他の共同作成者:
- フェデリコ・アランバリ |シニア ソフトウェア 開発者、Clarius コンサルティング
- Daniel Larsen | FastTrack for Azure のプリンシパル カスタマー エンジニア
- 天使ロペス |シニア ソフトウェア エンジニア、Azure のパターンとプラクティス
- Paolo Salvatori |Azure用 FastTrack のプリンシパル カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
関連するリソース
- シャーディングは、データ層をスケールアウトするもう 1 つの簡単な方法として使用できます。 スタンプは暗黙的にデータをシャード化しますが、シャーディングにはデプロイ スタンプは必要ありません。 詳細については、「 シャーディング パターン」を参照してください。
- ソリューションでトラフィック ルーティング サービスをデプロイする場合は、 ゲートウェイ ルーティング と ゲートウェイ オフロード パターンを 組み合わせて、このコンポーネントを最大限に活用できます。