クラウドとコンテナがアプリケーションサービスの分離を促進する仕組み

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

• アプリケーションは、それを支えるデリバリーインフラストラクチャの配置場所からフォームファクターに至るまで、あらゆる意思決定を左右します。組織の55%は、アプリケーションのニーズと要件に基づいてクラウドを選択しています。また、40%はアプリケーションに適したフォームファクターを選択できることを望んでいます。（State of Application Delivery 2018）
• クラウドとマイクロサービスのアーキテクチャによってアプリケーションが分割・分散されると、共有インフラストラクチャはメリットではなく負担となり、設備投資と運用のコストが増大します
• アプリケーション単位のアプリケーションサービスでアプリケーション単位のアーキテクチャを支えるうえで、コスト、構成、アップグレードが主な推進要因となります。
• 最新のアプリとアーキテクチャをサポートするには、アプリケーションサービスにアプリ単位のアプローチが必要です

ここ数年、Amazon、Microsoft、Googleなどのクラウドプロバイダーが、企業におけるアプリケーションサービスの切実なニーズに応えるため、足並みをそろえて取り組んできました。

現在、クラウドマーケットプレイスでは、セキュリティ（Webアプリケーションファイアウォールなど）やパフォーマンス（キャッシュ）、さらにはID管理に対応する多くのアプリケーションサービスが提供されており、その数は増え続けています。これは当然のことです。 企業は平均16種類のアプリケーションサービスを利用しています 。これにより、アプリケーションの高速性と安全性を高めています。その数は年々増加しています。企業がクラウドのスピードを得るために、こうしたサービスを手放すことはありません。

その点で、アプリケーションサービスは、お客さまとクラウドプロバイダーの双方に影響を与えています。しかし、その影響は一方向ではありません。クラウド、そして利用が拡大しているコンテナも、アプリケーションサービスとその提供方法に大きな影響を与えています。

企業がプライベート（オンプレミス）クラウドへの投資を継続し、コンテナの試行を進める中で、従来のアプリケーションサービス提供モデルが必ずしも適しているとは限らないことが明らかになっています。

ネットワークの大部分と同様に、アプリケーションサービスは長年にわたり、拡張性と信頼性に優れたハードウェアを基盤とするプラットフォーム（一般にApplication Delivery Controller、略してADCと呼ばれます）を介して提供されてきました。これらのデバイスは、高可用性と拡張性を実現し、数百のアプリケーションを同時にサポートできるよう設計されています。ネットワークかアプリケーションかを問わず、共有インフラストラクチャには以前からコスト面の利点がありました。設備投資と運用コストを複数のアプリケーションに分散することは合理的でした。

しかし、そうしたメリットが当てはまらないアプリケーションやアーキテクチャが登場しました。

アプリケーションとの親和性をより重視したアプローチを必要とするアプリやアーキテクチャが増えています。たとえば、多種多様な最新のマイクロサービスでは、単一のアプリケーション向けにアプリケーションサービスを展開できる、高速でスケーラブルかつ手頃な価格のプラットフォームが求められます。

共有サービスプラットフォームでは、アプリごとに専用設計されたプラットフォームのように、このニーズに対応することはできません。これには3つの明確な理由があります。

1. コスト。 利用するのが常に1人だけなら、12人乗りのバンを購入することはないでしょう。余分なスペースがあれば、初期費用も運用費用も増えます。適切な状況（および適切なアプリケーション）では、共有インフラストラクチャによってアプリケーションあたりのコストが下がり、財務面でも運用面でも大きなメリットがあります。しかし、1つのアプリケーションだけをサポートする場合は、価値を生み出さずに費用が増えるだけです。
2. 構成。最新のアプリとアーキテクチャは、頻繁な更新を前提として開発、デプロイされています。更新スケジュールが異なる8つのアプリとプラットフォームを共有している場合、問題が発生してそれらのアプリに影響が及べば、各アプリの担当者は不満を感じるかもしれません。さらに、構成の数が増え、規模が大きくなるほど、再読み込みや変更のたびに構成を読み取って検証する時間も長くなります。
3. アップグレード Bobは共有プラットフォームをアップグレードしたいのに、こちらはしたくない場合、どちらの意向が優先されるのでしょうか。Bobの意向が通り、その結果アプリケーションに不具合が生じれば、誰にとっても望ましい結果にはなりません。共有インフラストラクチャのアップグレードには、不安が伴うことがあります。また、構成を最新バージョンに合わせて更新またはアップグレード（場合によっては移行）するために、さらに時間がかかる可能性もあります。そうなると、結局は最初の問題に戻り、コストが積み重なっていきます。

単一のアプリケーションのみをサポートするよう専用設計されたアプリケーションサービスプラットフォームが必要とされ、需要も高まっています。対象を単一のアプリケーションに限定することで、構成の規模と複雑さを抑え、アップグレード失敗時の影響範囲をそのアプリケーションだけに限定し、導入コストと運用コストの両方を削減できます。

クラウド、コンテナ、マイクロサービスが普及したためです。また、DevOpsとデジタル経済により、組織にはより迅速かつ頻繁な提供が求められているためです。

アプリケーションとアーキテクチャは変化しています。環境も変化しています。それに伴い、アプリケーションサービスとその提供メカニズムも変わる必要があります。

著者について

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

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

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