サービスメッシュとは
KubernetesにHostingされたマイクロサービスでは「サービスメッシュ」がよく使われている。
「サービスメッシュ」はサービス間の通信を制御するコンポーネントだ。しかしサービス間で通信する機能は既にそれぞれのサービスの中で実装されている。なぜサービスメッシュという新たなコンポーネントを追加してシステムの複雑性を増さなくてならないのか？
サービスメッシュが求められる背景について見ていこう。
大規模なコンテナ環境の課題
今日のWebサービスに要求される拡張性と可用性を追求するとコンテナ化された分散サービスにたどり着く。そしてその規模はどんどん大きくなっている。
k8s上に構築された大規模なコンテナ環境には従来のMonolithic環境にはない課題がある。
Service Discovery
- コンテナ環境では常にコンテナ化されたサービスの作成、削除が行われている。
- これらのサービスに対するDNSやロードバンラサの設定変更作業は大変である。
- サービス同士が自動的に他のサービスを検知できる仕組みが必要となる。
Observability
- コンテナ環境では複数のサービスが1つのリクエストを処理する。
- 1つのサービスのログを確認してもリクエスト処理の全容を把握することはできない。
- 複数のサービスのログを横断的に確認してリクエストの流れを追跡する必要がある。
- これは分散Tracingと呼ばれ、統一された仕組みを用意しないとリクエストを追跡することはできない。
Fault Isolation（障害の分離）
- マイクロサービスではあるサービスで発生した障害が他のサービスに連鎖し、大規模な障害に繋がることがある
- 1つのサービスで発生した問題が他に波及しないデザインパターンを個々のサービスに実装する必要がある。
- サーキットブレーカー
- バルクヘッド
- 流量制御
- 障害検知
Resilience
- サービスはネットワークを介して通信を行う。
- ネットワークは不安定でなんらかの障害が発生する。
- サービスは復旧可能なエラーが発生した際に適切なRetry処理が実装する必要がある
- エラー対処法の詳細は以下の記事を参照。
East Westトラフィックの暗号化
- 送信中のデータは「Data in motion」と呼ばれる
- Data in motionはTLSで暗号化して経路上でのintegrityとconfidentialityを保証することがBest Practiceとされている
- 従来は暗号化不要と思われていたEast WestトラフィックもTLSで保護する必要がある
- 情報漏洩の多くが内部で発生している
- DCをまたぐEast Westトラフィックが増加している
- しかし多数のサービスの証明書を発行、管理するのは大変である。
柔軟なRouting
- マイクロサービスではcanary deploymentが注目されている。
- 柔軟な経路制御が求められている。
柔軟なLoadbalancing
- サービスの負荷分散には単純なRound Robinでは不十分だ。
- Least Connectionなどの柔軟な負荷分散が求められている。
アクセス制御
セキュリティ上、サービス間の通信を限定したい。 しかし多数の、増減するサービスのアクセス制御は大変である。
横断的解決
上述のこれら1つ1つの課題はサービスのコードを変更すれば解決可能だ。しかしサービスの数が多いため対応は大変だ。またこうしたシステムの横断的な課題に対する解を個々のサービスで設計・実装してしまうとサービスごとの独立した開発、運用ができなくなってしまい、マイクロサービスの大きな利点が失われてしまう。
サービスメッシュによる解決
そこで登場するのがサービスメッシュだ。
サービスメッシュはサービスの代わりに上述の課題を解決してくれるサービス間通信のプロキシーサービスである。開発者はインフラ固有の課題から解放されサービスの開発に注力できるようになる。
小規模環境では複雑性が増すだけだが、大規模になるほどメリットが大きくなる。
なお同じ課題をAPI Gatewayで解決する考え方もある。API Gatewayについてはこちらの記事を参照のこと。
サービスメッシュのデメリット
- システムの複雑性が増す
- ICMPやUDPを許容しないものが多い
- 実装によってはPolicy Violationに対するVisibilityが低いものがある
- トラフィックの詳細なInspectionはできない（SQLインジェクションの検知など）
著名な実装例を以下に示す。
- Istio
- Linkerd
- Conduit
- Consul
Istioについてはこちらの記事を参照。
