サービスメッシュ＠サービスメッシュ系ミドルウェア¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. マイクロサービス間通信の管理¶
非メッシュ¶
▼ 非メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間でパケットを直接的に送受信する。
しかし、マイクロサービスアーキテクチャ固有のインフラ領域の課題 (例：マイクロサービス間通信の制御、マイクロサービス間通信のセキュリティ、テレメトリー作成など) があり、非推奨である。
メッシュ¶
▼ メッシュとは¶
マイクロサービスアーキテクチャで、マイクロサービス間の通信をメッシュで管理する。
サービスメッシュを導入しない場合と比較して、サービスメッシュを導入すると固有の課題を一括で制御しやすい。
マイクロサービスアーキテクチャ固有のインフラ領域の問題 (例：サービスディスカバリーの必要性、マイクロサービス間通信の暗号化、テレメトリー作成、認証など) を解決するためのロジックを切り分け、各マイクロサービスに共通的に提供できる。
02. サービスメッシュ¶
サービスメッシュとは¶
マイクロサービス間の通信方式でリクエスト/レスポンス方式を採用した場合に使用するメッシュ。
サービスメッシュの層¶
マイクロサービスアーキテクチャでは、マイクロサービスへのインバウンド通信ロジック、マイクロサービスからのアウトバウンド通信ロジック、マイクロサービスのテレメトリーの収集ロジック、必要になる。
サービスメッシュの概念が提唱される前、これらのロジックを持つライブラリを各マイクロサービスに持たせていた。
サービスメッシュの概念が提唱され、アーキテクチャのインフラストラクチャ層としてリバースプロキシサイドカーをインジェクションするようになった。
サービスメッシュの概念により、アプリエンジニアがこれらのロジックを意識せずに (透過的に) 、インフラストラクチャ層より上層 (インターフェース層、ユースケース層、ドメイン層) の実装に注力できる。
共有ライブラリモデル¶
サービスメッシュが登場する前のモデル。
各マイクロサービスに共有ライブラリを配置する。
サイドカー型¶
▼ サイドカー型とは¶
マイクロサービスのリバースプロキシをサイドカーパターンで配置し、このコンテナをコントロールプレーンで一括管理する。
マイクロサービス間の通信を透過的にする (通信の存在を感じさせない) ことを思想としている。
▼ 透過的¶
サイドカー型でマイクロサービス間の通信を透過的にするためには、自動でサイドカープロキシを経由するような仕組みが必要である。
例えば、iptablesによるサイドカープロキシへのリダイレクトがある。
▼ 適するリバースプロキシ¶
マイクロサービスアーキテクチャでは、リバースプロキシのレイテンシー (レスポンスタイム) が重要である。
Envoy、Nginx、HAProxy、のレイテンシーの比較では、Envoyのレイテンシーが最も短いとの結果が出ている。
サイドカーレス型とは¶
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など)
- クラウド (例：AWS ALB)
Self registration¶
▼ Self registrationとは¶
サービスレジストリ (例：etcd) に自身を登録し、宛先を問い合わせ、宛先にルーティングする責務は、クライアント側マイクロサービスにある。