サービスメッシュ＠サービスメッシュ系ミドルウェア¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. マイクロサービス間通信の管理¶
非メッシュ¶
▼ 非メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間でパケットを直接的に送受信する。
しかし、マイクロサービスアーキテクチャ固有のインフラ領域の問題 (例：マイクロサービス間通信の制御、マイクロサービス間通信のセキュリティ、テレメトリー作成など) があり、非推奨である。
メッシュ¶
▼ メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間の通信をメッシュで管理する。
サービスメッシュを導入しない場合と比較して、サービスメッシュを導入すると固有の問題を一括で制御しやすい。
マイクロサービスアーキテクチャ固有のインフラ領域の問題 (例：サービス検出の必要性、パケットのアプリケーションデータの暗号化、テレメトリー作成、認証など) を解決するためのロジックを切り分け、各マイクロサービスに共通的に提供できる。
02. サービスメッシュ¶
サービスメッシュとは¶
マイクロサービス間の通信方式でリクエスト／レスポンス方式を採用する場合に使用するメッシュ。
一方のパブリッシュ／サブスクライブ方式では、メッセージ中継システムが専用のプロトコル (例：AMQP、MQTT、Kafka 独自プロトコル) を使用することが多い。
サービスメッシュツールはこれらのプロトコルに対応していないことが多く、パブリッシュ／サブスクライブ方式ではイベントメッシュ (例：Knative Eventing) のほうがよい。
サービスメッシュの層¶
マイクロサービスアーキテクチャでは、マイクロサービスへのインバウンド通信ロジック、マイクロサービスからのアウトバウンド通信ロジック、マイクロサービスのテレメトリーの収集ロジック、必要になる。
サービスメッシュの概念が提唱される前、これらのロジックを持つライブラリを各マイクロサービスに持たせていた。
サービスメッシュの概念が提唱され、アーキテクチャのインフラストラクチャ層としてリバースプロキシサイドカーをインジェクションするようになった。
サービスメッシュの概念により、アプリエンジニアがこれらのロジックを意識せずに (透過的に) 、インフラストラクチャ層より上層 ( インターフェース層、ユースケース層、ドメイン層) の実装に注力できる。
02-02. デザインパターン¶
共有ライブラリパターン¶
サービスメッシュが登場する前のモデル。
各マイクロサービスに共有ライブラリを配置する。
サイドカーパターン¶
▼ サイドカーパターンとは¶
マイクロサービスのリバースプロキシをサイドカーパターンで配置し、このコンテナをコントロールプレーンで一括管理する。
マイクロサービス間の通信を透過的にする (通信の存在を感じさせない) ことを思想としている。
▼ 透過的¶
サイドカーパターンでマイクロサービス間の通信を透過的にするためには、自動でサイドカープロキシを経由するような仕組みが必要である。
例えば、iptables によるサイドカープロキシへのリダイレクトがある。
▼ 適するリバースプロキシ¶
マイクロサービスアーキテクチャでは、リバースプロキシのレイテンシー (≒レスポンスタイム) が重要である。
Envoy、Nginx、HAProxy、のレイテンシーの比較では、Envoy のレイテンシーがもっとも小さいとの結果が出ている。
サイドカーレスパターン¶
Node 上にエージェントを配置し、これを経由してマイクロサービス間で通信する。
サービスメッシュの型の比較¶
| 共有ライブラリパターン | サイドカーパターン | サイドカーレスパターン | |
|---|---|---|---|
| Nodeのハードウェアリソース消費量 | × | ⭕️ |
|
| Nodeのストレージ使用量 | △ | △ | |
| データプレーンの冗長性 | ⭕️ |
△ | |
| マイクロサービスごとの設定カスタマイズ | ⭕️ |
△ | |
| 単純性 | × | ⭕️ |
❤︎
03. サービスメッシュの実装¶
サービスメッシュのコンポーネント¶
概念としてのサービスメッシュを実装する必要がある。
リバースプロキシとして動作するコンテナをサイドカーパターンで配置し、このコンテナを中央集中的に管理する。
サイドカープロキシが稼働する領域を『データプレーン』、中央集中的に管理する領域を『コントロールプレーン』という。
OSSごとの実装方法¶
データプレーンとコントロールプレーンの組み合わせにはさまざまある。
ここでは代表的な OSS と、そのデータプレーン/コントロールプレーンの実装例、および Envoy の xDS API との関係性を整理する。
| OSS名 | データプレーンの実装 | コントロールプレーンの実装 | xDS APIとの関係 |
|---|---|---|---|
| Istio | Envoy | Istiod | EnvoyのxDS APIをフルに活用 |
| Linkerd | ビルトインプロキシ (linkerd2-proxy) | Destination、Identity など | 独自プロキシであり、EnvoyのxDSとは非互換 |
| Consul | ビルトインプロキシ、Envoy | Consul control plane | Envoy連携時に一部のxDS APIを利用 |
| SPIRE | Envoy | SPIRE | EnvoyのSDS (Secret Discovery Service) を利用 |
| ... | ... | ... | ... |
04. サービス検出¶
サービス検出とは¶
マイクロサービスアーキテクチャにて、送信元マイクロサービスが宛先マイクロサービスの場所 (IP アドレス、ポート番号、完全修飾ドメイン名など) を動的に検出し、通信できるようにする仕組みのこと。
サービス検出の要素¶
サービス検出の仕組みは、次の要素からなる。
- 送信元マイクロサービス
- 宛先マイクロサービス
- サービスレジストリ
- ロードバランサー
- 名前解決 (DNS ベースのサービス検出の場合のみ)
05-02. 宛先検出¶
クライアントサイドパターン¶
▼ クライアントサイドパターン¶
サービスレジストリ (例：etcd) に宛先を問い合わせ、宛先にルーティングする責務は、クライアント側マイクロサービスにある。
(1)-
送信元マイクロサービスは、宛先マイクロサービスの場所をサービスレジストリに問い合わせ、宛先情報を取得する。
(2)-
送信元マイクロサービスは、ロードバランサーを経由して、宛先マイクロサービスにリクエストを送信する。
▼ 実装方法¶
- Netflix Eureka
サーバーサイドパターン¶
▼ サーバーサイドパターンとは¶
サービスレジストリ (例：etcd) に宛先を問い合わせ、宛先にルーティングする責務が、クライアント側から切り離されている。
(1)-
送信元マイクロサービスは、ロードバランサーにリクエストを送信する。
(2)-
ロードバランサーは、宛先マイクロサービスの場所をサービス検出に問い合わせ、宛先情報を取得する。
(3)-
ロードバランサーは、宛先マイクロサービスにリクエストをルーティングする。
- https://microservices.io/patterns/server-side-discovery.html
- https://www.baeldung.com/cs/service-discovery-microservices
- https://iximiuz.com/en/posts/service-discovery-in-kubernetes/
- https://blog.bitsrc.io/service-discovery-pattern-in-microservices-55d314fac509
- https://www.north-47.com/knowledge-base/service-discovery-in-a-microservices-architecture-client-vs-service-side-discovery/
▼ 実装方法¶
- Kubernetes の Service と kube-proxy + CoreDNS (DNS ベースのサービス検出)
- サービスメッシュツール (例：Istio、Linkerd など) のサイドカー
- サービス検出機能を持つリバースプロキシ (例：素の Envoy、Traefik など)
- クラウド (例：AWS ALB)
05-03. 宛先登録¶
セルフ登録¶
▼ セルフ登録とは¶
サービスレジストリ (例：etcd) に自身を登録し、宛先を問い合わせ、宛先にルーティングする責務は、クライアント側マイクロサービスにある。
サードパーティ登録¶
▼ サードパーティ登録とは¶
記入中...
06. サービスメッシュの将来¶
- ゼロトラスト
- ハイブリッドクラウド