次の方法で共有

Azure OpenAI Service での事業継続とディザスター リカバリー (BCDR) の考慮事項

  • [アーティクル]

Azure OpenAI は複数のリージョンで利用できます。 Azure OpenAI リソースを作成するときに、リージョンを指定します。 それ以降、ご使用のリソースとそのすべての操作は、その Azure サーバー リージョンに関連付けられたままになります。

リージョン全体に影響が及ぶネットワークの問題が発生することはまれですが、まったくないわけではありません。 自分のサービスを常に使用できるようにする必要がある場合は、別のリージョンにフェールオーバーするか、複数のリージョン間でワークロードを分割するように設計する必要があります。 どちらのアプローチでも、別々のリージョンで少なくとも 2 つの Azure OpenAI リソースが必要です。 この記事では、Azure OpenAI アプリケーションにビジネス継続性とディザスター リカバリー (BCDR) を実装する方法に関する一般的な推奨事項について説明します。

既定では、Azure OpenAI Service は 既定の SLA を提供します。 既定の回復性は多くのアプリケーションで十分ですが、高い回復性とビジネス継続性を必要とするアプリケーションでは、モデル インフラストラクチャをさらに強化するための追加の手順を実行する必要があります。

Standard デプロイ

Note

Global Standard デプロイを使用できる場合は、代わりにこれを使用する必要があります。 Data Zone デプロイは、データ処理を地理的境界内で完全に行う必要がある組織にとって、次に最適なオプションです。

  1. Standard デプロイの場合、既定ではData Zone デプロイ (米国またはヨーロッパのオプション) になります。

  2. 2 つの Azure OpenAI Service リソースをAzure サブスクリプションにデプロイする必要があります。 1 つのリソースを優先リージョンにデプロイし、もう 1 つはセカンダリまたはフェールオーバー リージョンにデプロイする必要があります。 Azure OpenAI Service では、サブスクリプションとリージョン レベルでクォータが割り当てられるため、クォータに影響を与えず、同じサブスクリプションに存在できます。

  3. 使用する予定のモデルごとに 1 つのデプロイが、優先する Azure リージョンの Azure OpenAI Service リソースにデプロイされている必要があり、セカンダリまたはフェールオーバー リージョンにこれらのモデル デプロイを複製する必要があります。 Standard デプロイで使用可能な完全なクォータをこれらの各エンドポイントに割り当てます。 これにより、複数のデプロイ間でクォータを分割する場合と比較して、最も高いスループット レートが提供されます。

  4. ネットワーク トポロジに基づいてデプロイ リージョンを選択します。 Azure OpenAI Service リソースをサポートされている任意のリージョンにデプロイし、そのリソースのプライベート エンドポイントを優先リージョンに作成できます。

    • Azure OpenAI Service の境界内に入ると、データ ゾーンで使用可能なコンピューティング全体のルーティングと処理が、Azure OpenAI Service によって最適化されます。
    • データ ゾーンの使用は、複数のリージョンデプロイでのセルフマネージド負荷分散よりも効率的で簡単です。

  5. デプロイが使用できない状態になっているリージョンで停止が発生した場合は、同じサブスクリプション内のセカンダリまたはパッシブ リージョンの他のデプロイを使用できます。

    • プライマリとセカンダリの両方のデプロイがゾーン デプロイであるため、ゾーン内のすべての利用可能なリージョンから引き出される同じゾーン容量プールから引き出されます。 セカンダリ デプロイは、プライマリ Azure OpenAI エンドポイントが到達できない状態になることを防ぎます。
    • Azure OpenAI Service エンドポイントの前で API Management などの負荷分散とサーキット ブレーカー パターンをサポートする生成 AI ゲートウェイを使用すると、リージョンの停止中の中断が、アプリケーションの消費に対して最小限に抑えられます。
    • 特定のサブスクリプション内のクォータが不足している場合は、上記と同じ方法で新しいサブスクリプションをデプロイし、そのエンドポイントを生成 AI ゲートウェイの背後にデプロイできます。

プロビジョニング済みのデプロイ

エンタープライズ PTU プールを作成する

  1. プロビジョニングされたデプロイでは、PTU のエンタープライズ プールとして機能する単一の Data Zone PTU デプロイ (2024 年 12 月 4 日利用可能) を用意することをお勧めします。 API Management を使用すると、複数のアプリケーションからのトラフィックを管理して、スループットの制限、ログ、優先度、およびフェールオーバー ロジックを設定できます。
    • このエンタープライズ PTU プールは、サービスの需要が高い場合に Standard デプロイで発生することがある "うるさい隣人" 問題から保護する "プライベート従量課金制" リソースと考えてください。 組織は、組織のユーザーだけが利用できる容量のプールへの専用アクセスを保証するため、他の顧客からの需要の急増から独立しています。
    • これにより、最初に待機時間が増加するアプリケーション エクスペリエンスを制御できるため、ミッション クリティカルなアプリケーションへのトラフィックに優先順位を付けられます。
    • プロビジョニング済みのデプロイは、待機時間 SLA によってサポートされており、待機時間の影響を受けやすいワークロードの場合は Standard (従量課金制) デプロイより適しています。
    • また、エンタープライズ PTU デプロイでは、アプリケーション ワークロード間でトラフィックが平滑化されるため、使用率が高くなりますが、個々のワークロードはスパイクが発生しやすい傾向があります。
  2. プライマリ エンタープライズ PTU のデプロイは、プライマリ Standard Zone のデプロイとは異なるリージョンに配置する必要があります。 これは、リージョンの障害が発生した場合に、PTU デプロイと Standard Zone デプロイの両方に同時にアクセスできなくなることを防ぐためです。

