はじめに

昨今、サービスメッシュという言葉をよく耳にすると思います。サービスメッシュを導入するとどのようなメリットがあるのか、どういうシステムであれば導入した方がいいのか、当社の開発経験を基に解説していきます。

サービスメッシュとは

一般的に、サービスメッシュとはインフラストラクチャ層においてアプリケーション間の通信トラフィックの制御をおこなったり、可観測性を向上させる手法の1つです。

主にKubernetes環境で使用されます。

サービスメッシュでは、IstioというOSSがサービスメッシュのデファクトスタンダードとなっています。

サービスメッシュの製品によって備えている機能はさまざまですが、主に以下のような機能を持っています。

• トラフィックの可視化
• トラフィック制御

サービスメッシュはEnvoyと呼ばれるプロキシを以下の図のように各サービスにつき1つ設置し、サービスが他のサービスと通信する際にはEnvoyを経由することでEnvoyがトラフィック情報を収集したり、トラフィック制御をおこなっています。

サービスメッシュの目的

サービスメッシュはマイクロサービスにおけるさまざまな問題を解決するために利用されます。マイクロサービスは元々1つであったシステムを複数のサービスに分割し、それぞれのサービスをAPIで通信させて1つのシステムとして動作させるアーキテクチャですが、それに伴っていくつかの課題が発生します。
サービスメッシュはそれらの課題をそれぞれ以下のように解決します。

サービス間トラフィックの複雑化

サービスが複数存在すると、どのサービスがどのサービスとどのような通信をおこなっているのか把握するのが難しくなります。
サービスメッシュはトラフィック情報を収集・可視化して複雑化したサービス間のトラフィックを把握しやすくします。

問題発生時の原因特定の難化

アプリケーションが複数のサービスに分割されたことによって問題がどこで発生しているのか特定するまでに時間がかかるようになります。
モノリシックなシステムであれば１つのアプリケーションログをみれば原因特定につながりやすいですが、サービスが複数存在する場合、通信の問題で障害が発生しているケースもあり、原因特定が難しくなります。

サービスメッシュではトラフィックの可視化、トレーシングをおこなうことができるため、問題発生箇所の特定がしやすくなります。

サービス間のトラフィックの制御が必要

マイクロサービスでは問題発生時に影響範囲を小さくしたり、通信するインスタンスを分散することができますが、トラフィックを制御できなければこれらのメリットを活かすことができません。

しかしアプリケーション層でトラフィックの制御をおこなう場合、アプリケーションはアプリケーションの機能以外のことも考慮して開発する必要がでてくるため、開発コストが高くなってしまいます。そこでサービスメッシュが代わりにインフラストラクチャ層でサービス間のトラフィックを制御することで、アプリケーションの開発コストをあげることなくマイクロサービスのメリットを活かすことができます。

どのようなシステムにサービスメッシュを導入すべきなのか

ここまででサービスメッシュには主にどんな機能があり、どのような課題を解決できるのか説明してきました。
では実際にどのようなシステムにサービスメッシュを導入したほうがいいのでしょうか。

先ほどサービスメッシュではサービス間のトラフィック制御をおこなうことができると説明しました。
具体的には、L7ロードバランシング、リトライ・タイムアウト制御、サーキットブレイカーなどの機能が存在します。
これらの機能は以下の課題を解決する時に活用することができます。

• ユーザ毎に通信するアプリのバージョンや種類を決定したい
• 障害発生時に障害が起きているサーバに対し、通信して応答待ちをすることなく即座にエラーとしたい

こういった課題はマイクロサービスで実現しているシステムで発生しやすく、サービスメッシュはこれらの課題が発生しやすい以下のようなシステムで導入すべきです。

• マイクロサービスで実現しているシステム
• 複数のアプリケーションが存在するシステム
• アプリケーション間の通信が多いシステム

サービスメッシュ導入によるデメリットはあるのか

ここまでサービスメッシュのメリットばかり説明してきましたが、デメリットはないのか？というのが気になるかと思います。

サービスメッシュの仕組みから考えると以下のようなデメリットが考えられます。

通信のパフォーマンスの低下

サービスメッシュの仕組みとして、アプリケーションのインスタンス毎にEnvoyプロキシを配置し、他のアプリケーションと通信する際にEnvoyプロキシを通すことになります。
その結果、応答速度が僅かに遅くなります。
しかし私が実際に携わった通信系システムにおいてもサービスメッシュを導入しましたが、大きな影響はありませんでした。通信要件がかなり厳しいシステムでない限り大きなデメリットとはならないでしょう。

使用リソースの上昇

こちらは当たり前のことですが、サービスメッシュの機能を動作させるためにリソースを消費することになります。
参考までに当社の社内に構築したKubernetes環境で、複数サービスで出来ているシステムを動作させた状態で、Istioを導入する前後で各node、各podが使用するリソース量を比較してみました。

まずはIstioを導入する前と後でのnodeのリソース状態の比較です。

※1000m=1コア

cpuはおおよそ400m、メモリはおおよそ1000Mi増加しています。

次にIstioを導入する前と後でのpodのリソース状態の比較です。

cpuは27m、メモリは341Mi増加しています。
1podあたりcpuは2~3m、メモリは平均で約40～50Mi増加しており、Envoyであるistio-proxyはpod毎に1つずつ作成されるため、pod(サービス)が増加するたびにリソース消費が増加することとなっています。

最後にIstioのコントロールプレーンのリソース状況です。

今回は何も通信が走っていない状態でリソースを確認したので、導入だけでどのくらいリソースが必要なのかというのが分かったと思います。

サービスメッシュ製品の紹介

ここまででサービスメッシュがどんなものであるのか、どんなシステムに導入した方が良いのか説明しました。
最後にどんなサービスメッシュの製品があるのか、いくつか特徴と合わせて紹介します。

Istio

Istioはサービスメッシュ製品のデファクトスタンダードとなるOSSの製品です。
デファクトスタンダードなだけあって後に紹介する2つの製品と比較してサービスメッシュの機能が多くそろっています。

システムにどれを採用するか迷った時には、基本的にはIstioを採用しておけば良いでしょう。

AppMesh

AppMeshはAmazon Web Serviceが提供している製品です。
Istioと比較して、機能が少なくAppMesh単体ではサービスメッシュとしての機能をあまり有していません。

しかしAmazon Web Servive のCloud WatchやX-Rayと連携することができ、それらサービスと組み合わせることで、ある程度サービスメッシュとして活かすことができます。
例えばモニタリング(Prometheusを使用して収集したメトリクス情報の可視化)をおこなう場合にはCloud Watchへメトリクスを転送することにより、Cloud Watch上でCPUやメモリなどのメトリクス情報を確認することができます。

Amazon Web Serviceを使用していて、メトリクス、ログなどをAmazon Web Service上で確認したい場合には採用しても良いかもしれません。

Linkerd

Linkerdはシンプルな設計の基作られた軽量な製品です。
Istioと比較してサービスメッシュとしての機能は少ないですが、その分軽量化されています。
IstioやAppMeshはサイドカープロキシに汎用的なEnvoyを使用していますが、Linkerdは独自に実装した軽量なものを使用しています。
サービスメッシュを導入するとすべての通信がEnvoyを経由しておこなわれるため、わずかに応答速度に影響しますが、できるだけパフォーマンスを維持したい場合や、リソースに余裕があまりない場合に採用すると良いかもしれません。

さいごに

いかがでしたでしょうか。

サービスメッシュには魅力的なメリットがたくさんあります。

ぜひこの機会に取り入れてみてはいかがでしょうか。