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

クラウドネイティブ アーキテクチャの不可欠なコンポーネントとなるアプリ サービスが増えています。 これが、アプリ サービスの責任が IT 運用から DevOps へと移行している理由の 1 つです。

当社の「アプリ サービスの現状」調査では、30 を超えるさまざまなアプリケーション サービスを追跡しています。 他にもたくさんありますが、毎年リストを見直して、何を削除し、何を追加するかを決定します。

2020 年には、いくつかのアプリ サービスをより広範なカテゴリに統合しました。 たとえば、ネットワーク ファイアウォール、スパム対策、IPS/IDS、スパム軽減は、「共通セキュリティ サービス」に統合されました。  私たちがこのアプローチを選んだ理由は 2 つあります。 まず、6 年間のデータから、展開率が非常に類似したアプリ サービスのグループが示されたためです。 2 つ目は、新しいアプリ サービスのための余地を作り、すでに非常に忍耐強い回答者ベースを圧倒したくないからです。

これらの新しいアプリ サービスは、ほぼすべてコンテナ ネイティブ アプリ サービスです。 これらは通常、クラウド ネイティブ アプリケーションを配信するために必要な運用環境の一部として展開されますが、常にそうとは限りません。 イングレス制御、サービス検出、サービス メッシュについて考えてみましょう。 API ゲートウェイもクラウド ネイティブ アプリケーションと密接に結合されることが多いですが、その使用法は API ベースのアプリケーションとほぼ同様です。

最新のクラウドネイティブ アプリを提供する上での重要性が高まっていること、そして驚異的な導入率を目の当たりにしていることを考えると、クラウドネイティブ アプローチを推進するこれらの企業について詳しく説明するのは良いタイミングであると思われます。

進入制御

アプリケーション サービスの 2020 年の展開状況: 進入制御

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

これは新しい概念ではありませんでした。 熱心な読者は、私が HTTP (レイヤー 7) ルーティングの利点を、特に、より効率的なスケーリング戦略を支援するために設計されたアーキテクチャ コンポーネントとして頻繁に称賛していることを覚えているでしょう。 覚えていない方や、今参加したばかりの方は、この基調講演で復習すると良いでしょう。 それで、スケールできると思いますか?

新しいのは、「マップ」の管理方法です。 Ingress コントローラーは、コンテナ クラスター内の現在の状態に基づいて動的に更新する必要があります。 つまり、Ingress コントローラーはクラスターの現在の状態を可視化できる必要があります。 つまり、運用 API を介して適切な Kubernetes コンポーネントと統合することを意味します。

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

サービス検出

アプリケーション サービスの 2020 年の展開状況: サービス検出

クラウド ネイティブ アプリケーションに関する興味深い事実は、その複合パーツの寿命です。 コンテナ クラスター内のスケーラビリティの動的な性質は、必然的に「コンテナ」が常に変化していることを意味します。 Sysdig の最新データによると、コンテナの 39% が 1 分未満、54% が 5 分未満で稼働しており、フラックスが増加していることがわかります。

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

これがサービス検出コンポーネントの存在意義です。 これらのコンポーネントはコンテナ クラスター内で実行され、サービスの「信頼できるソース」として機能します。 関心のある当事者は、このコンポーネントを照会して、特定のサービスに接続して通信する方法を調べることができます。 サービス検出コンポーネントは、サービスをリアルタイムで追跡することで、クラスターの不安定性に対処し、イングレス制御などの他のコンポーネントが適切に機能できるようにします。 

サービスメッシュ

アプリケーション サービスの 2020 年の展開状況: サービスメッシュ

サービス メッシュは、おそらくコンテナ ネイティブ アプリ サービスの中で最も議論の多いものです。 概念的な価値のためではなく、実装上の好みのためです。 サービス メッシュは、コンテナ クラスター内の可視性、スケール、セキュリティに関する問題に対処するように設計されています。 これらは、サイドカーまたはアプリごとのハイパーコネクテッド プロキシとして実装され、開発者とオペレーターの両方にさまざまな機能を提供します。

サービス メッシュは、コンテナ クラスターの外部にあるアプリケーション サービスではありません。 検出やイングレス制御と同様に、サービス メッシュはコンテナ環境と密接に統合されています。 これにより、コンテナネイティブ アプリ サービスにもなります。 

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

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

しかし、クラウド ネイティブ アーキテクチャへの統合と依存関係により、これらのアプリ サービス (および将来登場する可能性のあるその他のサービス) では、そうすることが必要になる可能性があります。 これは、一方 (アプリ サービス) の成長が他方 (アプリ アーキテクチャ) の成長を明確に示し、その逆も同様であるためです。 これは、アプリ サービスとアプリが非常に密接に絡み合っているため、両者の展開率が非常に類似するという特殊な状況です。 

モバイル iOS アプリと Android アプリを区別するのと同じように、コンテナ化された環境内でのみ動作するように設計されたアプリ サービスを、他の場所で動作するアプリ サービスに対して「コンテナ ネイティブ」としてタグ付けすることは有益であると考えられます。

どのように分類するかに関係なく、モバイルデバイスと、それに依存するアプリは確実に増加しています。