NHN Cloudはロードバランサーを提供します。ロードバランサーを利用すると、
ロードバランサーは計3つのロードバランシング方式をサポートします。
ラウンドロビン (順次選択、Round Robin)：トラフィックを伝達するインスタンスを順次選択する、最も基本的で一般的なロードバランシング方式です。全てのメンバーインスタンスが同じリクエストに対して同じレスポンスをする場合に使用できます。
リースト コネクション(最小接続優先選択、Least Connections)：現在TCP接続数が最も少ないインスタンスを選択する方式です。つまり、 TCP接続数を基準にしてインスタンスの負荷状態を把握し、メンバー中で最も負荷が小さいインスタンスに送り、できるだけ均等にリクエストが処理できるようにします。リクエストに伴う処理の負荷の変動が激しい時に適用すると、特定インスタンスに負荷が集中する状況を防止できます。
ソースIPハッシング (送信元IP基準選択、Source IP Hash)：リクエストした人の送信元IPをハッシュして処理するインスタンスを選択する方式です。この方式を使用する場合、同じIPから入ってくるリクエストは常に同じインスタンスに伝達されます。あるユーザーのリクエストを毎回同じインスタンスで処理したい時に使用すると役立ちます。
ロードバランサーは現在、下記のプロトコルをサポートします。
上記プロトコル中、 TERMINATED_HTTPSプロトコルはHTTPSトラフィックを受信してメンバーのインスタンスにはHTTPトラフィックで伝達する方式です。 TERMINATED_HTTPSプロトコルを使用する場合、エンドユーザーとロードバランサーの間ではHTTPSで通信するので、高いセキュリティー性を確保し、サーバーにはHTTPトラフィックを渡すことにより、復号化にかかるCPUの負荷を減らすことができます。
[参考] TERMINATED_HTTPSプロトコルを使用するためには、認証書とプライベートキーをロードバランサーに登録する必要があります。この時登録するプライベートキーは、パスワードが削除されていると正しく動作します。
SSL/TLSのバージョンの中から1つを選択してロードバランサーを作成します。作成されたロードバランサーは、下記のように選択したバージョンと選択したバージョン>の上位バージョンのみ使用してクライアントと通信します。
| SSL/TLSバージョン設定 | ロードバランサーが使用するTLSのバージョン |
|---|---|
| SSLv3 | SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
| TLSv1.0 | TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
| TLSv1.0_2016 | TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
| TLSv1.1 | TLSv1.1, TLSv1.2, TLSv1.3 |
| TLSv1.2 | TLSv1.2, TLSv1.3 |
| TLSv1.3 | TLSv1.3 |
| SSL/TLSバージョン設定 | 使用される暗号化スイート | 備考 |
|---|---|---|
| SSLv3 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 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 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 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 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 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 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 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 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 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除外 |
| TLSv1.3 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 |
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除外 |
ロードバランサーはVPCのサブネット内でIPを自動的に割り当てるか、IPを指定して作成できます。
ロードバランサーは、インスタンスをメンバーとして登録し、流入したトラフィックを分配します。メンバーは二つの方法で登録ができます。
ロードバランサーに流入して処理されるトラフィックはリスナーで定義します。リスナーごとにトラフィックを受信するポートとプロトコルを定義して、一つのロードバランサーで多様なトラフィックを処理するように構成できます。一般的にWebサーバーにはHTTPトラフィックを受信する80ポートリスナーとHTTPSトラフィックを受信する443ポートリスナーを設定して使います。一つのロードバランサーに複数のリスナーを登録できます。
[注意]ロードバランサーでは、同じ受信ポートを持つリスナーを重複して作成できません。
ロードバランサーはL7データに基づいてロードバランシングを行うことができます。L7ルーティングテンプレートを選択してロードバランサーを作成する場合、L7ポリシーを含むロードバランサーを作成できます。 使用可能なアクションは次のとおりです。
ロードバランサーはプロキシモードで動作します。クライアントはリクエストを送るためにロードバランサーと接続を行い、ロードバランサーはインスタンスサーバーと接続を行います。メンバーインスタンスサーバーからは、セッションの送信元(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ロードバランサー統計機能の特徴は次のとおりです。
提供されるチャートは次のとおりです。
| 統計指標名 (チャート名) |
区分 | 単位 | 説明 |
|---|---|---|---|
| クライアントセッション個数 | クライアント側 | 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、Port設定 IPのみ設定 ロードバランサーに設定されたPort以外のトラフィックは基本的に遮断 制御トラフィック 流入 / 流出トラフィック
選択可能流入トラフィックのみ制御対象 アクセス制御タイプ 許可ポリシーのみ設定 許可または遮断ポリシーを選択可能
セキュリティグループ設定とロードバランサーIPアクセス制御設定は、互いに影響を与えません。したがって、インスタンスに流入・流出するトラフィックを制御するにはセキュリティグループを使用し、ロードバランサーに流入するトラフィックを制御するにはIPアクセス制御機能を使用する必要があります。
IPアクセス制御機能を利用するために設定すべき事項は、次のとおりです。
[注意] '許可'タイプのアクセス制御グループをロードバランサーに適用するには、ロードバランサーのメンバーインスタンスIPをアクセス制御対象に追加する必要があります。
[参考] NHN Cloud Security Monitoringサービスを通して、脅威になる遠隔地IPを知ることができます。
IPアクセス制御タイプを'遮断'に設定したIPアクセス制御グループを作成し、上記サービスを通して発見した脅威IPをIPアクセス制御対象に追加すると、システムのセキュリティを高めることができます。
[参考]
- ロードバランサーとIPアクセス制御変更時の動作
- ロードバランサーを削除すると、アクセス制御バインドが削除されます。アクセス制御グループは削除されません。
- アクセス制御グループを削除すると、グループとバインドされたすべてのロードバランサーに削除履歴が反映されます。
- アクセス制御グループ内のアクセス制御対象を追加または削除すると、グループとバインドされたすべてのロードバランサーに履歴が反映されます。
ロードバランサー課金ポリシーは、大きく2つに分けられます。