F5 NGINX Gateway FabricでAIデリバリーを標準化

Karthik Krishnaswamyプロダクトマーケティング担当ディレクター | F5

企業は、AIの実験段階から運用段階へと急速に移行しています。この変化により、組織がアプリケーションデリバリインフラストラクチャに求める要件も変わります。

長年にわたり、Kubernetesのトラフィック管理は、技術的な実装の詳細として扱われることが少なくありませんでした。プラットフォームチームがIngressコントローラーを選定し、アプリケーションチームがルートを設定し、セキュリティチームが可能な範囲で制御を追加するという形です。このモデルは、主な課題がWebアプリケーションとAPIの提供であったときには機能していました。しかし現在、同じプラットフォームで、モダンアプリケーション、分散API、セキュリティポリシーに加え、希少で高コストなコンピューティングリソースを消費するAI推論ワークロードまでサポートする必要があるため、十分とは言えなくなっています。

この点が今重要である理由は、「2026 F5 State of Application Strategy Report」で明らかになっています。78%の組織がAI推論を自ら運用し、52%がAIモデルの適応と拡張にマルチモデルオーケストレーションを利用しています。つまり、企業は単一のサービスを通じて単一のモデルを呼び出すだけではありません。複数の環境で推論を実行し、複数のモデルを連携させ、AIを本番環境のアプリケーションアーキテクチャに組み込んでいます。

AIにより、企業が長年抱えてきた課題への対応がこれまで以上に急務となっています。それは、ガバナンス、セキュリティ、運用の一貫性を維持しながら、チームに必要なスピードを確保することです。

F5 NGINX Gateway Fabricは、Gateway API 1.5への準拠、F5 WAF for NGINXとの統合、Gateway API Inference Extensionのサポートという3つの重要な機能を組み合わせることで、この課題の解決を支援します。これらの機能により、Kubernetesのトラフィック管理を、より標準化され、セキュアで、AIに対応できるアプローチへと進化させることができます。

標準が重要な理由

Gateway APIは、多くのチームが同じ問題をそれぞれ異なる方法で解決しているという、企業でよく見られる課題に対処するため、Kubernetesのトラフィック管理における重要な標準になりつつあります。

従来のIngressアプローチは、実装固有のアノテーションやカスタム設定に大きく依存することが少なくありません。個々のチームでは機能しても、エンタープライズ規模ではガバナンスが難しくなります。ポリシーの監査が困難になり、移行手順も複雑化します。プラットフォームチームは、統制を維持しながらセルフサービスを提供することに苦慮する場合があります。アプリケーションチームは迅速に作業を進められる一方で、運用モデルが分断されてしまいます。

Gateway APIは、役割をより重視したKubernetesネイティブなモデルを導入します。プラットフォームチームは共有ゲートウェイインフラストラクチャを管理し、アプリケーションチームは自らのサービスのルーティングを定義できます。セキュリティチームと運用チームは、ポリシーを適用するためのより明確な仕組みを利用できます。その価値は、単なる技術的な洗練にとどまりません。より明確な運用モデルを実現できる点にあります。

その点で、NGINX Gateway FabricがGateway API 1.5に準拠していることは重要です。準拠しているからといって、すべての実装が同一であるわけではなく、アーキテクチャ上の判断が不要になるわけでもありません。しかし、成熟が進み、Kubernetesエコシステム全体でテストされている標準を基盤としていることに、企業はより大きな確信を持てます。

その意義は明確です。標準を採用することで、回避可能な複雑さを軽減できます。また、プラットフォームに関する意思決定を複数のチームやクラスターに展開しやすくなり、すべてのワークフローが独自仕様のパターンに固定されるリスクも低減します。さらに、すべてのアプリケーションを一斉に移行することなく、各チームが新しいトラフィック管理モデルを導入できるため、長期的なモダナイゼーションの基盤となります。

これは重要です。大企業におけるKubernetesの運用が、単一クラスターで完結することはほとんどないためです。多くの組織では、事業部門、地域、開発段階、クラウド環境にまたがって複数のクラスターを運用しています。共通のアプローチがなければ、クラスターごとに個別対応が必要になりかねません。NGINX Gateway Fabricを通じて実装されるGateway APIにより、プラットフォームチームはアプリケーションデリバリーの速度を落とすことなく、一貫性を確保できるようになります。

