Network > Load Balancer > 概要

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

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

ロードバランシング方式

ロードバランサーは、計3種類のロードバランシング方式をサポートしています。

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

• Least Connections (最小接続優先選択)：現在のTCP接続数が最も少ないインスタンスを選択する方式です。つまり、TCP接続数を基準にしてインスタンスの負荷状況を把握し、メンバーの中で最も負荷が少ないインスタンスに送信することで、可能な限り均等にリクエストが処理されるようにします。リクエストに伴う処理負荷の変動が激しい場合に適用すれば、特定のインスタンスに負荷が集中する状況を防ぐことができます。

• Source IP (送信元IP基準選択)：リクエスト元の送信元IPをハッシュ化し、処理するインスタンスを選択する方式です。この方式を使用する場合、同一のIPから入るリクエストは常に同じインスタンスに転送されます。あるユーザーのリクエストを毎回同じインスタンスで処理したい場合に使用すると便利です。

サポートプロトコル

ロードバランサーは以下のプロトコルをサポートしています。

• TCP
• HTTP
• HTTPS
• TERMINATED_HTTPS

上記のプロトコルのうち、TERMINATED_HTTPSプロトコルは、HTTPSトラフィックを受信し、メンバーインスタンスにはHTTPトラフィックとして転送する方式です。TERMINATED_HTTPSプロトコルを使用する場合、エンドユーザーとロードバランサー間ではHTTPSで通信して高いセキュリティを確保し、サーバーにはHTTPトラフィックを渡すことで、復号に必要なCPU負荷を軽減できます。

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

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

SSL/TLSバージョン

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

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

• クライアントとロードバランサー間の鍵交換、証明書の検証、メッセージの暗号化、メッセージの整合性チェックなど、HTTPS通信のために使用される暗号アルゴリズムのセットを暗号化スイートと呼びます。
• SSL/TLSバージョンによって使用される暗号化スイートは以下のとおりです。
• 高いTLSバージョンを選択すると、セキュリティの低いアルゴリズムを使用する暗号化スイートは使用されません。

カスタムSSLポリシー

標準で提供されるSSL/TLSバージョン別の暗号化スイートの組み合わせに加えて、必要な暗号化スイートのみを直接選んで適用したい場合は、カスタムSSLポリシーを作成してリスナーに接続できます。

SSLポリシーは次の要素で構成されます。

• 最小TLSバージョン(min_tls_version)：該当するポリシーが許可する最も低いTLSバージョンです。このバージョン以上の接続のみを許可します。作成後には変更できません。
• 暗号化スイート(ciphers)：使用する暗号化スイートの一覧です。TLS 1.2以下の暗号化スイートとTLS 1.3暗号化スイートを区別せずにコロン(:)で繋げた1つの文字列で指定します。サーバーが名前のプレフィックス(TLS_で始まればTLS 1.3)で自動分類して適用します。少なくとも1つ以上指定する必要があります。

ロードバランサーの作成

ロードバランサーはVPCのサブネット内でIPを自動的に割り当てられて作成するか、IPを指定して作成できます。

• 自動で割り当てる場合：サブネットの利用可能なIPのいずれかをロードバランサーのIPとして使用します。
• IPを指定する場合：指定されたIPをロードバランサーのIPとして使用します。IPはサブネットのCIDRの範囲内である必要があります。

ロードバランサーはインスタンスをメンバーとして登録し、流入したトラフィックを分散します。メンバーは2つの方法で登録できます。

• インスタンス：該当するVPC、及びVPCにピアリングされたVPCに属するインスタンスをメンバーとして追加できます。
• IPアドレス：IPを直接入力してメンバーを登録できます。この場合、ロードバランサーとインスタンスの通信経路が適切に設定されている必要があります。

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

ロードバランサーエンジンバージョン

ロードバランサーは、トラフィックを処理する内部エンジンのバージョンとして v1 と v2 の2種類を提供します。エンジンバージョンによって、HTTP トラフィックの処理など一部の動作が異なる場合があります。

