1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

弥生Advent Calendar 2024

Day 18

Azure Open AI の冗長化 (API利用)

Last updated at Posted at 2024-12-17

この記事は個人で検証した内容です。
Microsoft社の公式見解ではありません。
自身の判断で参照いただけますと幸いです。

2024年12月18日時点の状況に基づいた内容です

はじめに

この記事は弥生 Advent Calendar 2024 の12月18日の記事です。

弥生株式会社の不破です。コーポレートプラットフォーム部のインフラセキュリティとバックオフィス基盤のテクニカルリーダー (兼務) として弥生のシステム基盤を支えるプロジェクトであったり、新しい仕組みの導入推進をリードしています。

この記事では「Azure Open AI のクォータ制限を回避する方法」を考えるヒントになるような内容を記載したいと思います。

冗長化の目的

今更感ですが、冗長化の目的を簡単におさらいします。

  • システム障害対策 (冗長化は可用性の手段の一つ)
    • 例) A系に障害が生じた際にB系で動作し続ける
  • 災害対策
    • 例) 地理的分散してリスクを低減する
  • 負荷対策
    • 例) A系だけでは処理しきれないのでB系で負荷を分散して並列処理する
  • 損害の最小化
    • 例) 復旧までの時間最小化する
    • 例) データ保全する

このあたりの目的がありますが、今回のテーマは「Azure Open AI」なのでさらに目的が加わります。

  • クォーター制限の回避

Azure Open AI のクォーター制限

Azure Open AI にはリージョン単位でモデルをデプロイできるクォーターの制限があります。

このクォーター制限を回避する方法として考えられる例は、次の通りです。

  1. クォーターの上限緩和申請をする
  2. アプリ側でウェイト処理やリトライ処理を実装する
  3. 別のリージョンを利用する

1. クォーターの上限緩和申請をする

一番スマートな方法ですが、ハードルが2つあります。

申請は専用フォームから理由や根拠などの各項目を埋めて提出するだけです。
ただし宛先が Microsoft社本国の専門チームであるため、英語での記載が必要です。
これが1つ目のハードルになります。

次に、1つ目のハードルを正当な理由や根拠でクリアしたとしても2つ目のハードルがあります。
リージョン単位での上限緩和を受け付けていない場合があります。
US系など人気が高いリージョンや規模が大きくないリージョンが対象になることがあります。
これが2つめのハードルになります。

2. アプリ側でウェイト処理やリトライ処理を実装する

これはアプリ側で制限して妥協しましょうという例です。

3. 別のリージョンを利用する

この記事のメインです。
上で リージョン単位でモデルをデプロイできるクォーターの制限があります と記載しましたが、上限緩和やアプリ側で回避できない or したくない場合に選択します。
ただし、単体でリージョンごとにモデルをデプロイしてもアプリ側で振り分け実装することは非現実的です。
そこで利用するのが冗長化の仕組みです。

Azure の冗長化サービス

Azure には主に冗長化できるサービスが次の通りあります。

  1. DNS
  2. Front Door
  3. Load Balancer (NLB)
  4. Application Gateway (ALB)
  5. Traffic Manager
  6. API Management

Azure Open AI のクォーター制限を回避する構成

今回記載する構成は一例です。
今回のテーマは Azure Open AI のクォーター制限を回避することなので API Management の細かい内容は省きます。

構成イメージ

image.png

構成の説明

まず Azure Open AI を冗長化する方法として Azure API Management を採用しています。
理由は、

  1. Open AI API を利用する際に Key を送信する必要があるため平文で送るサービスは NG である
  2. Open AI API Key はリージョン (リソース) ごとに異なるが API Management が認証を統一してくれる
  3. ユーザーごとにリクエスト制限ができる

バックエンドの Azure Open AI のモデルは複数リージョン用意しています。
こうすることで、1リージョンあたりのクォーター上限に達していてもリージョンを束にすることで全体の総量をあげるという手法です。

おまけ

API Management の GenAI ゲートウェイ機能など新しい機能が次々と出てきています。
AI 関係のサービスは Open AI を含めて日進月歩で変わっています。
AI で DX 進めている感を出してもバックエンドは世代前なんてことも。
アンテナを広く張って常に最新の技術についていく必要がありますね。便利な反面、ある意味エンジニア泣かせな気もしますね・・・

まとめ

今回のテーマはここまでです。
少しでもみなさまのヒントになれば幸いです。
最後までご覧いただきありがとうございました。


1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?