現在開発中のシステムでは複数台のWebサーバ（EC2）に対してALBで負荷分散するようにしていましたが、とある理由によりNLBでの負荷分散も試してみましたので、今回はその件に関して書きたいと思います。

「とある理由」と言うのが、「とある目的のためロードバランサに対して固定IPを設定したい」と言うもので、ALBに固定IPは設定できず、NLBには固定IPの設定が可能と言うことなので、NLBの使用を目指しました。実はこの固定IPの必要性自体が私の勘違いだったのですが…

なお、下記で示した操作において、以前（ALB環境構築時）にも同じ画面を表示したことがあり、その際は日本語表記の画面だったように思うのですが、今回の操作ではターゲットグループ生成画面やロードバランサーの構築関連画面などが英語表記になっていました。これが個人的に発生していることなのか、AWSさん側の事情なのかは不明です。
とりあえず今回は英語画面ベースの説明になっている部分もありますが、日本語で見えている場合は適宜読み替えてください。

Elastic IP 取得

NLB構築以前に割り振る固定IPを取得しておく必要があります。
なお、固定IP（Elastic IP）ですがAZごとに分ける必要があるようです。負荷分散を行う場合、稼働率を考慮してサーバを複数AZに分散すると思いますので、それらAZの数だけIPが必要になります。

なお、NLBの設定に際してはIPを割り振らずに行うこともできますが、一旦生成されたNLBに対して後からElastic IPを設定し直す方法はなさそうなので、本手順のように先にElastic IPを確保しておいて、NLB構築時に忘れずに設定する必要があります。

Elastic IPの取得自体はEC2管理画面から可能で、左メニューから「Elastic IP」を選択し、右上の「Elastic IP アドレスの割り当て」をクリックし、表示された「Elastic IP アドレスの割り当て」にて必要事項を入力します。
と言っても、実は特に設定する必要のある内容はなく、識別のためにタグ（オプション）としてNameキーの設定を行えば良い程度です。

ターゲットグループ生成

ロードバランサー関連の設定として、まずはターゲットグループから生成しておきます。
EC2管理画面の左メニューから「ターゲットグループ」を選択し、右上の「Create target group」をクリックします。

「Choose a target type」では「Instances」がデフォルトになっていると思いますので、そのまま。

「Target group name」では以降同グループを識別するための名前を付けます。

「Protocol」と「Port」は悩みどころです。
そもそも、ここで設定するプロトコルとポートの使用目的自体が不明です。直感的にはロードバランサーとターゲットグループに属すEC2との間での通信に用いるプロトコルおよびポートということだと思うのですが、今回のようにネットワーク（L4）ロードバランサーを想定する場合、プロトコルはTCPで良いとして、ポートが1つに限定されることに不都合はないんでしょうか？
Webサーバの負荷分散を考えた場合、HTTP（80）とHTTPS（443）の両方を対象としたくなると思うのですが、この場合どうするんでしょう？
と、色々不明点があるのですが、とりあえずプロトコル「TCP」ポート「80」としてみました（この辺、不安）。

「VPC」に関しては使用しているVPCが選択できるようになっていると思いますので、これを選択します。

ここまで設定すると、次のページで具体的に負荷分散対象としたいEC2インスタンスが選択できるようになっていますので、選択の上「Create target group」をクリックします。

これでターゲットグループが生成できました。

NLB 構築

いよいよNLBの構築を行います。
EC2管理画面の左メニューから「ロードバランサー」を選択し、左上の「ロードバランサーの作成」をクリックします。
最初の画面ではロードバランサーのタイプ（ALB、NLB等）を選択できるようになっているので、「Network Load Balancer」を選択します。

次画面では具体的かつ細かな設定を行っていきます。

「Load balancer name」では以降同NLBを識別するための名前を付けます。

「Scheme」は「Internet-facing」がデフォルトになっていると思いますので、そのまま。

「IP address type」も「IPv4」がデフォルトになっていると思いますので、そのまま。

「VPC」に関しては使用しているVPCが選択できるようになっていると思いますので、これを選択します。

