AWS VPC Latticeを使用した、異なるVPC間のサービス間通信 | Offers Tech Blog
こんにちは！
Offers, Offers MGR を運営している株式会社 overflow の磯崎です。
VPC Latticeとは？
VPC Lattice とは複数の VPC、AWS アカウントにまたがるサービスをシンプルかつ安全に疎通させることができるサービスです。
マイクロサービスや、マルチ VPC やマルチアカウントの環境で、サービス間通信をしたい時に使えます。
他にも Private Link や VPC Peering、Transit Gateway を用いると、異なる VPC 間での通信が可能になります。
今回は、設定の手間と管理のシンプルさ、サービス追加時にも簡単に追加できるような冗長性などを踏まえ、VPC Lattice を使ってみました。
VPC Lattice はサービスネットワーク、サービス、ターゲットグループの 3 つで構成されています。
サービスネットワークとは
通信可能になるサービスの集合体です。
VPC とサービスを関連付け、サービスネットワークを構築することで、その範囲で通信ができます。
サービスとは
リスナーやターゲットグループが指定できます。
設定項目は ALB とほぼ一緒です。
サービスネットワークと関連付け、ターゲットグループを指定することで、リクエストを受け、指定のターゲットへのルーティングを行います。
ターゲットグループとは
EC2 で設定できるターゲットグループとは別の場所で設定できる、VPC Lattice のターゲットグループです。
サービスに関連付け、リクエストを送信するターゲットをここに設定します。
実際に設定していく
異なる VPC に存在する２つのサービス間で通信するための設定をしていきます。
両者とも Fargate で動いており、その前段にインターネット向けの ALB が存在します。
ターゲットグループの作成
今回はターゲットに IP アドレスを指定します。
２つのサービスを通信可能な状態にしたいので、今回は 2 サービス分この設定をしていきます。
VPC はそれぞれのサービスに現在設定されている VPC を選べば OK です。
ヘルスチェックなどのその他の項目も設定し、次に進みます。
次のページで、リクエストを転送するターゲットを指定します。
今回は IP アドレスで指定する形を選択したので、直接 IP アドレスを指定します。
既にそれぞれのサービスで設定されている ALB のターゲットグループで登録済みターゲットとして指定されている IP を指定します。
これで作成完了です。相互に通信したいサービス全てでこのターゲットグループを作成します。
サービスの作成
ターゲットグループができたので、次はサービスを作成します。
こちらも 2 サービス分作ります。
このサービスに上述したターゲットグループを設定します。
カスタムドメインも指定可能ですが、ここでは省略します。
省略すると、xxxxxxx.vpc-lattice-svcs.ap-northeast-1.on.aws のようなドメイン名でサービスが作られます。
内部でリクエストを送る際はこちらめがけて送ることになります。
Iam での認証を設定できます。これを設定することによって、認証されたサービスのみからのリクエストを受け付けるなど細かい設定ができます。
次へ進むと、ルーティングの定義に進みます。
ここで先程設定したターゲットグループを指定します。
その後のサービスネットワークの関連付けはこの後、サービスネットワークの設定でも紐付けることができるので、なにもせず次に進んで、作成して OK です。
サービスネットワークの作成
最後にサービスネットワークの設定をします。
上でつくったサービス２つをここで設定し、VPC も同様に関連付けます。
セキュリティグループの変更
ターゲットに指定した Fargate で動いているサービスで、VPC Lattice からの通信を許可する必要があります。
新たにセキュリティグループを作成し、それを関連付けます。
VPC→マネージドプレフィックスリストに記載のある、xxx.vpc-lattice, xxx.ipv6.vpc-lattice の２つをそれぞれ指定すれば OK です。
今回は、インバウンドルールに http, https でそれぞれ上記プレフィックスリストを設定しました。
疎通確認
これで準備完了です。実際に疎通できているか確認をします。
ある一方のサービスのコンテナから、もう一方のサービスに curl で get リクエストを送ります。
curl -v https://xxxx.vpc-lattice-svcs.ap-northeast-1.on.aws/health_check
200 が返ってきました。
上記環境以外のところで、同じようにリクエストを送っても、タイムアウトになることも確認できます。
まとめ
異なる VPC 間の通信が、細かいルーティングの設定なしにいとも簡単にぱぱっとできました。
また、VPC の CIDR が被っていても、通信可能なので、そこのコンフリクトを気にしなくて良いのもメリットです。
コストは VPC Peering で同様のことを実現するのに比べてかかってしまいますが、細かい設定なしに構築可能でその後の監視も簡単に行うことができます。
また、今後接続サービスが増えた時にも簡単に付け足しができるため、良い選択肢の 1 つだと思います。
関連記事
Discussion