EKS with AppMeshを使っていると、年内には諸々の再設計する必要性があるので初期調査メモとして残す。

AppMesh仕様

k8sリソースとの対応としては次の通り。
- kind: Service: kind: VirtualService
- kind: Deployment: kind: VirtualNode
AppMeshのVirtual Service制約として、サービス名はservice.__namespace__.svc.cluster.localである必要がある
この文字列は、サービスの識別子として使用されます。これは、対象とする実際のサービスのサービス検出名である必要があります。たとえば、my-service.default.svc.cluster.local にリクエストを送信するアプリケーションがある場合、仮想サービス名は同じである必要があります。
VirtualServiceはルーター設定(Virtual Router)を持ち、ルーティングポリシーによってVirtualNodeに通信される
- Virtual Router無しでも Service -> Nodeへの通信は可能だが、重みづけ送信やリクエスト条件、リトライ・タイムアウトを設定できる
- ref.) Routes: https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html
コンテナのIPアドレスはCloudMapで管理され、単一のエンドポイントで複数値を回答する
- ref.) SRVレコード：https://datatracker.ietf.org/doc/html/rfc2782
メッシュ内通信をするユースケースであればGatewayは不要
相互TLS認証（クライアント認証＋TLS暗号化）もAppMeshに統合されているので、セキュリティも管理できる
- ref.) https://docs.aws.amazon.com/ja_jp/app-mesh/latest/userguide/mutual-tls.html
- 自己証明書をストレージ管理したくない場合、AWS Private CA（$400 monthly）を使うことになる...

 AppMesh構成

powered by Claude 3.7 Sonnet
"グラフィックレコーディング"でお願いするとこういう構成図も提供してくれる。自身が理解できていない分野で生成AI使うと、自身のレビューぢからが試される時代になった。。

 AppMeshのリソースグラフ試しにNeo4jで作成してみたら、こうなる。

基本の理解としては正しかったな、という振り返りになったので良しとする。

T.S

Virtual Service命名規則

この文字列は、サービスの識別子として使用されます。
これは、対象とする実際のサービスのサービス検出名である必要があります。
たとえば、`my-service.default.svc.cluster.local` にリクエストを送信するアプリケーションがある場合、仮想サービス名は同じである必要があります。

通信先の動的な名前解決
Virtual NodeはSRVレコード(RFC 2782)に則り、宛先となる複数リソースを回答する。DNSレコードを使ったサービスディスカバリのプロトコルについては、RFC 6763に定義されている。
Mutual TLS
AppMeshの相互TLS認証を使うことで、通信を暗号化しつつクライアント認証も透過的に実現する。
その他
DNSベースのサービスディスカバリを実装しているミドルウェアとして、EurekaやDaprなどがある。k8s標準であれば、CoreDNSになる。

Eureka：https://spring.io/guides/gs/service-registration-and-discovery
クライアントからeureka-serverにエンドポイント情報が登録される。eureka-serverに問い合わせることで、宛先のURIを動的に取得できる。
Dapr：https://docs.dapr.io/concepts/overview/
pub/sub構成で使えるサイドカー。クライアントサイドでロードバランシングを実現する。”Building blocks”という設計思想のため、ユースケースに沿って複数のアーキテクチャを使い分けることも可能。
CoreDNS：https://coredns.io/manual/toc/#setups
クラスタ内のサービス(kind: Service)間通信を名前解決するゾーンやルールを管理する。Prometheusにも対応している。

このスクラップは5ヶ月前にクローズされました