AIアプリケーションデリバリーの課題トップ10：レイテンシーに対応できない

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

レイテンシーは、ユーザーの信頼を損ない、インシデントを急増させ、気づかないうちに予算を燃やし尽くし始めるまでは、誰もが「単なるパフォーマンスの問題」と見なしてきました。元の「ADC06」では、これをアプリケーションデリバリの問題として正しく捉えています。レイテンシーが1つのレイヤーだけに収まることはほとんどなく、行儀よく留まってもくれないからです。AIはこの状況をさらに顕在化させ、コストを押し上げ、スピナーでごまかすことをはるかに難しくします。

理由は単純です。AI体験はインタラクティブであり、会話のような応答を待っているとき、ユーザーは遅延を通常とは異なるものとして感じます。ページの読み込みが遅いと、いら立ちを覚えます。一方、「アシスタント」の応答が遅いと、何か問題があるように感じられます。待ち時間が長くなるほど、ダッシュボードで確認するまでもなく、ユーザーはそのシステムを「役に立つ」ものから「信頼できない」ものへと認識し直していきます。

パフォーマンスへの影響

従来のアプリケーションデリバリでは、レイテンシは応答時間の遅延として現れる傾向があり、アプリケーションの動作が重く感じられます。ユーザーから不満の声が上がり、NPSが低下し、コンバージョン率にも悪影響が及ぶと、原因はネットワークなのか、アプリケーションなのか、データベースなのか、それとも「クラウド」なのかという、いつもの議論が始まります。この問題は以前から現実に存在していましたが、同時によく知られた問題でもあるため、チームはその原因をどのように分析すべきかを理解しています。

AIでは、レイテンシーは単なる遅さではなく、能力不足と受け取られるようになります。ユーザーは長い待ち時間を「分散システムならではの処理」とは捉えません。ためらいや混乱、あるいは障害だと受け取り、いったんそう認識されると、その印象はなかなか消えません。最終的に出力が返ってきたとしても、システムが確信ではなく不確かさを示してしまったため、すでに不利な状況に置かれています。

トークンに左右される動作は、従来のアプリでは生じなかった形で、この問題をさらに悪化させます。誰もが「念のため」とコンテキストを追加し続けるため、プロンプトは時間とともに長くなります。また、モデルは制約を設けない限り出力を続けるため、出力サイズが膨れ上がることもあります。インフラストラクチャに問題がなくても、システムの性能が低下したからではなく、処理量が増えたことで、遅いと感じるエクスペリエンスになる可能性があります。

可用性への影響

レイテンシーは、以前からパフォーマンスの問題に見せかけた信頼性の問題です。依存先の応答が遅くなると、タイムアウトが発生します。タイムアウトが発生すると再試行が行われ、再試行によって負荷が増加します。負荷が増加すると、すべての処理がさらに遅くなります。その結果、技術的には何も停止していないにもかかわらず、障害のように振る舞う連鎖的な事象が発生します。

AIシステムは一般的なアプリケーションスタックよりも多くの構成要素を持つため、レイテンシーが可用性インシデントにつながりやすいという特徴があります。モデルエンドポイント、ゲートウェイ、オーケストレーションレイヤー、検索サービス、ツール実行システムに加え、多くの場合、リクエストの処理経路上でポリシーが適用されます。いずれかの要素の応答が遅くなり始めると、複雑で診断しにくい形でユーザー体験が低下します。

エージェント型ワークフローでは、単なる遅延であっても信頼性の低下に見える、別の障害パターンが生じます。エージェントは1回のユーザー操作に対して複数のアクションを実行する傾向があり、次のステップが前のステップの結果に依存するため、多くの場合は順番に処理します。そのため、ツール呼び出しが遅いと、システム全体が遅くなるだけでなく、処理の進行も妨げられます。多数のセッションがブロックされると、キューが蓄積し、同時実行性が損なわれます。その結果、タイムアウトやセッションの中断が発生し、トレースを確認するまでは理不尽に思えるユーザーからの苦情が急増するなど、システムにダウンタイムのような症状が現れ始めます。

スケーラビリティへの影響

AIシステムのスケーラビリティが誤解されやすいのは、実際の制約がリクエスト当たりの処理時間であることが多いにもかかわらず、チームがリクエスト量を基準に考え続けているためです。レイテンシが増加すると、各セッションが開いたままになる時間が長くなり、コンピューティングリソースがより長時間占有されるため、実効スループットが低下します。

