かつて、アプリを配信するアプリサービスは、単純で一本道のデータパスを形成していました。基本的に、すべてのアプリが同じネットワーク上で同じ一連のサービスを経由していました。このシンプルなアーキテクチャにより、制御と実行をそれぞれ1か所に集約することが容易でした。これが、アプリケーションデリバリコントローラー（ADC）の台頭につながりました。ADCを介することで、アプリトラフィックの調整、振り分け、スケーリング、保護をすべて1か所で行えました。制御と実行を組み合わせることで、運用担当者はデータパス上に戦略的なポイントを確保し、そこであらゆるポリシーを適用、実行できました。
クラウドの台頭とコンテナ導入の継続的な拡大により、このデータパスは分断されました。現在、アプリケーションは複数のデータパスを介して配信され、その経路が動的に変化する場合もあります。制御と実行を単一の戦略的ポイントに集約することは、運用面でもアーキテクチャ面でも、多くの場合もはや現実的ではありません。
しかし、実行を異種のアプリサービス群に委任する場合でも、統合された制御ポイントが実現できなくなるわけではありません。
データパス上のアプリサービスを運用（デプロイ、構成、管理）するための制御ポイントは、できる限り少なくすることが重要です。複数の制御ポイントの使用を促すと、必然的にポリシーの競合が生じ、アプリの利用者に問題をもたらします。問題のトラブルシューティングも複雑になり、時間がかかるため、ユーザーの不満や不安が高まります。残念ながら、クラウドネイティブアーキテクチャをすでに多様化しているアプリポートフォリオに追加して管理する担当者からは、ツールの乱立が共通の問題として挙げられています。
2020年版「State of App Services」調査から、アプリサービスの運用は主に運用部門が担っているものの、関与しているのは運用部門だけではないことがわかっています。オンプレミスとパブリッククラウドのいずれにおいても、DevOps、NetOps、SecOpsの各チームがアプリサービスの運用に携わっています。
多くの場合、両者の違いは、担当するアプリケーションサービスの具体的な機能にあります。
DevOpsは主に、信頼性、パフォーマンス、アプリ固有のポリシーを担当します。一方、NetOpsは、その名が示すとおり、ネットワーク属性に重点を置きます。多くの場合、インフラストラクチャの観点からアプリサービスを維持するのはNetOpsです。SecOpsは、当然ながら、インフラストラクチャとアプリに関わるセキュリティを担当します。
しかし、職務が分担されているからといって、それぞれの業務に別々のツールを使用すべきとは限りません。現在、CI/CDパイプラインと継続的デプロイパイプラインが異なるツールセットで構築されていることを示す証拠は十分にあります。CI/CDパイプラインではJenkinsとGitリポジトリが主流である一方、継続的デプロイではAnsibleとPythonが多く選ばれています。ツールセットの選定では、日常的にツールを操作するさまざまな関係者の業務方法に適合するかどうかが大きな判断材料となります。
したがって、ポリシーの一貫性を高め、トラブルシューティングを迅速化し、ツールの乱立に伴う複雑さとコストを解消する単一のツールが登場するなら、そのツールには適切なインターフェースが必要です。これにより、データパス上のアプリサービスに関わる主要な担当者全員が、そのツールセットを活用して各自の職務を遂行できるようになります。
これは、アプリサービス自体の全体的なセキュリティと信頼性にとって重要です。制御ポイントを一元化することで、組織は変更が追跡され、その内容が把握されているという確信を持てます。イミュータブルな実装ではありませんが、制御を単一のツールに集約することで、その実践に向けて複数の段階を前進できます。
このようなツールの一例が「NGINX Controller」です。
想定どおり、運用と実行が分散していても、分析、API管理、セキュリティ、サービスメッシュなど、さまざまなアプリケーションサービスを一元的に制御できることがわかります。
どのような環境でも、設定ミスや設定の競合によって生じ得る問題を軽減するには、データパスのコンポーネント（アプリサービス）との連携を許可するツールの数を減らすことが重要です。最新のマルチクラウド環境では、データパスを構成するアプリサービスが指数関数的に増加することも多く、それに伴って複雑さが増すため、制御の一元化がさらに重要になります。
予算責任者にとってさらに大きなメリットとなるのは、反復的な手作業を自動化によってなくし、それに伴う運用コストを削減できることです。
そのための方法の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ブログをご覧ください。