AI901-Concept#78-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある EC 企業が、商品検索チャット ボットを Azure AI Foundry にデプロイし、ピーク時 (年末セール) は通常時の 10 倍のトラフィックを処理する必要があります。安定したレイテンシと予算予測可能性を両立する必要があります。
解決策
通年で従量課金 (Pay-as-you-go) のみで運用し、ピーク時は単純に並列リクエスト数を 10 倍に増やします。容量予約や PTU は使用しません。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
従量課金のみではピーク時のレイテンシ安定性とレート制限抵触リスクが大幅に高まります。Azure OpenAI / Foundry の Pay-as-you-go テナント レート制限は明示的に設定され、10 倍のトラフィック急増では 429 Too Many Requests が頻発し、結果として SLA 違反と顧客体験悪化を招きます。さらに従量課金のコストは予算前読みが難しく、財務計画にも不利です。大規模本番では PTU で基準容量を確保し、必要に応じてスピル オーバーする設計が標準です。
【「はい」が違う理由】
設計上の安定性とコスト予測のいずれも満たせず、本番品質には不適切です。非機能要件を満たせない設計のため、「目的を満たす」と判定する根拠はありません。 スピル オーバー機能を活かさない構成は Foundry の本番運用ガイダンスにも反します。 結果として SLA 違反が発生しやすく事業継続性を損ねます。
従量課金のみではピーク時のレイテンシ安定性とレート制限抵触リスクが大幅に高まります。Azure OpenAI / Foundry の Pay-as-you-go テナント レート制限は明示的に設定され、10 倍のトラフィック急増では 429 Too Many Requests が頻発し、結果として SLA 違反と顧客体験悪化を招きます。さらに従量課金のコストは予算前読みが難しく、財務計画にも不利です。大規模本番では PTU で基準容量を確保し、必要に応じてスピル オーバーする設計が標準です。
【「はい」が違う理由】
設計上の安定性とコスト予測のいずれも満たせず、本番品質には不適切です。非機能要件を満たせない設計のため、「目的を満たす」と判定する根拠はありません。 スピル オーバー機能を活かさない構成は Foundry の本番運用ガイダンスにも反します。 結果として SLA 違反が発生しやすく事業継続性を損ねます。
コメント