ここ数年、同僚のCindy Borovickと私は、世界中のITプロフェッショナルから寄せられた数千件もの回答を、State of Application Delivery調査を通じて収集、集計、分析してきました。この調査では、F5らしく、アプリケーションサービスの全体像を把握することに主眼を置いています。調査結果を発表すると、このテクノロジーにあまり詳しくない方々から、よく同じ質問を受けます。「アプリケーションサービスとは何ですか？」
いい質問です。答えだけでなく、図も必要でしょう。図のない技術ブログなんて、退屈ですから。そう、退屈なのです。
この質問に対する最も簡単な答えは、「アプリサービスとは、ネットワーク上でホストされ、アプリケーションデータの検査、変更、拒否、転送、または変更を行うサービス」です。IT部門以外の人に説明するなら、「アプリサービスとは、現在地から目的地までの間にナビゲーションシステムで設定する経由地」です。実際、アプリサービスはデータパス上の経由地なのです。
データパスを分解する
データパスは、ローカルネットワーク、インターネット、企業ネットワークにまたがります。すべてのパケットは、ポイントA（クライアント）からポイントB（アプリ）に到達するまで、この経路を通ります。データパスを通過する間、パケットは複数のデバイスやサービスを経由する必要があります。各デバイスやサービスは、単純なルーティングから複雑な暗号処理まで、さまざまなネットワーク機能やアプリケーション機能を提供します。F5の調査では、アプリケーションとユーザーの両方に対して、セキュリティ、パフォーマンス、アイデンティティとアクセス、モビリティ、可用性を支援する26種類のサービスを追跡しています。これらのサービスはすべてデータパス内に導入されています。つまり、アプリケーションのリクエストとレスポンスは、宛先であるクライアント（アウトバウンド）またはアプリ（インバウンド）に到達するために、これらのサービスを通過する必要があります。
アプリケーションごとに要件やニーズは異なるため、それぞれに固有のデータパスと、それらに対応するアプリサービスが必要になると考えられます。要件やニーズには、ビジネス上の理由によるものもあれば、規制に基づくものもあります。その背景にかかわらず、いずれも満たす必要があります。そのために、アプリサービスが存在します。
このため、「ネットワークファイアウォール」のようなネットワーク系サービスもアプリケーションサービスに含めています。ネットワークファイアウォールは、通常はポートとIPアドレスのみを対象とするため、アプリケーションを認識する度合いが最も低いものの、アプリケーションを認識するサービスであることに変わりはありません。また、データパスが必ず通過するサービスの1つでもあります。F5が追跡しているアプリケーションサービスの中で最も広く導入されており、回答者の83%が現在少なくとも1つを導入していると回答しています。
ネットワークファイアウォールを通過した後も、データパスは多種多様なアプリサービスを経由します。興味深いことに、受信データパスと送信データパスは同じとは限りません。そのため、お決まりの図では両者を分けて示しました。実際、プログラマビリティが高度に発達した今日では、データパスがアプリごとだけでなく、リクエストごとに変化するケースが増えています。サービスプロバイダーネットワークには速度に対する厳しい要件があります。データ転送速度が光速の制約を受けることを無視できないのと同様に、サービスがリクエストやレスポンスを検査するたびに、少なくとも一定のレイテンシー（遅延）が加わることも無視できません。そのため、サービスネットワークの運用者は、動的サービスチェイニングに精通するようになりました。これは、現在転送しているアプリケーションデータに基づいて、データパスをリアルタイムで調整する仕組みです。
ほとんどの企業ネットワークは、設計上それほど柔軟ではありませんが、アプリサービスに関しては、受信データパスと送信データパスに違いが見られる可能性があります。セキュリティがその好例です。最新の調査に回答した企業のデータパス保護戦略を見ると、受信データパスと送信データパスでは、アプリサービスによって保護される頻度に違いがあります。Webアプリケーションファイアウォールなどのセキュリティアプリサービスが送信レスポンスを保護するケースよりも、受信リクエストを保護するケースの方がわずかに多くなっています。そのため、受信リクエストは、対応する送信レスポンスとは異なる経路を通る場合があります。
アプリケーションサービス
したがって、アプリサービスには、ネットワーク上に存在し得るさまざまな「機能」が含まれます。これらに共通する定義は、データパスがサービスを通過し（受信方向、送信方向、またはその両方）、アプリケーションデータの検査、拒否、転送、変更を可能にすることです。ここで「アプリケーション」という限定は極めて重要です。これがなければ、アプリケーションデータを処理することはほとんどなく、代わりにネットワークデータに基づいてパケットを可能な限り迅速かつ効率的に転送することに重点を置く、スイッチやルーターなども含める必要があるためです。
アプリサービスには、DNS、負荷分散、Webアプリファイアウォール、ネットワークファイアウォール、SSL VPN、キャッシュ、TCP最適化、SSL/TLSオフロードサービスなどがあります。F5が追跡している26種類のサービスのうち、ほとんどの組織が平均で少なくとも14種類を利用しており、2017年時点では4分の3近く（74%）が10種類以上のアプリサービスを導入していました。そのため、ここに掲載した図はやや単純化されています。実際の環境におけるアプリサービスの本格的な導入状況を十分に表現できていないからです。一方、データパスが曲線で描かれているのは現実に即しています。ケーブルは、さまざまな物理的障害物やラック、パッチパネルの上や間を縫うように配線されるためです。本当です。図でよく描かれるような直線ではありません。
F5が年次調査でアプリサービスについて質問するのは、それがF5の事業だからです。つまり、クラウドでもデータセンターでも（あるいは、その両方を組み合わせたような環境でも）、組織がアプリを稼働できるよう、アプリサービスを提供しています。長年にわたり、これらのサービスは「あれば便利な追加機能」ではなく、アプリ導入に不可欠な要素となってきました。拡張性、速度、セキュリティは、もはやアプリにとって任意の要素ではありません。これらは基本要件であり、多くの場合、アプリサービスの利用が必要になります。
意識しているかどうかにかかわらず（ほとんどの場合、意識せずに済むことが望ましいのですが）、API経由でもブラウザーのURL経由でも、アプリへのほぼすべてのリクエストは少なくとも1つ、多くの場合は複数のアプリサービスを通過します。拡張性、セキュリティ、パフォーマンスのいずれにおいても、今日のアプリケーションはアプリサービスの支援によって、より安全かつ高速に動作します。
著者について
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ブログをご覧ください。