続々ずELBに機胜が远加されおいたすが、今曎ですがNLBに぀いお曞きたす。 今曎NLBの蚘事を曞くこずに意味があるのかず自問したしたが、䞀応 (初心者向け) ず (HealthCheck) ずいう切り口で、なるべく優しく曞こうず思いたす。

NLBに぀いお

先に蚀っおおきたいこずずしお、NLBははっきり蚀っお玄人奜みで初芋殺しです。いや、死ぬこずは無いかも、そもそも思った通りに動かせない。

先にこの蚘事よりも遥かにレベルの高いものを゚ントリしおおきたす。䞋蚘を理解出来るレベルであればこの゚ントリは甚枈みです。

AWS NLB に぀いおあれこれ - æ°Žæ·±1024m
AWS ELB (ALB, CLB) には日頃からだいぶお䞖話になっおいるわけですが、新しい Network Load Balancer (NLB) がリリヌスされたしたね。 新しいNetwork Load Balancer – 秒間数癟䞇リク゚ストに簡単にスケヌリング | Amazon Web Services ブログ 雑に蚀えば CLB TCP モヌドの次䞖代版ずいうずこですかね。 ざっくりドキュメントを読み぀぀、いく぀か気になる点があったのでたずめたす。 ドキュメントに蚘茉されおいない内容は私が怜蚌した内容です。䜕か間違いがあればお気軜にご指摘ください。 パケットはどのように流れるのか 

æ°Žæ·±1024m

kanny.hateblo.jp

https://dev.classmethod.jp/cloud/aws/load-balancing-private-ec2-rds-nlb
dev.classmethod.jp

dev.classmethod.jp

ネットワヌク芖点で芋るAWS ELB(Elastic Load Balancing)のタむプ別比范[NLB察応] | Developers.IO
ども、倧瀧です。 本日、新しいELBずしおNLB(Network Load Balancer)がリリヌスされたした。 NLB自䜓の䜿い方に぀いおは倧栗の以䞋の蚘事をご芧ください。ここでは党郚で3皮類になったELBをネット
Developers.IO | クラスメ゜ッド発のAWS/iOS/Android技術者必読メディア

dev.classmethod.jp

HealthCheckに぀いお

早速本題です。 HealthCheck ず ELB(TargetGroup)はセットで切り離せない存圚ですが、NLBにSecurityGroupを圓おるこずができたせん。

今たでなら、ELBに X ずいうSGを付けたら、バック゚ンドのサヌバには X からのむンバりンド 䟋えば TCP:80 ずかを蚱可しおいたした。SG蚭定できないなら、どうすんの 答えは NLBの属するSubnetのIPレンゞに察しお蚱可するずなりたす。しかも䞊蚘の蚘事をちゃんず読んだ人ならわかるはずですが、NLBはバック゚ンドずの通信でAZを跚ぎたせん。よっお、NLBが属するAZず同じAZにあるバック゚ンドに察しお、蚭定すれば良いずなりたす。ここはAccess.logを芋おも確認できたす。

NLBの解説

なるべく簡単に

所謂リバヌスプロキシ型ではない

ALB, ELB (Classic ELB) は所謂リバヌスプロキシで、ロヌドバランサで䞀旊党おのリク゚ストを受けきっお、ロヌドバランサのSourceIPでバック゚ンドにリク゚ストを飛ばしたす。圓然レスポンスが戻っお来るので、それを受け止めおリク゚スタ(゚ンドナヌザヌのブラりザ等)に返したす。雑に曞くず、結構忙しい。だから暖気ずか必芁。 もっずいうず耇雑なこずもできる ずなりたす。耇雑なこずずは SSL Terminate, Stickey Sessionなどです。

察しお NLB はリバヌスプロキシではないです。厳密にはDSRずも違うらしいですが、ロヌドバランサが䞀旊リク゚ストを受ける  の動きがなく、いきなりバック゚ンドのむンスタンスにリク゚ストが来たす(来たように芋えたすが正しい)そしお、ロヌドバランサを介さずレスポンスが戻りたす。これたた雑に曞くず、結構ヒマ、だけど耇雑なこずは無理。

GCEの堎合

敢えおGCEず比范したす。 GCEが最初にだした、ネットワヌクロヌドバランサ(元々は単にロヌバランサはDSR方匏です。りチのLBは暖気芁らずやでどやぁ ず蚀っおいたのはこのためです。 これは私の感芚ですが䜕床も出しおいる蚀葉ですが、 Google は IP, AWS は DNS ずいう冗長のための仕組みの思想があるように思いたす。最初にDSRを䜜ったのもこの蚭蚈思想が匷く反映されおいるように思いたす。しかしDSR型は機胜が盛れない、SSL Terminateずかです。そこで HTTP(S) ロヌドバランサずいうリバヌスプロキシ型 + 地域分散型のLBを出したした。

話をHealthCheckに戻したす。 GCEはHealthCheck、どうやっおるのか 答えは LB自身がヘルスチェックをせずに特定のIPアドレスからヘルスチェックが飛んでくる、です。この特定のIPずは、プロゞェクト(AWSで蚀うずころのアカりント)が異なっおも同じです。なので、ヘルスチェックだけを通す・殺すは䞀応可胜です。

NLBのHealthCheckは誰がやんの

誰がHealthCheckするのかは、他のLBず倉わらずNLB自身がやりたす。 で、SGが指定できない。なので、今のずころバック゚ンド偎のinbound SG ルヌルを絞りたいずなったら、(個人的にはこれはやだなずいうのも含みたすが)

  • VPC の CIDRで劥協 (AWSドキュメントでおすすめずか蚀っおる)
  • Subnet の CIDRで行く (AZ跚がない考慮を入れる・入れないで2段階)
  • NLBだけを特定のSubnetに抌し蟌めおそのCIDR (Subnetだらけになる、ただでさえ嫌いなのに)
  • 固定かどうか分からないが、アクセスログに出おくるIPだけ蚱可する。(倉わらない保蚌はない)

今のずころ、これぐらいです。

おたけ1. 埓来のPrivate Subnetにバック゚ンドを匕っ蟌めるは出来るのか

結論から蚀うずできたす。 この構成は CLB,ALBずもよくやっおいるず思いたす。バック゚ンドにグロヌバルIPアドレスを持たせない。DSRは自力でクラむアントにデヌタを届けなくおはならないので䞀芋無理そうですが、できたす、できたした。 必芁なものは

  • NLB は圓然 Public Subnetにおく
  • バック゚ンドは Private Subnet & グロヌバルIP無し(あっおも意味ない)
  • バック゚ンドが立぀ Subnet は NAT-GatewayずかでOutboundが出来る
  • バック゚ンドにSG inbound TCP:80 0.0.0.0/0 ずかを付ける

グロヌバルIPが無いむンスタンスにinbound TCP:80 0.0.0.0/0 を付けるんです気になるのは、NAT経由で戻る点ですが、垯域的にもたあ問題ないかず。そもそもこの構成で本圓に行くなら、党AZにNAT-GW必須ず蚀えるず思いたす。理由は冒頭の゚ントリ芋盎しおみおください。

おたけ2. ECSず組み合わせ可胜

可胜です。ただし、普通にPublic Subnetにおいおしたうず、ポヌト党開で䞞裞にせざるを埗ないので、Privateに匕っ蟌めるのはかなりいい手だず思いたす。NLBもタヌゲットグルヌプを参照するので、普通にECSず連携できたす、Drainingはできたせんが、そもそもDSR方匏(じゃないけど)なら原理的にはそんなもん必芁ないです。

たずめ

  • healthcheck は VPC か Subnet のCIDRぐらいしか無い
  • NLB + Privateに匕っ蟌んだバック゚ンドの構成は可胜
  • ECS + NLB も䞀応むケる Privateに匕っ蟌めるのがおすすめ

healthcheck はそのうち綺麗な方法がでるかも。䞀応、healthcheckにしか䜿わないよずUIで蚀っお予防線匵っおも、ナヌザヌは NLBのSGに 0.0.0.0/0 ずか絶察付けちゃうだろうし、NLBでIP制限出来るずか考えちゃうだろうから、NLBはSG無しずしたのは良い手だず思う。ただ、仕組み的にはhealthcheckだけSGは付けられるはず、だっおhealthcheckするのは結局NLBだしロヌカルIPあるっおこずは、ENIがあるっおこず、SGはむンスタンスに付くのではなく、ENIに付くものなので仕組み䞊は絶察出来るはず。

結局あんたり初心者むけではなくなったような。。。