AWS

Network Load Balancer(NLB)について

aws, Elastic Load Balancing, Network Load Balancer コメントを残す

こんにちは、ディーネットの山田です。

Network Load Balancer(NLB)について今まで深く調べたことがなかったので調べてみました。
NLBは、Elastic Load Balancing(ELB)に分類されるサービスの1つで、他にも以下のような種類のロードバランサがあります。

  • Application Load Balancer
  • Gateway Load Balancer
  • Classic Load Balancer

今回は、NLBについてそもそもNLBとは何か？という部分から簡単に説明したいと思います。

Network Load Balancer(NLB)とは何か？

  • AWS上で提供される数あるロードバランシング機能の中で、OSI参照モデルで言うところの第4層で機能するロードバランサになります。
  • NLBで受信したトラフィックをEC2インスタンスや特定のIPアドレスなどに分散することができます。

Network Load Balancerについて

Application Load Balancer(ALB)との違いについて

  • NLB単体でロードバランサのIPアドレスを固定化することができ、暖気対応（暖気運転）は不要になります。
  • 送信元IPアドレスと送信元ポートを維持することができ、分散先のEC2インスタンスなどはロードバランサが存在していないかのように扱うことができます。
  • NLBにはセキュリティグループを設定することが出来ないため、リクエストはすべてEC2などの分散先に到達します。
  • 分散先のセキュリティグループ等でファイアウォール制限の対応が必要です。

検証した結果を踏まえて先に挙動をまとめてしまいますと

  • NLBは、NAT方式のL4ロードバランサになります。
  • しかし、AWS Hyperplaneと呼ばれる特殊なAWS独自の負荷分散技術を用いているため設定次第ではNAT方式のL4ロードバランサではなくDSR方式のL4ロードバランサに近い挙動を合わせもつことができます。
  • また、一般的にDSR方式を実現しようとすると戻りのパケット経路などを考慮する必要がありますが、NLBでは考慮する必要がありません。
  • 言ってみれば、NAT方式にDSR方式の欲しいところを組み合わせた感じでしょうか。

外部サイトで恐縮ですが、図解でわかりやすくご説明されておりました。
L7ロードバランサとL4ロードバランサ

発生する費用について

NLBの利用料金は、2つの要素から算出する必要があります。

  1. Network Load Balancer 時間
  2. NLCU 時間

Elastic Load Balancing料金

Network Load Balancer 時間の費用とは

NLBを構築してから1時間毎に発生する費用になります。
NLBを介した通信を行っていなくても、NLBを保有しているだけで 1時間に0.0243USD(東京リージョンの場合) 発生します。
(例) 24時間×31日×0.0243USD = 18.0792 (約18USD) 日本円だと大体2000円程度1か月間に必要となります。

NLCU時間の費用とは

簡単に言うとNLBを使った量に応じて発生する費用になります。
NLCU時間あたりに0.006USD(東京リージョンの場合)発生します。

NLCU は Network Load Balancer がトラフィックを処理するディメンションを測定します (1 時間あたりの平均)。以下の 3 つのディメンションを測定します。

  • 新しい接続またはフロー: 1 秒あたりの新たに確立された接続またはフローの数。多くのテクノロジー (HTTP、WebSockets など) では、効率を高めるために Transmission Control Protocol (TCP) 接続を再利用します。新しい接続数は、通常、リクエストまたはメッセージ数よりも少なくなります。
  • アクティブな接続またはフロー: 1 分ごとにサンプリングされたピーク時の同時接続またはフローの数。
  • 処理バイト: ロードバランサーによって処理されたバイト数 (ギガバイト (GB) 単位)。

計算式や条件が複雑であるため、実際にはAWS Pricing Calculatorを利用することをおすすめします。

ではここから実際に構築した環境でパケット通信を見てみます

まず、構成は以下のような環境を準備しました


※便宜上シンプルアイコンは、理解に必要なもののみにしております。

それぞれ数字の地点で通信パケットをキャプチャしてみます

※以下の結果に表示されている、送信元のIPアドレスは予めテストネットワーク用アドレスに置き換えておりますが、送信元のポート番号はそのまま表示しております。

  • 198.51.100.20 - ELB
  • 192.0.2.13 - EC2

①

