ストーリー
田
田中VPoE
API Gatewayの設計ができたら、次はスケーリングだ。LLMアプリケーションのスケーリングは従来のWebアプリとは考え方が異なる部分がある
あなた
先月、CS-AIのリクエストが急増した時にOpenAIのレート制限に引っかかって30%のリクエストがエラーになりました
あ
田
田中VPoE
LLMアプリケーションのスケーリングはボトルネックが「自社インフラ」ではなく「外部APIのレート制限」にあることが多い。そこが従来との大きな違いだ
LLMアプリケーションのスケーリング特性
ボトルネックの違い
| 観点 | 従来のWebアプリ | LLMアプリケーション |
|---|---|---|
| ボトルネック | CPU/メモリ/DB | 外部APIレート制限、トークンスループット |
| スケール対象 | アプリケーションサーバー | Gateway + バックエンドAPI容量 |
| コスト | インフラ費用（比較的予測可能） | API従量課金（リクエスト数に比例） |
| 制約 | 自社インフラの物理限界 | プロバイダのTPM/RPM制限 |
プロバイダのレート制限
| プロバイダ | モデル | RPM制限 | TPM制限 |
|---|---|---|---|
| OpenAI | GPT-4o | 10,000 | 30,000,000 |
| OpenAI | GPT-4o-mini | 30,000 | 150,000,000 |
| Anthropic | Claude 3.5 Sonnet | 4,000 | 400,000 |
| Anthropic | Claude 3.5 Haiku | 4,000 | 400,000 |
注: 上記は一般的なTier 3-4の制限値例。実際の制限は契約・利用実績によって異なります。
水平スケーリング
Gatewayのスケーリング
Gateway スケーリング:
ALB
│
┌────────────┼────────────┐
▼ ▼ ▼
Gateway 1 Gateway 2 Gateway 3
(Fargate) (Fargate) (Fargate)
│ │ │
└────────────┼────────────┘
│
Redis (共有状態)
- レート制限カウンター
- キャッシュ
- セッション情報
オートスケーリング条件:
- CPU使用率 > 70%
- 同時接続数 > 80/Pod
- リクエストキュー長 > 100| スケーリング設定 | 値 | 説明 |
|---|---|---|
| 最小インスタンス数 | 2 | 高可用性のため最低2つ |
| 最大インスタンス数 | 10 | コスト上限 |
| スケールアウト閾値 | CPU 70% | 余裕を持った閾値 |
| スケールイン閾値 | CPU 30% | 過剰なスケールインを防止 |
| クールダウン期間 | 300秒 | 頻繁なスケーリングを防止 |
レート制限への対策
マルチプロバイダ分散
複数のプロバイダにリクエストを分散し、単一プロバイダのレート制限を回避します。
マルチプロバイダ分散:
リクエスト → Gateway → ロードバランサ
│
┌─────────┼─────────┐
▼ ▼ ▼
OpenAI Anthropic Azure
(40%) (40%) OpenAI
(20%)
各プロバイダのレート使用率を監視し、
余裕のあるプロバイダにリクエストを振り分ける| 戦略 | 説明 | メリット |
|---|---|---|
| ラウンドロビン | 均等に分散 | シンプル、実装が容易 |
| 重み付き分散 | レート残量に応じて配分 | レート制限到達を最小化 |
| レイテンシベース | 応答速度が速いプロバイダに優先 | ユーザー体験の最適化 |
| コストベース | 低コストプロバイダに優先 | コスト最適化 |
リクエストキューイング
レート制限に近づいた場合、リクエストをキューイングして平滑化します。
リクエストキューイング:
リクエスト到着
│
▼
レート制限チェック
│
├── 余裕あり → 即座にLLM APIコール
│
└── 制限に近い → キューに投入
│
▼
優先度付きキュー
┌──────────┐
│ Critical │ ← CS-AI
│ High │ ← FAQ Bot
│ Normal │ ← Code Review
│ Low │ ← バッチ
└──────────┘
│
▼ レート回復時に順次処理
LLM APIコールコスト考慮のスケーリング
予算ベースのスケーリング
| フェーズ | 月間予算消化率 | 対応 |
|---|---|---|
| 通常 | 0-70% | 通常運用 |
| 警告 | 70-85% | 低優先度リクエストを遅延処理に切替 |
| 制限 | 85-95% | 軽量モデルへの切替を開始 |
| 緊急 | 95-100% | Critical以外を一時停止、経営判断を仰ぐ |
# 予算ベーススケーリング設定
budget_scaling:
monthly_budget: 1000000 # 100万円
thresholds:
- level: "warning"
percentage: 70
actions:
- downgrade_model:
from: "gpt-4o"
to: "gpt-4o-mini"
services: ["code-review"] # 低優先度のみ
- notification:
channel: "#llmops-alerts"
- level: "critical"
percentage: 85
actions:
- downgrade_model:
from: "gpt-4o"
to: "gpt-4o-mini"
services: ["faq-bot", "code-review"]
- enable_aggressive_caching: true
- level: "emergency"
percentage: 95
actions:
- suspend_services: ["code-review"]
- notification:
channel: "#executive"
message: "AI API予算95%到達。追加予算承認が必要です"負荷テストと容量計画
負荷テストの観点
| テスト項目 | 目的 | 方法 |
|---|---|---|
| 最大スループット | Gatewayの処理限界を把握 | 段階的にリクエスト数を増加 |
| レート制限耐性 | レート制限発動時の挙動確認 | プロバイダの制限をシミュレート |
| フォールバック性能 | フォールバック時のレイテンシ | Primaryを意図的に障害させる |
| キャッシュ効果 | キャッシュありなしの比較 | キャッシュを無効化して比較 |
容量計画
容量計画の計算例:
現状:
CS-AI: 50,000 req/月 = 約1,700 req/日 = 約70 req/時（ピーク時x3 = 210 req/時）
FAQ Bot: 20,000 req/月 = 約670 req/日 = 約28 req/時（ピーク時x3 = 84 req/時）
Code Review: 10,000 req/月 = 約330 req/日 = 約14 req/時（ピーク時x3 = 42 req/時）
ピーク時合計: 336 req/時 = 5.6 req/分
6ヶ月後（成長率 月20% 想定）:
336 × 1.2^6 = 約1,000 req/時 = 約17 req/分
必要なGatewayインスタンス数:
1 Gateway = 100 req/分 処理可能
17 req/分 → 1インスタンスで十分（冗長性のため最低2）
必要なプロバイダレート制限:
17 req/分 = 1,020 RPM → 現在の制限（10,000 RPM）で十分まとめ
| ポイント | 内容 |
|---|---|
| ボトルネック | LLMアプリのボトルネックは外部APIのレート制限。自社インフラよりプロバイダ容量を重視 |
| マルチプロバイダ | 複数プロバイダに分散してレート制限を回避し、可用性も向上させる |
| 予算スケーリング | 予算消化率に応じて段階的にモデルダウングレードやサービス制限を行う |
| 容量計画 | 成長率を考慮した容量計画で、プロバイダのレート制限上限に到達するタイミングを予測する |
チェックリスト
- LLMアプリケーションのスケーリング特性を理解した
- マルチプロバイダ分散の戦略を説明できる
- 予算ベースのスケーリング設計を理解した
- 容量計画の計算方法を把握した
推定読了時間: 30分