はじめに
最近、Kubernetesを中心としたコンテナ環境やマイクロサービスの文脈において、「サービスメッシュ」「Istio」というキーワードを聞く機会が増えています。
「Istio」は、2018/7/31にバージョン1.0に到達したことが発表され、ますます注目されるオープンソースソフトウェアとなっています。また、自分が所属しているSIerであっても、最近「サービスメッシュ」という言葉を聞く機会が増えてきています。
本記事では、サービスメッシュの概要から、サービスメッシュを実現するソフトウェアについて、Web上の情報などを元に調査した内容を整理したいと思います。
サービスメッシュとは
マイクロサービスの課題
サービスメッシュの説明をする前に、サービスメッシュの前提となるマイクロサービスにおいて、どのような課題が存在するか整理したいと思います。
Service Discovery（サービスの発見）
複数の小さなサービスが相互に連携するマイクロサービスにおいて、依存関係にあるサービスの接続情報の管理が課題となっています。例えば、あるサービスにおいてシステム構成（ホスト追加など）が変更になった場合、依存関係にあるサービスに対して、いかに接続情報の更新を通知するのかが課題となります。
従来ではDNSやロードバランサにより実現していましたが、ソフトウェアを迅速に提供することを目的に採用されるマイクロサービスにおいて、デプロイやリリースの度にDNSやロードバランサの設定変更を行うことは、ソフトウェアの迅速な提供を妨げる原因になってしまいます。
Fault Isolation（障害の分離）
マイクロサービスでは、複数の小さなサービスが相互に連携しているため、あるサービスで発生した障害が連鎖し、大規模な障害に繋がる可能性があります。
このため、マイクロサービスを提唱した Martin Fowler が「サーキットブレーカー」パターンを提唱しており、障害のあったサービスへのアクセスを遮断することで、連鎖した大規模障害のリスクを減らす方法が述べられています。
※参考： https://martinfowler.com/bliki/CircuitBreaker.html
しかし、これを実現するには各サービスの外部呼び出し側に実装しなければならず、それぞれのサービスにおいて実装することは、大きなコストを発生させてしまいます。
Observability（分散トレーシング）
マイクロサービスでは、一つのリクエストが複数のサービスに跨ることにより、リクエスト全体の処理の流れを把握（トレーシング）することは難しくなります。
例えば、あるサービスにおいてレスポンスの悪化やエラーが発生した場合、どのサービスで問題が発生したか確認することは、マイクロサービスにおいて非常に難しく、各サービスにおいて個別に実装すると大きなコストを発生させてしまいます。
Security（認証・認可）
マイクロサービスにおいても、アクセス元のサービスの権限に応じて、提供するコンテンツを制御したいケースが存在すると考えられます。
通常、このようなケースを実現するには、認証・認可の仕組みが必要となるのですが、各サービスにおいて個別に実装していくと大きなコストを発生させてしまいます。
サービスメッシュの登場
これらのService Discovery・Fault Isolation・Observability・Securityなどのマイクロサービスの課題からアプリケーション開発者を解放し、アプリケーション開発者がビジネスロジックの開発に専念できるよう登場してきたのが、「サービスメッシュ」という概念とソフトウェアになります。
サービスメッシュの概念図は以下の通りです。
※引用： http://philcalcado.com/img/service-mesh/6-a.png
すべてのサービスに対して「サイドカープロキシ」を用意し、サービス間のコミュニケーションをすべてサイドカープロキシ経由とすることにより、マイクロサービス固有の課題の解決を行っています。
※引用： http://philcalcado.com/img/service-mesh/mesh1.png
また、サイドカープロキシを経由し、すべてのサービスがメッシュ状に接続されることから、「サービスメッシュ」と呼ばれています。
サービスメッシュを実現するソフトウェアの選択肢
サービスメッシュを実現するソフトウェアとして「Istio」が最も有名ですが、他にもいくつかソフトウェアが存在しています。
Istio
Google社・IBM社・Lyft社が開発したサービスメッシュを実現するためのソフトウェアであり、前述の通り2018年7月にバージョンが1.0に到達しています。
※参考： https://istio.io/blog/2018/announcing-1.0/
2017年5月にオープンソースとして公開された時点では、Kubernetesのみをサポートしていましたが、2018年8月時点は以下のプラットフォームがサポートされています。
- Service deployment on Kubernetes
- Services registered with Consul
- Services running on individual virtual machines
※参考： https://istio.io/docs/concepts/what-is-istio/
Istioのアーキテクチャは以下の通りです。
※引用： https://istio.io/docs/concepts/what-is-istio/
Istioのアーキテクチャは、大きく「Data Plane（データプレーン）」と「Control Plane（コントロールプレーン）」の2つに分けることができます。
Data Plane（データプレーン）では、プロキシによるマイクロサービス間の通信を管理しており、Istio用に拡張された「Envoy」をサイドカープロキシとして、KubernetesのPod内にデプロイしています。
Control Plane（コントロールプレーン）には、以下の3つのコンポーネントが含まれています。
- Mixer
- Pilot
- Citadel
それぞれのコンポーネントの役割は以下の通りです。
- Mixer：サイドカープロキシ（Envoy）から各サービスのデータを収集し、その情報を元にアクセスコントロールを行うコンポーネントです。プラグインモデルを取っており、カスタマイズすることが可能です。
- Pilot：サイドカープロキシ（Envoy）のサービスディスカバリやトラフィック管理を担当するコンポーネントです。例えば、A/Bテスト・カナリーリリースの実現や、タイムアウト・リトライ・サーキットブレーカーなどの手法を用いてFault Isolation（障害の分離）の問題を解決することができます。
- Citadal：サービス間認証とエンドユーザ認証を実現するコンポーネントです。以前は「Istio-Auth」という名称でしたが、バージョン0.8より「Citadel」に名称変更されています。
※参考： https://istio.io/about/notes/0.8/
Envoy
前述の「Istio」のData Plane（データプレーン）としても利用されている、Lyft社が開発したサービスメッシュを実現するためのソフトウェアです。また、CNCF（Cloud Native Computing Foundation）に、プロジェクトがホストされています。
サイドカープロキシとしてデプロイされ、各サービスに対してアプリケーションの改修なく、以下のような機能を付加できます。
- サービスディスカバリ
- 負荷分散
- TLS終端
- HTTP/2 と gRPC のプロキシ
- サーキットブレーカー
- ヘルスチェック
- トラフィックの分割（A/Bテスト）
- Fault injection（フォールト・インジェクション）
- メトリクスの取得
Linkerd
クラウドネイティブソフトウェア企業のBuoyant社が開発し、CNCF（Cloud Native Computing Foundation）にホストされている、サービスメッシュを実現するためのソフトウェアです。
Linkerdのアーキテクチャは以下の図の通りです。
※引用： https://res.infoq.com/news/2017/03/linkerd-celebrates-one-year/en/resources/linkerd-diagram.png
ホスト毎にLinkerdインスタンスを持つモデルと、サイドカープロキシとしてKubernetesのPodにデプロイするモデルを選択することができます。Linkerdインスタンスが重めのプロセスのため、ホスト毎に持つモデルが推奨されています。また、「namerd」というサービスがコントロールプレーンとして存在し、それぞれのLinkerdインスタンスのルーティング情報を一元管理しています。
Istioが公開される以前の2017年4月にバージョンが1.0に到達しており、プロダクション環境に導入された実績が多いことが特徴となっています。
※参考： https://blog.buoyant.io/2017/04/25/announcing-linkerd-1-0/
Conduit
Linkerdを開発していたメンバが開発し、2017年12月に発表されたばかりのKubernetes用のサービスメッシュを実現するソフトウェアです。Linkerdと比較して軽量であることがメリットとして強調されていました。
※参考： https://blog.buoyant.io/2017/12/05/introducing-conduit/
しかし、2018年7月にバージョン0.5.0がConduitとしての最後のリリースとなり、Linkerd 2.0にマージされることが発表されました。（非常に短い期間でしたね）
※参考： https://blog.conduit.io/2018/07/06/conduit-0-5-and-the-future/
Hashicorp Consul
「Hashicorp Consul」は、Hashicorp社により開発され、Service Discovery（サービスの発見）を実現するソフトウェアとして提供されていましたが、2018年6月に発表されたバージョン1.2からサービスメッシュを実現する機能（Connect）が追加されています。
※参考： https://www.hashicorp.com/blog/consul-1-2-service-mesh
新機能であるConsul Connectでは、サービス間の通信のTLS暗号化やIDベースでの認証を実現しますが、2018年8月時点ではパブリックベータの機能として提供されています。（機能追加はこれからという印象を受けました）
さいごに
本記事では、サービスメッシュについて調査してみました。
サービスメッシュを実現するソフトウェアは「Istio」だけじゃないということが理解できたと思いますが、色々と調査を進めて行くうちに機能面などから、結局は「Istio」がデファクトスタンダードになるのかなと個人的には考えております。
また、以下のコンテナプラットフォームとコンテナランタイムの動向について整理したQiita記事も書いているので、ご興味ある方はご参照ください。