アプリが稼働する場所でのセキュリティ

セキュリティは、導入後に追加するよりも、プラットフォームに組み込むことで高い効果を発揮することが少なくありません。アプリケーションチームがセルフサービスと迅速なリリースサイクルを求めるKubernetesでは、特にその傾向が顕著です。

NGINX Gateway FabricとF5 WAF for NGINXの統合により、エンタープライズアプリケーションセキュリティをKubernetesゲートウェイレイヤーにより近い位置で実現できます。この統合により、セキュリティチームはアプリケーション保護ポリシーを定義・管理でき、プラットフォームチームはKubernetesネイティブのワークフローを通じて、その保護機能を利用可能にできます。

ビジネス上の価値は、すべてのITリーダーがポリシー適用の技術的な仕組みを理解することにあるのではありません。セキュリティチームが保護ポリシーの管理責任を維持しながら、プラットフォームチームとアプリケーションチームが引き続き迅速に業務を進められることにあります。

このような責任の分離は極めて重要です。セキュリティ対策が、各アプリケーションチームによる制御の適切な実装に依存していると、企業全体の保護にばらつきが生じます。一方、セキュリティ対策によってリリースのたびに遅延が生じれば、各チームは回避策を探すようになります。より優れたモデルは、ガバナンスを共有することです。セキュリティチームがポリシーを定義・管理し、プラットフォームチームが適用ポイントを提供することで、アプリケーションチームはソフトウェアの提供を継続できます。

顧客向けアプリケーション、API、AI対応サービスのKubernetesへの移行が進む中、これは特に重要です。プラットフォームの戦略的重要性が高まるにつれて、リスクの範囲も拡大します。Webアプリケーションへの攻撃、設定ミス、管理されていないルート、一貫性のないセキュリティ態勢は、単なる技術上の懸念にとどまらず、事業継続性、コンプライアンス、評判にも関わる問題となります。

ゲートウェイレベルのWAFモデルは、セキュアな開発プラクティスや、より広範なアプリケーションセキュリティプログラムに取って代わるものではありません。しかし、アプリケーションの配信ポイントに近い場所に、実用的なポリシー適用レイヤーを設けることができます。これにより、セキュリティを、デプロイのたびに後追いで対応する個別のプロセスではなく、プラットフォームアーキテクチャの一部として組み込めます。

AI推論への準備

AIワークロードは従来のWebリクエストとは異なる動作をするため、AI推論によってトラフィック管理のあり方が変わります。

従来のWebリクエストは通常、処理時間が短く、比較的予測しやすいものです。一方、推論リクエストは、処理時間、ペイロードサイズ、コスト、リソースへの影響が大きく異なる場合があります。1件のリクエストが高価なGPUリソースを長時間占有することもあります。タスクに応じて複数のモデルを使い分ける場合もあります。コスト、パフォーマンス、精度のそれぞれに最適化されたモデルが使用されることもあります。ルーティングの判断は、ユーザーエクスペリエンス、インフラストラクチャの利用効率、運用コストに影響を及ぼす可能性があります。

このため、Gateway API Inference Extensionが重要になります。モデルを考慮したルーティングが可能になり、モデルのバージョン、種類、コストパフォーマンス特性に基づいてリクエストを振り分けられます。NGINX Gateway Fabricのサポートにより、価値が比較的低いリクエストや遅延を許容できるリクエストを、よりコスト効率の高いモデルにルーティングしながら、ユーザーエクスペリエンスとインフラストラクチャの利用効率を向上できます。

重要なのは、基盤となるスケジューリングの仕組みではありません。AIデリバリーには、運用面での成熟が必要だということです。78%の組織がAI推論を自ら運用している現在、推論はもはやデータサイエンスだけの課題ではなく、エンタープライズアプリケーションデリバリースタックの一部となっています。また、52%がマルチモデルオーケストレーションを利用しているため、トラフィック管理では、より動的なAI環境を考慮する必要があります。

NGINX Gateway FabricによるInference Extensionのサポートは、プラットフォームチームや機械学習チームが、使い慣れたKubernetes運用モデルにAIワークロードを組み込むのに役立ちます。AI専用のデリバリーアーキテクチャを別途構築するのではなく、標準に準拠したゲートウェイアプローチを使用して、AIサービスをアプリやAPIと併せて管理できるようになります。

