Service Mesh についての調査
Service Mesh とは
マイクロサービス間の通信を統制するための仕組み
コンテナの Sidecar としてプロキシをデプロイし、プロキシがログの収集やセキュリティなどの面倒見る
マイクロサービスにまたがった上記のようなプロキシを中央集権管理するものが Service Mesh
L7 での Load Balancing
現状 Kubernetes の Service は L4 での LB のみ提供しているため、L7 での LB を導入したい場合に Service Mesh を導入するというユースケースがある
Service Mesh でできること
分散トレーシング
Canary Release
mTLS
OAuth2 を用いた認可
分散トレーシングや Canary Release など社内のオペレーションを改善してから mTLS などセキュリティ要件を満たしていきたいお気持ち
各 Service Mesh の特徴について
Istio
Service Mesh 関連の OSS で最も成長している
サーバーのインフラが Kubernetes であれば Istio を導入するのが現時点ではベターか?
インフラが Kubernetes である企業は Istio を導入している企業が多い印象(Mercari / ZOZO ...)
App Mesh
AWS 謹製の Service Mesh
クロスアカウントで使用できる
Kubernetes だけでなく、ECS 等でも利用できる
X-Ray を用いて分散トレーシングができる
Istio と比較すると機能は少ないらしい
Canary Release 運用の際の Tips
アプリケーションのリリース時
リリースを行うのは基本的にインフラエンジニアではなくアプリケーションエンジニア
リリースの際に同時にインフラを変更することは(インフラの破壊的変更時を除いて)稀
したがって、Canary Release 時のトラフィックの比重を terraform で書くべきでない
テスト
リリース時に新環境に対してテストを行うべき
まずは手動で簡単なテストを開発エンジニアに行ってもらう
将来的には自動化をするべき
テスト成功したらそのまますべてのコンテナに対してデプロイする
テスト失敗したらロールバックする必要がある
社内のエンジニアのみがテストできるように特定のヘッダー(?)が付与されているときは新環境に接続できるみたいな機能を App Mesh 側で持たせられると良いかも
App Mesh のデプロイツールに必要なもの
上記の通り、基本的にダイレクトに使用するのはインフラエンジニアではなくアプリケーションエンジニア
機能面
設定ファイルを読み込んでトラフィックの比重を変更できる
デプロイ時 / ロールバックをシームレスに行える
設定ファイルは tfstate を読むことができる
設定ファイルのフォーマットは AWS API リファレンスの json に則る
参考文献