ワークロード専用 PTU のデプロイ

  1. 特定のワークロードでは、独自の専用のプロビジョニング済みデプロイが必要になる場合があります。 その場合は、そのアプリケーション専用の PTU デプロイを作成できます。
  2. ワークロードとエンタープライズ PTU プールのデプロイは、リージョンの障害から保護する必要があります。 このためには、リージョン A にワークロード PTU プールを配置し、リージョン B にエンタープライズ PTU プールを配置します。
  3. このデプロイは、最初にエンタープライズ PTU プールに、次に Standard デプロイにフェールオーバーする必要があります。 これは、ワークロード PTU デプロイの使用率が 100% を超えると、要求は引き続き PTU エンドポイントによって処理され、そのアプリケーションの、より待機時間が長い SLA が有効になることを意味します。

ディザスター リカバリーのアーキテクチャ図。

このアーキテクチャの付加的な利点は、Standard デプロイをプロビジョニング済みデプロイにスタックできるため、好みのレベルのパフォーマンスと回復性に調節できることです。 これにより、ワークロード全体のベースラインの需要に PTU を使用し、トラフィックのスパイクに従量課金制を利用できます。

プロビジョニング済みのスケーリングの図。

サポートするインフラストラクチャ

Azure OpenAI アーキテクチャをサポートするインフラストラクチャは、設計時に考慮する必要があります。 アーキテクチャに関係するインフラストラクチャ コンポーネントは、アプリケーションによる Azure OpenAI Service の使用がインターネット経由かプライベート ネットワーク経由かによって異なります。 この記事で説明するアーキテクチャは、組織が生成 AI ゲートウェイを実装していることを前提としています。 成熟した Azure フットプリントとハイブリッド接続を持つ組織はプライベート ネットワークを介してサービスを使用する必要があります。一方、ハイブリッド接続のない組織や、GCP や AWS などの別のクラウド内のアプリケーションを使用する組織は、Microsoft パブリック バックボーンを介してサービスを使用します。

Microsoft パブリック バックボーンを使用するための設計

Microsoft パブリック バックボーンを介してサービスを使用する組織は、次の設計要素を考慮する必要があります。

  1. 生成 AI ゲートウェイは、Azure リージョンに障害が発生した場合に確実に使用できるようにデプロイする必要があります。 APIM (Azure API Management) を使用する場合は、複数のリージョンに個別の APIM インスタンスをデプロイするか、APIM のマルチリージョン ゲートウェイ機能を使用して行うことができます。

  2. パブリック グローバル サーバー ロード バランサーを使用して、アクティブ/アクティブまたはアクティブ/パッシブのいずれかの方法で、複数の生成 AI ゲートウェイ インスタンス間で負荷分散を行う必要があります。 組織の要件に応じて、Azure FrontDoor を使用して、この役割を果たすことができます。

フェールオーバーのアーキテクチャ図。

プライベート ネットワークを使用するための設計

プライベート ネットワークを介してサービスを使用する組織では、次の設計要素を考慮する必要があります。

  1. ハイブリッド接続は、Azure リージョンの障害から保護する方法でデプロイする必要があります。 ハイブリッド接続をサポートする基盤となるコンポーネントは、組織のオンプレミス ネットワーク インフラストラクチャと、Microsoft ExpressRoute または VPN で構成されます。
  2. 生成 AI ゲートウェイは、Azure リージョンに障害が発生した場合に確実に使用できるようにデプロイする必要があります。 APIM (Azure API Management) を使用する場合は、複数のリージョンに個別の APIM インスタンスをデプロイするか、APIM のマルチリージョン ゲートウェイ機能を使用して行うことができます。
  3. Azure Private Link プライベート エンドポイントは、各 Azure リージョンの Azure OpenAI Service インスタンスごとにデプロイする必要があります。 Azure プライベート DNS の場合、リージョン障害に対する追加の保護を提供するために、Azure OpenAI Service へのすべてのアプリケーション アクセスが生成 AI ゲートウェイを介して行われる場合は、スプリットブレイン DNS アプローチを使用できます。 それ以外の場合は、Azure リージョンが失われた場合にプライベート DNS レコードを手動で変更する必要があります。
  4. プライベート グローバル サーバー ロード バランサーを使用して、アクティブ/アクティブまたはアクティブ/パッシブのいずれかの方法で、複数の生成 AI ゲートウェイ インスタンス間で負荷分散を行う必要があります。 Azure には、プライベート DNS 解決を必要とするワークロード向けのグローバル サーバー ロード バランサー用のネイティブ サービスがありません。 このトピックのその他の背景情報については、こちらの非公式ガイド「https://github.com/adstuart/azure-crossregion-private-lb」を参照してください。グローバル サーバー ロード バランサーの代わりに、組織は、生成 AI ゲートウェイの DNS レコードを切り替えると、アクティブ/パッシブ パターンを実現できます。