Network > Load Balancer > 概要

NHN Cloudはロードバランサーを提供します。ロードバランサーを利用すると、

  • インスタンス1つで処理するのが難しい負荷を複数台のインスタンスで分散し、処理量を増やすことができます。
  • 障害発生中や、メンテナンス中のインスタンスを自動的にサービスから除外し可用性を高めることができます。

ロードバランシング方式

ロードバランサーは計3つのロードバランシング方式をサポートします。

  • ラウンドロビン (順次選択、Round Robin):トラフィックを伝達するインスタンスを順次選択する、最も基本的で一般的なロードバランシング方式です。全てのメンバーインスタンスが同じリクエストに対して同じレスポンスをする場合に使用できます。

  • リースト コネクション(最小接続優先選択、Least Connections):現在TCP接続数が最も少ないインスタンスを選択する方式です。つまり、 TCP接続数を基準にしてインスタンスの負荷状態を把握し、メンバー中で最も負荷が小さいインスタンスに送り、できるだけ均等にリクエストが処理できるようにします。リクエストに伴う処理の負荷の変動が激しい時に適用すると、特定インスタンスに負荷が集中する状況を防止できます。

  • ソースIPハッシング (送信元IP基準選択、Source IP Hash):リクエストした人の送信元IPをハッシュして処理するインスタンスを選択する方式です。この方式を使用する場合、同じIPから入ってくるリクエストは常に同じインスタンスに伝達されます。あるユーザーのリクエストを毎回同じインスタンスで処理したい時に使用すると役立ちます。

サポートするプロトコル

ロードバランサーは現在、下記のプロトコルをサポートします。

  • TCP
  • HTTP
  • HTTPS
  • TERMINATED_HTTPS

上記プロトコル中、 TERMINATED_HTTPSプロトコルはHTTPSトラフィックを受信してメンバーのインスタンスにはHTTPトラフィックで伝達する方式です。 TERMINATED_HTTPSプロトコルを使用する場合、エンドユーザーとロードバランサーの間ではHTTPSで通信するので、高いセキュリティー性を確保し、サーバーにはHTTPトラフィックを渡すことにより、復号化にかかるCPUの負荷を減らすことができます。

[参考] TERMINATED_HTTPSプロトコルを使用するためには、認証書とプライベートキーをロードバランサーに登録する必要があります。この時登録するプライベートキーは、パスワードが削除されていると正しく動作します。

ロードバランサーSSL/TLSバージョン

  • TERMINATED_HTTPSプロトコルを使用するロードバランサーを作成する時、クライアントとロードバランサー間の通信に使用するSSL/TLS(Secure Socket Layer/Transport Layer Security)の バージョンを選択できます。
  • SSL/TLSプロトコルのバージョンが低い場合、セキュリティの欠陥がある場合があり、暗号化スイート(Cipher Suite)を構成する暗号アルゴリズムのセキュリティ性も 低いため、クライアントがサポートするSSL/TLSバージョンのうち最も高いバージョンのTLSを選択することを推奨します。
  • NHN Cloudロードバランサーは、TLSv1.3をサポートするために準備しています。

SSL/TLSのバージョン

SSL/TLSのバージョンの中から1つを選択してロードバランサーを作成します。作成されたロードバランサーは、下記のように選択したバージョンと選択したバージョン>の上位バージョンのみ使用してクライアントと通信します。

SSL/TLSバージョン設定 ロードバランサーが使用するTLSのバージョン
SSLv3 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2
TLSv1.0 TLSv1.0, TLSv1.1, TLSv1.2
TLSv1.0_2016 TLSv1.0, TLSv1.1, TLSv1.2
TLSv1.1 TLSv1.1, TLSv1.2
TLSv1.2 TLSv1.2

SSL/TLSバージョン別暗号化スイート

  • クライアントとロードバランサー間のキー交換、証明書検証、メッセージ暗号化、メッセージ整合性のチェックなど、HTTPS通信のために使用される暗号アルゴリ ズムの集合を暗号化スイートと呼びます。
  • 各SSL/TLSバージョンで使用される暗号化スイートは下記の通りです。
  • 高いバージョンのTLSバージョンを選択すると、セキュリティ性が低いアルゴリズムを使用する暗号化スイートが使用されません。
