サービスメッシュとは｜仕組みやメリット・デメリットを徹底解説！
サービスメッシュは、マイクロサービスアーキテクチャにおいて非常に重要な概念です。近年は、マイクロサービスが広がっているため、このキーワードを耳にする人も多いでしょう。
多くのメリットがある概念ですが、まだまだ詳しく理解されていない状況です。今回はサービスメッシュの概要から仕組みやメリットとデメリットについて解説します。
この記事の目次
サービスメッシュとは
サービスメッシュは、アプリケーションレベルの通信を、アプリケーションではなくインフラストラクチャで制御する技術です。一般的に、アプリケーションの通信は、アプリケーション自身が制御します。しかし、サービスメッシュでは、アプリケーションからインフラへと移行させるのです。
通信をアプリケーションが管理するとなると、アプリケーションの内部に通信に関する処理を実装しなければなりません。今までは当たり前でしたが、現在のように複数のアプリケーションや機能を組み合わせる際に、これは障壁となってしまいます。特に、利用する技術が異なるアプリケーションを組み合わせると、スムーズに実装できません。
この状況を解決するために、根本的にアプリケーションから通信を分離するという考え方が生み出されました。これがサービスメッシュであり、マイクロサービス間の通信はアプリケーションで処理するのではなく、インフラ側に集約するのです。
サービスメッシュの仕組み
サービスメッシュの基本的な考え方は、マイクロサービスごとにプロキシを配置して、それを経由した通信とすることです。プロキシ側で通信内容を制御することによって、アプリケーションでは複雑な通信を実装しなくて済みます。一般的に利用されているサービスメッシュは「データプレーン」と「コントロールプレーン」の2つに分割できる仕組みです。
データプレーン
データプレーンは、インバウンド・アウトバウンドを問わず、全ての通信を一元管理するプロキシを指します。全ての通信は「Envoy」やこれに類するプロキシを通過する仕組みとなっていて、このプロキシの中で中心に関する問題を解決する仕組みです。
例えば、マイクロサービスはその機能によって、異なるプログラミング言語で実装されている場合があります。この状況では、サービス間の通信を実現する際に、アプリケーション開発側の負担が大きくなりかねません。そのため、データプレーン側でこれらの通信を一元的に処理できるようにします。
また、仮に同じプログラミング言語だとしても、全ての通信を同じルールで管理するのは難しいと考えられます。マイクロサービスにおいては、サーキットブレーカーを導入する選択肢もありますが、仕様を踏まえると導入が難しいこともあるでしょう。
このような実現が難しい課題について、データプレーンに問題を集約して解決を目指します。また、ルーティングやメトリクスの収集、リカバリー作業などもデータプレーンが行うことによって、インフラとしての機能を充実させることも可能です。
コントロールプレーン
コントロールプレーンは、サービスメッシュの主な様子であるデータプレーンを管理する仕組みです。データプレーンは、アプリケーション側で設定が必要なものではなく、コントロールプレーン側で一元管理します。プロキシの設置場所によって、求められる仕様は少々異なりますが、そのような差についても全てコントロールプレーン側で制御するのです。
基本的にはこのような制御ですが、設定内容が誤っていないか、最新化されているかを強化する機能が実装されています。また、ネットワークの状況を可能な限り可視化するために、ログを集約することも可能です。サービスメッシュのコアとなる部分はデータプレーンですが、コントロールプレーンがあることでサービスメッシュという概念が成り立つといえます。
サービスメッシュのメリット
サービスメッシュを導入することで、以下のようなメリットが生み出されます。
相互運用
サービスメッシュを導入することで、マイクロサービスを連携しやすくなります。結果、相互に運用しやすいアプリケーションの構築が可能です。今まで独立したアプリケーションでも、相互に活用できるかもしれません。
特に、サービスメッシュによってルーティングが自動化されれば、適切な通信を素早く実現できます。今までは、手動で設定していたような内容でも、インフラ側で素早く処理できるようになるのです。結果、設定変更などによる影響が少なくなり、さまざまなマイクロサービスを連携できるようになります。
プロキシによるデータ監視
マイクロサービス間の通信は、プロキシを経由させることでリアルタイムに情報収集が可能です。また、収集した情報を監視したり分析したりすることで、何かしらの問題が発生した際に素早く対処できます。
問題といえば、外部からの攻撃をイメージするかもしれませんが、ここではサービス間の負荷なども含みます。例えば、とあるマイクロサービス間での通信が極端に遅いならば、その原因を調査したり修正したりするなどです。通信を監視することで、内部的な問題も外部からの問題もどちらも素早く察知できます。
マイクロサービスの管理
サービスメッシュによりサービス間の通信を管理するためには、サービスの状況を適切に把握することが重要です。起動しているサービスと終了したサービスを管理できなければ、サービスメッシュにより通信できません。
言い換えると、サービスメッシュを導入することは、これらを管理することにも繋がります。コントロールプレーンは、全てのデータブレーンの状況を確認するため、起動しているかどうかの一元管理が可能なのです。もし、何かしらの理由でデータプレーンから反応がなければ、サービスが停止している状態であると判断できます。インフラに問題が発生した場合も検知できるのです。
サービスメッシュのデメリット
サービスメッシュのメリットは理解してもらえたでしょう。デメリットがないのか気になる人が多いと思われるため、デメリットについても解説します。
処理速度の若干の低下
サービス間で通信するためにプロキシを経由するため、通信速度が若干低下する可能性があります。厳密には、プロキシで処理する工程が挟まることで、若干ですが処理速度が低下すると捉えると良いでしょう。
ただ、理論的には若干の影響を与えますが、アプリケーションの実装において影響を感じることはほとんどありません。基本的には、プロキシによる処理速度や通信速度の低下は、無視できるデメリットと考えて良いでしょう。非常に通信要件が厳しい場合のみ、意識しなければなりません。
リソース消費量の増加
サービスメッシュを実現するためには、アプリケーションとは別にインフラを起動しなければなりません。新しく機能を起動するため、どうしてもリソースを消費してしまいます。特に、CPUやメモリの消費量が増加すると理解しておきましょう。
アプリケーションが機能しなくとも、サービスメッシュを起動するだけでリソースが必要です。実際には、アプリケーションの処理に応じて、さらなるリソースを確保しなければなりません。
サービスメッシュの実現方法
サービスメッシュを実現するためには、専用のツールを導入しなければなりません。いくつかの選択肢があるため、具体的な製品を紹介します。
Istio
Istioは、サービスメッシュを実現する、オープンソースのツールです。世界的に利用されているものであり、サービスメッシュの世界ではデファクトスタンダードといえるでしょう。
デファクトスタンダードになることもあり、サービスメッシュに必要な機能が充実しています。マイクロサービスの設計内容によっては、利用しない機能も存在しますが、どのツールにするか悩むならばIstioを導入しておけば良いでしょう。
AppMesh
AppMeshは、AWSが提供するサービスメッシュに関するサービスです。ただ、ネットワークなどリソースの管理や監視が中心であり、単体で実現できる機能は限られています。AWSにはいくつもの機能があるため、それらと組み合わせてサービスメッシュを実現すると考えましょう。
例えば、AWSにはAppMeshと呼ばれるサービスがあります。これと組み合わせることで、サービスメッシュに必要な機能を準備できるのです。メトリクスの設定などが必要とはなりますが、最低限、求める機能は揃うでしょう。
とはいえ、AppMeshを利用する場合は、マイクロサービス自体をAWSで構築している必要があります。サービスメッシュだけをAWSに設置することは、基本的にはないと考えておきましょう。
Linkerd
Linkerdは、サービスメッシュの機能を最小限に抑え、軽量化を目指したツールです。オープンソースで開発されていて、ソースコードを変更することなく、サービスメッシュを実現できます。
大きな特徴として、Linkerdはサイドカープロキシに、独自のアルゴリズムで軽量化したものを導入しています。IstioやAppMeshは、汎用的なEnvoyが採用されているため、ここは大きな違いです。
サービスメッシュでは、すべての通信がEnvoyを経由するため、わずかに処理速度が低下します。Linkerdを採用することによって、この影響を極限まで軽減できるのです。
サービスメッシュを導入すべきか
サービスメッシュの概要を理解できると「全てのマイクロサービスにおいてサービスメッシュを導入した方が良いのではないか」と考えるでしょう。確かに、サービスメッシュは非常に魅力的な概念ではありますが、全ての環境において適しているとは言い切れません。
例えば、サービスメッシュの導入にはまとまったコストが必要です。また、サービスメッシュによって自動化できる部分はあるとはいえども、運用に関連するコストも発生します。そのため、損益分岐点を考慮して、サービスメッシュを導入するか今までと同じような通信を実装するか考えることが重要です。
また、サービスメッシュはプロキシを利用した通信であるため、ネットワーク自体は複雑になってしまいます。アプリケーションで管理する必要がなくなり、アプリケーション側はシンプルな実装になりますが、ネットワーク側には一定の負担が生じるのです。そのため、ネットワーク側に生じる負荷を受け入れられるかどうかも検討した方が良いでしょう。
サービスメッシュを少しずつ改良する
サービスメッシュは新しい概念であり、現時点ではベストプラクティスと言えるようなものが存在しません。そもそも、マイクロサービスの実装自体にベストプラクティスが存在しないため、それぞれのサービスにおいてエンジニアが試行錯誤している状況です。
このような現状を考えると、サービスメッシュの実装や運用、使いこなし方においても試行錯誤が必要でしょう。短期的に見ると損益分岐点などを意識する必要はありますが、試行錯誤を繰り返し少しずつ改良した結果、今までとは違うネットワークを生み出し、大きく状況が改善されるかもしれません。今すぐに利用できる・利用できないと判断することは早計という捉え方もあるのです。
まとめ
サービスメッシュは、一般的なアプリケーションのようにアプリケーション層で通信を管理するのではなく、プロキシを経由して通信を実現する方法です。プロキシを経由することによって、プロキシ側、つまりインフラ側で通信の制御ができるようになります。今までのように、アプリケーションレベルで通信を実装したり制御したりする必要はなく、開発の工数を大幅に削減できるのです。
また、サービスメッシュは「データプレーン」と「コントロールプレーン」に分割が可能であり、それぞれが独立して機能します。このような独立した構造があるからこそ、効率よくアプリケーションの通信を管理できるようになると考えましょう。それぞれの役割を理解して、使い分けできることが求められますが、それさえできればサービスメッシュは非常に利便性の高いものなのです。
