y-ohgi's blog

TODO: ここになにかかく

CloudMapについて調べた

f:id:y-ohgi:20190627164854p:plain

概要

マイクロサービス間の名前解決を行うサービス。

例えばECSで管理しているサービス同士、サービスAPIから会員APIへ、の疎通を行うときなどに使います。

なぜ必要なのか

CloudMapはECSだけじゃなくEKSやLambdaやEC2などの様々なAWSリソースの名前を解決することでARN・IP・IP&Portを手に入れることができます。

例えばECSでマイクロサービスを構築して「ServiceA」と「ServiceB」を生み出したとしましょう。
そしてServiceAからServiceBへ接続する必要があるとします。

f:id:y-ohgi:20190627164845p:plain

ECSで管理しているコンテナは基本的にIPが動的に変化し、そしてスケールアウト/スケールインします。
その動的に変化するIPに追従するために、 ドメイン を発行して自動的にそのドメインにIPを紐付けるようにするものがCloudMapです。

いままではサービス間の疎通はELBを介してしかできなかったサービス間の疎通がDNSベースでできるようになったのが嬉しいわけですね。

コンポーネント

f:id:y-ohgi:20190627164837p:plain Namespace,Service,Instanceの3つのコンポーネントから成り立ちます。

Namespace

  • 名前空間
  • 1マイクロサービス1Namespaceのようなイメージ
  • Prd/Stg環境のような単位で分けると良さそう

Service

  • いわゆるマイクロサービスのサービス単位

Instance

  • コンテナやEC2など、名前解決した際の実体

所感

いままでECSのサービス間はELBを噛まさなければならなかったのが、カジュアルにRoute53を使用した名前解決ができるようになったのは嬉しいですね。
しかもIPだけじゃなくてarnも解決できます。

名前解決の方法もDNSだけじゃなくてAPI経由もあります。
中の人に聞く話によるとAPI経由が推奨らしく、反映速度がDNSだと40,50秒ほどかかるのに対してAPIベースだと2,3秒とのこと。

また、タグベースでCloudMapの解決ができるようになっていて、AWSの「タグ」への力の入れ方を見ているとタグはこの先重要な機能担ってくるのかなと感じます。