[新機能]静的なIPを持つロードバランサーNetwork Load Balancer(NLB)が発表されました!

288件のシェア(すこし話題の記事)

ウィスキー、シガー、パイプをこよなく愛する大栗です。

先程新しいロードバランサーNetwork Load Balancer(NLB)が発表されました!

Network Load Balancer

Network Load Balancer(NLB)はApplication Load Balancer(ALB)と異なりL4のロードバランサーです。

特徴

Network Load Balancerには以下の特徴があります。

  • 静的なIPアドレス:ロードバランサーに固定のIPアドレスを設定できます。
  • ゾーナリティ:サブネットごとのIPアドレスはパフォーマンス向上によるレイテンシの低減、分離と耐久性により可用性が向上、NLBの利用によってクライアントアプリケーションを透過的にします。
  • Source Address Preservation:パケットの送信元IPアドレスと送信元ポートを書き換えなくなりました。今まではX-Forwarded-Forでアクセス元IPアドレスを判断していましたが、パケットの情報自体で判断できます。
  • 長時間接続:NLBはフォルトトレランス機能を内蔵したコネクション処理を持ち、数カ月から数年のオープンなコネクションを処理できます。
  • フェイルオーバー:Route 53のヘルスチェックにより、リージョン内とリージョンを跨いだフェイルオーバーを行えます。

また、リソース構成はALBと同様に、ロードバランサとリスナー、ターゲットグループに分かれています。

料金

料金はALBと同様に起動時間とLCUの使用量で算出されます。

  • 1時間あたりの料金:$0.0243(東京リージョン)
  • LCU時間あたりの料金:$0.006(東京リージョン)

NLBの1LCUには以下の内容が含まれます。ALBのものとは異なるので注意してください。

  • 800件の新しい非SSLコネクションまたは毎秒のフロー。
  • 100,000のアクティブなコネクションまたはフロー
  • 2.22 Mbps(つまり1GB/時)

試してみる

NLBを作成してみる

丁度先程のNAT GatewayのブログでVPCを作成していたので、そこに NLBを作成します。

Management Consoleでロードバランサの画面を開きロードバランサーの作成をクリックすると、以下の画面が表示されます。ALB、NLB、CLBが表示されていますが、NLBを選択します。

EC2_Management_Console

任意の名前を付け、今回はインターネット向けを選択します。プロトコルはTCPのみです。

EC2_Management_Console

NLBを配置するVPCとサブネットを選択します。ここではNLBに設定するElastic IPも選択しますので、事前に割り当てておきましょう。タグも設定できます。

EC2_Management_Console

次にターゲットグループの設定を行います。ここでは新規にターゲットグループを作成するため新しいターゲットグループを選択します。ヘルスチェックも設定するのですが、ヘルスチェック用のプロトコルは以下の3種類から選択できます。ここではHTTPを選択してみましょう

  • HTTP
  • HTTPS
  • TCP

EC2_Management_Console

ターゲットとなるEC2インスタンスを登録します。

EC2_Management_Console

NLBの設定内容を確認して作成をクリックします。

EC2_Management_Console

EC2のターゲットのhttpdを起動して待っているのですが、unhealthyになってしまいました。

EC2_Management_Console

これは、EC2のセキュリティグループに問題がありました。 ヘルスチェックのためにNLBのターゲットはVPCのCIDRを許可する必要があります。 VPCのCIDRでポート80を許可したセキュリティグループをEC2に設定すると無事healthyになりました。

EC2_Management_Console

NLBにアクセスしてみる。

ターゲットのEC2は、事前にhttpdをインストールしてindex.htmlにインスタンスIDを設定したものを使用します。

$ sudo yum install -y httpd
$ curl -s http://169.254.169.254/latest/meta-data/instance-id | sudo tee /var/www/html/index.html > /dev/null
$ sudo service httpd start

NLBのDNS名にアクセスしてみます。するとタイムアウトになってしまいます。。。 NLB自体にセキュリテイグループを設定できないため、アクセス制御はターゲットのEC2で行います。つまりEC2自体がインターネットに対してアクセス許可をする必要があります。例えInternet Gatewayにルーティングされていないサブネットであってもです。

blog-test-32f0c75ea692ad52_elb_ap-northeast-1_amazonaws_com

気を取り直して。再度アクセスします。するとインスタンスIDを確認できました。

blog-test-32f0c75ea692ad52_elb_ap-northeast-1_amazonaws_com

別のブラウザでアクセスすると他のインスタンスへアクセスできました。

blog-test-32f0c75ea692ad52_elb_ap-northeast-1_amazonaws_com_index_html

IPアドレスの確認

digでNLBの名前解決をしてみます。すると、設定したElastic IPが表示されます。ちゃんと静的なIPになっています。

$ dig blog-test-1a2b3c4d5e6f7g8h.elb.ap-northeast-1.amazonaws.com

; <<>> DiG 9.8.3-P1 <<>> blog-test-32f0c75ea692ad52.elb.ap-northeast-1.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53955
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blog-test-1a2b3c4d5e6f7g8h.elb.ap-northeast-1.amazonaws.com. IN	A

;; ANSWER SECTION:
blog-test-1a2b3c4d5e6f7g8h.elb.ap-northeast-1.amazonaws.com. 60	IN A 13.112.XXX.XXX
blog-test-1a2b3c4d5e6f7g8h.elb.ap-northeast-1.amazonaws.com. 60	IN A 52.196.XXX.XXX

;; Query time: 42 msec
;; SERVER: 192.168.179.1#53(192.168.179.1)
;; WHEN: Fri Sep  8 10:02:02 2017
;; MSG SIZE  rcvd: 109

NLBの注意点

NLBはCLBのTCP機能と異なる点があります。気をつけましょう!

  • SSLアクセラレーション機能がないためhttpsを使用する場合はEC2でSSLターミネートを行う。
  • ヘルスチェック元の許可としてVPCのCIDRを許可する。
  • NLBにセキュリティグループ機能がなく、ターゲットのEC2でインターネット側のアクセス元を許可する必要がある。

さいごに

ずっと望まれていた静的なIPアドレスを持つロードバランサーが登場しました。どうしてもアクセス先をドメイン名ではなくIPアドレスで許可しなければならない場合などに重宝するでしょう。またhttpを理解するALBとくらべてTCPレベルのロードバランシングを行うNLBではパフォーマンスを上がっています。ただし、SSLアクセラレーションがない、セキュリティグループの扱いが異なるなど置き換えるものではないため、ALBとの使い分けが必要になります。

また、これでCLBを選択する必要もなくなったと思います。一応CLBのみの機能としてプロトコルとしてセキュアTCPに対応している点があります。しかし、ほとんどの場合はhttpか素のTCPの転送で賄えるため、CLBを使用しなくても大きな影響は出にくいと思います。

基本的にHTTP関連の場合はALB、それ以外のプロトコルや静的なIPが必要な場合はNLBと上手く使い分けていきましょう。