この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ウィスキー、シガー、パイプをこよなく愛する大栗です。
先程新しいロードバランサーNetwork Load Balancer（NLB）が発表されました！
- New Network Load Balancer – Effortless Scaling to Millions of Requests per Second
- Announcing Network Load Balancer for Elastic Load Balancing
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を選択します。
任意の名前を付け、今回はインターネット向けを選択します。プロトコルはTCPのみです。
NLBを配置するVPCとサブネットを選択します。ここではNLBに設定するElastic IPも選択しますので、事前に割り当てておきましょう。タグも設定できます。
次にターゲットグループの設定を行います。ここでは新規にターゲットグループを作成するため新しいターゲットグループを選択します。ヘルスチェックも設定するのですが、ヘルスチェック用のプロトコルは以下の3種類から選択できます。ここではHTTPを選択してみましょう
- HTTP
- HTTPS
- TCP
ターゲットとなるEC2インスタンスを登録します。
NLBの設定内容を確認して作成をクリックします。
EC2のターゲットのhttpdを起動して待っているのですが、unhealthyになってしまいました。
これは、EC2のセキュリティグループに問題がありました。
ヘルスチェックのためにNLBのターゲットはVPCのCIDRを許可する必要があります。
VPCのCIDRでポート80を許可したセキュリティグループをEC2に設定すると無事healthyになりました。
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 startNLBのDNS名にアクセスしてみます。するとタイムアウトになってしまいます。。。 NLB自体にセキュリテイグループを設定できないため、アクセス制御はターゲットのEC2で行います。つまりEC2自体がインターネットに対してアクセス許可をする必要があります。例えInternet Gatewayにルーティングされていないサブネットであってもです。
気を取り直して。再度アクセスします。するとインスタンスIDを確認できました。
別のブラウザでアクセスすると他のインスタンスへアクセスできました。
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: 109NLBの注意点
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と上手く使い分けていきましょう。
6
