🗂

Auto Scale機能により、Azure Document Intelligence は本当にスケールするのか？

に公開
Azure
Microsoft
tech

オートスケール検証ツールを作った話

Azure Document Intelligence（旧 Form Recognizer）を本番で使おうとすると、必ずと言っていいほど出てくるのがこの問いです。

「これ、本当に必要な TPS までスケールしてくれるの？
429 で詰まって SLA 割れしない？」

ドキュメント上は「Standard(S0) はデフォルト 15 TPS、サポート依頼やオートスケール設定で引き上げ可能」と書かれていますが、自分たちのワークロードでどう振る舞うのかは実際に叩いてみないと分かりません。 

そこで、Azure Document Intelligence のオートスケール挙動を手軽に検証できるツールとして、GitHub リポジトリ 「DocumentIntelligence_scaling_bench」 を作りました：

👉 https://github.com/sasukeh/DocumentIntelligence_scaling_bench 

この記事では、このツールの狙いや構成、実際のテストシナリオを紹介しつつ、エンジニアが自分の環境でオートスケールを検証できるところまでをゴールにします。

Azure Document Intelligence のスケールの前提

公式ドキュメントでは、Standard(S0) の Document Intelligence リソースには以下のような制限があります： 

  • Analyze TPS（POST）: デフォルト 15 TPS（標準プラン）
  • Get operations TPS（GET）: デフォルト 50 TPS
  • これらはサポートリクエストで引き上げ可能
  • オートスケールを有効にすると、上限を超えたリクエストも、サービスの空きキャパシティに応じてスケールアウトして処理される

また、オートスケールは魔法ではなく、スケール完了まで数分かかることがあるとドキュメントにも示されています。 

つまり本番設計では、

  • どのくらいの TPS で投げると、
  • どれくらいの時間でスケールし、
  • 429 がどれくらいの割合で発生するか

を理解した上で、ワークロード設計とリトライ戦略を組む必要があります。

なぜスケール検証ツールを作ったのか

理想を言うと、こういうことを事前に確認しておきたいはずです：

  • うちのケースでは 30 TPS / 60 TPS / 300 TPS くらいまで本当に耐えられるのか
  • スパイクさせたとき、**「最初の数分 429 だらけ」**にならないか
  • ベストプラクティスどおりにリトライ（Exponential Backoff）を入れると、
    トータルの成功率やレイテンシはどう改善するのか 

ところが、これを検証するための「ほどよいベンチツール」が見当たりませんでした。

  • シンプルなループで叩くだけだと、クライアント側がボトルネックになる
  • JMeter などの汎用ツールを使うと、結果の分析が Document Intelligence 目線にならない
  • Azure Load Testing を本格導入する前に、ローカルでサクッと傾向を掴みたい

そこで作ったのが DocumentIntelligence_scaling_bench です。**「Document Intelligence 向けに特化したスケーリング挙動の可視化ツール」**という位置づけです。 

DocumentIntelligence_scaling_bench の概要

リポジトリの中身をざっくり整理すると、以下のような構成です： 

  • load_test.py
    • メインの負荷テストスクリプト（数十 TPS までのシナリオ向け）
  • autoscale_test.py
    • マルチセッション・高並列で叩く、高負荷オートスケール検証用（200 TPS 以上向け）
  • metrics.py / analyze_results.py
    • リクエスト/レスポンスを記録し、成功率・レイテンシ・TPS・429 の発生タイミングなどを集計
  • quick_test.py
    • 接続確認と簡易レートリミットチェック
  • scripts/
    • Azure リソース作成や .env セットアップ用のスクリプト群
  • TEST_GUIDE.md
    • もう少し詳細なテストガイド

狙いはシンプルで、「Document Intelligence リソースを用意したら python load_test.py で即テストできる」ことです。

セットアップ：3 ステップでテスト開始

1. リポジトリを取得して環境構築

git clone https://github.com/sasukeh/DocumentIntelligence_scaling_bench.git
cd DocumentIntelligence_scaling_bench

python -m venv .venv
source .venv/bin/activate  # Windows は .venv\Scripts\activate
pip install -r requirements.txt

2. Document Intelligence リソースの設定

既存のリソースを使う場合は、対話的セットアップが一番ラクです：


python scripts/setup_env.py

もしくは .env.example をコピーして手動編集します。

cp .env.example .env
  • エンドポイントとキーを設定
    新規に Azure リソースを作りたい場合は、スクリプトも用意しています：
bash scripts/create_azure_resources.sh

3. 接続確認

python quick_test.py

問題なく接続できれば、負荷テストに進めます。 

代表的なテストシナリオ

