コードを書くJames Ward氏（本人による表現）は最近、現在と10年前のアプリケーションデプロイを比較した優れた記事を執筆しました。IT業界全体であまり知られていない事実の1つは、アプリケーションのアーキテクチャとデプロイの変化が、アプリケーションデリバリ（アプリケーションを利用者にとって高速かつセキュアで、利用可能な状態にするための実際のプロセス）に直接影響することです。たとえば、現在マイクロサービスによってもたらされている変化は、デプロイモデルだけでなく、ネットワークアーキテクチャを変えるという点でも大きなものです。
そう、分かっています。マイクロサービス、コンテナ化、クラウドへの移行によってネットワークが抽象化され、アプリケーションのネットワークへの依存度は低くなる、とお考えでしょう。開発者、そしておそらく運用担当者の視点では、そのとおりです。しかし、ネットワークは依然として必要です。やり取りされるデータは引き続きネットワークを経由する必要があり、ネットワーク上のサービスは、アプリケーションの高速化、セキュリティの確保、可用性の保証に関わる多くの機能を担っています。そのため、アプリケーションがそうしたサービスの存在を認識していなくても、アプリケーションを構成し、デプロイする場所や方法が変われば、必然的にサービスにも影響が及びます（実際、アプリケーションがその存在を知る必要はありません。いわば守護天使のようなものです）。
このような関係を踏まえ、たとえアプリケーション側がその関係を意識していなくても、Jamesの記事に触発され、この10年間でアプリケーションのデリバリー方法がどのように変化したかについても同様に振り返ってみました。
デプロイアーキテクチャ
| 2005 | 2015 |
| コンガライン | プラットフォーム |
 |  |
2005年当時、ネットワークチーム（NetOps）は、アプリケーションの配信に必要な各種アプリケーションサービスを、F5が「コンガライン」と呼ぶ形で導入していました。これらは個別のポイントソリューションでした。アプリケーションを高速化する必要があれば、Webパフォーマンス最適化製品を専用の独立したボックスに導入していました。負荷分散用に別のボックス、アプリケーションセキュリティ用にさらに別のボックスという具合です。やがて多数のボックスが長く連なるようになり、トラフィックはそのすべてを双方向に通過しなければなりませんでした。
2004年にアプリケーションデリバリコントローラーが登場し（2005年時点ではまだ非常に未成熟でした）、現在の形であるプラットフォームへと進化し始めました。こうしたプラットフォームは共通の機能と処理能力を備え、モジュール（プラグイン、アドオンなど、呼び方はさまざまです）によって拡張できます。プラットフォーム方式では、コンテナ化や仮想化によってアプリケーションとサービス間の移動時間が短縮されるのと同様に、「ネットワーク上」で費やす時間が大幅に短縮されます。また、現在のアプリケーションデリバリに必要な各種アプリケーションサービスの管理を標準化する共通基盤、すなわちプラットフォームを共有することで、運用コストを削減できる可能性もあります。
アプリケーションのデプロイが、コンテナやマイクロサービスなどの新しいテクノロジーを活用した、より使い捨て可能で分割されたアーキテクチャやクラウド環境へと移行する中、製品からプラットフォームへの進化は大きなメリットをもたらします。同じ標準化されたコアを使用して、さまざまなアプリケーションサービスを導入することも、単一のサービスだけを導入することもできるためです。これにより、導入するアプリケーションサービスの規模が拡大しても管理負荷を抑えられるほか、アプリケーションの成長に応じて必要なサービスを追加できます。
導入方法
| 2005 | 2015 |
| 手動デプロイ | プログラム可能なデプロイ |
 |  |
2005年当時、WebベースのGUIは標準的に使われ始めたばかりで、アプリケーションサービスのプロビジョニングと設定には主にCLIが使用されていました。この作業は、あらゆる手作業と同様に時間がかかり、アプリケーションサービスが複雑になるほど、さらに多くの時間を要しました。人為的ミスによる問題とその影響（ネットワーク内では、設定ミスの影響範囲が飛躍的に拡大します）を防ぐための確認作業にも、より多くの時間が必要でした。コピー＆ペーストが広く使われていましたが、確実な方法ではありませんでした。また、サービス管理の運用負荷が非常に大きかったため、こうしたサービスのメリットを享受できるのは、重要度の高いアプリケーションに限られていました。
時代は進み、2015年にはDevOps革命が到来しました。APIとテンプレートベースの構成によるプログラマビリティが、ネットワークを含むあらゆる領域を変えつつあります。アプリケーションサービスは、PuppetやChefなどの一般的なフレームワークを使用してAPI経由で自動化できるようになりました。また、Cisco APICやVMware NSXなどのオーケストレーションソリューションとの事前統合や、Python、Perl、bash、curlによるカスタム制御も可能です。アプリケーションサービステンプレートは、標準化と再利用を可能にし、インフラストラクチャを「コードとして」扱うことを促進することで、継続的デリバリーの実践をネットワークにも拡張できるようにします。
アプリケーションデリバリにおける継続的デリバリの普及度は、アプリケーション開発ほど高くありません。しかし、アプリケーションデリバリは進化を遂げており、現在も進化を続けています。これにより、サービスの迅速なプロビジョニングによる市場投入期間の短縮と、自動化および再利用による運用コストの削減を実現する、プログラム可能なデプロイオプションをサポートしています。
導入形態
| 2005 | 2015 |
| 大型専用機 | 仮想化 |
 |  |