• 新規ロードバランサー: 常に最新バージョン（v2）で作成されます。
• 既存のロードバランサー: この機能が導入される前に作成されたロードバランサーは、旧バージョン（v1）を維持します。
• エンジンバージョンの変更: ロードバランサーのエンジンバージョンを変更できます。

エンジンバージョン別サポート機能

ロードバランサー HTTP プロトコルバージョン

次のプロトコルを使用する場合、プロトコルバージョンとして HTTP/1 または HTTP/2 を選択できます。

• リスナー TERMINATED_HTTPS
• メンバーグループ HTTP、HTTP_REENCRYPT

HTTP/2 を選択した場合、メンバーグループで HTTP を選択すると H2C（平文）で、HTTP_REENCRYPT を選択すると H2（TLS 暗号化）で通信します。 選択したプロトコルバージョンに従って厳密に動作し、HTTP/2 を選択した場合は HTTP/1 で通信することはできません。 ヘルスチェックプロトコルを HTTP または HTTPS で選択すると、メンバーグループで選択したプロトコルバージョンと同じように動作します。

L7ルール

ロードバランサーはL7データに基づいてロードバランシングを実行できます。L7ルーティングテンプレートを選択してロードバランサーを作成する場合、L7ポリシーが含まれたロードバランサーを作成できます。 使用可能なアクションは以下のとおりです。

• 対象グループへ転送：L7ルールに一致した場合に、設定された対象グループへ送信する方式です。L7データに基づいて特定の対象グループへパケットをルーティングできます。
• URLへ転送：L7ルールに一致した場合に、設定されたURLにリダイレクトする機能です。HTTPヘッダのLocationを使用してリダイレクトを実行します。
• ブロック：L7ルールに一致した場合にブロックする機能です。Forbidden (403)のレスポンスを返却します。

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

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

```
PROXY INET_PROTCOL CLIENT_IP PROXY_IP CLIENT_PORT PROXY_PORT\r\n
```

プロキシプロトコルとヘルスチェック

リスナーにプロキシプロトコルを設定すると、サービストラフィックには常にプロキシプロトコルが送信されますが、ヘルスチェックトラフィックにはヘルスチェックポートの設定に応じて送信されるかどうかが異なります。ヘルスチェックポートをメンバーポートに設定した場合はヘルスチェックの接続にもプロキシプロトコルが送信され、ユーザー指定で別のポートを指定した場合は送信されません。

したがって、ヘルスチェックプロトコルに HTTP または HTTPS を使用しながらプロキシプロトコルが送信される場合、メンバーインスタンスがプロキシプロトコルを認識できる必要があります。認識できる場合に正常なレスポンスが返され、ACTIVE 状態になります。メンバーインスタンスがプロキシプロトコルをサポートしていない場合は、ヘルスチェックポートをユーザー指定に設定してプロキシプロトコルが送信されないようにする必要があります。

セッション接続制限

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

セッション維持

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

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

• Source IP (送信元IPによるセッション管理)：リクエスト元の送信元IPを基準にセッションを維持する方式です。このため、最初のリクエスト時にロードバランシング方式によって選択されたインスタンスと送信元IP間のマッピングテーブルを内部的に保管します。その後、同じ送信元IPを持つリクエストが入ってきた場合、マッピングテーブルを確認して最初のリクエストにレスポンスを返したインスタンスに転送します。ロードバランサーは最大10,000個の送信元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に含めて送信すると、最初にレスポンスを返したサーバーにリクエストが転送されます。

無効なリクエストのブロック

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

カスタムレスポンス

ロードバランサーのリスナーで特定のHTTPエラーコードが発生した際に、ユーザーに送信するレスポンスをユーザーが直接定義できます。カスタムレスポンスを設定すると、デフォルトのシステムレスポンスの代わりに、目的のカスタムメッセージやHTMLなどの内容をクライアントに送信できます。

サポートするHTTPステータスコードは400、403、408、500、502、503、504です。レスポンスボディは最大1024文字まで入力でき、コンテンツタイプはtext/html、text/plain、application/json、application/javascript、text/cssの中から選択できます。同一のリスナー内で、各エラーコードは1回のみカスタムレスポンスとして登録できます。

