コンテナネイティブなアプリケーションサービス

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

クラウドネイティブアーキテクチャに不可欠な要素となるアプリサービスが増えています。これも一因となり、アプリサービスに対する責任がIT運用部門からDevOpsへと移行しつつあります。

F5では、State of App Services調査で30種類を超えるアプリケーションサービスを追跡しています。ほかにも多くのサービスがあるため、毎年リストを見直し、削除するものと追加するものを決定しています。

2020年は、複数のアプリケーションサービスをより広いカテゴリーに統合しました。たとえば、ネットワークファイアウォール、アンチスパム、IPS/IDS、スパム対策を「共通セキュリティサービス」にまとめました。このアプローチを採用した理由は2つあります。1つ目は、6年間のデータから、導入率が非常に近いアプリケーションサービスのグループが確認されたためです。2つ目は、新たに登場するアプリケーションサービスを追加する余地を確保するとともに、これまでも辛抱強くご協力いただいている回答者の負担を増やさないためです。

こうした新しいアプリサービスは、ほぼすべてがコンテナネイティブのアプリサービスです。必ずしもすべてではありませんが、一般に、クラウドネイティブアプリケーションの提供に必要な運用環境の一部として導入されます。たとえば、イングレス制御、サービスディスカバリ、サービスメッシュなどです。APIゲートウェイもクラウドネイティブアプリケーションと密接に連携することが多いものの、その用途は広く、あらゆるAPIベースのアプリケーションに対応します。

最新のクラウドネイティブアプリの提供において、これらの重要性が高まり、導入も驚異的なペースで進んでいる今こそ、クラウドネイティブなアプローチを支える立役者について詳しくご紹介します。

Ingress制御

State of Application Services 2020：導入環境におけるイングレス制御

Ingress controlは、HTTPリクエストを細かく振り分けるためにKubernetesに導入された概念です。オペレーターはURIを特定のKubernetes Serviceに簡単にマッピングできるため、受信（Ingress）リクエストを適切なマイクロサービスインスタンスにルーティングできます。

これは新しい概念ではありません。熱心な読者の方なら、より効率的なスケーリング戦略を支援するアーキテクチャコンポーネントとして、HTTP（レイヤー7）ルーティングの利点を私がたびたび取り上げてきたことをご存じでしょう。覚えていない方や初めてご覧になる方には、次の基調講演がよい振り返りになります：スケールできると思いますか？

新しいのは、この「マップ」の管理方法です。Ingressコントローラーは、コンテナクラスター内の現在の状況に応じて動的に更新する必要があります。そのため、Ingressコントローラーはクラスターの現在の状態を把握できなければなりません。つまり、運用APIを介して適切なKubernetesコンポーネントと統合する必要があります。

この統合によって、Ingress制御が環境と密接に結び付き、アプリケーションアーキテクチャに組み込まれます。完全な機能を備えたIngressコントローラーは、クラウドネイティブアプリケーションのスケーリングと運用に必要なインフラストラクチャの一部であるため、本質的に「コンテナネイティブ」です。

サービスディスカバリ

State of Application Services 2020導入：サービスディスカバリ

クラウドネイティブアプリケーションについて興味深い点の1つは、その構成要素の寿命です。コンテナクラスター内ではスケーラビリティが動的に変化するため、「コンテナ」は常に入れ替わります。Sysdigの最新データによると、この入れ替わりは増加しており、コンテナの39%は稼働時間が1分未満、54%は5分未満です。

問題は、他のコンポーネントがそれらのコンテナを検出できる必要があることです。

これこそが、存在意義です。サービスディスカバリコンポーネントはコンテナクラスター内で稼働し、サービスに関する「信頼できる情報源」として機能します。関係するコンポーネントは、このコンポーネントに問い合わせることで、特定のサービスへの接続方法や通信方法を確認できます。サービスをリアルタイムで追跡することにより、サービスディスカバリコンポーネントはクラスターの変動性に対応し、イングレス制御などの他のコンポーネントが適切に機能できるようにします。

サービスメッシュ

アプリケーションサービスの現状 2020：Service Meshの導入

サービスメッシュは、おそらく最も議論を呼んでいるコンテナネイティブなアプリケーションサービスです。その理由は、概念そのものの価値ではなく、実装方法に対する考え方の違いにあります。サービスメッシュは、コンテナクラスター内の可視性、スケーラビリティ、セキュリティに関する課題に対処するよう設計されています。サイドカー型またはアプリケーション単位の高度に相互接続されたプロキシとして実装され、開発者と運用担当者の双方に多様な機能を提供します。

サービスメッシュは、コンテナクラスターの外部で利用されるアプリケーションサービスではありません。ディスカバリーやイングレス制御と同様に、サービスメッシュはコンテナ環境と密接に統合されています。そのため、サービスメッシュもコンテナネイティブなアプリケーションサービスに該当します。

コンテナネイティブなアプリサービス

私たち（業界全体としても、企業としてのF5も）は、これまでアプリケーションサービスをこのように分類したことはありません。もちろん、セキュリティ、可用性、パフォーマンス、モビリティ、アイデンティティといった主な用途に基づいて分類することはあります。しかし、これらは広範な用途別の分類であり、特定のアプリケーションアーキテクチャに固有のものではありません。

しかし、これらのアプリサービス（および今後登場する可能性のあるその他のサービス）は、クラウドネイティブアーキテクチャに統合され、依存しているため、このような分類が必要になるかもしれません。アプリサービスの成長はアプリアーキテクチャの成長を明確に示し、その逆も同様だからです。アプリサービスとアプリが密接に結び付いており、両者の導入率が非常に近いものになるという、特有の状況です。

モバイルのiOSアプリとAndroidアプリを区別するのと同様に、コンテナ化された環境内でのみ動作するよう設計されたアプリサービスには、その他の環境でも動作するものと区別するため、「コンテナネイティブ」というタグを付けることが有用かもしれません。

どのように分類するにせよ、こうしたアプリサービスは、それらに依存するアプリとともに確実に増加しています。

著者について

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

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

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