SSL/TLSバージョン設定 使用される暗号化スイート 備考
SSLv3 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA
RC4-MD5
TLSv1.0 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA
RC4-MD5除外
TLSv1.0_2016 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA除外
TLSv1.1 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
同上
TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
AES256-SHA
AES128-SHA除外

ロードバランサー作成

ロードバランサーはVPCサブネットに作成されます。ロードバランサーは作成時に指定されたサブネットからIPを割り当てられ、自分のIPで使用します。また指定されたサブネットと同じVPCに属するインスタンスをメンバーに登録し、流入したトラフィックを分配します。該当VPCとPeering接続した他のVPCに属すインスタンスもメンバーに追加できます。それ以外のインスタンスは追加できません。

ロードバランサーに流入して処理されるトラフィックはリスナーで定義します。リスナーごとにトラフィックを受信するポートとプロトコルを定義し、1つのロードバランサーでさまざまなトラフィックを処理するように構成できます。一般的にWEBサーバーにはHTTPトラフィックを受信する80ポートリスナーと、HTTPSトラフィックを受信する443ポートリスナーを設定して使用します。 1つのロードバランサーに複数のリスナーを登録できます。

[注意]ロードバランサーでは、同じ受信ポートを持つリスナーを重複して作成できません。

ロードバランサーはプロキシモード

ロードバランサーはプロキシモードで動作します。クライアントはリクエストを送るためにロードバランサーと接続を行い、ロードバランサーはインスタンスサーバーと接続を行います。メンバーインスタンスサーバーからは、セッションの送信元(Source) IPがロードバランサーのIPに見えます。サーバーでクライアントのIPを確認するには、ロードバランサーが追加したX-Forwarded-Forヘッダの情報を参照するか(HTTP/TERMINATED_HTTPSプロトコル) Proxy Protocolを使用する必要があります(TCP/HTTPSプロトコル)。

[参考]プロキシモード
L4ロードバランサーの動作方式の1つで、サーバーのレスポンスがロードバランサーを経由してクライアントに伝わることです。つまり、ロードバランサーがクライアントとのTCP接続を確立し、再びサーバーとTCP接続を確立するようになります。

ロードバランサーがプロキシモードで動作する場合、クライアントがリクエストするポートとサーバー側でサービスするポートを別でサービスすることができます。また、同じサブネットでなくてもロードバランサーに追加できます。

その代り、クライアントとロードバランサー間、ロードバランサーとサーバー間で2回接続を確立するため、リソースの浪費が発生します。つまり、1つの接続のためにロードバランサーが使用できるポートを2個ずつ消費することになります。またクライアントIPをサーバー側で認識するのが困難です。これを克服するためにはX-Forwarded-ForのようなHTTPヘッダを活用するか、ロードバランサーで提供するプロキシプロトコルを使用する必要があります。


[参考] X-Forwarded-Forヘッダ
HTTP非標準ヘッダで、サーバーがクライアントのIPを確認するために使用します。 ロードバランサーを通して入ってくるHTTPリクエストはX-Forwarded-For キーを含みます。その値はクライアントのIPです。

X-Forwarded-ForヘッダはロードバランサーのプロトコルをHTTP/TERMINATED_HTTPS に設定した時のみ活性化されます。


[参考]プロキシプロトコル(Proxy Protocol)
ロードバランサーでTCP使用時、クライアント側のIP情報を転送するためのプロトコルです。人が理解しやすいようにUS-ASCIIフォーマットのテキスト1行で表現されています。 TCP接続が確立されると最初に1回転送され、受信側で全て受信するまで他のデータ転送は遅延します。

プロキシプロトコルは大きく6個の項目に分けられます。各々の項目は空白文字で区切られます。 最後の文字は必ずCarrige Return (\r) + Line Feed (\n)で終わる必要があります。 PROXY INET_%TCOL CLIENT_IP PROXY_IP CLIENT_PORT PROXY_PORT\r\n

