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

カバー

[!] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

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

サービスメッシュとは

一般的に、サービスメッシュとはインフラストラクチャ層においてアプリケーション間の通信トラフィックの制御をおこなったり、可観測性を向上させる手法の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のリソース状態の比較です。

nodecpu(導入前)cpu(導入後)メモリ(導入前)メモリ(導入後)
master000171m192m2115Mi2156Mi
master001158m171m1484Mi1633Mi
master002173m198m1568Mi1719Mi
worker000109m351m2439Mi2546Mi
worker001124m174m2131Mi2606Mi
worker00297m156m2865Mi2932Mi
合計832m1242m12602Mi13092Mi

※1000m=1コア

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

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

podcpu(導入前)cpu(導入後)メモリ(導入前)メモリ(導入後)
nginx0m3m2Mi47Mi
db1m3m29Mi76Mi
サービスA1m4m237Mi220Mi
サービスB2m4m219Mi288Mi
サービスC2m4m253Mi270Mi
サービスD2m4m28Mi73Mi
サービスE4m7m35Mi78Mi
サービスF2m4m230Mi270Mi
サービスG3m6m30Mi75Mi
サービスH2m4m393Mi311Mi
サービスI1m4m322Mi411Mi
合計20m47m1778Mi2119Mi

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

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

podcpuメモリ
grafana3m40Mi
istio-egressgateway4m40Mi
istio-ingressgateway3m40Mi
istiod30m61Mi
jaeger10m39Mi
kiali1m12Mi
prometheus31m489Mi
合計82m721Mi

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

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

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

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

さいごに

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

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

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


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