だからといって、企業のAIに関するあらゆる課題をゲートウェイで解決できるわけではありません。モデルガバナンス、データガバナンス、セキュリティテスト、コスト管理、コンプライアンスには、引き続き、より広範な統制が必要です。しかし、ルーティングはAI本番環境の基盤を成す要素です。リクエストが効率的に振り分けられない場合、インフラストラクチャからのシグナルが無視される場合、または各チームが推論への経路を個別に構築する場合、複雑さは急速に増大します。

最も重要な変化はアーキテクチャにあります。AIは、安全性と可観測性を確保し、ポリシーに基づいてデリバリーする必要がある、新たな種類の本番ワークロードになります。

AI時代のモダンなアプリケーションデリバリー

NGINX Gateway Fabricは、単なるKubernetesネットワーキングコンポーネントとして評価すべきではありません。モダンなアプリケーションデリバリを実現する、より広範なプラットフォーム戦略の一環として捉える必要があります。

Gateway API 1.5への準拠、F5 WAF for NGINXとの統合、Inference Extensionのサポートを組み合わせることには、次の3つの優先事項を結び付けるという重要な意義があります。

• 標準化：Kubernetesのトラフィック管理を成熟しつつあるコミュニティ標準に準拠させることで、断片化を抑えます。
• セキュリティ：Kubernetesアプリケーションが公開される場所により近い位置で、エンタープライズアプリケーション保護を適用します。
• AI対応の準備: 従来のサービスよりも動的で、多くのリソースを必要とし、ビジネス上の重要性が高い推論ワークロードに対応できるよう、デリバリーレイヤーを準備します。

実務上のメリットは、より一貫性のある運用モデルを実現できることです。プラットフォームエンジニアリングチームは、共有インフラストラクチャとセルフサービスのパターンを提供できます。アプリケーションチームは、独自のトラフィックモデルを考案することなく、開発を迅速化できます。セキュリティチームは、確立された制御を通じてポリシーを適用できます。MLチームは、AIデリバリーを個別対応のアーキテクチャとして扱うことなく、推論ワークロードをKubernetesに導入できます。

これが重要なのは、AI導入の次の段階では、組織が立ち上げたパイロットの数だけでなく、AI対応アプリケーションを本番環境でどれだけ高い信頼性とセキュリティ、効率性をもって運用できるかが評価基準となるためです。

多くの企業には、Kubernetesプラットフォーム、アプリケーションデリバリーインフラストラクチャ、セキュリティプログラム、AIイニシアチブ、そしてそれぞれを担当するチームがすでに揃っています。課題は、これらの要素をスケーラブルな形で統合することです。NGINX Gateway Fabricは、標準に準拠したゲートウェイレイヤーを提供し、従来のアプリケーション、API、セキュリティポリシー、新たなAI推論パターンをサポートできるようにすることで、組織の取り組みを支援します。

これは実用的な価値提案です。組織は、ゼロからやり直したり、アプリケーションデリバリーアーキテクチャを一から再構築したりする必要はありません。Kubernetesのトラフィック管理を、より一貫性とセキュリティが高く、AIワークロードへの対応準備が整ったモデルへと進化させることができます。これにより、Kubernetesのトラフィック管理を、より一貫性とセキュリティが高く、AIワークロードへの対応準備が整ったモデルへと進化させる道筋が得られます。

AIがエンタープライズアプリケーションに深く組み込まれるにつれ、インフラストラクチャに関する議論もそれに合わせて進化させる必要があります。ゲートウェイの役割は、もはやトラフィックをクラスターに取り込むことだけではありません。最新のアプリケーション、API、AIサービスを大規模に配信、保護、運用するためのコントロールポイントになりつつあります。

詳細については、F5 NGINX Gateway FabricのWebページをご覧ください。

また、ぜひF5 AI Summitにもご参加ください。6月23日（火）に開催される3時間のオンラインイベントで、「Delivering AI on Kubernetes with F5 NGINX」セッションでは、Kubernetes上でのAIワークロードのデリバリーについて詳しくご紹介します。

著者について

Karthik Krishnaswamyプロダクトマーケティング担当ディレクター | F5

Karthik Krishnaswamyのその他のブログ記事