略語 ASCII HEX 説明
PROXY "PROXY" 0x50 0x52 0x4F 0x58 0x59 プロキシプロトコルであることを伝えるための表示子
INET_%TOCL "TCP4"または"TCP6" 0x54 0x43 0x50 0x34または0x54 0x43 0x50 0x36 使用中のINETプロトコル形式
CLIENT_IP 例) "192.168.100.101"
または"fe80::a159:b1f3:c346:5975"
0xC0 0xA8 0x64 0x65 送信元アドレスIP
PROXY_IP 例) "192.168.100.102"
または"fe80::a159:b1f3:c346:5976"
0xC0 0xA8 0x64 0x66 宛先アドレスIP
CLIENT_PORT 例) "43179" 0xA8 0xAB 送信元ポート
PROXY_PORT 例) "80" 0x80 宛先ポート

プロキシプロトコルの例は次のとおりです。

  • "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n": TCP/IPv4
  • "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n": TCP/IPv6
  • "PROXY UNKNOWN\r\n":不明な接続

接続制限

ロードバランサーはQoSを保障するために、リスナーごとに同時に維持可能な接続数を制限しています。もし指定された接続制限値を超えるリクエストが入ると、ロードバランサー内部のキューに累積されて先に入ったリクエストが完了した後に処理されます。またキューがいっぱいになるかサーバー/クライアント側がタイムアウトになると、リクエストが強制中断されることがあります。この場合、クライアント側は予期せぬレスポンス遅延が発生する場合があります。

[参考]一般ロードバランサーに接続できるセッション数は最大60,000、専用ロードバランサーは480,000、物理Basicロードバランサーは1,000,000、物理Premiumロードバランサーは3,000,000です。

セッション持続性

ユーザー情報を維持する必要がある場合や、あるクライアントのリクエストが特定サーバーにのみ伝達される必要があるサービスのために、ロードバランサーのセッション持続性機能を利用できます。この機能は、クライアントのリクエストを処理したサーバーが持続的にそのクライアントのリクエストを処理するようにする設定です。ロードバランシング方式をSOURCE IPに選択した場合、クライアントのIPをベースにサーバーを決定するため、セッション持続性が提供されます。ロードバランシング方式をROUND ROBINやLEAST CONNECTIONを使用する場合、次のようなセッション持続性機能を使用できます。

ロードバランサーでサポートするセッション維持方式は次のとおりです。

  • No Session Persistence (セッション維持しない):セッション維持をしない方式です。

  • Source IP (送信元IPによるセッション管理):リクエストした人の送信元IPを基準にセッションを維持する方式です。これのために最初のリクエスト時、ロードバランシング方式により選択されたインスタンスと送信元IPの間のマッピングテーブルを内部的に保管します。以後、同じ送信元IPを持つリクエストが入ってくると、マッピングテーブルを確認して最初のリクエストにレスポンスしたインスタンスに伝達されます。ロードバランサーは最大10000個の送信元IPのマッピングを保存できます。 TCPプロトコルリスナーでセッションを維持するように設定したい場合は、この方式を使用する必要があります。

  • APP Cookie (アプリケーションサーバーによるセッション管理):サーバー側が割り当てる明示的なCookie設定を通してセッションを維持する方式です。最初のリクエスト時、サーバーは自分に設定されたCookie値を設定するようにHTTPのSet-Cookie ヘッダを通して伝達する必要があります。この時ロードバランサーは、サーバーレスポンスの中で指定されたCookieがあるかチェックして、 Cookieがあれば内部的にCookieとサーバーID間のマッピングを維持します。以後、クライアントがCookie ヘッダに特定サーバーを指すCookieを入れて送ると、ロードバランサーがCookieに対応するサーバーにリクエストを送信します。ロードバランサーではCookieとサーバーIDの間のマッピングが3時間使用されないと自動的に削除されます。

  • HTTP Cookie (ロードバランサーによるセッション管理): APP Cookie方式と似ていますが、ロードバランサーで自動的に設定してくれるCookieを通してセッションを維持する方式です。ロードバランサーはサーバーのレスポンスにSRVというCookieを追加して転送します。この時、 SRV Cookieの値はサーバーごとに固有のIDです。クライアントがSRVをCookieに入れて送ると、最初にレスポンスしたサーバーにリクエストが伝達されます。

