IT技術 アーキテクチャー 負荷分散

HTTP サーバーのロードバランシングの方法

2020年2月24日

 

ロードバランシング

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を解かなくてよい場合、さらに追加で(今時、こんなケースは殆ど無いと思うが・・・)

3)共有DBベース
参考:

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 として構成できるるモジュールがあるようだ。

Web三層の負荷分散

created by Rinker
¥216 (2024/03/28 07:40:47時点 Amazon調べ-詳細)

-IT技術, アーキテクチャー, 負荷分散

Copyright© エンジニアの何でもメモ帳 , 2024 All Rights Reserved.