サービスメッシュ導入の前に知っておくべきこと

はじめに

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

サービスメッシュとは

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

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

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

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

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

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

envoy

サービスメッシュの目的

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

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

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

mesh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用リソースの上昇

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

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

node cpu(導入前) cpu(導入後) メモリ(導入前) メモリ(導入後)
master000 171m 192m 2115Mi 2156Mi
master001 158m 171m 1484Mi 1633Mi
master002 173m 198m 1568Mi 1719Mi
worker000 109m 351m 2439Mi 2546Mi
worker001 124m 174m 2131Mi 2606Mi
worker002 97m 156m 2865Mi 2932Mi
合計 832m 1242m 12602Mi 13092Mi

※1000m=1コア

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

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

pod cpu(導入前) cpu(導入後) メモリ(導入前) メモリ(導入後)
nginx 0m 3m 2Mi 47Mi
db 1m 3m 29Mi 76Mi
サービスA 1m 4m 237Mi 220Mi
サービスB 2m 4m 219Mi 288Mi
サービスC 2m 4m 253Mi 270Mi
サービスD 2m 4m 28Mi 73Mi
サービスE 4m 7m 35Mi 78Mi
サービスF 2m 4m 230Mi 270Mi
サービスG 3m 6m 30Mi 75Mi
サービスH 2m 4m 393Mi 311Mi
サービスI 1m 4m 322Mi 411Mi
合計 20m 47m 1778Mi 2119Mi

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

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

pod cpu メモリ
grafana 3m 40Mi
istio-egressgateway 4m 40Mi
istio-ingressgateway 3m 40Mi
istiod 30m 61Mi
jaeger 10m 39Mi
kiali 1m 12Mi
prometheus 31m 489Mi
合計 82m 721Mi

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

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

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

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を経由しておこなわれるため、わずかに応答速度に影響しますが、できるだけパフォーマンスを維持したい場合や、リソースに余裕があまりない場合に採用すると良いかもしれません。

さいごに

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

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

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

ALPHA SYSTEMS INC.

株式会社アルファシステムズは、ITサービス事業を展開しています。このブログで、技術的な取り組みを紹介しています。