AIアプリケーションデリバリのトップ10：互換性のないデリバリポリシー

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

互換性のないデリバリーポリシーは、かつては何か問題が起きて初めて注目される「アーキテクチャの健全性」に関する話題の1つでした。よくあるパターンです。あるチームがCloud Aのルーティングを変更し、別のチームがCloud Bのセキュリティルールを更新すると、突然、本番環境がステージング環境とはまるで別物のような挙動を示します。誰も安定して再現できず、確信を持って言えるのは「おそらくネットワークの問題だ」ということだけです。

ADC07は、この問題の本質を明確に指摘しています。環境間でデリバリーポリシーが整合していないと、パフォーマンスが予測不能になり、フェイルオーバーの信頼性が低下し、スケーリングのボトルネックが生じるほか、運用上の問題が山積します。

ここにAIが加わると、問題はじわじわと進行する混乱では済まず、一気に加速します。

パフォーマンスへの影響

互換性のない配信ポリシーは、ランダムに見えるパフォーマンス問題として現れます。ランダムな問題は常に最も厄介です。エンジニアは「ランダム」を修正できず、ただ追い続けるしかないからです。

AIのインタラクションは複数ステップの処理チェーンになることが多いため、トラブルシューティングは非常に困難になります。1件のユーザーリクエストが、検索、再ランキング、推論、ツール呼び出し、さらにもう一度の推論処理を引き起こす場合があります。いずれかの段階でポリシーが異なる環境間の境界を越えると、エクスペリエンス全体にジッターが生じます。

従来型アプリケーションでもモダンアプリケーションでも、互換性のないポリシーは、プロバイダー間の非効率なルーティングとレイテンシの増大を招きます。これが基本的な現実です。AIデリバリーでは、すべてが技術的には「稼働中」であっても、この非効率性によって、システムの応答が鈍く不安定に感じられます。

可用性への影響

ここで、互換性のないデリバリーポリシーは、単なる厄介事から障害の発生要因へと変わります。可用性は高負荷時にも一貫した動作を維持できるかどうかに左右されますが、互換性のないポリシーは、まさに高負荷時に顕在化する傾向があります。

典型的な例がフェイルオーバーです。あるプロバイダーのフェイルオーバーロジックが別のプロバイダーのものと整合していない場合、トラフィックを適切にリダイレクトできなかったり、技術的には稼働していても運用上の問題が生じているリージョンにリダイレクトされたりする可能性があります。ADC07では、冗長化とフェイルオーバーのアプローチが一致していないハイブリッドマルチクラウド環境におけるこの問題を明確に指摘しています。

AIでは、オーケストレーションとエージェントの動作という別のレイヤーが加わります。エージェントで遅延や障害が発生すると、多くの場合、再試行するか別の経路を試みます。環境ごとにデリバリーポリシーが異なる場合、こうした代替経路が同じように動作するとは限りません。その結果、システムが部分的な結果を返す、ワークフローの途中でタイムアウトする、アクセスしたツールエンドポイントによって異なる回答を返すといった「ソフト障害」が発生します。

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

マルチクラウド環境でスケーリングを実現するには、容量に余裕のある場所へトラフィックを自由に移動できるよう、ポリシーに十分な一貫性が必要です。配信ポリシーに互換性がない場合、スケーリングは利用可能なリソースの場所ではなく、「正しい」ポリシーが存在する場所に制約されます。

その結果、一部のリージョンに負荷が集中する一方で、ほかのリージョンは十分に活用されない状態になります。AIシステムでも、インフラストラクチャを拡張しながらポリシーの整合性を同様に拡張しなければ、まさに同じことが起こります。ある場所に十分なコンピューティングリソースがあっても、ルーティングルール、レート制限、セキュリティ上の制約によって、そのリソースを利用できなくなります。

AIでは、「1秒あたりのリクエスト数」という従来の考え方も通用しません。負荷を構成するのは、セッション、トークン、複数ステップのチェーンです。ある環境でペイロードサイズ、同時実行数、タイムアウトしきい値の制限が厳しいと、意図せずシステム全体のスケーラビリティに上限を設けることになります。さらに、処理先によって成功するセッションと失敗するセッションが生じると、ユーザーによる再試行で負荷が増幅し、スケーリングの負荷がさらなるスケーリングの負荷を生む、典型的な悪循環に陥ります。

運用効率への影響

互換性のないデリバリーポリシーがあると、運用チームはエンジニアリングではなく、ポリシーの読み替えに追われることになります。環境の境界を越えるたびに、意図を解釈し直さなければなりません。クラウドごとに独自の設定項目やデフォルト値があり、それぞれ特有の問題が日々の業務を妨げます。

プロバイダーごとに監視とレポートの基準が異なるため、すでに全体像の把握が難しく、インシデント対応にも時間がかかっています。AIではエンドツーエンドのトラブルシューティングが必要になるため、状況はさらに複雑になります。ユーザーから「アシスタントの応答が遅い」と言われた場合、原因が推論、検索、ルーティング、ツール呼び出し、ポリシー適用のどこにあるのかを特定する必要があります。

また、ポリシードリフトは机上の問題ではありません。AIデリバリーパイプラインでは、新しいコンポーネントが次々と追加され、ポリシーの一貫性への対応が「後で整理すればよい」と先送りされがちなため、この問題がさらに深刻化します。しかし運用において、この言葉は往々にして取り返しのつかない事態を招きます。

互換性のないデリバリーポリシーを緩和するためのベストプラクティス

解決策は地道であるがゆえに、実践が難しいものです。デリバリーポリシーは、誰かのコンソール操作に依存する属人的なノウハウではなく、第一級の成果物として扱う必要があります。

つまり、ポリシーは宣言的かつ移植可能で、環境を問わず一貫して適用される必要があります。ルーティングルール、フェイルオーバー動作、キャッシュに関する判断、レート制限、セキュリティ制御は、アプリケーションとともに移行でき、コードと同じ方法で検証できるようにする必要があります。クラウド間の手作業による変換に依存すると、構成のずれが生じます。このずれこそが、「昨日は動いていたのに」という問題の根本原因です。

可視化できないものは管理できないため、統合されたオブザーバビリティも必要です。クラウドごとに監視が分断されると死角が生じ、AIシステムはその死角を確実に突いてきます。テレメトリとポリシー検証チェックに一貫性を持たせることで、トラブルシューティングが遺跡発掘のような作業になるのを防げます。

最後に、特にAIシステムでは、最新のトラフィックパターンを理解するポリシーが必要です。エージェントやツール呼び出しは、従来のデリバリーポリシーでは想定されていなかった動作を生み出します。すべてのリクエストが整然としたユーザー主導のREST呼び出しであるかのようにポリシーを適用すると、正当なAIワークフローをブロックするか、危険なワークフローを見逃すことになります。どちらも、稼働時間やリスクの観点から望ましい結果ではありません。

まとめ

ADC07の本質的な問題は一貫性の欠如にあり、それは信頼性の高いデリバリーを妨げます。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のその他のブログ記事