ここ二週間くらい引きずっている話ですが、改めてL7/L4ロードバランサーおよびALB（アプリケーションロードバランサー）NLB（ネットワークロードバランサー）の違いに関して整理したいと思います。

なお、L7ロードバランサー／L4ロードバランサーと書くのは面倒なので、L7LB/L4LBと略記することにします。

L7LB/L4LBについて

L7LB/L4LBの違いについては、最終的には以下の内容に集約されるっぽいです。

L7LBの性能を「遅い」と表現していますが、これはあくまでL4LBに対しての相対評価の意味です。

結局のところL7LBの方が細かな制御をしようとするが、それだけ必要な処理も増え、時間も要するようになるため、性能的にはL4LBの方が優位というだけの話のようです。

蛇足ながら、今まで個人的に間違っていた認識に関しても触れておきたいと思います。

（誤）L7LBにはSSL(TLS)オフロード機能があり、L4LBにはない

SSL（TLS）オフロードとは、サーバ本体に代わりSSL（TLS）の暗号化／復号の処理を行う機能です。
つまり、負荷分散先の各WebサーバにSSL証明書を配置しなくても、SSL（TLS）オフロード機能を持つ装置にSSL証明書を配置しておくだけでHTTPS接続に対応できます。証明書の更新に際してWebサーバ台数分の作業をする必要がなくなる点は魅力です。

そもそもTLSはOSI階層モデルの何層なのか？という観点で考えた時、TCPがトランスポート層（L4）相当なので、その上に載るSSL（TLS）の処理はL4LBの対象にならないという判断からこのように思っていましたが、TCP/IPの世界におけるこの辺の境界はアバウトっぽく、L4LBとしてSSL（TLS）オフロード機能を備えているケースも多いようです。

（誤）L7LBにはセッション維持機能があり、L4LBにはない

セッションはcookieとしてセッションIDをクライアント・サーバ間でやり取りすることで管理されますが、セッション上のデータの実体としてはファイルとして管理されているケースが多く、そのファイルは生成したサーバ上にしか存在しないため、同クライアントからの送信が別のサーバに割り振られてしまうとセッション上のデータを参照できなくなってしまいます。
そうならないように同一セッションに関する通信の振り先が特定のサーバになるよう制御する機能がセッション維持機能（パーシステンス）です。

前述のようにセッションIDをcookieとしてやり取りしますが、セッション維持の方法としてはこのcookie（セッションID）から振り先を特定するというものが代表的な方法であるとのやんわりとした知識があったため、そこからcookieに直接関与しないL4LBではセッション維持ができないと思っていました。

ただ、L4層でも処理情報としてIPアドレスは判断材料として利用できるため、同じアクセス元IPからの送信は同じサーバに割り振ると言うことでL4LBでもセッション維持ができる模様です。
セッション維持が主目的の振り分けかどうかは分かりませんが、結果としてセッション維持もできるようになると言ったところでしょうか。

なお、先に「セッション上のデータはファイルで管理するケースが多い」と書きましたが、複数サーバで共通的に利用するSQL/NoSQLデータベース上に持つ方法もあり、こちらであれば負荷分散環境下の全てのサーバでセッションを共有できます。
可用性の観点からはセッション維持に依存せずにこちらを用いるのが正解のように思います。

ALB/NLBについて

前述したようにL7LB/L4LBに関して色々と誤解していたこともあり、当初はALB/NLBの機能とL7LB/L4LBの特徴が合っていないように思っていましたが、今ではALB=L7LB、NLB=L4LBという対応で、個人的には理解しています。

ただ、上記のような関係性について明確に書かれた記事（相応に信頼できそうなもの）は今のところ見た気がしません。
加えてNLB（ネットワークロードバランサー）という名称に対して、L4はネットワーク層ではなくトランスポート層なんだけど？と言うような些末な違和感もあり、前述の解釈に関して確証は得られていません。

また、L7LB/L4LBの違いと言えるかどうか分からないもので、ALB/NLBの違いとしては明確な特徴として以下があります。

• NLBには固定IP（Elastic IP）が設定できる。ALBには固定IP（Elastic IP）を設定できない。
• NLBではアクセス元IPとしてクライアントのIPがそのままサーバに渡されるが、ALBではサーバから見えるアクセス元IPはALBのIPになる。

前者に関しては以前の記事でも触れましたが、これが一般的なL7LBの特徴なのかは不明です。
なお、ALBでも「Global Accelerator」なる機能を前面に使用することで固定IPが使えるようになる模様ですが、個人的には未確認です。

後者に関しては、L4LBとしても複数（最低2つ）の方式があるようで、その方式次第ではアクセス元IPがL4LBのIPになることもあるようです。
少なくともNLBではアクセス元IPとしてクライアントのIPが維持されます。

結局はALB/NLBがそれぞれL7LB/L4LB相当のものであるかどうかではなく、ALB/NLB自体がどのような機能であるかをしっかり把握することが重要と言うことですかね？（元も子もない結論…）

総括

ロードバランサーに関しては今まで関わる機会も少なく、加えて昨今のホスティング環境ではコンパネからの簡単操作で使えたので、あまり深く考えたことがありませんでした。
過去に関わったロードバランサーは今考えれば全てL4LBだったように思われますが、当時はそのような意識もありませんでしたし。

ロードバランサーの意義としては「可用性」と「拡張性」が語られますが、どちらの観点からも特定の機能が特定の環境（サーバ等）に依存しないことが重要であり、その意味では同一の機能を提供するサーバが複数存在して、それらに対して負荷状況（死活監視含む）に応じて処理を割り振れると言う基本的な機能を有すれば十分なような気がします。言い換えれば負荷状況による割り振り以上に期待することが、個人的には今のところ思い当たりません。

そうなってくるとNLBがあれば十分で、ALBを使いたい動機がなくなってしまいます。
ただ、ネットでELBの設定関連情報を調べると、ヒットする記事の多くはALBに関して言及したものとの印象があります。言い換えれば記事の量から判断するとNLBは今ひとつ不人気との印象です。
この辺の理由が謎なのですが、ELBの歴史的にはALBよりもNLBの方が後発なので、まだ世の中に浸透していないのかもしれません。

まずは自分の判断を信じてNLBを使いながら、引き続きALBの利点に関しても探っていきたいと思います。