[参考]ロードバランサーにTCPセッション接続維持時間を設定できます。 Keepalive timeoutの値を設定してクライアントとロードバランサー、ロードバランサーとサーバー間のセッション維持時間を調整できます。

有効ではないリクエスト遮断

HTTPリクエストヘッダに有効ではない文字が含まれている場合、これを遮断する機能です。サーバーの脆弱性を狙うハッカーの攻撃や、バグがあるブラウザを通して有効ではない文字が含まれるHTTPリクエストヘッダが流入することがあります。ロードバランサーは機能が有効になっている場合、有効ではない文字が含まれるHTTPリクエストを遮断してインスタンスに伝達されることを防ぎ、 400レスポンスコード(Bad Request)をクライアントに返します。

インスタンス状態確認

NHN Cloudロードバランサーは、メンバーに登録されたインスタンスが正常に動作しているか確認するために、周期的に状態確認を行います。状態確認は、指定されたプロトコルによって決められたレスポンスが来るかを確認することによって実行されます。もし指定された回数や時間内に正常にレスポンスが来なければ非正常インスタンスと考え、負荷分散の対象から除外します。この機能を通して、予期せぬ障害やメンテナンスでも中断することなくサービスを提供できます。

ロードバランサーは状態確認プロトコルとしてTCP、 HTTP、 HTTPSをサポートします。精密な状態確認のために、各々のプロトコル使用時の状態確認方法を様々な形で設定できます。

ロードバランサー統計機能

ロードバランサーが処理したトラフィック監視の統計指標を、チャートで確認できます。 NHN Cloudロードバランサー統計機能の特徴は次のとおりです。

  • ロードバランサー別、リスナー別の統計チャートを提供します。
  • 1時間、24時間、1週間、1か月、指定期間などで期間を指定して確認できます。
  • ロードバランサーを基準にクライアント側の統計量とインスタンス側の統計量が互いに異なるチャートで提供されます。
  • インスタンス側の統計量はメンバーインスタンスごとに確認でき、収集した結果のみを確認することもできます。(インスタンスごとに参照: ON/OFF)

提供されるチャートは次のとおりです。

統計指標名
(チャート名)
区分 単位 説明
クライアントセッション個数 クライアント側 ea ロードバランサーがクライアントと接続中のセッション数
クライアントセッションCPS クライアント側 cps
(connections per second)
1秒間、クライアントと新たに接続したセッション数
セッションCPS インスタンス側 cps
(connections per second)
1秒間、インスタンスと新たに接続したセッション数
トラフィックIn インスタンス側 bps
(bits per second)
ロードバランサーがインスタンスに送ったトラフィック量
トラフィックOut インスタンス側 bps
(bits per second)
インスタンスがロードバランサーに送ったトラフィック量
ロードバランシング除外個数 インスタンス側 ea ヘルスチェック失敗によりロードバランシング対象から除外された回数

[参考]制約事項および参考事項

  • 現在使用中のロードバランサー、リスナー、メンバーについてのみ統計チャートが提供されます。ロードバランサーのリソースを削除した場合、該当リソースの過去の統計データは提供されません。
  • 単位がeaのチャートで、設定した期間に応じて数値の意味が変わることがあります。数値の意味は個別チャートの上段にある疑問符にマウスオーバーすると確認できます。
  • トラフィックIn、トラフィックOutなど、ネットワーク使用量関連の指標のチャートに表示される数値はL2、L3、L4ヘッダのサイズが除外された、ペイロード転送サイズを単位時間で割ったデータです。したがってチャートに表示される数値は課金データと関係ありません。
  • 統計データは最長1年間提供されます。

ロードバランサーIPアクセス制御機能

ロードバランサーに流入するパケットを制御するために、 IPアクセス制御機能を利用できます。 この機能はセキュリティグループとは異なる機能で、次のような違いがあります。

