【リージョン冗長】Azure OpenAI 本番構成アーキテクチャパターン【スケールアウト】

Azure OpenAI 本番構成アーキテクチャパターン【リージョン冗長・スケールアウト】

この記事の内容

• Azure OpenAI Service（AOAI）を本番環境で利用する際の代表的なアーキテクチャパターンを紹介します
• Azure Front Door を使ったグローバルロードバランシングによるリージョン冗長化の方法を解説します
• Azure API Management（APIM）を前段に配置することで実現できる高度な制御機能を説明します
• Front Door と APIM を組み合わせたマルチリージョン本番構成の全体像を紹介します
• 各パターンの制限事項や注意点についても合わせて解説します

はじめに

Azure OpenAI Service（以下、AOAI）を活用したアプリケーションの検討が、多くの企業・組織で本格化しています。PoC（概念実証）レベルでの検証は比較的容易に進められますが、いざ本番環境へ移行しようとすると「可用性をちゃんと確保したい」「障害時でも止まらない構成にしたい」という要件が出てきます。

この記事では、Microsoft の公式ドキュメント「Azure OpenAI Architecture Patterns and Implementation Steps」の内容をもとに、AOAI の本番構成として使える代表的なアーキテクチャパターンを解説します。

用語の整理：AOAI とは

ドキュメントを読んでいると「AOAI」という略語が頻出します。これは Azure OpenAI Service の略称です。本記事でも以降は AOAI と表記します。

Azure リージョンの可用性について（前提知識）

本題に入る前に、Azure リージョンの可用性について正しく理解しておくことが重要です。

1 つの Azure リージョンの中には、地理的に分散した複数のデータセンターが存在しています。そのため、1 つのデータセンターで大規模な障害が発生しても、リージョン全体としてのサービスは継続されます。一般企業が複数のデータセンターを契約して冗長化構成を組むのと同等の仕組みが、Azure リージョン単体でも実現されています。

つまり、1 リージョンだけの構成でも可用性は十分に高い と言えます。

それでも、以下のような要件がある場合にはマルチリージョン構成が有効になります。

• リージョン全体の障害に備えたい
• 国内外をまたいだ冗長構成を取りたい
• 1 つのリージョンだけではパフォーマンスが不足している

本記事で紹介するパターンは、こうした要件に対応するためのものです。

パターン 1：Azure Front Door によるロードバランシング

概要

最初のパターンは、Azure Front Door を使ってグローバルなロードバランシングを実現する構成です。

アーキテクチャのイメージは以下のとおりです。

• 2 つ（以上）のリージョンそれぞれに AOAI サービスを展開する
• 入り口を 1 つにまとめるために、Azure Front Door を前段に配置する
• Front Door がリクエストを各リージョンへ振り分ける

Azure Front Door とは

Azure Front Door は、リージョンを横断したグローバルなロードバランシングが可能なサービスです。特定のリージョンに展開するものではなく、サービス自体がすでに全世界に分散して提供されています。CDN 機能や Azure のグローバルバックボーンネットワークも活用できるため、ユーザーに近い入り口からAzureの内部ネットワーク経由で高速・安定した接続が得られます。

ヘルスチェックの仕組み

Front Door がバックエンドの死活監視をするためのエンドポイントとして、以下のパスが使用されます。

このパスは Azure API Management（APIM）の死活監視用エンドポイントです。AOAI の前段には APIM が配置されており、このパスにリクエストを送ることでバックエンドが正常稼働しているかどうかを確認できます。Front Door はこのエンドポイントをポーリングし、ルーティング先を動的に制御します。

Azure Front Door を使うメリット

注意点

現時点では、Azure Front Door から AOAI Service への接続にはプライベートリンクを使用できません。Front Door からのアクセスは、Azure 内部ネットワークを経由しますが、AOAI Service はグローバル IP アドレスを持つ形になります。

ただし、接続元の制限（特定のネットワークからしか受け付けない設定）は可能なため、実質的にはほぼ閉じた構成にはできます。プライベートリンク対応はロードマップに含まれているため、将来的にはサポートされる予定です。

また、同じ重み付けを設定していても、完全なラウンドロビン（均等分散）にはなりません。ネットワーク遅延などの影響で若干の偏りが生じます。均等分散が厳密に必要な要件の場合は、別のロードバランシング方式を検討する必要があります。

パターン 2：Azure API Management によるラッピング

概要

2 つ目のパターンは、Azure API Management（APIM） を前段に配置して AOAI を管理する構成です。Front Door との違いは、よりアプリケーションレベルでの細かい制御が可能になる点です。

APIM は仮想ネットワーク（VNet）内のサブネットに配置されるため、AOAI へのアクセスをプライベートリンク経由で行えるという大きなメリットがあります。

APIM で実現できること

APIM では「ポリシー」と呼ばれる設定を記述することで、さまざまな処理をリクエスト・レスポンスのフロー上に追加できます。代表的な例を以下に示します。

• 認証・認可: Azure AD と連携し、ユーザー・グループ単位でのアクセス制御
• レート制限: ユーザーや組織ごとにリクエスト数の上限を設定
• コスト管理: 予算上限を設定し、超過した場合に対象リージョンへのアクセスを停止
• キャッシング: 同一リクエストのレスポンスをキャッシュして AOAI の呼び出し回数を削減
• モニタリング: Azure Monitor・Application Insights と連携したログ収集と可視化
• 開発者ポータル: API ドキュメントの自動生成・テスト環境の提供
• オーケストレーション: 複数の AOAI モデルや他の Azure サービスと連携した複合 API の構築

たとえば以下のようなユースケースが実現できます。

• ユーザーごとの月次利用コストをレポートとして出力する
• 課金額が設定した予算を超えたリージョンへのリクエストを自動停止する
• Azure Functions などの他サービスと組み合わせた複合処理 API を公開する

注意点

このパターンでは APIM がリージョン内の VNet に配置されるため、APIM 自体はリージョン冗長ではありません。APIM が単一リージョンに集中すると、APIM 自体が障害点になる可能性があります。

パターン 3：Azure Front Door ＋ APIM によるフル冗長構成

概要

3 つ目のパターンは、Azure Front Door と APIM を組み合わせたマルチリージョン本番構成です。前述の 2 つのパターンの利点を組み合わせた、最も本格的な構成です。

アーキテクチャ構成

構成のイメージは以下のとおりです。

各リージョンに APIM ＋ AOAI のセットを用意し、その前段に Azure Front Door を配置します。

この構成で実現できること

• リージョン冗長: 一方のリージョンが障害になっても、もう一方で処理を継続できる
• スケールアウト: リージョンを追加するだけで処理能力を拡張できる
• 細かい制御: APIM によるポリシーベースの柔軟なAPI管理
• プライベートリンク: APIM 経由のため AOAI へのアクセスはプライベートリンクで実現可能
• セキュリティ: Front Door の WAF・DDoS 保護が有効

コストについて

この構成は Azure Front Door、APIM（複数リージョン）、AOAI（複数リージョン）をすべて利用するため、コストは増加します。本番環境における可用性・スケーラビリティの要件と、コストのバランスを考慮して採用を判断してください。

まとめ

Azure OpenAI Service を本番環境で運用するためのアーキテクチャパターンとして、以下の 3 つを紹介しました。

PoC から本番へ移行するタイミングで、どこまでの可用性・スケーラビリティを求めるかに応じて、適切なパターンを選択してください。また、今回紹介したアーキテクチャの考え方（Front Door による冗長化・APIM によるAPI管理）は、AOAI に限らず他の Azure サービスを本番運用する際にも広く応用できる考え方です。ぜひ参考にしていただければと思います。