AIではばらつきが加わるため、この影響はさらに顕著になります。短時間で処理できるリクエストもあれば、大規模なプロンプト、大量の情報取得、長い出力、複数回のツール呼び出しを伴うものもあります。平均値を基準に設計すると、テール部分が深刻な問題を引き起こします。AIシステムにおけるテールは、丸め誤差として無視できるものではありません。ユーザーが覚えているのは過去最高の応答ではないため、テールレイテンシーがそのままユーザー体験を左右します。

同時実行性の特性も異なります。AIワークロードは多くの場合、対話型かつセッション指向であるため、整然としたステートレスAPIトラフィックのようには動作しません。システムはコンテキストを保持し、後続のリクエストを処理しながら、一貫した体験を維持する必要があります。レイテンシが徐々に増加すると、1秒あたりに処理できるリクエスト数だけでなく、1分あたりに対応できる会話数も減少します。応答性が製品価値を左右する場合、この違いは重要です。

運用効率への影響

レイテンシーは、予測できるにもかかわらず苛立たしい形で運用に負担をかけます。通常、最初の対応はキャパシティの追加です。最も迅速に実行でき、正当化もしやすいためです。次に行われるのは、多くの場合キャッシュの追加です。巧妙な対策に思え、実際に役立つ可能性もあります。3つ目は通常、信頼性を求めて再試行を追加することです。その結果、いつの間にか、処理の遅さを負荷の増幅へと変えるシステムができあがっています。

時間が経つにつれ、レイテンシーによって、チームが機能の提供よりもデリバリーシステムの保守に多くの時間を費やす運用モデルが定着します。AIでは、パフォーマンスがエンドツーエンドかつ複数の領域にまたがるため、この問題がさらに深刻になります。その結果、単一の一貫したパイプラインとしてデバッグされることを想定していない複数のチーム、ベンダー、サービスを横断してトラブルシューティングすることになります。調査のたびに依存関係と処理時間の全体像を把握する必要があり、答えが単純であることはほとんどありません。

レイテンシの課題を軽減するためのベストプラクティス

最初に実践すべき最も重要なことは、AIデリバリーをモデルの問題ではなく、デリバリーの問題として捉えることです。推論だけを最適化するのは、交通量や道路、交差点を無視してエンジンだけを改良するようなものです。モデルの呼び出し前後に行われる処理も含め、ユーザー入力から最終回答に至るまでの経路全体を考慮する必要があります。

AIワークロードは距離とキューの深さに影響されやすいため、ルーティングが再び重要な調整手段となります。推論処理と検索処理の距離に加え、リクエストの種類に応じて適切なキャパシティプールを選ぶことも重要です。正常なエンドポイントでも、過負荷状態にある場合や、距離が遠い場合、低速なダウンストリーム依存関係と組み合わされている場合には、必ずしも最適とは限りません。システムの負荷が高まったとき、インテリジェントなルーティングが、利用可能なエクスペリエンスを維持できるか、緩やかな機能不全に陥るかを左右します。

AIの需要は突発的かつ予測不能であり、キャパシティプランニングだけではこの現実に対処できないため、適応型のリソース割り当ても必須です。システムには、リクエストシェーピング、グレースフルデグラデーション、モデル選択戦略、1回のインタラクションで実行可能なオーケストレーション量の制限など、高負荷時のリソース消費を制御する仕組みが必要です。これらは単なるコスト管理ではなく、安定性を維持するための制御でもあります。

まとめ

レイテンシーは、アプリケーションデリバリーにおける根本的なリスクであり続けてきました。ADC06がこれを指摘したのには、十分な理由があります。AIによってこのリスクがより顕在化し、影響もさらに深刻になります。AIの利用時に遅延が生じると、信頼性に欠けると感じられ、信頼性の欠如は、ほぼ何よりも早く導入の妨げとなるためです。

現在、AI対応アプリケーションを構築するうえで、レイテンシへの対処は、システムが十分に機能していると感じられるようにすること、実環境でも可用性を維持すること、コストの際限ない増大を避けながらスケールすること、そして運用チームが絶えずフォレンジックデバッグに追われる状況を防ぐことの一環です。従来の原則は今も変わりませんが、その影響はより深刻です。ユーザーはAIの応答時間を、システムがそもそも信頼して利用できるかどうかを判断する指標と捉えるためです。

世界中の組織が直面しているアプリケーションデリバリーにおける課題トップ10について、詳しくご覧ください。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事