アプリケーションサービスにアプリ単位のアプローチが重要な理由

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

人の心を読むことはできません（子どもたちは異論があるようですが、それはさておき）。しかし、F5の「State of Application Delivery」調査への回答なら読み解けます。アプリ開発者を自認する回答者の視点から分析すると、非常に興味深い実態が浮かび上がってきます。

開発者が重視するのは、スピード、セキュリティ、そしてスケーラビリティです。優先順位は必ずしもこの順ではありませんが、3つすべてが重要です。さらに、これらすべての実現に役立つアプリケーションサービスの価値も認識しています。

つまり、開発者が求めているのは、漠然とした「高速化」をうたうアプリケーションサービスだけではありません。TCP最適化やキャッシュといった具体的な機能を提供するサービスです。さらに、Webアプリケーションファイアウォールや負荷分散も求めています。

問題は、こうしたアプリケーションサービスの大半が、共有インフラストラクチャモデルで提供されていることです。各アプリケーションには固有の「仮想表現」が割り当てられますが、物理的には共有のソフトウェアまたはハードウェア上に存在します。

これは深刻な問題を引き起こす可能性があり、IT部門とアプリ開発部門の間に今なお残る摩擦の一因にもなっています。システムを共有するという性質から、変更可能な時間帯や変更審査委員会、土曜の夜のデプロイ（不満を和らげるためのピザ付き）といったプロセスが生まれました。こうしたプロセスは開発を遅らせ、関係者全員にとってデプロイをストレスの多い作業にしています。

巨大なモノリシックアプリをデプロイする時代は終わりました。マイクロサービスに熱中してアプリを何百もの小さなサービスに分割していなくても、以前より多くのアプリを、より短い間隔でデプロイするようになっています。アプリ開発は1年単位のプロジェクトではなく1週間単位のスプリントで進められ、更新をより迅速かつ頻繁にリリースする必要があります。

結局のところ、（パブリック）クラウドがこれほど成功した大きな理由はそこにあります。自分のアプリと自分のインフラストラクチャなので、アップデートをプッシュする前にBobやAlice、Johnを待つ必要がないからです。すべて自分のものであり、問題が起きた場合の責任もすべて自分にあります。

同じアプローチはオンプレミスでも実現可能であり、むしろ望ましいと考えます。そのためには、アプリケーションのデリバリーチェーンを構成するすべての要素が、クラウドによって求められるようになったアプリケーション単位のアプローチに対応する必要があります。

基本的に、必要なネットワークサービスとアプリケーションサービスをアプリごとに提供するアプローチは、そのアプリケーション専用のサブネットを割り当てることに似ています。いわば、アプリケーション配信用VLANです。専用サービスを用意し、1つのアプリケーションに特化します。

このような分離は、デプロイスケジュールだけでなく、関係者全員にとっても有益です。障害は起こり得るため、発生時には影響範囲をできる限り限定する必要があります。アプリ単位のアーキテクチャなら、障害の影響を厳密に限定できます。そのため、「万一に備えて」待機している担当者も、呼び出しを受けずに済みます。月に1回リリースおよびデプロイするアプリに影響を与えることなく、毎週リリースおよびデプロイできます。自分のアプリ、自分のサービス、自分のデプロイスケジュール。

アプリケーション単位のアーキテクチャでは、本番環境で発生する問題のトラブルシューティングも容易になります。実際、こうした問題は頻繁に発生します。2017年のAtlassianの調査では、開発者の50%がコードのリリース後に本番環境で問題が発生したと回答しています。他の誰かによる変更がアプリケーションに影響した可能性はありません。そのため、どのシステムが関係している可能性があるのかを突き止めるために貴重な時間を費やすことなく、関係するシステムをすぐに調査できます。

アプリ単位のアーキテクチャは、パブリックかプライベートかを問わず、クラウドを前提としたモデルであるため、クラウドに自然に適合します。各アプリには、拡張、高速化、セキュリティ確保のための専用のアプリケーションサービス一式が用意されます。

実際のところ、アプリケーション単位のアーキテクチャが登場するのは必然でした。 これは以前から述べてきたことです。アプリケーションが周囲を引きつける力は無視できないほど強く、アプリケーションを保護するために必要なセキュリティも、ますます個々のアプリケーションに特化したものになっています。そのため、遅かれ早かれアプリケーション単位のアプローチが登場することは避けられませんでした。

これは望ましいことです。開発者が求めるアプリケーションサービスは、多くの場合、アプリケーションごとに異なるからです。あるアプリケーションで有効なものが、別のアプリケーションでも有効とは限らず、むしろ悪影響を及ぼす可能性もあります。アプリケーションデリバリにアプリケーション単位のアーキテクチャを採用することで、アプリケーションの拡張、保護、高速化に必要な機能を開発者に提供できるだけでなく、オンプレミスかクラウドかを問わず、開発者がクラウドに期待するセルフサービスモデルをより適切にサポートできます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事