サービスメッシュ＠サービスメッシュ系ミドルウェア¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. マイクロサービス間通信の管理¶
非メッシュ¶
▼ 非メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間でパケットを直接的に送受信する。
しかし、マイクロサービスアーキテクチャ固有のインフラ領域の課題 (例：マイクロサービス間通信の制御、マイクロサービス間通信のセキュリティ、テレメトリー作成、など) があり、非推奨である。
メッシュ¶
▼ メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間の通信をメッシュで管理する。
マイクロサービス間で直接的に通信を送受信する (サービスメッシュを導入しない) 場合と比較して、サービスメッシュを導入すると固有の課題を一括で制御しやすい。
マイクロサービスアーキテクチャ固有のインフラ領域の問題 (例：サービスディスカバリーの必要性、マイクロサービス間通信の暗号化、テレメトリー作成、など) を解決するためのロジックを切り分け、各マイクロサービスに共通的に提供できる。
02. サービスメッシュ¶
サービスメッシュとは¶
マイクロサービス間の通信方式でリクエストリプライ方式を採用した場合に使用するメッシュ。
サービスメッシュの層¶
マイクロサービスアーキテクチャでは、マイクロサービスへのインバウンド通信ロジック、マイクロサービスからのアウトバウンド通信ロジック、マイクロサービスのテレメトリーの収集ロジック、必要になる。
サービスメッシュの概念が提唱される前、これらのロジックを持つライブラリを各マイクロサービスに持たせていた。
サービスメッシュの概念が提唱され、アーキテクチャのインフラストラクチャ層としてリバースプロキシサイドカーをインジェクションするようになった。
サービスメッシュの概念により、アプリエンジニアがこれらのロジックを意識せずに (透過的に) 、インフラストラクチャ層より上層 (インターフェース層、ユースケース層、ドメイン層) の実装に注力できる。
共有ライブラリモデル¶
サービスメッシュが登場する前のモデル。
各マイクロサービスに共有ライブラリを配置する。
サイドカープロキシモデル¶
▼ サイドカープロキシモデルとは¶
マイクロサービスのリバースプロキシをサイドカーパターンで配置し、このコンテナをコントロールプレーンで一括管理する。
マイクロサービス間の通信を透過的にする (通信の存在を感じさせない) ことを思想としている。
▼ 透過的¶
サイドカープロキシメッシュでマイクロサービス間の通信を透過的にするためには、自動でサイドカープロキシを経由するような仕組みが必要である。
例えば、iptablesによるサイドカープロキシへのリダイレクトがある。
▼ 適するリバースプロキシ¶
マイクロサービスアーキテクチャでは、リバースプロキシのレイテンシー (レスポンスタイム) が重要である。
Envoy、Nginx、HAProxy、のレイテンシーの比較では、Envoyのレイテンシーが最も短いとの結果が出ている。
カーネルモデルとは¶
Node上にエージェントを配置し、これを介してマイクロサービス間で通信する。
サービスメッシュの型の比較¶
| サイドカープロキシメッシュ | Nodeエージェントメッシュ | |
|---|---|---|
| Nodeのハードウェアリソース消費量 | × | ⭕️ |
| Nodeのストレージ使用量 | ⭕️ (なし) |
△ |
| データプレーンの冗長性 | ⭕️ |
△ |
| マイクロサービスごとの設定カスタマイズ | ⭕️ |
△ |
| 単純性 | × | ⭕️ |
03. サービスメッシュの実装¶
サービスメッシュのコンポーネント¶
概念としてのサービスメッシュを実装する必要がある。
リバースプロキシとして動作するコンテナをサイドカーパターンで配置し、このコンテナを中央集権的に管理するように実装する。
サイドカープロキシが稼働する領域を『データプレーン』、中央集権的に管理する領域を『コントロールプレーン』という。
OSSごとの実装方法¶
データプレーンとコントロールプレーンの組み合わせには様々ある。
| OSS名 | データプレーンの実装 | コントロールプレーンの実装 | サポートしているXDS-API |
|---|---|---|---|
| Istio | Envoy | Istiod | 全てのXDS-API |
| Linkerd | ビルトインプロキシ (Linkerd2-proxy) | Proxy Injector、Destination、Identity | 全てのXDS-API |
| Consul | ビルトインプロキシ、Envoy | Consul-control-plane | 全てのXDS-API |
| SPIRE | Envoy | SPIRE | SDSのみ |
| ... | ... | ... | ... |
04. サービスディスカバリー¶
サービスディスカバリーとは¶
マイクロサービスアーキテクチャにて、送信元マイクロサービスが宛先マイクロサービスの場所 (IPアドレス、ポート番号、完全修飾ドメイン名、など) を動的に検出し、また同時に名前解決できるようにする仕組みのこと。
サービスディスカバリーの要素¶
サービスディスカバリーの仕組みは、次の要素からなる。
- 送信元マイクロサービス
- 宛先マイクロサービス
- サービスレジストリ
- ロードバランサー
- 名前解決 (DNSベースのサービスディスカバリーの場合のみ)
05. デザインパターン¶
クライアントサイドパターン¶
▼ クライアントサイドパターン¶
サービスレジストリ (例：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、など)