[参考]セキュリティグループとロードバランサーIPアクセス制御機能の比較

区分 セキュリティグループ ロードバランサーIPアクセス制御 備考
制御対象 インスタンス ロードバランサー
設定対象 IP、Port設定 IPのみ設定 ロードバランサーに設定されたPort以外のトラフィックは基本的に遮断
制御トラフィック 流入 / 流出トラフィック
選択可能
流入トラフィックのみ制御対象
アクセス制御タイプ 許可ポリシーのみ設定 許可または遮断ポリシーを選択可能

セキュリティグループ設定とロードバランサーIPアクセス制御設定は、互いに影響を与えません。したがって、インスタンスに流入・流出するトラフィックを制御するにはセキュリティグループを使用し、ロードバランサーに流入するトラフィックを制御するにはIPアクセス制御機能を使用する必要があります。

IPアクセス制御機能を利用するために設定すべき事項は、次のとおりです。

IPアクセス制御グループ

  • 1つのプロジェクトに最大10個のグループを作成できます。
  • グループは名前、メモ、アクセス制御タイプなどのプロパティを持ちます。
  • アクセス制御タイププロパティは、'許可(Allow)'と'遮断(Deny)'のいずれかの値を持つことができます。
  • アクセス制御グループに、制御したいIPアクセス制御対象を追加できます。
  • IPアクセス制御グループを削除すると、グループ内のすべてのIPアクセス制御対象が削除され、このアクセス制御グループが適用されていたすべてのロードバランサーでそのIPに対する制御を行いません。

IPアクセス制御タイプ

  • '許可(Allow)':グループに属するIPのアクセスは許可し、それ以外のすべてのIPのアクセスを遮断します。
  • '遮断(Deny)':グループに属するIPのアクセスは遮断し、それ以外のすべてのIPのアクセスを 許可します。

    [注意] '許可'タイプのアクセス制御グループをロードバランサーに適用するには、ロードバランサーのメンバーインスタンスIPをアクセス制御対象に追加する必要があります。

IPアクセス制御対象

  • 1つのプロジェクトに最大1,000個のアクセス制御対象を作成できます。
  • アクセス制御対象は、メモ、IPアドレスなどのプロパティを持ちます。
  • 1つのアクセス制御対象は、IPアドレスまたはCIDR形式のIPアドレス範囲を持つことができます。CIDR形式のIPアドレス範囲を入力する場合、該当ネットワーク内のすべての帯域がアクセス制御対象に含まれます。

[参考] NHN Cloud Security Monitoringサービスを通して、脅威になる遠隔地IPを知ることができます。

IPアクセス制御タイプを'遮断'に設定したIPアクセス制御グループを作成し、上記サービスを通して発見した脅威IPをIPアクセス制御対象に追加すると、システムのセキュリティを高めることができます。

IPアクセス制御グループの適用

  • 1つのアクセス制御グループは、複数のロードバランサーに適用できます。
  • 1つのロードバランサーに複数のアクセス制御グループを適用できます。ただし、バインドされるグループのアクセス制御タイプが同じである必要があります。
  • IPアクセス制御グループを適用していないロードバランサーは、すべてのIPのアクセスを許可します。

[参考] * ロードバランサーとIPアクセス制御変更時の動作 * ロードバランサーを削除すると、アクセス制御バインドが削除されます。アクセス制御グループは削除されません。 * アクセス制御グループを削除すると、グループとバインドされたすべてのロードバランサーに削除履歴が反映されます。 * アクセス制御グループ内のアクセス制御対象を追加または削除すると、グループとバインドされたすべてのロードバランサーに履歴が反映されます。

課金

ロードバランサー課金ポリシーは、大きく2つに分けられます。

  • ロードバランサー使用料金:ロードバランサーを使用した時間だけ請求されます。ロードバランサーの状態がACTIVEでなければ請求されません。
  • ロードバランサートラフィック料金:ロードバランサーから出るトラフィック量だけ、プロジェクト全体のトラフィックに加えて一緒に請求されます。
TOP