なぜアプリケーションサービスへのアプリごと（Per-App）のアプローチが重要なのか

私は人の心を読むことはできませんが（私の子どもたちはそう思っていないでしょうが、それはまた別の話です）、当社の「アプリケーションデリバリの状況」調査の結果を読み解くことはできます。アプリケーション開発者のレンズを通してこの調査レポートを読むと、大変興味深い絵が浮かび上がってきます。

開発者が重視しているのは、スピード、セキュリティ、スケールです。優先度は必ずしもこの順番通りではないですが、いずれにしてもこれらの3要素を重視しています。また、開発者はこれらの3要素すべての実現をサポートしてくれるアプリケーション サービスの価値も認め、これを重視しています。

すなわち、開発者が求めているのは漠然とした「アクセラレーション」アプリケーション サービスだけでなく、TCP最適化とキャッシングを提供する具体的なサービスで、WAF（Web Application Firewall）とある程度のロードバランシングを立ち上げたいと考えています。

ここで問題となるのは、これらのアプリケーションサービスのほとんどが共有インフラストラクチャモデルを通じて提供されるという点です。各アプリケーションはそれぞれが独自の「仮想表現」を有していますが、物理的にはソフトウェアやハードウェアの共有部分に配置されています。

これが現実的な問題の原因になり得るとともに、IT部門とアプリケーション開発者の間に残る摩擦の原因の一部でもあります。このようなシステムの共有性こそ、変更ウィンドウとレビューボード、また週末の導入展開の原因です。これらのプロセスによって開発のスピードは遅くなり、導入展開において関係者のすべてが不満を持つことになります。

私たちは、もうモノリシックなモンスターアプリケーションを展開することはありません。たとえ注目されているマイクロサービスを使ったりアプリケーションを数百の細かいサービスに分解したりしていなくても、これまで以上に多くのアプリケーションを、これまで以上に頻繁なスケジュールで展開しなければなりません。これらのアプリケーションは年単位のプロジェクトではなく週単位の短いスパンで開発されているとともに、より短い期間で、より頻繁にアップデートする必要があります。

結局のところ、このような状況こそ（パブリック）クラウドがこれほど大きな成功を収めている理由です。クラウドではそれぞれが自分のアプリ、自分のインフラストラクチャであり、IT部門の誰かの手が空くのを待たなくても、アップデートすることができます。すべてが自分のもので、もし何かが起こったとしてもそれは自分の責任です。

これと同じアプローチは、オンプレミスに適用することも可能です。必要なことは、アプリケーションのデリバリチェーンを形作っているすべての構成要素が、クラウド普及の原動力となったものと同じタイプのアプローチ、すなわちアプリごと（Per-App）のアプローチをサポートすることです。

必要なネットワークサービスとアプリケーションサービスを提供するアプリごとのアプローチは、基本的にアプリケーションに合わせてサブネットを特化することに似ています（例えば、アプリケーションデリバリVLAN）。すべては1つのアプリケーションを対象としており、このアプリケーションに特化したサービスを提供します。

このようなアプリケーションの分離は展開スケジュールにとって好都合であるだけでなく、他のすべての関係者にとってもメリットがあります。もし何らかの障害が発生した場合、誰もが影響を受ける範囲をできる限り狭い範囲に限定したいと考えるでしょう。アプリごとのアーキテクチャでは障害の影響をごく狭い範囲に封じ込めることができるので、「万が一」に備えて待機しているすべてのスタッフは、駆り出されることがなくなり満足でしょう。また、毎月1回リリースと展開を実行するアプリケーションと衝突することなく、これらのアプリケーションのリリースと展開を毎週実行することができます。自分のアプリケーション、自分のサービスを、自分のスケジュールで展開できるのです。

アプリごとのアーキテクチャでは、本番環境で不意に発生した問題へのトラブルシューティングも簡単に実行できます。このような問題は、よく発生します。実際、Atlassian社が行った2017年の調査において、コードリリース後の本番環境で問題が発生したことがあると回答した開発者は50%に上ります。アプリごとのアーキテクチャでは、誰かが行った変更が自分のアプリケーションに影響を与えることはありません。障害に関係しているかもしれないシステムを探すことに貴重な時間を費やすことなく、ピンポイントに対象のシステムに対処することができます。

パブリックかプライベートかに関係なく、アプリごとのアーキテクチャは本来的にクラウドによくフィットします ―― なぜなら、そもそもこのモデルはクラウドを前提に構築されているからです。各アプリケーションには、スケーリング、スピードアップ、セキュリティに特化した一連のアプリケーションサービスが用意されています。

実際のところ、アプリごとのアーキテクチャは現れるべくして現れました。アプリケーションの引力は無視できないほど強く、アプリケーションの安全性維持に欠かせない、アプリケーションに特化したセキュリティの高まりは、遅かれ早かれアプリごとのアプローチの登場につながるものでした。

これは良いことです ―― なぜなら、開発者が求めるアプリケーションサービスは、大抵がアプリケーションに特化したものだからです。あるアプリケーションで役立つものが、必ずしも別のアプリケーションで役立つ必要はありません ―― むしろ悪影響を与える恐れがあります。アプリケーションデリバリにアプリごとのアーキテクチャによるアプローチを採用することで、開発者が求め、アプリケーションのスケーリング、セキュリティ、スピードアップに必要なものを提供できるだけでなく、オンプレミス／オフプレミスに関係なく開発者がクラウドに期待しているセルフサービスモデルを、より強力にサポートすることが可能になります。

＜より詳しく知りたい方へ＞

・BIG-IP Cloud Edition 製品ページ
https://www.f5.com/ja_jp/products/cloud-editions/big-ip-cloud-edition

・マンガでわかる！ アプリ開発チームとインフラチームの摩擦を解消する方法
https://interact.f5.com/jp-solutions-devops.html

・資料ダウンロード：アプリの展開スピードを向上させる為には？
https://interact.f5.com/boost-app-deployment-speed-jp.html