🐕

すごいよ、サービスメッシュ！ 〜 マイクロサービスアーキテクチャの設計パターン 〜

に公開
サービスメッシュ
マイクロサービスアーキテクチャ
idea

※本記事は、2020年5月に個人ブログ「ふじやまエッグのブリコルール日誌」に初出したものを、ブログ閉鎖にともない一部加筆・修正のうえ、こちらに転載したものです。

マイクロサービスアーキテクチャの効果を最大限活かすなら、サービスメッシュの導入の検討は必須です。
本記事では、サービスメッシュに関して、できるだけわかりやすく説明していきたいと思います。

サービスメッシュとは？

サービスメッシュの概要

サービスメッシュとは、マイクロサービスアーキテクチャの設計パターンのひとつです。
個々のサービスの主要な関心事は、「顧客管理」や「購買管理」などであって、「認証・認可」、「ロギング」、「セキュリティ」など、いわゆる「横断的関心事」ではありません。しかもマイクロサービスアーキテクチャにおいては、マイクロサービス間がお互いに通信し合うことで、どのマイクロサービスであっても、「横断的関心事」を無視することができなくなっているのです。
そのような「横断的関心事」をプロキシ(仲介人)にませることで、サービスは本来の主要な関心事に集中することができるようにしたのが、サービスメッシュなのです。

マイクロサービスが抱える課題

マイクロサービスアーキテクチャを採用していない従来のシステム（モノリス（一枚岩）のシステムと呼ばれることが多いです）では、あまり問題にならなかったようなことがマイクロサービスアーキテクチャでは課題になってきています。これは、そのまま分散システムにおける課題といっていいと思います。
下記は、マイクロサービスアーキテクチャの先進企業である、アマゾン、ネットフリックスで稼働するサービスをモデル化したものです。もはや、手がつけられない、といった感じですね、、、

出典: [https://divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others/:title]

このような状況において、個々のサービスごとに、「横断的関心事」を解決するのは、不可能ではないとしても、少なくとも効率が悪そうですよね。

サービスメッシュが提供する機能

ここで登場するのが、サービスメッシュです。
サービスメッシュは、分散システムの課題の解決のため、主に以下のような機能を提供します。

  • サービスディスカバリ
    必要なサービスのIPアドレス等のネットワーク位置を検出します。
  • サービス認証・認可
    サービスとサービスが通信するうえでの、サービスの認証・認可の仕組みを提供します。
  • 障害の分離(Fault Isolation）
    あるサービスとの通信が安定しない場合、障害が発生している場合、呼び出し側サービスで、タイムアウト、リトライ、サーキットブレーカーなどの機能を提供します。サーキットブレーカーとは、障害が発生しているサービスにはリクエストをださずにすぐに次の処理に進むようにする機構です。
  • テレメトリ収集
    どのサービスや通信路で問題が発生しているのかを把握するのが難しくなってきています。そんな時、各サービスの稼働情報(テレメトリ)の収集機構を提供します。
  • トラフィックコントロール
    カナリアリリースのような柔軟なロードバランシングを実現します。

名前の由来

マイクロサービス間をプロキシを介して網目状(mesh)に結ばれるところから、サービスメッシュ (service mesh)と言われています。プロキシは、サイドカー(Sidecar)と呼ばれます。常にメインとなるマイクロサービスの横にくっついているからですね。

出典: [https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh:title]

サービスメッシュという用語は、サービスメッシュ製品Linkerdを提供するBuoyant 社のブログで、以下のように初めて使われた、と言われています。

Linkerd is our open-source service mesh for cloud-native applications.

出典: [https://linkerd.io/2016/02/18/linkerd-twitter-style-operability-for-microservices/#.XsBfgf1LgZg.twitter:title]

サービスメッシュを構成する要素

サービスメッシュは、データプレーン(data plane)とコントロールプレーン(control plane)と呼ばれるコンポーネントから構成されています。

データプレーンは、プロキシの役割を担います。

コントロールプレーンは、管理者からの指示によって、データプレーンにトラフィックの流れの制御を指示したり、あるいは、各データプレーンで収集した各種メトリクス情報を集約したりします。データプレーンをコントロールすることで、サービスメッシュ全体を統制することができるようになるのですね。

カナリアリリース

コントロールプレーンから各データプレーンに指示を出して、ルーティングの比率をコントロールすることができます。
この仕組みにより、いわゆるカナリアリリースのような、新バージョンを段階的に導入する、といったことが実現することができるのです。

  • 第１段階のトラフィック配分. バージョン1: 95%, バージョン2: 5%

  • 第２段階のトラフィック配分. バージョン1: 50%, バージョン2: 50%

  • 第３段階のトラフィック配分. バージョン1: 0%, バージョン2: 100%

サービスメッシュに対応する製品は？

サービスメッシュ を実装した製品は、以下のようなものがあるとのことです。

  • Linkerd
  • Istio
  • Consul
  • Kuma
  • Maesh
  • AWS App Mesh

出典: [https://www.infoq.com/jp/articles/service-mesh-ultimate-guide/:title]

サービスメッシュの何がすごいのか？

サービス本来の関心事に集中できる

データプレーンに「横断的関心事」をまかせることで、マイクロサービスの本来の関心事に集中できるのです。これにより、開発での俊敏性(agility)を高めることができるのです。

共通ライブラリよりマイクロサービスに適している

サービスメッシュが導入される前は、共通ライブラリに「横断的関心事」をまかせる、というアプローチがとられていました。
しかし、このアプローチには、マイクロサービスを増やしていいくううで、以下のような弱点がありました。

  • 共通ライブラリを更新する際、サービスの再デプロイ(配備)が必要になるケースが多い。
    共通ライブラリは、サービスと同一プロセス空間で動作することになるため、サービスとの結合度が高いです。そのため、通常、共通ライブラリを入れ替えることは、サービスの再デプロイが必要になることを意味しています。
    一方、サービスメッシュでは、データプレーンは、独立したプロセスでサービスとの結合度が弱まり、データプレーンのみを入れ替える、といったことがやりやすくなるのです。

  • 共通ライブラリをサービスの実装言語ごとに準備する必要がある。
    マイクロサービスのメリットとしてあげられることのひとつに「サービスに適したプログラミング言語に応じて実装できる」というものがあります。しかし、共通ライブラリのアプローチだと、サービスごとに実装した言語に応じて共通ライブラリを準備する必要がある、ということになってしまいます。

マイクロサービス全体の統制、管理が可能

コントロールプレーンから各データプレーンへ指示することにより、サービスアーキテクチャ全体を統制することができます。
例えば、トラフィックの流量をコントロールして、カナリアリリース等を実現することができるのです。

結局、サービスメッシュとは？

サービスメッシュは、マイクロサービスにおける縁の下の力持ちだ！
サービスメッシュが、マイクロサービスのメリットをさらに加速させるのだ！

参考

Discussion