2005年には、より大規模で高性能、高速かつ多機能なネットワークハードウェアの構築が急速に進みました。イーサネットの高速化とWebベースのアプリケーションの爆発的な増加に伴い、アプリケーションサービスの要件に対応するため、ネットワークに導入される大型ハードウェアも拡張されました。
現在は、密度とリソースの最適な活用が重視されています。つまり、仮想化とクラウドコンピューティングです。いずれも、アプリケーションデリバリープラットフォームの仮想化によって支えられています。現在、アプリケーションデリバリープラットフォームは、AWS、Microsoft Azure、Rackspaceなどのクラウド環境に加え、専用ハードウェアまたは汎用ハードウェアに導入可能な仮想アプライアンスとしても展開できます。この機能は、クラウド環境をサポートするだけでなく、マイクロサービスなどの新たなアーキテクチャに適応するためにも不可欠です。James Ward氏が指摘するように、今日のマイクロサービスやサーバー自体は「使い捨て可能で、不変かつ一時的なもの……」です。
つまり、DevOpsの領域へ移行しつつある多くのアプリケーションサービス（負荷分散、アプリケーションセキュリティ、最適化）は、Software-Defined Data Centerの基準を満たす必要があります。少なくとも、大規模環境でイミュータブルかつ使い捨て可能なモデルに適合できなければなりません。現在、多くのアプリケーションデリバリープラットフォームがこの段階に達しており、プログラム可能な導入オプションと組み合わせることで、この課題に対応する準備が整っています。
デプロイの責任
| 2005 | 2015 |
| ネットワークチーム | ネットワークチーム／DevOps |
2005年当時、そして現在でも多くの組織では、アプリケーションデリバリの導入と管理をネットワークチームが全面的に担っています。調達からプロビジョニング、構成に至るまで、デリバリのあらゆる側面をネットワーク運用部門が担当していましたが、現在もそうしているケースは少なくありません。この分断されたモデルでは、要件の調整、チケットの作成、アプリケーションのデリバリに必要なアプリケーションサービスのエンジニアによる手動でのプロビジョニングと構成に時間がかかり、遅延が生じていました。
現在も多くの組織でこの状況が続いていますが、クラウドとマイクロサービスの影響にDevOpsの導入が加わり、変化が生じています。IT as a Serviceへのニーズが高まる中、アプリケーションサービスの構成責任は、運用チーム、さらには開発チームへと移行しつつあります。アプリケーションと密接に関連するサービスは、物理的にもトポロジー上もアプリケーションの近くに配置する必要があります。その結果、DevOpsが主導的な役割を担い、これらのサービスのプロビジョニングと構成を担当することになります。
だからといって、ネットワークチームがアプリケーションデリバリへの関与をやめるわけではありません。アプリケーションや企業の懸念事項には、俊敏性よりも信頼性の確保を重視し、従来型の方法で提供されるアプリケーションサービスを必要とするものが相当数あります。こうしたサービスは現在もネットワークチームの担当領域であり、今後もその可能性が高いでしょう。一方、その他のサービスはDevOpsの担当へと移行しており、今後もその流れは続きます。
この10年間で、アプリケーションデリバリは大きく進化しました。個別製品の集合から統合プラットフォームへと発展し、プログラマビリティを備え、大型専用機からハイパーバイザーやクラウドへの導入をサポートする形へと変化しています。モバイルアプリケーション、マイクロサービス、DevOpsによって、アプリケーションの構築、デプロイ、配信方法が今後も大きく変わる中、最終的にそれらのアプリケーションを配信し、高速性、セキュリティ、可用性を維持するサービスも進化し続けると考えられます。
著者について
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ブログをご覧ください。