ちゃっす。 ユニファのインフラ鈴木です。
久しぶりのブログです。
花粉がすごいらしいですね！！
最近鼻水とか出ますけど、私は花粉症ではないので関係ないでしょうね…うん
前回に引き続きNLBの事をブログに書こうと思います。
あ、NLBはなんぞやというかたは、公式のブログをどうぞ
NLBの何を書くかというと、複数のAZで複数のターゲットグループが設定されていた場合に、1つのターゲットグループが単一AZの利用になっていた場合どういう挙動になるのかなと言うものです。
では確認していきます。
1つのターゲットグループでAZの数を変えた時の挙動
ターゲットグループにdのインスタンス（正確にはECSのタスクですが…）が割当たっている状態
名前解決すると１つだけ返る
'->$ nslookup sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Server: 192.168.11.1 Address: 192.168.11.1#53 Non-authoritative answer: Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.114.244.161
続いて別AZのインスタンスを割り当てる
initialだけどなんか結果かわった…いいのかな？
AZ(a)が増えた分名前解決から返ってくるのが１つ増えます
'->$ nslookup sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Server: 192.168.11.1 Address: 192.168.11.1#53 Non-authoritative answer: Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.114.244.161 Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.230.61.191
試しに返ってきたIPに直接リクエストなげてみたら同じように返ってきてるので両方利用できていますね。
'->$ curl sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
'->$ curl 13.114.244.161
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
'->$ curl 13.230.61.191
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
その状態から1つ外してみてリクエストなげてみます。
するとタイミングの問題だと思うのですが、インスタンスの居ない方にリクエストを投げると通信できないですね。
'->$ nslookup sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com
Server: 192.168.11.1
Address: 192.168.11.1#53
Non-authoritative answer:
Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com
Address: 13.230.61.191
Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com
Address: 13.114.244.161
'->$ curl 13.114.244.161
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
'->$ curl 13.230.61.191
^C # 返ってこないのでキャンセル
少し置くと名前解決で返ってくる値は1つになります
リスナーとターゲットグループを一つ追加しそちらは常に複数AZにしておく
NLBのリスナーに2つ目を追加し、ポート80と9292の2つで受けれるようにしています。
適当なアプリが欲しかったのでsinatraのアプリを利用してみています。(port:9292の方)
sinatraの方は複数AZ構成
元々のECSのサンプルアプリは単一AZ構成
このような状態で名前解決してみると1つしか返ってこないですね…
つまりNLBは少ないターゲットグループの方を優先するようです、
そうなると複数AZ設定している方は片方のリソースが無駄になってしまいますね。
利用側からするとそのほうが嬉しくて、両方のリージョンの名前が返ってくるようだと、単一AZのターゲットグループにリクエスト投げた際に、ターゲットが居ない方のAZにルーティングされてしまうと通信ができなくてリクエストがエラーになってしまいます。
'->$ nslookup sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Server: 192.168.11.1 Address: 192.168.11.1#53 Non-authoritative answer: Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.114.244.161
その為リソースを効率よく運用するのであれば、すべてのターゲットグループで複数AZを利用する必用があるようです。
クロスゾーンのオプションを有効にするとどうなるのか？
NLBにはクロスゾーン負荷分散というオプションが存在しています。（ALBにはない）
これを有効にしてみて名前解決してみると2つ返ってきますね。
クロスゾーン負荷分散オプションのおかげでNLB内でリージョン間通信が行えるようになったようです。
nslookup sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Server: 192.168.11.1 Address: 192.168.11.1#53 Non-authoritative answer: Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.230.61.191 Name: sample-7955badb69cae298.elb.ap-northeast-1.amazonaws.com Address: 13.114.244.161
複数から単体に変更したタイミングだとリクエストが返って来なかったものも返ってくるようになりました。 この機能のおかげで、片方のターゲットが障害になって通信できなくなったとしても、もう片方のターゲットへリクエストが行くので小規模でサービスを提供するなら有効にしておいて損のないオプションなのかと思います。
'->$ curl 13.114.244.161
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
'->$ curl 13.230.61.191
<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>
調べてみたら、これは最近追加された機能だったらしいですね。
恒例のごとくクラスメソッドさんのブログで詳細が書かれていました。
ご興味ある方は参照ください。
今回のNLBの挙動確認は以上です。
日々新しくなっていくAWSですが情報集めが大変ですね。
そんななか、もう少しでAWS Summitが開かれますが今年は東京だけでなく大阪も開かれるようでAWSの拡大が垣間見れます。
今年は私も久しぶりに参加してみて直接情報を集めようと思っています。
以上、コメント等あればお気軽にお願いします。
すずき