# curl yamada-nlb-blog-hogehogehoge.elb.ap-northeast-1.amazonaws.com
TEST PAGE by DENET. machine 1

②

# tcpdump -n -n port 80 -A
15:19:01.432902 IP 10.24.10.20.47194 > 198.51.100.20.80: Flags [P.], seq 1:130, ack 1, win 211, options [nop,nop,TS val 277479710 ecr 615163129], length 129: HTTP: GET / HTTP/1.1
E.....@.@...
.
.#K.H.Z.PI......T....6g.....
....$...GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: yamada-nlb-blog-hogehogehoge.elb.ap-northeast-1.amazonaws.com
Accept: */*

③

# tcpdump -n -n port 80 -A
06:19:01.433090 IP 192.0.2.13.47194 > 10.10.10.174.80: Flags [P.], seq 1:130, ack 1, win 211, options [nop,nop,TS val 277479710 ecr 615163129], length 129: HTTP: GET / HTTP/1.1
E.....@.>...6..P

..Z.PI......T.....&.....
....$...GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: yamada-nlb-blog-hogehogehoge.elb.ap-northeast-1.amazonaws.com
Accept: */*

④

# tcpdump -n -n port 80 -A
06:19:01.433369 IP 10.10.10.174.80 > 192.0.2.13.47194: Flags [P.], seq 1:305, ack 130, win 437, options [nop,nop,TS val 615163129 ecr 277479710], length 304: HTTP: HTTP/1.1 200 OK
E..dc.@....j

.6..P.P.Z...TI..............
$.......HTTP/1.1 200 OK
Date: Wed, 01 Sep 2021 06:19:01 GMT
Server: Apache/2.4.48 ()
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Wed, 01 Sep 2021 02:25:27 GMT
ETag: "1e-5cae5c78e596f"
Accept-Ranges: bytes
Content-Length: 30
Content-Type: text/html; charset=UTF-8

TEST PAGE by DENET. machine 1

⑤

# tcpdump -n -n port 80 -A
15:19:01.433461 IP 198.51.100.20.80 > 10.24.10.20.47194: Flags [P.], seq 1:305, ack 130, win 437, options [nop,nop,TS val 615163129 ecr 277479710], length 304: HTTP: HTTP/1.1 200 OK
E..dc.@....I#K.H
.
..P.Z...TI........3.....
$.......HTTP/1.1 200 OK
Date: Wed, 01 Sep 2021 06:19:01 GMT
Server: Apache/2.4.48 ()
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Wed, 01 Sep 2021 02:25:27 GMT
ETag: "1e-5cae5c78e596f"
Accept-Ranges: bytes
Content-Length: 30
Content-Type: text/html; charset=UTF-8

TEST PAGE by DENET. machine 1

パケットキャプチャから見えたパケットの流れ


※AWS Hyperplaneと呼ばれる特殊なAWS独自の負荷分散技術を用いているためAWS内部ではどのように扱われているか実際のところは不明ですが、パケットキャプチャから見えたパケットの流れを想像含めて記載しております。（緑色の部分が想像です）

注意点やまとめ

  • 今回の構成では、ターゲットグループにある Preserve client IP addresses 設定を Enabled にして検証を行っておりますため、分散先であるホストで接続元IPアドレスや接続元ポート番号を受け取ることが出来ております。
  • 仮に Preserve client IP addresses 設定を Disabled にした場合は、一般的なNATロードバランサと同じ挙動になり分散先であるホストで接続元IPアドレスや接続元ポート番号を受け取ることは出来ません。
  • 分散先ホストのセキュリティグループ等でファイアウォール制限の対応が必要とはじめに記載しましたが、あくまで Preserve client IP addresses 設定を Enabled にした場合は送信元の情報が通知されるため対応可能ですが、 Disabled にした場合は送信元の情報が通知されないため、接続元を制限することは出来なくなります。
    • NLBからはヘルスチェックのリクエストが定期的に行われるので、NLBのIPアドレスは必ず開放する必要がありますので、実際のところ遮断する方法がありません。

参考サイト

https://www.slideshare.net/AmazonWebServicesJapan/20191029-aws-black-belt-online-seminar-elastic-load-balancing-elb
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-elb-update-network-load-balanernlb
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/introduction.html

返信を残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA