みなさんはApplicationLoadBalancer(以下:ALB)とNetworkLoadBalancer(以下:NLB)、きちんと特性を理解して使い分けていますか？
AWSの知見がない頃は、とりあえずALBを選んでおけば良いくらいの認識でした。
しかしサービスによっては突発的なトラフィックの発生など、ALBでは対処しきれない自体が発生するケースもあります。
AWS認定資格の勉強をしていた方なら、「暖気申請すればいいんでしょ？」と思うかもしれませんが、実務では予期できな大量のトラフィックや、突然判明するケースが多々ありました。
「突然ですが2時間後にLINEプッシュ流すので大量のアクセスきます！」みたいな感じで・・。
ALBの暖気申請には1~2週間前から余裕を持って申請しておく必要がありますので、急に決定すると対応が間に合わないですね。(サポートに緊急でチケット切れば対応してもらえないこともないですが・・・)
ということで、今回のようなケースでは、常に大量のトラフィックを捌くことができるNLBを採用することをおすすめします。
ALBとNLBの特徴
今回のケースでNLBと使い分けをするためにも、特徴をおさらいしたいと思います。
自分の言葉でまとめると下記になります。
◆ALBはOSIモデル第7階層であるアプリケーション層で動作します。
◆リスナールールにより固定レスポンスを返したり、ドメインやアクセスに応じてターゲットを切り替えるなど複雑なルーティングが可能です。
◆普段のトラフィック量に応じて自動的にスケールします。
◆セキュリティグループが設定できます。
◆リクエスト数の他、HTTPの返すエラーやELB自身が返すエラーなど様々なメトリクスを確認できます。
◆普段のトラフィック量に応じてスケールするため、突発的なトラフィックには弱いです。
一方でNLBの特徴は、
◆OSIモデルの第4階層であるトランスポート層で動作します。
◆毎秒数百万リクエストという大規模なアクセスを処理できます。
◆TCP通信の際にはアクセスログを取得できません。
◆ALBと比較すると確認できるメトリクスの種類が少ないです。
機能面ではALBの方が様々なケースに対応できると思います。
ただし、ALBを常に暖気することはできないので、予測できない急激なトラフィックが多発する場合はこちらを採用せざるを得なくなります。
多くのケースではCloudFrontも一緒に利用すると思うので、リクエスト数やエラーレートなどはCloudFrontのメトリクスも合わせて確認する方が良いかもしれませんね。
ECSで利用する場合の穴
NLBを採用する上でハマりがちなのが、セキュリティグループの設定です。
ポート番号を固定にしてECSタスクを実行しているケースでは問題ないのですが、ポート番号をランダムに割り当てている場合にはセキュリティグループでどのポートを開けたら良いか分からなくなってしまいます。
ALBを採用している場合には、上図のようにALBにユーザーから受け付けたいポート番号を解放したセキュリティグループをアタッチして、ターゲット側ではALBにアタッチしたセキュリティグループからの通信を許可してあげるだけで済みました。
しかしランダムにポートが割り当てられる状態のECSタスクに対してNLBから疎通を行うためには、タスクごとに割り当てられているポート番号がきちんと許可されていなければなりません。
ECSでポートの自動割り当てをしている場合には、エフェメラルポートの範囲から割り当てられます。例えばLinuxであれば32768から61000の範囲になります。
※ただしECSエージェントが51678-51680のポート範囲を予約しているため注意が必要です。
このポート範囲は基本的には他のソフトウェアなどで明示的に使用することはないため、ECSタスク以外に使われることもほぼありません。
ECSでNLBを採用する場合で、ポートが固定化されていないパターンでは、EC2インスタンスのセキュリティグループでエフェメラルポートの範囲を許可してあげる必要があります。
例えば外部公開で誰でもアクセス可能なサービスであれば、[0.0.0.0/0]を許可します。
「NLBへのアクセスが80ポートや443ポートだから」と80や443ポートだけしか開けていないと疎通ができませんのでご注意ください。
この時のECS用のEC2インスタンスはプライベートなサブネットに配置して、ALBやNLB経由でアクセスするようにしておくとより安全ですね。
実際に運用して
実際にどちらのELBも使用している実績があるのですが、NLBでは不具合が生じたときにエラーを追うための情報が少なくて苦労します。
また、メンテナンス入りなどでホワイトリストのIPアドレス以外には固定レスポンスとしてJSONを返したいなどの要求はNLBでは手間が掛かります。ALBのリスナールールのようなものがあれば良いのですが・・・。
いちいち暖気申請が不要なのは大きなメリットなのですが、ALBの方が機能的に優れている場面が多いのでサービスに応じてきちんと選定しておき、場合によってはALBからNLBへの切り替えなどもできるように構えておくと良いかもしれませんね。
まとめると
・ALBの方が便利機能が多い
・固定レスポンスを返す、複雑なルーティングやターゲットの使い分けなどはALB
・ALBを採用中の場合、予期できる大量のトラフィックには暖気申請を行う
・予期できない大量のトラフィックが定期的に発生する場合にはNLBを使う
・NLBはめちゃくちゃレスポンスが早くて大量のアクセスに耐えられる
