ネットワークは枝分かれし、二分され、分散しつつあります。企業ネットワークという静かな郊外から、データセンターネットワークのアプリケーション側にある、慌ただしく騒がしい都市部へとネットワークサービスが移転する現象をどう表現するかは自由です。今回の主題は用語ではありません。なぜこの現象が起きているのかを掘り下げて考察します。
「でも、Lori、企業ネットワークがハードウェアに大きく依存しているのは明らかですし、ハードウェアには、開発・運用部門の先進的でアジャイルな環境に適応するために必要な柔軟性や俊敏性がないだけでしょう」と言う人もいるかもしれません。
いえ、そうではありません。 ハードウェアかソフトウェアかという問題ではありません。実際、何をするにもハードウェアは必要だからです（RAM、コンピューティング、ネットワークアクセスなどのリソースが何もないところから生まれるわけではありません）。むしろ、一部のサービスを一方から他方へ移行させる要因となっているのは、2つのネットワークそれぞれを支配する運用文化と現実です。
実際に起きているのは、アプリケーションが今や重心となり、月が地球に引き寄せられるのと同じように、アプリケーションとの親和性が高いあらゆるサービスを引き寄せているということだと思います。
実際、負荷分散、キャッシュ、アクセラレーション、Webアプリケーションセキュリティなど、アプリケーションに密接に関連するサービスは、個々のアプリケーションに固有のものです。あらゆるアプリケーションに一律に適用できるサービスではありません。むしろ、1つのアプリケーションの配信、保護、最適化を目的としたポリシーを備える、対象を絞ったアプリケーション中心のサービスです。
すべてではありません。同じ種類のものすべてでもありません。たった1つ。そこにある、その1つです。
これは、たとえばネットワークファイアウォールやIPS/IDSとは大きく異なります。これらの動作は、実際には特定のアプリケーションにそれほど依存しません。Webアプリはポート80で動作するため、そのポートを開放し、ファイアウォールを通過できるようにします。そこに「アプリケーション」固有の要素はほとんどなく、同じプロトコル（HTTP）を使用し、同じポートで動作するという程度です。
一方、単一のURI（/login.x）に関連付けられた1つの入力フィールド（ユーザー名、メールアドレス、コメントなど）に対して、関連付け可能なデータの種類（文字列、整数、英数字など）とデータ量（15文字、12文字、100文字など）を規定するセキュリティポリシーの設定は、まさにアプリケーション固有のものです。スタイルシートの縮小や連結を制御するポリシー、ロードバランシングサービスにおけるアプリケーションのヘルスモニタリングも同様です。
アフィニティが重要な理由
現在、一般的な企業が管理するアプリケーションは平均約508個といわれています。 F5の調査によると 実際に500個以上を管理している組織は31%に上ります。しかし、ここで重要なのはこの数字そのものではなく、あくまで基準にすぎないという点です。多くの組織が、今後さらに多数のアプリケーションを構築する計画だからです。また、マイクロサービスアーキテクチャを採用する組織では、アプリケーション数が必ずしも変わらなくても、前述のアプリケーションアフィンなサービスを必要とする「システム」の数は変化します。
では、ある組織が管理対象のアプリケーション数を2倍に増やそうとしているとします。500個から始めて、一気に1,000個になるとしましょう。すべてのポリシーを1つずつプロビジョニング、設定、管理する必要があります。計算を簡単にするため、各アプリに必要なポリシーは、スケーリング用とセキュリティ用の2つだけとします。それでも、対応すべきポリシーは2,000個です。準備はいいですか？では、始めましょう。
そうです。問題は、企業ネットワーク内の「ハードウェア」に処理能力がないことではありません。むしろ、専用設計のハードウェアだからこそ処理でき、汎用サーバーをはるかに上回るキャパシティを備えています。問題は、すべてを実行するために必要なプロセスと人員です。必要なデバイスの数だけでなく、導入しなければならないアプリケーション固有のポリシーの数も問題になります。
しかも、必要なのは導入だけでなく更新です。アプリケーションに密接に関連するポリシーは、特定のアプリケーション向けに構成されているため、アプリケーションのアップグレードや修正の適用に伴い、関連するアプリケーションサービスのポリシーも更新が必要になる可能性が高まります。さらに、組織がより頻繁なデプロイを望めば、企業ネットワークの担当者が対応しきれなくなることは容易に想像できます。
一方、アプリネットワーク側では、開発チームと運用チームが意欲を燃やしています。アプリをデリバリーし、デプロイしたくてたまりません。自動化とオーケストレーションに関する新たなスキルを活用し、そのプロセスを加速する準備は万全です。
実際、運用担当者は、アプリケーションと密接に関連するサービスを次々と担い、それらを導入アーキテクチャやプロセスに組み込んでいます。DevOpsへの認識が高まり、SDNが業界での普及を後押ししたこともあり、現在ではほぼすべてのネットワークサービスでAPIが利用できます。さらに多くのサービスでは、アプリケーションを支えるインフラストラクチャの管理と導入に「Infrastructure as Code」アプローチを採用する運用担当者に最適なテンプレートが利用できます。
そのため、アプリケーションネットワークに登場する「アプリケーションサービス」が増え、エンタープライズITの重心がアプリケーションへと移りつつあります。
これは、ビジネスと運用を拡張するための戦略です。アプリケーションポートフォリオの急速な拡大に対し、ネットワークやアプリケーションの担当者を増員してブルックスの法則に抵触することなく対応する方法です。また、ネットワーク運用担当者が管理するポリシー数を突然、現在の2倍、3倍、あるいはそれ以上に増やすことで生じる混乱を避けながら、IT部門がアプリケーションをより迅速かつ頻繁に市場へ提供できるようにする方法でもあります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。