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

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

マイクロサービスは開発の迅速化に大きく貢献しますが、このアーキテクチャの複雑さは、マイクロサービスが依存するサービス間通信にあります。

現在、コンテナ化されたマイクロサービスをスケーリングするためのアーキテクチャには、少なくとも3つの異なる選択肢があります。いずれも、あらゆるスケーリングと同様に、プロキシベースのロードバランサーを基盤としています。それぞれに固有の課題があります。そのうちのいくつかは、コンテナ環境内のスケーリングが多くの場合iptablesに依存している一方で、iptablesは従来のネットワーク層（IPとTCP）より上位のレイヤーを扱う能力が限られているという単純な事実に起因します。

これらのプロキシはいずれも、コンテナ環境全体に分散するサービスをスケーリングするという、同じ中核機能を提供します。驚くべきことに、サービスは一時的な構成要素です。サービスを定義するリソース（構成）ファイル内を除けば、実体として存在するわけではありません。IPテーブルベースのスケーリングソリューションにとって問題となるのは、これらのサービスがレイヤー7（HTTP）の構成要素であり、多くの場合、アプリケーション全体ではなく、単一のAPI呼び出しの「バックエンド」として機能する点です。

一般にアプリケーションは、クライアント側から見ると、単一の統合された構成体に見えることがあります。しかし実際には、多種多様な分散型マイクロサービスで構成されています。その中には、他のサービスから利用されるように設計された、完全に内部向けのサービスもあります。そのため、コンテナ化された環境内では、サービス間で多くの通信が発生します。

このような環境では、すべてがHTTP/HTTP2経由のAPIであるため、L7（HTTP）ルーティングが必要です。また、一貫したセキュリティ方針、認証、ポリシー適用も必要です。IPテーブルベースのアプローチでは、これらを実現できません。

多くの場合と同様に、ここでもオープンソースが力を発揮します。こうした課題に対応するため、複数のオープンソースサービスメッシュが登場しています。多くのオープンソースプロジェクトと同様に、これらのサービスメッシュ（Istioなど）は、Aspen Meshなどのプロジェクトによって、エンタープライズグレードのソリューションを実現する機能（およびサポート）を備えるよう拡張されています。

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

以下に、8つの課題と、サービスメッシュによる解決方法を示します。

1. ビルド – これは、サービスメッシュが提供できることが限られる課題の1つです。対応できるのは、ポリシーをCI/CDツールチェーンと統合し、宣言型の構成モデルを確保することで、サービスメッシュをInfrastructure as Codeとして扱えるようにすることです。
2. テストと統合 – サービスメッシュは、開発、テスト、本番などの環境間でポリシーの一貫性を確保することで、この課題の解決に役立ちます。段階的なデプロイを完全に廃止しようとしている組織もあります。このアプローチは以前は有効でしたが、デプロイプロセスに遅延をもたらす要因の1つでもあります。こうした組織は、サービスを本番環境に直接デプロイし、障害に対処するためにトラフィックステアリングとロールバックの仕組みを活用する方法を模索しています。
3. バージョン管理 – サービスメッシュは基本的なAPIゲートウェイとして機能し、APIバージョンなどの変数に基づいてトラフィックをルーティングできます。さらに、APIバージョンの移行期間には、バージョンを変換して移行を支援することもできます。特にコンシューマー向けアプリでは、クライアントのアップグレードを常に強制できるとは限らないため、複数のバージョンに対するリクエストが発生します。サービスメッシュは、古いAPIバージョンへのリクエストを最新バージョン向けに変換できるため、同じAPIの複数バージョンを維持するコストと負担の軽減に役立ちます。
4. デプロイ – HTTPを自在に扱えるサービスメッシュは、Blue/Greenデプロイメント、カナリアテスト、トラフィックステアリングを実現するのに最適です。
5. ロギング – 分散ロギングには常に課題が伴います。インスタンスの存続期間が大きく変動する環境では、さらに深刻です。サービスメッシュは、ロギングを実装するための共通の一元化された場所を提供するとともに、リクエストトレーシングなどの機能を実行できるようにします。
6. 監視 – スケーリングの要となるのが監視です。アプリケーションに特定の機能（再試行、サーキットブレーカーなど）を実装して、避けられないサービス障害に対処することもできますが、本来は不要な負担がアプリケーションにかかります。サービスメッシュはサービス間通信を担い、監視を行うための共通基盤を提供します。本番環境の運用は難しく、障害は避けられないため、目標は本番環境でのMTTDとMTTRの短縮に重点を置くことです。
7. デバッグ – システムが複雑になるほど、デバッグは難しくなります。サービスメッシュは、根本原因分析を支援し、アナリティクスとテレメトリを使用して統計情報や障害発生前の通知を提供できます。また、コンテナを停止する代わりに隔離し、詳細な調査を可能にします。これは、緩やかなメモリリークが原因で障害が発生する場合に特に役立ちます。
8. ネットワーキング – コンテナにとってネットワーキングは依然として重要であり、複雑性の低い環境よりも重要性が高いともいえます。サービスをネットワークから抽象化するには、サービスディスカバリ、SSLと証明書の管理、サーキットブレーカー、再試行、ヘルスモニタリングなど、各サービスに実装したくない多くの要素に対応する必要があります。マイクロサービスの目標は、「ローカルに、小さくコーディングする」ことでした。ネットワーク関連機能まで組み込む必要が生じると、マイクロサービスが肥大化し、アーキテクチャ上および技術上の負債が増加します。サービスメッシュはこれらの機能を担い、開発の足かせになることなく、求められる拡張性とセキュリティを実現します。

サービスメッシュは、クラウドとコンテナの最新原則に、スケーラビリティという強固な基盤を組み合わせた、注目すべき進化です。2018年にコンテナの導入がさらに進み、エンタープライズグレードのスケーラビリティとサポートへの需要が高まるにつれて、サービスメッシュも普及していくと見込まれます。

著者について

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

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

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