こんにちは。島村です。
最近マイクロサービスアーキテクチャの勉強をしています。
サービスメッシュの概念がわかりにくかったのでまとめてみようと思いブログにしてみました。
サービスメッシュの概念とAWS App Meshのアーキテクチャについて記載していきます。
今回は概念の説明だけに留まりますが、次回はハンズオンブログも書いてみたいと思います。
- サービスメッシュ とは
- サービスメッシュ という技術はなぜ生まれた背景
- サービスメッシュ 製品
- サービスメッシュ が提供する機能
- サービスメッシュのアーキテクチャ
- AWS AppMesh とは何か
- AWS App Mesh のコンポーネント
- 最後に
- 参考
サービスメッシュ とは
サービスメッシュは端的にいうと、アプリケーションに追加できるインフラストラクチャ層です。
マイクロサービスアーキテクチャでは、機能やサービス毎にアプリケーションが分かれアプリケーション連携を行うアーキテクチャです。
アプリケーション間の通信をマイクロサービスアプリケーションごとにそれぞれ実装するのではなく、サービスメッシュを使うことで、アプリケーションから相互通信におけるロジックを削除することができ、通信制御を一元的に管理できるようになります。
サービスメッシュ という技術はなぜ生まれた背景
なぜ、アプリケーション連携において通信を一元的に管理する必要があるのでしょうか。
サービスメッシュが解決する課題を見ていくと必要性が理解できます。
1.アプリケーションによって開発言語が異なる
アプリケーションごとに、開発言語が異なる場合連携する個別システムごとにシステム関連携のためにライブラリ(ツール)などを用意する必要があり学習コストや実装コストが言語にが多くなるほど比例して大きくなり開発者の負担になる課題がありました。もちろん、通信におけるセキュリティについても考慮する必要があります。
サービスメッシュを使うことで、通信のセキュリティ仕様や言語毎の通信に関する実装を言語毎にする必要がなくなります。
2.通信制御
マイクロサービスアーキテクチャでは、アプリケーション間連携が行われますがアプリケーション同士の連携が必要ない場合があります。
大規模な通信制御を個別に行うのは大変運用負荷が高い状態です。
3. 通信の観測性
アプリケーション間に関するものですが、アプリケーションが連携している部分見えにくい状態になってしまいます。
サービスメッシュでは、通信を観測する機能もあるためアプリケーション連携の可視化も可能になります。
システム間連携には、サービスディスカバリ(サービス検出)も含まれます。
また、サービス間連携時のセキュリティ要件を満たすために言語ごとに異なる実装をしないといけません。
サービスメッシュ 製品
Cloud Native Computing Foundation (CNCF)のランドスケープガイドで、サービスメッシュ製品を検索してみました。
余談ですが、CNCFのランドスケープガイドを使用することでサービス分類でカテゴライズすることができます
- Istio(CNCF/Our Graduated Projectsに位置)
- Linkerd(CNCF/Our Graduated Projectsに位置)
中でもIstioとLinkerdは卒業プロジェクトの位置におり、十分に成熟されたサービスとして認定されている扱いとなります。
サービスメッシュ が提供する機能
一般的にサービスメッシュが提供する機能を記載します。多機能ですね。
細かく見ると他にも機能は多くありますが、大枠で記載しています。
- サービスディスカバリ
- ロードバランシング
- トラフィック管理
- セキュリティ
- モニタリング
サービスメッシュのアーキテクチャ
サービスメッシュはサービス間通信のロジックを個別のサービスから削除し、インフラレイヤーで管理します。
具体的にインフラレイヤーで見ていくと、プロキシコンテナがサービス間通信を仲介します。
サイドカーコンテナとして、プロキシコンテナが存在しているイメージですね。
また、サービスメッシュには2つのコンポーネントが存在しています。
重要なので覚えておくと、サービスメッシュをより理解しやすくなると思います。
コントロールプレーン
サービスメッシュの設定/管理を担うコンポーネントです。
サービスメッシュが提供する機能のコンフィグレーションの内容を定義し、設定をデータプレーンに配布します。
プロキシへの設定反映は動的に行われます。
データプレーン
コントロールプレーンで定義した設定に応じて、通信を実際に処理するコンポーネントです。
データプレーンで通信を受け取ると、通信の送信元とプロキシ(サイドカーコンテナ)の間で暗号化された通信が確立されます。
https://istio.io/ から抜粋
AWS AppMesh とは何か
App Mesh はサービスメッシュコントロールプレーンを提供するAWSサービスです。
プロキシコンテナには Envoyと呼ばれるOSSのサービスメッシュ用プロキシのコンテナイメージが使用されます。
タスク定義にEnvoyプロキシコンテナイメージを追加することで、EnvoyをApp Meshで管理することが可能になります。
AWS App Mesh のコンポーネント
AWS App Mesh のコンポーネントは次のとおりです。
名前 | 詳細 |
---|---|
メッシュ | サービス間のネットワーク通信範囲を定義する概念です。メッシュの中に複数のサービスが含まれる状態になります。 仮想サービス、仮想ノード、仮想ゲートウェイ、仮想ルータはサービスメッシュ内に含まれるコンポーネントです。 |
仮想ノード | ECSサービスやKunatenesデプロイメントなどのタスクグループを指す論理的なコンポーネントです。 |
仮想ルータ | メッシュ内に存在している仮想サービスへトラフィックを処理します。仮想ノードから異なる仮想サービスに紐づく仮想ノードにトラフィックを送るルートを定義して関連付けることで通信制御を実現します。 |
仮想サービス | 仮想サービスは特定のマイクロサービスアプリケーションを指し、トラフィックが到達すべきアプリケーションを指しています。 |
仮想ゲートウェイ | メッシュ外のリソースがメッシュ内のリソースと通信する必要がある場合に使用するコンポーネントです。マイクロサービスアプリケーションのサイドカーコンテナとしてデプロイされているEnvoyとは別に別サービスとしてデプロイされ、このサービスをメッシュ内に含める必要があります。 |
図では、仮想ノードから異なる仮想サービスに紐づく仮想ノードへ通信する際に、仮想サービスから仮想ルータへつながっていますが、仮想ルータにトラフィックを流すことは必須ではありません。
設定次第では、仮想サービスから直接仮想ノードへトラフィックを流すことができます。
AWS App Mesh で提供している機能
ロードバランシング
仮想ルータでは、ロードバランシングの機能が提供されています。
例えば、仮想ノードで実行しているマイクロサービスアプリケーションの新しいバージョンをデプロイした際に
トラフィックの何割かを新しいバージョンに流すことなどもできます。
サービスディスカバリ
Cloud Mapを利用することで動的なサービス検出を行います。
セキュリティ
マイクロサービス間の通信ではmTLSを使用して相互認証を行い、通信元の特定を確実にすることで通信の信頼性を高めることが可能です。
モニタリング
App Meshではサービス間の通信はEnvoy コンテナを介して通信がおこなれます。
Ingress 通信と Egress 通信 それぞれの分けられたメトリクスがエクスポートされ、CloudWatch で確認することができます。
Envoyのコンテナ定義を変更する必要がありますが、 AWS X-Rayとも統合ができるため、
X-Rayを使用してサービス間通信のパフォーマンスを確認することができボトルネック特定も可能となります。
CloudWatch や X-Ray以外でも、Splunk、Prometheus、Jaeger、Flagger、Grafana、Zipkin 、LightStep などのサードパーティツールも利用できるようです。
最後に
今回はサービスメッシュについて調べてみました。
次回はAWS App Meshを使用したハンズオンを実際にブログにまとめてみたいと思います。
多機能なのでやれることが多いのは魅力的ですが、サービスメッシュに関する概念や コンポーネントの仕組みを理解した上で実装していきたいですね。
参考
https://www.cloudflare.com/ja-jp/learning/access-management/what-is-mutual-tls/
島村 輝 (Shimamura Hikaru) 記事一覧はコチラ
最近ECS周りをキャッチアップ中。趣味は車・バイク全般。
一応、AWS12冠です。