はじめに
AWSのALB（Application Load Balancer）のパスベースのルーティングを利用することで、1つのALBでパスごとに複数のアプリケーションを公開することが可能です。強力な機能ですが、ALBはIPアドレスが動的に変化してしまうため、オンプレミスとのハイブリット環境等でDNSの名前解決に制約がある場合や、セキュリティポリシー等でIPアドレスにてアウトバウンドの通信制限をしなければいけない要件などがあった場合にハードルがあり、利用を断念することがこれまでありました。
またIPアドレス固定については、ALBの前段にGlobal Acceleratorを置く手段はありましたが、特に閉域環境では利用が難しい状況でした。
そんな中、2021年9月にNLBのターゲットとしてALBを設定可能になるアップデートがありました。これを利用することで閉域環境でもNLBでIPアドレスを固定しつつ、ALBでパスベースのルーティングを実現することができるようになったため、動作検証を行いました。
検証したアーキテクチャ
検証したアーキテクチャは以下の通りです。
VPC（10.0.0.0/16）内に二つのSubnet（10.0.10.0/24、10.0.11.0/24）を配置し、NLBとALBをInternal Load BalancerとしてVPC内に配置しています。またNLBのターゲットとしてALBを設定し、さらにALBのターゲットとして、3つのターゲットを設定しています。1つ目は/パスでアクセスできるデフォルトのアプリケーション（nginxのデフォルトページを出力）、2つ目は/app1でアクセスできるApp1（アクセスするとapp1と出力するアプリ）、3つ目は/app2でアクセスできるApp2（アクセスするとapp2と出力するアプリ）です。
またそれぞれのアプリケーションはECSのタスクとして定義して配置しています。
検証環境のデプロイ
検証に利用したAWS環境およびコンテナアプリケーションは下記に公開していますので、適宜ご参照ください。
https://github.com/moreyhat/nlb-alb-ecs
設定の確認
ポイントとなる設定を確認していきます。
NLBのIPアドレス
NLBではSubnetごとにプライベートIPアドレスを固定しています。
NLBのターゲットグループ
NLBのターゲットグループには「Application Load Balancer」がターゲットとして登録されています。
ALBのリスナールール
ALBのリスナールールは/app1*と/app2*でそれぞれ対応するターゲットグループにルーティングするように設定されています。また/はデフォルトのルーティング先にフォワードされます。（今回はヘルスチェックのパスとして利用）
ALBのターゲットグループ
ALBのルーティング先となる3つのターゲットグループはそれぞれECSで起動されたタスクがターゲットとして登録されています。
動作検証
動作検証ではVPC内にEC2インスタンスを立てて、そこからNLBのIPアドレスに対してそれぞれのパスでアプリケーションにアクセスできるかを検証しました。その結果、下記のような出力が得られたため、期待通りに動作しているのを確認しました。（/はnginxのデフォルトページが表示されるため、省略しています。）
$ curl -L 10.0.10.30/app1
app1
$ curl -L 10.0.10.30/app2
app2
$ curl -L 10.0.11.30/app1
app1
$ curl -L 10.0.11.30/app2
app2
まとめ
NLBのターゲットとしてALBが設定可能になったことで、今回検証したようにALBの機能をIPアドレスを固定しながら実現できたり、その他にもPrivateLink経由でのアクセスなども可能になり、より広い用途でALBの機能を利用できるようになったと思います。