「Mappings」では使用中のリージョンに属するAZが複数選択できるようになっています。
負荷分散対象となるEC2が属するAZを選択しますが、選択すると「Subnet」が選択できるようになるので、ここも対象となるEC2が属するサブネットを選択します。また、「IPv4 settings」として当該AZ用に割り振るIPの設定方法が選択できるようになりますが、ここで「Use an Elastic IP address」を選択すると先に取得したElastic IPを選択できるようになります。

「Listeners and routing」ではプロトコルとポートの組み合わせに対して「Default action」として転送先のターゲットグループを指定します。
ここで指定するターゲットグループは先に生成したものを指定しますが、問題は例によってプロトコルとポートの組み合わせです。ここでは複数の組み合わせを設定できます。
まずはプロトコル「TCP」ポート「80」を選択します。HTTPとしてはこれで良いはず。
ではHTTPSに対してはどのように設定すれば良いでしょう？
この辺はネット情報を頼りにプロトコル「TLS」ポート「443」と設定しました。加えて、この選択に対しては「Default SSL certificate」としてSSL証明書の設定ができるようになります。証明書の導入方法として「From ACM」を選択することで、ACMで生成した証明書が適用できるようになります。
これにより、HTTPS使用時にNLBに設定された証明書が使用されるようになるため、EC2個別に証明書を配置する必要がなくなって便利です。
なお、合わせて設定が必要な「Security policy」に関してはよく分かりませんがデフォルトのままにしておきます（recommendedって書いてあるので…）。

以上を設定の上、「Create load balancer」をクリックすれば、NLBが構築できます。

Route53のAレコード変更

最後に当該ドメインへのアクセスがNLB経由となるようにRoute53の設定を書き換えます。最初に触れたように、従来はALBを経由するようにAレコードが設定されていたので、このALB指定の部分を構築したNLBを指定するように変更するのみです。

Route53管理画面から対象ホストゾーンを選択し、負荷分散対象となるEC2へのアクセスに使用するドメインのAレコードを選択して「レコードを編集」をクリックします。

「トラフィックのルーティング先」の最初の選択肢で「Network Load Balancer へのエイリアス」を選択すると、次の選択肢としてリージョンが選択できるようになり、さらに次の選択肢として先に構築したNLBが選択できるようになります。

上記変更を行った上で「保存」を実行すれば、当該ドメインに対するアクセス先が構築したNLBに切り替わります。

なお、もともと構築してあったALBもそのまま残してあるので、上記Aレコードの「トラフィックのルーティング先」の更新のみでアクセス先をALBにしたりNLBにしたりと繰り返し切り替えができます。
色々と試行錯誤がしやすく、便利です。

総括

上記作業によりNLBでの負荷分散ができるようになりました。
digコマンド等を用いれば、当該ドメインに対してNLBに設定したElastic IPが対応付けられていることが分かります。

若干釈然としないのは、NLBとしてSSL証明書の処理ができてしまう点です。
個人的には通信系のプログラムを担当してきた過去もあり、OSI参照モデルに照らして考える傾向があるのですが、その視点ではHTTPSは第7層（アプリケーション層）のプロトコルであり、一方でNLBは第4層（トランスポート層）のロードバランサー（L4ロードバランサー）であるため、扱っているレイヤが合っていないように思えてしまいます。
そもそもインターネット自体がOSI参照モデルとは無関係に発展したものなので、OSI参照モデルに照らして考えること自体が不適切との意見もあるようですが、それであればALB（アプリケーションロードバランサー）NLB（ネットワークロードバランサー）やL7/L4ロードバランサーと言う表現自体も不適切のように思うのですが。

また、途中でも書きましたが、ターゲットグループで指定するプロトコルとポートの組み合わせの意味も結局は分かっていません。
とりあえずプロトコル「TCP」ポート「80」としてある現状で当該ドメインへのHTTPSアクセスが成立しているので、結果オーライなのですが。

と言うことで、色々と釈然としない点もありますが、そもそも最初に書いたようにNLB使用の動機であったロードバランサーへの固定IP設定自体が現時点では不要となっているため、問題がありそうであれば元のALBでの運用に戻そうと思っています。
本記事はあくまで、「とりあえず問題なく動いているように見えるNLB」を構築した記録として残しておくものです。