DNSラウンドロビン、L4スイッチ、L7スイッチってなんだ?

DNSラウンドロビン、L4スイッチ、L7スイッチってなんだ?

普段なぁなぁで使ってる負荷分散のシステムを勉強してみました。
負荷分散とはその名の通り、リクエストを分散する仕組みです。冗長化の手段でもあります。
※記事中のドメインやIPはありえないものを使用しています。333とかありえないとわかっているのでご指摘無用です。

DNSラウンドロビン

DNSラウンドロビンとは、１つのFQDNに対して、複数のIPを登録しておき、問い合わせごとに順番にIPを返していくといった負荷分散技術になります。
DNSへの名前解決の問い合わせごとに登録されたIPを順番で返却します。
図で表すと下記のようなイメージです。

この図でいうとユーザAが「www.hogehoge.aaajp」のIPを聞くと「333.1.1.1」が返ってくるので「333.1.1.1」サーバーへリクエストします。
次にユーザBが「www.hogehoge.aaajp」のIPを聞くと「333.1.1.2」が返ってくるので「333.1.1.2」サーバーへリクエストします。
同じようにユーザCは「333.1.1.3」が返ってきます。

メリット

1. DNSサーバのゾーンファイルで設定することができるのでとても気軽に設定できます。
2. 負荷分散装置をネットワークのルート上におく必要がないため、ネットワーク設計が容易にできます。
3. クライアントが使用しているDNSでキャッシュしてくれるため、全てのユーザの名前解決の問い合わせがオリジンに来るわけでないので、キャッシュ期間を短くしたとしてもDNSの負荷が極端に跳ね上がることはあまりない。

デメリット

1. DNSの仕組み上、全ての名前解決の問い合わせがオリジンに来るわけではないので、正確に分散することが出来ず、負荷が偏る可能性があります。
2. サーバの負荷情報を確認せずに単純にラウンドロビンで振っていくので負荷が偏る可能性があります。
3. 特定のクライアントを継続して特定のサーバに振ると行ったセッション管理が出来ない。クライアントの名前解決のキャッシュに依存してしまいます。
4. ヘルスチェックをしてラウンドロビンをしてくれるわけではないので、障害が発生しているサーバのIPでも返してしまいます。（※これについては後で記載）
5. DNSの仕組みに依存するため、TTLを短くしていたとしても、ゾーンファイルを書き換えたとしてもその設定が瞬時に世の中に行き渡るわけではない。つまり特定のIPに障害が発生し、すぐに修正したとしても、不通になるクライアントはある程度の時間存在してしまう。※chromeとか結構賢くて、不通になったら別のIPを試すみたいなのもやってくれるとも言います。
6. 経路にいるわけではないのでSSL終端が出来ない。

デメリット4の解決方法

ヘルスチェックをして動的にゾーンファイルを書き換える方法もあります。実際にこういったサービスも存在しています。
例えば、AWSのRoute53などはヘルスチェックも組み込むことが出来ます。AとBのIPを登録しておき、Bが死んだ場合はAのみを返してくれるようになります。超便利！！！
（これ、AWS以外のも使えるし最強じゃない？）

L4スイッチ

OSI参照モデルにおけるレイヤ4（トランスポート層）に分類される情報を参照し、行き先を振り分けるスイッチの事をいいます。
宛先となるIPとTCP/UDPのポート番号を見て適切なサーバにパケットを転送します。

NAT構成、DSR構成

L4スイッチにはNAT構成とDSR構成が存在します。

NAT構成

こちらが一般的な構成だと思います。

リクエストをL4スイッチが受け付け、バランシングを行い、サーバーにリクエストを転送します。そしてサーバはレスポンスをロードバランサーに返します。つまり戻りパケットはL4スイッチを経由して処理されます。

メリットとしては、ループバックIPアドレスを設定する必要がなくシンプルな構成になります。

デメリットとしてはサーバーからのレスポンスもL4スイッチを経由するためL4スイッチ自体がボトルネックになる可能性があります。

DSR構成

こちらはあまり使われない構成かもしれません。
リクエストをL4スイッチが受け付け、バランシングを行い、サーバーにリクエストを転送します。そしてサーバはクライアントにダイレクトに返します。つまり戻りパケットはL4スイッチを経由せずに処理されます。

こちらの長所はレスポンスがロードバランサーを経由しないため、ロードバランサーのキャパシティが増えることになります。

レスポンスの接続元IPをロードバランサに見せかける必要があるため、ループバックIPアドレスを設定する必要があります。

特徴

1. 通信要件の異なるものを同一経路に統合することが出来ます。例えばメールサーバとウェブサーバを同じIPで運用することが出来ます。
2. 様々な負荷分散アルゴリズムを選択することが可能です。例えばラウンドロビン・重み付けラウンドロビン・接続数、等々存在します。
3. 同一IPからのリクエストは同じサーバーに転送するなどTCP/IPレベルでのセッション維持機能を利用することができます。
4. ヘルスチェックが可能でヘルスチェックで不通が発見された場合は負荷分散先から切り離す事が可能です。
5. L7と比較すると機能的にはどうしても落ちてしまう

L7スイッチ

L7スイッチは、その名の通りレイヤー7、OSI参照モデルのアプリケーション層の中身まで解析して分散先を決定することができます。L7スイッチがクライアントとバックエンドサーバの間に入って仲介することになります。L4スイッチで不得意だったところを解決します。
コネクションは図のように

• クライントとL7スイッチ間
• L7スイッチとバックエンドサーバ間
  に貼られることになります。
  

AWSではALB、GCPではCloud Load Balancingがこれに当たると思います。

特徴

1. アプリケーション層の中身まで見ることができるのでTLS終端として働くことが出来ます。L7で復号化し、L7からバックエンドはHTTPで通信することも可能です。
2. ドメインやパラメータなどURLばかりかhttpヘッダなどを参照して分散をコントロールすることができます。動的パスはAサーバ、静的パスはBサーバといった形での負荷分散も可能になります。
3. L7スイッチとバックエンドサーバ間でkeepaliveを有効にすることが可能です。
4. アプリケーション層を編集することができるのでcookieなどを用いたスティッキーセッションも可能です。
5. L4よりオーバヘッドは大きくなる？
6. オンプレだとL4より高価？