ロードバランシング
IPレベルのロードバランシング
DNSのレベルで振り分けるので、DataCenter 間のロードバランシングにも使われる。
- アプリケーションのドメイン名を解決する時に、権威DNSサーバーがラウンドロビンや一定の割合で違う IP を返す。
例) www.example.com 用に 権威 DNS サーバーが 3つの IP を持っており、クライアントがDNSサーバーに名前解決をする度に違うIPを返す。 - 災害対策用に、本番系のデータセンターとバックアップ用のデータセンターの間の切り替えにも良く使用される
→ 権威 DNS サーバーは、本番、バックアップのデータセンターとは別の仕組みで可用性を維持する - 通常の DNS では、振り分けた先の IP が生きているかどうかまで確認しないため、指定したIPアドレスに対してヘルスチェックができるサービスを選ぶ必用がある。AWS の Route 53や、Akamai の GTM (Global Traffic Management) では、ヘルスチェックや分散先の IPに対する重み付けをサポートしている。
HTTPレベルのロードバランシング
ロードバランサー(物理 / 仮想 ) が、サーバーの代わりにリクエストを受け付け、背後に控えている複数の HTTP サーバーなどにリクエストを割り振る
- ロードバランサーが、対象 Webサービスのドメインを保持し、HTTPリクエスト毎にラウンドロビンで背後にあるサーバーにリクエストを割り振る
例) ロードバランサーが www.example.com というドメイン名を持ち、その背後に 3つある HTTP サーバーにランダムに HTTP リクエストを割り振る
セッションの維持
セッションの管理方法はおおよそ3つに分かれる
1) クライアントIPベース
- 接続元のクライアントのIPを見てセッションを維持する方法。同じクライアントIPからのリクエストは常に同じ Webサーバーに割り振る。
- インターネット上の Webシステムだと会社からなどのアクセスの場合、Proxy の IP になってしまう。そのためWebではこの方法は使用しにくい。
- 社内で個別IPが降られているなら有りかもしれない(が、HTTP通信が一般的である現在では、非HTTP 通信でしか使用しないと思われる)
2) HTTPベース
HTTPSの場合は、セッションを維持するトークンは、通信内部にクッキーや引数の形で含まれているため、HTTPS を解いて中身を見る必用がある。
SSLアクセラレーターのような、HTTPS暗号を解ける機能を持った ロードバランサー が必要になる 。今では一般的で、オンプレでもあるしクラウドタイプもある。
- HTTP Cookie - サーバーが使用する Cookie 名を 負荷分散装置に指定し、Cookie の内容で接続先を割り振る or ロードバランサーが Cookie をつける (例) AWS の ALB)
- URL内の引数 - URL内の引数を見る。Java なら jsessonid= のようなもの。jsessionid を見るように負荷分散装置に指定する。
- HTTP Authorization Header : Basic 認証などに使われるヘッダー(これも結果的にユーザーが一意になる)を負荷分散装置に指定し、それを使って接続先を割り振る→ この仕様は例外的だと思う。
※HTTPの場合どの HTTP Header でもいいかな。と思ったが、サーバー/クライアント間で、ユニークな識別子として使えるヘッダーは限られる。Webブラウザーは勝手にヘッダーをつけないし、サーバーから特定IDを相手に埋め込むには、Cookie しかない。Atuhorazation ヘッダーは例外的にブラウザー側がセットする事になる(今は Authorization ヘッダーをセッション管理に使う人はいるのだろうか?)
HTTPSを解かなくてよい場合、さらに追加で(今時、こんなケースは殆ど無いと思うが・・・)
- SSL セッション ID を使用する(暗号化を解かなくてもよい)
→ 現実的にはセッションIDは、ブラウザがコロコロ変更するので、期待通りに動かない。
3)共有DBベース
- Application 側での埋め込みが必要になる。
- 共有DBを使ったセッション維持(UserIdなどに紐づけ)→ IP / HTTP の両方に使える
- → AWS だと Elastic Cache を使うのが一般的のようだ
→この Elastic Cache は、Memcached か Redis のどちらかが選べる。(ElastiCacheはMemcachedとRedisのどっちを選ぶ?)
参考:
- nginxでセッション維持するロードバランサを構築 nginx を使ったセッション維持の Load Balancer の構築
- コミュニティ版NGINXまたはNGINX PLUSを使ったAPACHE TOMCATサーバーのロードバランシング Nginx Plus (コミニティ版 Nginx を拡張した Enterprise 版 Nginx ) を使ったセッション維持
- Apacheロードバランサで負荷分散。冗長化構成を開発環境でも。~負荷分散と冗長化の基礎を添えて~ Apache を使ったセッション管理 ( sticky セッション)
AWSのロードバランサー
AWSの LB は、3種類ある (Classic, NLB, ALB)
微妙にサポートしている機能が違う。
元々は Classic (旧 ELB ) しか無かったが、その後、ALB、NLB ができて区別されるようになった。Classic でしかできない事もあるが、VPC の場合は、ALB/NLB を使うように書いてある。
ALB (Appklication Load Balancer) L7で動作する
- L7 レイヤー (HTTP レイヤー)で動作する
- HTTP/HTTPSのみ. HTTP2 対応
- リバースプロキシー型
- Cookie を使ったセッション維持(スティッキーセッション)
- インスタンスを直接指定するのでは無く、サーバーグループに対してルーティングを設定する事ができる
- WAF が使用できる
- 可変 IP (ドメイン名がアサインされる)
- Application Load Balancer とは
NLB (Network Load Balanacer)
- L4 で (IPレイヤー) で動作する。NAT
- TCP / UDP / TLS
- 帰りの通信は NLB を通らない (リバース・プロキシーでは無い)
- TLS を使用する場合は、証明書をデプロイする
- パフォーマンスに優れている
- 固定 IP
- Network Load Balancer とは
Classic Load Balancer (初期の ELB )
- L4 と L7で動作する。
- リバースプロキシー型
- TCP, SSL/TLS, HTTP, HTTPS
- ClassicのEC2 をサポートしている。
- 可変 IP (ドメイン名がアサインされる)
- Classic Load Balancer とは
CLB (Classic Load Balancer) が、L4 / L7 の両方の Proxy として動くという事がピンと来なかったのだが、Nginx もTCP/UDP Proxy として構成できるるモジュールがあるようだ。