今をときめくバズワード「クラウドネイティブ」には、何とも皮肉が効いています。
まず注目すべきは、クラウドネイティブは、その名に反してクラウドを必要としないという点です。意外ですよね。この名称は、インフラストラクチャに依存し、クラウドの概念である弾力性、規模の経済、分散コンピューティングを中心に設計されたアプリケーションを構築する、というアーキテクチャアプローチに由来します。そして、これらの概念をアプリケーションデリバリのあらゆる側面に浸透させたのがクラウドコンピューティングであることは、疑いようがありません。その範囲は、アプリケーションアーキテクチャから自動化、APIベースの統合からインフラストラクチャにまで及びます。クラウドコンピューティングは、アプリケーションの開発、構築、デプロイの方法を変えました。パブリッククラウドで生まれたアプリケーションは、当然ながら同じ依存関係や特性の多くを備えるようになりました。したがって、この名称は、このアーキテクチャスタイルの語源を的確に表しています。
クラウドネイティブとコンテナの間にも、明らかな関連性があります。この点だけでも、同様の目標を達成するために主に仮想マシンとクラウドネイティブサービスを利用する、クラウドで生まれたアプリとは異なります。クラウドネイティブとコンテナが密接に結び付いているのは、関連するコンテナオーケストレーター(Kubernetes)が、アプリケーションと、弾力性を実現し、それを通じて求められる規模の経済を達成するために必要なインフラストラクチャを連携させるうえで、最も容易かつ広く普及している手段だからです。

クラウドネイティブアプリケーションでは、規模の経済を実現できるよう、コンポーネントを細分化します。そのため、クラウドネイティブとコンテナはほぼ同義とされています。需要のある機能だけをオンデマンドでスケールできる必要があります。このようにアプリケーションを機能単位で分割し、柔軟にスケールさせる仕組みは、従来、レイヤー7(HTTP)ルーティングを利用するアーキテクチャによって実現されてきました。クラウドネイティブも例外ではありません。こうした最新のアプリケーションにも同じ原則が適用され、通常はイングレスコントローラー(インフラストラクチャアプリケーションサービス)を使用して、受信リクエストをアプリケーションコンポーネントの適切なコンテナベースのインスタンスに振り分けます。
この分割は多くの場合APIレベルで行われ、URIをAPI呼び出しに対応付け、さらにそのAPI呼び出しを特定のコンテナServiceに対応付けます。Ingress制御はリクエストを適切なコンテナServiceに転送し、そのServiceがコンポーネント/アプリケーションインスタンスのプール全体にリクエストを分散します。これは2層構造であり、レイヤー7(HTTP)のIngress制御が、配信と処理を担う従来型のロードバランサー(POLB)にリクエストを振り分けます。
さらに、サービスレジストリにも依存しています。サービスレジストリは、内部的にはクラウドネイティブアプリケーションの伸縮性を実現するために必要な、もう1つのインフラストラクチャアプリケーションサービスです。サービスディスカバリの仕組みがなければ、負荷分散とイングレス制御が機能せず、その結果、アプリケーションも動作しなくなります。
コンポーネント、サービス、サービスレジストリ、ロードバランサー、イングレス制御の間にあるこの関係は、クラウドネイティブアプリケーションの原則を具現化したものです。アプリケーションコンポーネントとインフラストラクチャは、密結合することなく緊密に連携しています。レイヤー7ルーティングと従来型のロードバランシング機能がなければ、コンポーネントは規模の経済を実現することも、複数の環境に分散することもできません。インフラストラクチャとアプリケーションの依存関係は現実に存在し、アプリケーション提供というビジネス上の要請に応えるうえで極めて重要です。
これらはいずれも、いかなる種類のクラウドコンピューティング環境にも依存せず、必要ともしません。クラウドネイティブアプリケーションは単独でデプロイでき、実際にそのようにデプロイされることも少なくありません。コンテナとその実行場所に関するデータを見ると、実際には「オンプレミス」がパブリッククラウド環境よりも依然として優勢であることがわかります。

確かに、コンテナをプライベートクラウド(オンプレミス)にデプロイすることもできます。実際、F5の調査では、オンプレミスのプライベートクラウドが依然として最も広く利用されているクラウドモデルであることが引き続き示されています。F5の「State of Application Services 2019」では、回答者の4分の3超(79%)がオンプレミスのプライベートクラウドでアプリケーションを運用している一方、パブリッククラウドは45%にとどまり、依然として過半数に達していません。
クラウドネイティブアプリケーションは急速に普及しているアーキテクチャであり、今後5年間も成長が続くことは確実です。こうした最新のアプリケーションを適切に提供し、保護するには、インフラストラクチャのアプリケーションサービスとの関係性と依存関係を理解することが不可欠です。
著者について

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ブログをご覧ください。