コンテナのスケーリングの未来がサービス メッシュである 8 つの理由

マイクロサービスは開発速度の向上に優れていますが、これらのアーキテクチャの複雑さは、マイクロサービスが依存するサービス間通信にあります。

現在、コンテナ化されたマイクロサービスをスケーリングするためのアーキテクチャ オプションは少なくとも 3 つあります。 それぞれは、すべてのスケールと同様に、プロキシベースのロード バランサーに基づいています。 それぞれに独自の課題があります。 それらのいくつかは、コンテナ環境内のスケールが IP テーブルに依存することが多く、従来のネットワーク層 (IP と TCP) より上位の層との互換性が限られているという単純な事実に起因しています。

これらのプロキシはすべて、コンテナ環境全体に分散されたサービスをスケーリングするという同じコア機能を提供します。 奇妙なことに、サービスは一時的な構成物です。 これらは、それらを定義するリソース (構成) ファイル内を除いて、実際には存在しません。 IP テーブルベースのスケーリング ソリューションの問題点は、これらのサービスがレイヤー 7 (HTTP) 構造であり、多くの場合、application全体ではなく単一の API 呼び出しの「バックエンド」として機能することです。

私たちが知っているように、applicationsはクライアント側から見ると単一の全体的な構造のように見えることがあります。 実際には、それらは多くの異なる（分散された）マイクロサービスで構成されています。 これらのサービスの一部は純粋に内部的なもので、他のサービスによって使用されるように設計されています。 これは、コンテナ化された環境内で多くのサービス間通信が行われることを意味します。

これらの環境ではすべてが HTTP/HTTP2 経由の API であるため、L7 (HTTP) ルーティングが必要です。 また、一貫したセキュリティ体制、認証、ポリシーの適用も必要です。 IP テーブルベースのアプローチでは、そのようなことは起こりません。

いつものように、オープンソースが救いの手を差し伸べてくれます。 これらの課題に対処するために、いくつかのオープンソース サービス メッシュが登場しました。 多くのオープンソース プロジェクトと同様に、これらのサービス メッシュ ( Istioなど) は、エンタープライズ グレードのソリューションを提供する機能 (およびサポート) を備えたAspen Meshなどのプロジェクトによって拡張されています。

これらの拡大された取り組みは、組織がコンテナにマイクロサービスを展開する際に直面する 8 つの課題を解決することに重点を置いています。

これらは 8 つの課題と、サービス メッシュがそれらをどのように克服できるかです。

1. ビルド – これは、ポリシーを CI/CD ツールチェーンと統合し、サービス メッシュをインフラストラクチャとしてコードとして扱えるように構成の宣言型モデルを確保すること以外に、サービス メッシュが提供できるものがほとんどない課題の 1 つです。
2. テストと統合 – サービス メッシュは、開発、テスト、本番などの間で一貫したポリシーを確保することで役立ちます。 一部の組織では、段階的な展開を完全に排除することを検討しています。 このアプローチは過去にはうまく機能していましたが、デプロイメント プロセスに遅延をもたらす障害の 1 つとなっています。  これらの人々は、サービスを本番環境に直接デプロイし、トラフィック ステアリングとロールバック メカニズムを使用して障害に対処する方法を求めています。  
3. バージョン管理 – サービス メッシュは、API バージョンなどの変数に基づいてトラフィックをルーティングする基本的な API ゲートウェイとして機能し、API バージョンの移行期間中に役立つようにバージョンを変換することもできます。 クライアントのアップグレード、特に消費者向けアプリのアップグレードは必ずしも強制できるわけではなく、複数のバージョンに対するリクエストが届くことになります。 サービス メッシュは、古い API バージョンへのリクエストを最新バージョンに変換できるため、同じ API の複数のバージョンを維持するためのコストと負担を軽減できます。
4. デプロイ – HTTP を流暢に使用できるサービス メッシュは、ブルー/グリーン デプロイメント、カナリア テスト、トラフィック ステアリングを実現するのに最適な場所です。
5. ロギング – 分散ロギングは常に問題であり、インスタンスの存続期間が非常に変動する環境ではさらに厄介です。 サービス メッシュは、ログ記録を実装するための共通の集中化された場所と、リクエスト トレースなどの機能を実行する機能を提供します。
6. 監視 – スケールの中心となるのは監視です。 applicationsは、サービスの避けられない障害に対処するために特定の機能 (再試行、回路遮断など) を実装できますが、これにより、applicationに負担する必要のない負担がかかります。 サービス メッシュは、サービス間通信の負担を引き受け、監視のための場所を提供します。 実稼働環境での実行は困難であり、障害は避けられないため、目標は実稼働環境での MTTD と MTTR に焦点を当てることです。
7. デバッグ – システムが複雑になるほど、デバッグが難しくなります。 サービス メッシュは、根本原因の分析を支援し、分析とテレメトリを使用して統計情報と障害前通知を提供し、コンテナを強制終了するのではなく隔離して徹底的に調査できるようにします。 これは、失敗の原因が遅いメモリ リークである場合に特に役立ちます。
8. ネットワーク – ネットワークは、それほど複雑でない環境よりも、コンテナにとって依然として重要です。 ネットワークからサービスを抽象化したいということは、すべてのサービスに実装したくない可動部分が多数あることを意味します。 サービス検出、SSL および証明書管理、サーキットブレーカー、再試行、ヘルスモニタリングなど。 マイクロサービスの目標は、「ローカルでコードを小さくする」ことでした。 ネットワーク関連の機能を組み込む必要性が生じると、マイクロサービスが肥大化し、追加のアーキテクチャ上および技術的負債が発生します。 サービス メッシュはこれらの機能を引き受け、開発を停滞させることなく、必要なスケールとセキュリティを実現します。

サービス メッシュは、クラウドとコンテナの最新の原則とスケールの強固な基盤を組み合わせた、エキサイティングな進化です。 2018 年もコンテナの採用が増加し、エンタープライズ グレードのスケールとサポートの需要が高まることから、サービス メッシュが普及すると予想されます。