このツールでは、Document Intelligence のオートスケール挙動を確認するために、いくつかの典型的なシナリオをあらかじめ定義しています。 

シナリオ 1: ベースラインテスト（まずは 10 TPS）

python load_test.py --tps 10 --duration 30 --warmup 0
  • 目的: デフォルト 15 TPS の制限以下で、ほぼ 100% 成功することを確認
  • 想定結果: 429 はほぼ発生せず、レイテンシも安定

シナリオ 2: オートスケール検証（30 TPS）

python load_test.py --tps 30 --duration 180 --warmup 60
  • 目的: 15 TPS の倍程度の負荷をかけたときの挙動を見る
  • 想定結果:
    • テスト開始〜1〜2分: 429 がそれなりに発生
    • スケール完了後: 30 TPS 付近で安定して処理、429 は減少

シナリオ 3: 目標ロードテスト（60 TPS）

python load_test.py --tps 60 --duration 300 --warmup 120
  • 目的: 本番で想定している TPS（例: 60 TPS）を達成できるか検証
  • 想定結果:
    • Warmup 期間で徐々に負荷を上げることで、スケール完了とともに 60 TPS 付近まで到達
    • レイテンシと 429 発生率から、必要な余裕度を見積もる

高負荷検証（200〜500 TPS）

もっとガッツリ検証したい場合は autoscale_test.py を使います： 

デフォルトは 300 TPS × 5 分

python autoscale_test.py

500 TPS まで上げて 10 分

python autoscale_test.py --tps 500 --duration 600

内部では複数セッション・複数接続を使って効率的にリクエストを発行するため、
クライアント側のボトルネックをなるべく排除した形で Document Intelligence の限界を探れます。

結果の見方：オートスケールが「効いている」状態とは？

テスト結果は results/ 配下に JSON として保存され、analyze_results.py で集計 & 可視化できます。 

python analyze_results.py results/load_test_results.json --graph

  • レポート例：

    • 総リクエスト数 / 成功数 / 429 数
    • 成功率（%）
    • レイテンシ（P50 / P95 / P99 / Max）
    • TPS の推移と、スケールが安定するまでの時間

  • README に掲載している例では、60 TPS で 5 分間テストした場合に： 

    • 成功率: 97.2%
    • 429: 2.5%
    • スケール安定まで: 約 3 分
    • Peak TPS: 59.8

といった形で、 「この設定なら実質 60 TPS は維持できそう」 と判断できます。

ベストプラクティスとツールの関係

Document Intelligence の公式ドキュメントでは、スロットリングを避けるために以下のようなベストプラクティスが示されています： 

  • 429 に対して Exponential Backoff（指数バックオフ） でリトライする
  • いきなり負荷をジャンプさせず、徐々に TPS を上げる
  • GET で結果をポーリングする際は、最低 2 秒以上あける
  • 必要に応じてサポートに TPS 増加をリクエストする(定常的にTPSが足りないなどのエビデンスが必要）

DocumentIntelligence_scaling_bench では、これらを実装に取り込みつつ、**「ベストプラクティスを守ると、実際にどのくらい安定するのか」**を確かめられるようにしています。

  • di_client.py 内でのリトライロジック
  • --warmup オプションでの緩やかな負荷増加
  • metrics.py / analyze_results.py での 429 分析

つまりこのツールは、単なるベンチマークではなく、 「ベストプラクティス込みの設計を検証するための実験環境」 という位置づけです。

本番設計にどう活かすか

このツールを使うことで、以下のような設計判断を “感覚” ではなく データベース で行えます。

  • バッチ処理で夜間に一気に 10 万件流し込みたい
    →何 TPS にすれば、何時間くらいで終わるか
  • Web API からリアルタイムに PDF をアップロードする
    →ピークアクセス時に レスポンスタイムと 429 発生率が許容範囲か
  • オートスケールだけで足りるか、それとも キューイングやバッファリングが必要か

特に「SLA を約束したい SaaS 側」のエンジニアにとっては、
事前にこうしたデータを取っておくことで、営業トークにも説得力が増します。

まとめ：まずは自分のリソースで叩いてみよう

  • Document Intelligence はデフォルト 15 TPS から、オートスケール & サポート依頼で高 TPS に対応できますが、自分たちのワークロードでどう動くかは検証しないと分からない。 
  • そのためのツールとして、DocumentIntelligence_scaling_bench は
    • セットアップが簡単で
    • Document Intelligence 向けのメトリクスが揃っていて
    • ベストプラクティスを踏まえた設計検証ができる
      という位置づけです。 

本番導入前に、いちど自分の Azure サブスクリプションで実行してみてください。

👉 GitHub: https://github.com/sasukeh/DocumentIntelligence_scaling_bench 

Discussion