X-Forwardedヘッダ

ロードバランサーは、リスナー単位でX-Forwardedヘッダの追加/削除を制御できます。X-Forwardedヘッダは、クライアントのオリジン情報(プロトコル、ポート、IPアドレス)をバックエンドサーバーに送信するために使用されます。

X-Forwardedヘッダの種類

• X-Forwarded-Proto：クライアントが使用したプロトコル(httpまたはhttps)をバックエンドサーバーに送信します。HTTPリスナーの場合はhttp、TERMINATED_HTTPSリスナーの場合はhttpsの値が設定されます。
• X-Forwarded-Port：クライアントが接続したポート番号をバックエンドサーバーに送信します。
• X-Forwarded-For：クライアントのオリジンIPアドレスをバックエンドサーバーに送信します。

X-Forwardedヘッダの制御

リスナーの作成時またはリスナーの修正時に、次の3つのフラグを通じて各ヘッダの追加/削除を制御できます。全てのフラグのデフォルト値はtrueです。

• enable_x_forwarded_proto：X-Forwarded-Protoヘッダのon/off
• enable_x_forwarded_port：X-Forwarded-Portヘッダのon/off
• enable_x_forwarded_for：X-Forwarded-Forヘッダのon/off

インスタンスのヘルスチェック

NHN Cloudのロードバランサーは、メンバーとして登録されたインスタンスが正常に動作しているかを確認するため、定期的にヘルスチェックを試みます。ヘルスチェックは、指定されたプロトコルに従って決められたレスポンスが来るかを確認することで行われます。指定された回数や時間内に正常なレスポンスが来ない場合は、異常なインスタンスとみなして負荷分散の対象から除外します。この機能を通じて、予期せぬ障害やメンテナンスの際にも、中断することなくサービスを提供できます。

ロードバランサーは、ヘルスチェックのプロトコルとしてTCP、HTTP、HTTPSをサポートしています。精密なヘルスチェックを行うため、各プロトコルの使用時にヘルスチェックの方法を多様に設定できます。

リスナーにプロキシプロトコルを設定した場合、ヘルスチェックポートの設定に応じてヘルスチェックの動作が異なります。詳細については、「ロードバランサープロキシモード」の「プロキシプロトコルとヘルスチェック」を参照してください。

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

ロードバランサーが処理したネットワークフローに関する様々な統計指標をチャートで確認できます。NHN Cloudロードバランサーの統計機能の特徴は以下のとおりです。

• ロードバランサーごと、リスナーごとの統計チャートを提供します。
• 1時間、24時間、1週間、1か月、指定期間などで期間を分類して表示できます。
• ロードバランサーを基準として、クライアント統計量とインスタンス統計量がそれぞれ異なるチャートで提供されます。
• インスタンス統計量は、メンバーインスタンスごとに分けて表示することも、集計結果のみを表示することもできます。(インスタンスごとに表示：ON/OFF)

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

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

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

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

IPアクセス制御機能を利用するには、以下の事項を設定する必要があります。

IPアクセス制御グループ

• 1つのプロジェクトに最大10個のグループを作成できます。
• グループのプロパティは、名前、メモ、アクセス制御タイプです。
• アクセス制御タイプのプロパティは、「許可(Allow)」と「ブロック(Deny)」のいずれかを設定できます。
• アクセス制御グループに、制御を希望するIPアクセス制御対象を追加できます。
• IPアクセス制御グループを削除すると、グループ内の全てのIPアクセス制御対象が削除され、このアクセス制御グループが適用されていた全てのロードバランサーでそのIPを制御しなくなります。

IPアクセス制御タイプ

• 「許可(Allow)」：グループに属するIPのアクセスは許可し、それ以外の全てのIPのアクセスをブロックします。
• 「ブロック(Deny)」：グループに属するIPのアクセスはブロックし、それ以外の全てのIPのアクセスを許可します。

IPアクセス制御対象

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

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

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