 本記事は TechHarmony Advent Calendar 2024 12/25付の記事です。 |
こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。
re:Invent 2024で『VPC LatticeがTCPによるアクセスをサポート』というアナウンスがありました。
PrivateLinkの機能追加とあわせて、AWSのネットワークまわりに大きな変化がありそうです。
……と言っておきながら、実は私、VPC Latticeを使ったことがありません。というのも、VPC Latticeはコンテナと合わせて語られることが多く、あまりコンテナと関わってこなかった私にとっては、そのうち勉強しようと思っているけれどなかなかその機会に恵まれないサービスだったのです。
そういうわけで、re:Inventで発表された機能を使ってみる前に、とりあえずVPC Latticeを使ってみよう、というのが本記事の趣旨になります。
検証構成
今回は、まずは基本を抑えねばということで、新機能の検証ではなく、従来通りのVPC Latticeを試してみることにしました。図にすると以下のようになります。
VPC Latticeがどういうものかというと、ALBに近いものをイメージすればよさそうです。今回の機能拡張前は、HTTPとHTTPSのみの対応であったという点もALBに似ています。
Service NetworkがALB本体のようなもので、接続元となるVPCに関連付ける必要があります。
Serviceは、ALBのリスナーとターゲットグループをひとまとめにしたようなものです。リスナーとターゲットグループという用語はALBそのままですね。何番ポートで通信を待ち受けて(リスナー)、どこ(どのIP/どのインスタンス、など)に転送するか(ターゲットグループ)を設定します。
環境構築
マネジメントコンソールでは、『VPC』→ 『PrivateLink and Lattice』のメニューから設定を進めていきます。
ターゲットグループの作成
まずは接続先を定義するターゲットグループから作成していきます。
メニューから『ターゲットグループ』を選択し、『ターゲットグループの作成』をクリックします。
ターゲットタイプの選択では、インスタンスよりIPアドレスの方が汎用性が高い使い方ができるだろうということで、IPアドレスを選択しました。
ターゲットグループ名、プロトコル、ポート、IPアドレスタイプ、接続先側のVPC、プロトコルバージョン、ヘルスチェックを指定します。今回はつながりさえすればよいというのを目標にしているので、HTTP(80番ポート)でEC2に接続し、ヘルスチェックもデフォルトのまま( / へのHTTPによるヘルスチェック)にします。
次の画面に進むと、ターゲットの登録をすることになります。VPCを選択し、接続先のIPとポートを指定して、『保留中として以下を含める』をクリックするとターゲットとして登録されます。
ターゲットが登録されたら『ターゲットグループの作成』をクリックしてターゲットグループの作成を完了させます。
サービスの作成
メニューから『Lattice services』を選択し、『サービスを作成』をクリックします。とりあえずつながることを目指しているので、カスタムドメイン設定、サービスアクセス、Share service、モニタリングはデフォルトのまま進みます。
次へ進み、『ルーティングを定義』というところでリスナーの設定をします。プロトコルをHTTPに、ポートを80に設定します。リスナールールは設定せず、リスナーのデフォルトアクションとして『ターゲットグループへ転送します』を選び、ターゲットグループとして先ほど作成したターゲットグループを選択します。
次にサービスネットワークの関連付けの画面が出ますが、まだサービスネットワークは作成していないので、飛ばします。『確認と作成』画面が出るので、『VPC Latticeサービスを作成』をクリックしてサービスを作成します。
サービスネットワークの作成
メニューから『サービスネットワーク』を選択し、『サービスネットワークを作成』をクリックします。
サービスの関連付けのところで、先ほど作成したサービスを選択します。VPCの関連付けのところで、接続元のVPCを指定し、適用するセキュリティグループを選びます。他はデフォルトのままでサービスネットワークを作成します。
接続確認
設定はこれで完了ですが、先ほど登録したターゲットは生きていると判定されているでしょうか。作成したターゲットグループを選び、『ターゲット』タブを確認します。ヘルスステータスが正常になっているので、うまくいったようです。
さて、接続確認を実施したいのですが、どこにアクセスすればよいのでしょうか？答えは、「サービス」の詳細のところにあります。
「ドメイン名」を確認し、接続元VPCのEC2から接続してみます。
接続できました！
考察
接続できましたが、どのような仕組みになっているのか気になるところです。
まずは、ドメイン名を名前解決するとどうなるか確認してみます。
169.254. から始まるリンク・ローカル・アドレスが返ってきました。
接続元EC2が存在するサブネットのルートテーブルを確認してみます。
129.224.0.0/17と169.254.171.0/24が登録され、ターゲットがVpcLatticeとなっています。
129.224.0.0/17はどこで使われるのでしょうね？これは今後気が向いたら調べることにします。
次に、接続を受ける側のEC2で、どこから通信が来ているのかtcpdumpを使って確認してみます。
/ にはいくつかのIPから通信が来ていて紛らわしいので、/test にアクセスしてみました。169.254.171.194から来ていることが分かります。こちらもリンク・ローカル・アドレスということですね。
接続先側のルートテーブルも確認してみます。
169.254.171.0/24が登録され、ターゲットがVpcLatticeとなっています。
今回、説明を端折りましたが、169.254.から通信が来るので、接続先EC2のセキュリティグループで169.254.のCIDRを許可してやる必要があります。
接続元側は169.254.xx.xxのIPに接続し、接続先側は169.254.xx.xxから通信が来ているように見えるということは、もし別のVPCから利用したいという場合には一工夫する必要がありそうです。もっとも、一工夫するのではなく素直に接続元VPCにLatticeを構築するのが正攻法だと思います。
まとめ
VPC Latticeの新機能を試す前に、まずはこれまでのVPC Latticeがどういうものなのか知らなくては、という動機でこの記事を書き、なんとなくどういうものなのか分かってきました。
次は、新機能の検証に進みます。