Cloudn Load Balancing Advanced (LBA) 操作マニュアル

本マニュアルでは、 Cloudn Load Balancing Advanced (LBA) のご利用方法に関してご説明いたします。
右のサイドバーより検索がご利用いただけます

1. はじめに

1.1. サービスの概要

Cloudn Load Balancing Advanced (LBA) は、複数の Cloudn Compute 仮想サーバーにアプリケーショントラフィックを自動的に分散させる負荷分散サービスです。
物理NWでいう、ロードバランサのアプライアンスに相当します。

LBAを利用する事により、インターネットから流入する大量のトラフィックを、複数台の Cloudn Compute 仮想サーバーを使って効率的に処理し、仮想サーバー単体での性能制限に縛られないスケーラブルなシステムを構築する事ができます。

主な提供機能

アプリケーショントラフィックの分散
  • LBAを作成すると、作成時に指定したゾーンにLBAインスタンスという特殊な仮想サーバーが作成されます

    • LBAインスタンスに到着するアプリケーショントラフィックを、事前に登録したCompute仮想サーバーに振り分けます
  • LBAインスタンスの数は、平均同時接続コネクション数に基づき自動的に増減します

  • クライアントからのHTTP/HTTPSセッションはLBAインスタンスで終端されます

  • Cookie を用いて、仮想サーバーとのセッション維持を行うことができます

  • LBAにSSL証明書を登録することで、クライアントからLBAまでSSL通信することができます

ヘルスチェック
  • 負荷分散先の仮想サーバーに対して、 LBAサービスはヘルスチェック (死活監視) を行います

    • 万一仮想サーバーが正常に反応しなかった場合は、負荷分散先から除外します
    • 除外された仮想サーバーについても継続的にヘルスチェックを行い、再度正常に反応した時点で負荷分散先に追加します
  • ヘルスチェックの方法はHTTP, HTTPS, TCPなどのプロトコルから選択可能です

    • デフォルトでは、仮想サーバーの 80 番ポートに対して、TCPプロトコルにてヘルスチェックを行います
    • HTTP/HTTPSプロトコルでヘルスチェックを行う場合、特定のURLパスにアクセスし、HTTPレスポンスとして成功応答 (200番台) が戻ってくるかで判断します
LBA利用イメージ

Cloudn LBAの利用イメージ

1.2. サービスの用語・提供機能一覧・技術仕様

Cloudn LBAの主な技術仕様、および用語は以下の通りです。 Computeサービスについて利用/習熟していることが前提となりますので必ず合わせてCompute操作マニュアルもお読み下さい。

Cloudn LBAで用いられる用語

LBA
インターネットからの各種トラフィックを複数の仮想サーバーへ向けて分散する仮想的な装置です。
物理的な機器としては、L7ロードバランサーに相当し、 Cloudn LBAは Cloudn ComputeやDNSと連携した機能を提供し、
これを利用することで複数ゾーンもしくは同一ゾーンへの仮想サーバーへのトラフィックを分散することが可能です。
LBAインスタンス (LBI)
LBAの実体であるインスタンスであり、ロードバランス機能を持つソフトウェアが動作する仮想サーバーです。

LBAのサービスは1つ以上のLBAインスタンスによって提供されます。
例えば、LBAの複製機能や自動スケールアウト/イン機能によってLBAインスタンスの数は増減します。
また、複数のゾーンに登録Computeが存在する場合、各ゾーン毎にLBAインスタンスが作成されます。
DNS名

LBAコンソール、及びAPIで使用されるLBAのFQDNです。 LBAを作成すると自動的にユニークなFQDNが生成されます。

LBAへトラフィックを流すには、このDNS名を用いて、もしくは Cloudn DNSのエイリアスレコード やCNAMEを利用してLBAへアクセスが行われるようにする必要があります。

警告

LBAインスタンス (LBI)のIPアドレスは変更される場合があります。 また、 自動スケールアウト/イン機能 によってLBIの数も増減します。

LBIへのIPアドレスを利用したアクセスはサポートされません。

登録Computeに対する通信を制限する目的で、登録ComputeのセキュリティグループルールにLBIのIPアドレスを指定しないでください。 LBIのIPアドレスが変更されたタイミングでLBAと登録Computeの通信が遮断されます。 登録ComputeでLBAからの通信を許可する場合、 ソースセキュリティグループ (Source Security Group) をご利用ください。

参考

DNSエイリアスレコードに関しては、DNS操作マニュアルをお読みください。

仮想サーバー (Instance)
Computeにてお客様が作成されている仮想サーバーです。
登録Compute

仮想サーバーのうち、LBAの負荷分散先として登録されているものを指します。

Cloudn LBA、LBAインスタンス、DNS名、登録Computeのイメージ

LBA, LBI, DNS名、登録Computeのイメージ

リスナー (Listner)
LBAや登録Computeで通信を受け付けるプロトコルやポート番号、セッション維持設定情報のセットを指します。
LBAプロトコル

LBAとクライアントとの通信プロトコル

LBAポート

LBAがクライアントからの通信を待ち受けるポート番号

Computeプロトコル

LBAと登録Computeとの通信プロトコル

Computeポート
登録ComputeがLBAからの通信を待ち受けるポート番号
(LBAから登録Computeへの通信に使用するポート番号)
ゾーン (AvailabilityZone)
ゾーンの概念は基本的にComputeと同じです。

LBAの登録Computeが複数のゾーンに存在している場合、LBAインスタンスも各ゾーンに存在します。
APIを使用してLBAに複数のゾーンをまたいで仮想サーバーを登録する場合、ロードバランスを開始するにはLBAに各ゾーンを追加して明示的に有効化する必要があります。
GUIを使用する場合はゾーンの有効化は自動的に実行されるため、特に意識することなくご利用いただけます。

注釈

複数ゾーンにおいてLBAを有効化しても、料金は変わりません。

参考

Computeに関しては、別途Compute操作マニュアルをご参照ください。

ポリシー (Policy)
APIでのみ使われる用語で、リスナーに適用するセッション維持のルールです。

ポリシーは、ロードバランサークッキーによるセッション維持を行うポリシーと、アプリケーションクッキーによるセッション維持を行うポリシーの2種類があります。
前者の場合、セッション維持のルールとしてクッキーの有効期間を指定し、後者の場合はアプリケーションクッキー名を指定します。

あるLBAに設定済みのリスナーにAPIでセッション維持を設定する場合、まずはポリシー作成APIにてポリシーを作成する必要があります。
ポリシーはLBA毎に複数作成することが可能で、作成時はポリシーを作成するLBA、クッキーの有効期間(もしくはアプリケーションクッキー名)、ポリシー名を指定する必要があります。

次に、LBAに設定済みのリスナーで使用しているLBAポート番号に対してポリシーを適用することで、当該リスナーにおいてポリシーに設定したセッション維持が有効になります。

GUI (LBAコンソール) による操作では、「リスナー設定」タブからリスナー毎にセッション維持の設定を実施するため、特にポリシーとリスナーの対応を意識することなくセッション維持機能をご利用いただけます。
セキュリティグループ (Security Group)
セキュリティグループの概念は基本的にComputeと同じです。
ファイアウォールにおける通信許可ルールの集合に相当します。

Computeで別途作成したセキュリティグループをLBAに適用することが可能です。
LBAに設定されているリスナーでの通信が可能となるように、リスナーに対応するセキュリティグループがLBAに適用されている必要があります。

LBAにセキュリティグループを適用した後、Computeにて当該セキュリティグループルールを変更した場合、変更が自動でLBAに反映されることはございません。
反映させる場合は、再度セキュリティグループをLBAに適用する必要があります。

また、 LBAインスタンスのヘルスチェック が失敗することを避けるため、リスナーでの通信を許可するセキュリティグループルールには、CIDRに必ず “0.0.0.0/0” を設定してください。
さらに同様の理由から、LBAにリスナーを追加で設定する際は、設定するリスナーの通信を許可するセキュリティグループをLBAにあらかじめ適用しておくことを推奨いたします。

なお、LBA側でセキュリティグループを適用しましても、80/443番ポートに通信制限をかけることはできません。

DoS攻撃などで特定のIPアドレスからの通信を遮断したい場合には、登録Compute側でiptablesなどにより通信を遮断する必要があります。
ソースセキュリティグループ (Source Security Group)
LBAからの通信のみ受信許可するルールが設定されたセキュリティグループで、LBA作成時にCompute上に自動的に作成されます。

LBAの登録Computeとなる仮想サーバーを作成する際、LBAのソースセキュリティグループを適用することで、登録Computeが受信許可する通信をLBAからの通信のみに制限することができるため、セキュリティが向上します。
また、通常のセキュリティグループのみを利用した場合、 リスナー (Listner) に応じて登録Computeのセキュリティグループへルールをお客様自身で追加頂く必要がありますが、ソースセキュリティグループを利用した場合、ルールはリスナーを設定すると自動的に設定されます。
そのため、Computeセキュリティグループの管理の煩雑さを簡略化することが可能です。

参考

ソースセキュリティグループと通常のセキュリティグループの両方を仮想サーバーへ適用することで、たとえばTCP80/443ポートのアクセスはインターネットからLBA経由で、TCP22ポートのアクセスは一部のCIDRからのみ受付といったことが可能になります。 詳細は LBAを編集する (詳細設定 - 登録Computeの選択) を参照してください。

警告

お客様自身によるソースセキュリティグループのルール変更・追加・削除といった編集はサポートされません。 LBAインスタンスのIPアドレスは動的に増減あるいは変化する可能性があり、LBAは増減や変化に追従してソースセキュリティグループ内のルールを自動的に更新します。 よって、お客様によるソースセキュリティグループのルール編集は必要ありません。

また、LBAによるソースセキュリティグループのルール更新時に、お客様による変更は全て破棄されてしまいます。 そのため、ソースセキュリティグループのお客様によるルール編集や追加はサポートされません。

注釈

LBA作成後、Computeにてソースセキュリティグループを確認するとルールが設定されていないように見える場合がありますが、ソースセキュリティグループを設定した仮想サーバーがLBAの登録Computeに設定された時点でルールが投入されますので、ご安心ください。

ソースセキュリティグループが不要になりましたら、お客様自身でComputeコンソールから削除してください。 万が一、誤ってソースセキュリティグループを削除してしまった場合などは、LBAコンソールの「セキュリティグループ適用」タブから「SourceSecurityGroupの再作成」をクリックすることで再作成が可能です。

注釈

ソースセキュリティグループを利用する際は、Compute の制約上、既存の仮想サーバーに対してセキュリティグループを追加することができませんので、LBA作成後に当該LBAのソースセキュリティグループを指定して仮想サーバーを新たに作成する必要があります。 一般的なLBA適用の流れについては、 LBAを編集する (詳細設定 - 登録Computeの選択) を参照してください。

注釈

ソースセキュリティグループを利用した場合、TCP/port80はデフォルトでLBAからのアクセスを許可します。 これを一部のCIDRからのアクセスに限定、もしくは削除することは出来ません。

自動的にルールが編集されるソースセキュリティグループのルールは以下となります。

  • TCP/port80 (デフォルト) , LBAのCIDRからのアクセス
  • リスナーに設定したプロトコル/ポート, LBAのCIDRからのアクセス

なお、TCP/port80のLBAのCIDRからのアクセスを許可しないことは出来ません。 LBAを利用するのはインターネットからのトラフィックであるという考えのもと、この機能は設計されております。

注釈

ソースセキュリティグループは任意のセキュリティグループと併用していただけます。 仮想サーバーでLBA以外からの通信も許可する必要がある場合、仮想サーバー作成時にソースセキュリティグループと同時に 任意のセキュリティグループを併せて指定することでLBAからの通信および任意のセキュリティグループに紐づけられた セキュリティグループルールに従った通信が許可されます。

セッション維持
LBAプロトコルが”HTTP”または”HTTPS”である場合、クッキー (Cookie)を使用した2種類のセッション維持が可能です。
セッション維持により、LBAは同じ利用者からの通信を同じ登録Computeに振り分け続けるといった動作が可能になります。
ヘルスチェック (Health Check)

LBAには以下の2種類のヘルスチェックが存在します。

仮想サーバー (登録Compute) のヘルスチェック
LBA配下の登録Computeに対し、任意のヘルスチェックを設定することが可能です。
ヘルスチェックを設定することで、何らかの障害が発生してヘルスチェックが失敗した場合には登録Computeを負荷分散先から自動的に除外し、正常な登録Computeにのみ通信を振り分けることができます。
また、除外されたComputeのヘルスチェックが再度成功 (復旧) した場合、負荷分散先として自動的に再設定されます。

以下がLBAで取得される登録Computeのヘルスチェック状態です。
  • InService

    • ヘルスチェックが成功し、仮想サーバーが負荷分散先として登録されている状態
  • OutOfService

    • ヘルスチェックが失敗し、仮想サーバーが負荷分散先から除外されている状態
  • HealthChecking

    • LBAの新規作成/編集などの設定変更時に、仮想サーバーの初期ヘルスチェックを実施している状態 LBA編集前に仮想サーバーがInServiceであった場合、当該仮想サーバーはHealthChecking状態であっても負荷分散対象のままであり、振り分け動作は継続されます。 上記の操作以外にも、 自動スケールアウト/イン機能 が発動したタイミングでHealthChecking状態となる場合があります。
LBAインスタンスのヘルスチェック
LBAインスタンスへ行われるサービス運用上のヘルスチェックです。

LBAインスタンスにお客様が設定された全てのリスナーに対して、TCP接続か可能かどうかを Cloudn 設備から監視しております。

ヘルスチェックに失敗した場合、LBAインスタンスは異常状態であると判定し、当該LBAインスタンスを”DNS名”から削除します。
すなわち、LBAコンソールで表示されている”DNS名”から異常状態となったLBAインスタンスのAレコードが削除され、DNSラウンドロビンから除外されます。
ヘルスチェックが再度成功すると、自動的に”DNS名”も再登録されます。

なお、こちらのヘルスチェックは、LBAのサービス提供状況を確認するために弊社が実施するものであり、お客様が特に設定するものではございません。
自動スケールアウト/イン機能
LBAの負荷状況によって、自動的にLBAインスタンス数を増減する機能です。

LBAの負荷状況を定期的に監視し、負荷が一定を超えると自動的に新しいLBAインスタンスが作成されてスケールアウトします。
その後、負荷の減少を検知すると、自動作成されたLBAインスタンスは削除され、スケールインします。

なお、監視間隔は約2分ですが、LBAサービス全体の負荷状況によっては数分程度遅延する可能性があります。
また、自動スケールアウトによるLBAインスタンスの作成にも通常は数分程度を要しますので、突発的な負荷増加に対応したい場合は複製機能を利用し、あらかじめLBAインスタンス数を増加しておくことを推奨いたします。
(参照 複製機能 )

自動スケールアウトによって作成されるLBAインスタンス数は最大10台です。

注釈

自動スケールアウト/イン機能により増減したLBAインスタンスへの追加の課金はありません。

複製機能
LBAインスタンスを複製する機能です。

LBAでは 自動スケールアウト/イン機能 によってLBAインスタンス数は増加しますが、スケールアウトには一定の時間を要します。
複製機能を利用することで、”DNS名”を利用したDNSラウンドロビンによって複数のLBAインスタンスに通信が振り分けられるため、LBAインスタンス1台あたりにかかる負荷に対し自動スケールアウト/イン機能より早く対応することが可能です。
そのため、あらかじめ負荷の増大が見込まれる場合は、複製機能を利用して事前にLBAインスタンス数を増加しておくことを推奨いたします。

また、自動スケールアウトの最大台数を超えてトラフィックを処理したい場合にも有効です。

複製は最大で10セット作成することが可能です。
複数のゾーンにLBAの登録Computeが存在する場合、各ゾーン毎にLBAインスタンスが1台ずつ存在しますが、この状態で複製を1セット作成すると、各ゾーンのLBAインスタンスがそれぞれ1台ずつ増加します。

注釈

複製によりLBAインスタンスの料金がかかります。

SSL終端機能
LBAにお客様のSSL証明書を登録し、LBAでSSL終端する機能です。
SSL終端機能により、LBAの登録Compute全てに証明書をセットする手間を省略し、SSL終端処理をLBAにオフロードすることが可能です。

SSL証明書の登録では、秘密鍵、証明書、中間証明書の3点を登録します。
その際、パスフレーズ無しの秘密鍵をご用意いただく必要があります。
(秘密鍵にパスワードがセットされている場合、必ず解除したものをご登録ください。)

SSL証明書にはワイルドカード証明書やクロスルート証明書をご利用いただけます。

注釈

SSL終端機能を利用する場合、LBAインスタンスの負荷が増大(通常時より10倍程度)しますので、 複製機能 を利用した負荷の低減が必要なケースがあります。

SSL終端機能によりLBAのパフォーマンスが低下した場合はSSLを仮想サーバーにおいて終端、もしくは 複製機能の検討をご利用ください。

注釈

LBAに登録するSSL証明書をご購入の前に、無料のテスト証明書等で事前に検証されることを強く推奨いたします。 LBAでは全ての証明書の動作保証はいたしかねます。

注釈

SSL証明書の登録には別途料金が発生します。

Sorryページ
LBAの登録Computeが何らかの原因で全て “OutOfService” 状態となり、負荷分散先の登録Computeが存在しなくなった場合に表示するWebページです。

Sorryページの内容はLBAに直接設定することが可能です。
もしくはお客様が別途用意したWebサーバーにSorryページを設定していただき、そちらにLBAからリダイレクトさせることも可能です。

登録Computeに故障が発生した場合の他にも、メンテナンスなどで登録Computeを一時的に停止する際に、Sorryページにメンテナンス中であることを記載することで、エンドユーザに状況を通知することが可能です。

注釈

Sorryページの利用には別途料金が発生します。

その他設定
LBAとクライアント(エンドユーザ)間、およびLBAと登録Compute間の通信における以下の各種タイムアウト値を設定可能です。
クライアント リクエスト受信待機時間
LBAがクライアントからのリクエストを受信して読み込みが完了するまでの待機時間の上限です。
Compute レスポンス受信待機時間
LBAが登録Computeからのレスポンスを受信して読み込みが完了するまでの待機時間の上限です。
Compute レスポンス待機時間を超過してもComputeからのレスポンスが受信できなかった場合、LBAはクライアントに504エラーを返却します。
動的コンテンツの生成等でComputeからのレスポンスに時間を要する場合、処理時間に合わせて本設定値を適切にチューニングする必要があります。
Compute 接続待機時間
登録Computeに対するリクエスト送信やヘルスチェック実行時、LBAが登録Computeとの接続確立まで待機する時間の上限です。
トンネルモード接続待機時間
クライアントとComputeで双方向の接続が確立されている状態で通信が無くなった場合に、次の通信を待機する時間の上限です。
本設定値はコネクションがアップグレードされ、使用プロトコルがWebSocketに切り替わった場合に有効となります。したがって、WebSocket利用時に クライアント リクエスト受信待機時間 および Compute レスポンス受信待機時間 よりも長時間のタイムアウト値を使用したい場合に指定します。
その他、LBAがHTTP CONNECTメソッドのリクエストを受信し、登録Computeに転送する場合にも本設定値がタイムアウト値として用いられます。

注釈

クライアント リクエスト受信待機時間Compute レスポンス受信待機時間 には同一のタイムアウト値を設定することを推奨します。

注釈

各種タイムアウト値に必要以上に長い時間を設定すると、LBAのパフォーマンスに影響する可能性があります。

API
Cloudn LBAでは、Amazon Web Services Elastic Load Balancerに互換性のあるAPIを提供しております。
各種AWSのAPIツールをご利用いただくことが可能です
詳細はAPIマニュアルをお読み下さい。

LBA APIリファレンス

提供機能一覧

Cloudn LBAで提供する機能は以下のとおりです。

カテゴリ 機能 GUI API
LBA管理 一覧表示 Yes Yes
LBA作成 Yes Yes
LBA編集 Yes Yes
LBA削除 Yes Yes
SSL証明書登録 Yes Yes
複製 Yes Yes
その他 LBAのDNS名に対する別名定義 Yes [1] Yes [1]
LBAの各種統計情報確認 Yes [2] Yes [2]

脚注

[1](1, 2) Cloudn DNSの利用により可能です。詳細はDNS操作マニュアルを参照してください。
[2](1, 2) Cloudn Monitoringの利用により可能です。詳細はMonitoring操作マニュアルを参照してください。

技術仕様・制限

料金およびSLA
LBA名に関する制限
  • 1〜32文字であること
  • 先頭文字: [a-zA-Z] であること
  • 末尾文字: [a-zA-Z¥d] であること
  • 文字種:[a-zA-Z¥d¥-] であること
  • 同じ名前のLBAが同一リージョンの同一アカウントで保持されていないこと
負荷分散方式
  • L7/L4レイヤーによる負荷分散

    • 同一ゾーン内、もしくは異なるゾーンをまたいで負荷分散が可能
  • 負荷分散アルゴリズム: Least Connections

  • 通信方式: SourceNAT方式での通信

  • アクセスログについて

    • アクセスログを閲覧したい場合、負荷分散先ComputeのWebサーバ等でログを保存する設定が必要です。(LBA自体のアクセスログは提供されません。)

    • 負荷分散Computeに残ったアクセスログの “X-Forwarded-For” ヘッダによりアクセス元IPを判別可能です

      • Webサーバーの設定により、アクセス元IPを記録できるよう設定可能です

        • Apacheではhttpd.confのLogFormatディレクティブを設定
        • Windows (IIS) では詳細ログ⇛ログ記録フィールドの編集⇒フィールドの追加より設定
        • ただし、仮想サーバーでSSL (443ポート) を終端している場合は、上記方法でもクライアントIPを記録することができません
      • 上記設定はお客様サーバー内部となりますのでお客様の責任においてご設定ください

        • 詳細な設定については該当Webサーバーのmanやドキュメントをご参照ください
  • 帯域: 1 LBAインスタンスあたり100Mbps (ベストエフォート)

    • LBAインスタンスがスケールアウトするごとに100Mbps増加します
    • ただし、LBAにおけるSSL終端機能をもちいた場合スループットが頭打ちとなる場合があります
    • その場合、LBAの複製機能などを用いる必要があります
  • HTTPセッション数はMonitoringサービスの RequestCount メトリクスで確認可能です

リスナー
  • 設定可能LBAプロトコル

    • TCP
    • HTTP
    • HTTPS
    • SSL
  • 設定可能LBAポート

    • 80,443,1024-60000 で任意の値(整数)を設定可能
    • ただし、同一のLBAポート番号を持つリスナーを2つ以上重複して設定することは出来ません
  • 設定可能Computeプロトコル

    • LBAプロトコルがTCP, SSLの場合

      • TCP
      • SSL
    • LBAプロトコルがHTTP, HTTPSの場合

      • HTTP
      • HTTPS
  • 設定可能Computeポート

    • 1-65535 で任意の値(整数)を設定可能
  • 利用可能セッション維持形式

    • LBAプロトコルが”HTTP”または”HTTPS”である場合、クッキー (Cookie)を使用した2種類のセッション維持が可能

      • セッションを維持する最大時間: 86400 [秒](24時間)
      • 詳細は クッキー (cookie) を参照
  • 利用可能X-Forwardedヘッダ

    • LBAプロトコルおよびComputeプロトコルが”HTTP”または”HTTPS”である場合、LBAはリクエストに以下の3種類のX-Forwardedヘッダを付与します

      • X-Forwarded-For: < LBAにリクエストを送信したクライアントのIPアドレス >
      • X-Forwarded-Proto: < LBAにリクエストを送信した際にクライアントが利用したプロトコル (http or https) >
      • X-Forwarded-Port: < クライアントのリクエストを受け付けたLBAポート番号 >
DNS名
  • 以下の通りの規則でDNS名が決定されます

    • "${LBAName}-${UNIXTIME}.${ENDPOINT}"

      • ${LBAName}: LBA名を表します
      • ${UNIXTIME}: unix timeを表します
      • ${ENDPOINT}: LBAのAPIエンドポイントを表します
    • (ex.) example-1390872173.lba2.jp-e1.cloudn-service.com

  • 一度決定したDNS名を変更することは出来ません

  • 一度削除されたLBAのDNS名は開放されます

    • 同じDNS名を取得することは出来ません
  • DNS名に紐づくIPアドレスへ向けた直接通信はサポートされません

    • LBAインスタンスのIPアドレスはDNS名にひも付きますが、名前解決を用いないIPアドレスは変更されます
    • そのため、サポートされません
  • DNS名に紐づくIPアドレスの逆引きはComputeと同様のものとなります

    • (ex.) 203-0-113-2.compute.jp-e1.cloudn-service.com. のようになります
    • これを変更することは出来ません
  • Cloudn DNSのエイリアスレコード機能によりDNS名をひもづけることが可能

    • 別途 Cloudn DNSのご利用、およびその料金が必要です
    • 詳細は Cloudn DNSをお読み下さい
利用可能仮想サーバー
  • Cloudn Compute FLATタイプ

    • 全リージョンで利用可能
    • ただし、ご利用Computeと同じリージョンのLBAを利用する必要があります
仮想サーバー (登録Compute) のヘルスチェック
  • 利用可能プロトコル

    • TCP

      • TCPコネクションのハンドシェイクが成功するかでヘルスチェックを行います
    • HTTP

      • LBAからのHTTP GETリクエストに対し200番台もしくは300番台のHTTPステータスコードが返ってくるかでヘルスチェックを行います
      • HTTPステータスコードが400番台や500番台であった場合、失敗と判定されます
    • HTTPS

      • LBAからのHTTPS GETリクエストに対し200番もしくは300番台のHTTPステータスコードが返ってくるかでヘルスチェックを行います
      • HTTPステータスコードが400番台や500番台であった場合、失敗と判定されます
      • SSL証明書の登録が必須です
    • SSL

      • LBAからのSSLハンドシェイクが成功するかでヘルスチェックを行います
  • 利用可能ポート

    • 1-65535 で任意の値を設定可能
  • パス

    • HTTP/HTTPSをプロトコルで利用した際に設定可能
    • Webサーバーのトップディレクトリからのパスを表します
    • 設定することで、HTTPのGETリクエストをLBAより発行し、そのHTTPステータスコードによりヘルスチェックを行います
  • ヘルスチェック受信待機時間

    • ヘルスチェックのタイムアウト値として利用されます
      LBAから登録Computeに対するヘルスチェック接続確立後、登録Computeからのヘルスチェックに対するレスポンスを受信し読み込むまでの待機時間の上限を指定します
    • ヘルスチェックは通常のリクエストよりも単純な場合が多いため、一般的にはComputeレスポンス受信待機時間よりも小さい値を指定します

    • 必要以上に長い時間を設定すると、LBAのパフォーマンスに影響する可能性があります

    • デフォルト値: 10 [秒]

    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]

  • チェック間隔

    • 指定されたヘルスチェック方法にもとづき登録Computeの状態をチェックする間隔です
    • 短い間隔を設定すると登録Computeの障害や復旧を素早く検知できますが、LBAのパフォーマンスが低下する可能性があります
    • デフォルト値: 30 [秒]
    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]
  • 成功と判断する連続回数

    • この回数連続のヘルスチェックに対し成功であった場合、ヘルスチェック成功と判断します
    • すでにOutOfServiceと判断されている登録Computeに対し成功と判断された場合、負荷分散対象へ戻します
    • 成功と判断した場合、該当の登録Computeの状態はInServiceとなります
    • デフォルト値: 10 [回]
    • 1-10 の範囲で任意の値(整数)を設定可能 [単位:回]
  • 失敗と判断する連続回数

    • この回数連続のヘルスチェックに対し失敗であった場合、ヘルスチェック失敗と判断します
    • 失敗と判断した場合、該当の登録Computeの状態をOutOfServiceと判断し、負荷分散対象より除外します
    • デフォルト値: 2 [回]
    • 1-10 の範囲で任意の値(整数)を設定可能 [単位:回]

注釈

初期設定の各ヘルスチェック値はあくまで初期設定です。
お客様環境 (Webサーバーの設定やアプリケーションの設定) に合わせ、お客様ご自身でHTTP Errorとならないよう設定を行う必要があります。

注釈

Cloudn AutoScalingと組み合わせてご利用いただく場合、AutoScalingで設定するクールダウン時間内で LBAのヘルスチェックが成功するように余裕を持たせて「チェック間隔」と「成功と判断する連続回数」を設定してください。 (クールダウン時間に対して長すぎるチェック間隔、多すぎる連続回数を設定しないでください。)

LBAインスタンスのヘルスチェック
  • Cloudn としてLBAへのサービス運用上のヘルスチェックを行っています

  • LBAに独自に設定されたリスナー(TCP-80, 443以外)は必ず、0.0.0.0/0より通信が可能な必要があります

    • 通信が可能でない場合、LBAの”DNS名”より登録が削除されます
    • 通信可能に戻った場合、10-20分程度で自動的に登録が復旧されます

警告

LBAインスタンスへのヘルスチェックはLBAに設定されたリスナーに向けて実施されます。

リスナーへのヘルスチェックが失敗する場合、LBIが故障したとみなし該当LBIをLBAの”DNS名”の登録から削除します そのため、リスナーへの通信がLBAに適用されたセキュリティグループにより遮断されている場合、 故障として検知され、LBIが”DNS名”から登録削除されます。

結果として、LBAの”DNS名”に紐づくLBIが存在しなくなり、通信が断絶することとなります。

そのため、必ずリスナーを追加した場合は該当リスナーへ 0.0.0.0/0 からの通信を許可してください。

なお、 ソースセキュリティグループ (Source Security Group) を利用した場合、自動的にLBAからの通信がリスナーに応じて許可されますので意識する必要はありません。

  • ヘルスチェック間隔

    • 10分間隔
    • 2回NGとなった場合、DNS登録を削除します
    • その後1回でもOKとなればDNS再登録が実施されます
セキュリティグループ
  • セキュリティグループの同時利用が可能

    • 仮想サーバーAに対し、セキュリティグループ1とセキュリティグループ2を重ねて利用することが可能
    • 詳細はCompute操作マニュアルを参照してください
ソースセキュリティグループ
  • ソースセキュリティグループのルール

    • Compute画面から編集可能ですが、編集はサポートされません

    • ソースセキュリティグループの追加・削除をした場合には自動的にルールがLBAにより削除されます

    • ソースセキュリティグループに自動で追加編集されるルール群が以下のとおりです

      • TCP/port80 (デフォルト) , LBAのCIDRからのアクセス
      • リスナーに設定したプロトコル/ポート, LBAのCIDRからのアクセス
複製機能
  • 複製の最大数: 10 セット

  • 複製には別途利用料金がかかります

  • 複製を複数ゾーン利用可能なLBAで実施した場合、LBAインスタンスとしては両ゾーンで複製されます

    • この場合、複製にかかる料金は 1 複製分です
SSL終端機能
  • 証明書形式

    • X.509 PEM形式
    • ワイルドカード証明書やクロスルート証明書も利用可能
  • 証明書名

    • 証明書名の先頭文字には全角半角英数字または-(ハイフン)を指定してください。

    警告

     以下の文字列(記号)を先頭文字に指定した場合、エラーとなります。
     _(アンダースコア) .(ドット) ,(カンマ) =(イコール) @(アットマーク) +(プラス)
  • 登録可能な証明書の上限

    • 1アカウントあたり 100 個まで
    • ただし、”仕様 - リスナー “にある通り、LBAではポート番号を重複してリスナーに設定することは出来ません
    • そのため同じポート番号で異なる証明書を利用される場合にはLBAを複数用意する必要があります
  • 登録時には証明書の正当性をチェックし、確認できない場合は登録が失敗します

    • 正当な証明書でない場合, もしくは中間証明書を利用する場合はチェーンファイルを登録可能
  • リスナーに登録されているSSL証明書は削除できません

  • 非利用時に比べ、LBAのパフォーマンスが低下します

    • 複製機能をご利用ください
  • Cipher Suite (利用可能な暗号アルゴリズムとハッシュアルゴリズムの組)

    • API DescribeLoadBalancers にて確認可能です
    • GUIからは確認できません
    • 利用可能なCipher Suiteをお客様ご自身で変更することは出来ません
    • 利用可能なCipher Suiteは暗号化方式の危殆化等にともなって更新されることがございますので、ご確認の上ご利用ください
Sorryページ
  • 以下の2つの方法でSorryページを設定可能

    • 他サーバー(お客様が別途ご用意されたSorryサーバー)へのリダイレクト

    • LBA自体にSorryページを登録

      • HTMLを記述可能です
      • 登録するHTMLは W3C勧告 “HTML 4.01 Specification” に従い妥当 (Valid) なHTMLである必要があります
タイムアウト設定
AWS互換機能に関する制限
  • APIバージョン: “2012-06-01”

  • 対応署名バージョン: Signature Version 2

    • Signature Version 4による署名には対応していません
  • Connection Drainingはサポートされません

  • LBAへのアクセスログ出力機能はありません

    • X-Forwarded-Forヘッダによるアクセスログのみサポートされます
  • マニュアルに記載されていない機能はサポートされません

  • 証明書のアップロードなど、一部 Cloudn 独自APIがあります

他サービスとの連携
  • Cloudn DNS

    • DNS名の別名を定義することが可能
    • エイリアスレコード、もしくはCNAMEによりLBAのDNS名を登録可能
    • 詳細はDNS操作マニュアルをお読み下さい
    • LBAのIPによる登録はサポートされません (LBAインスタンスのIPアドレスは動的に変化します)
  • Cloudn Monitoring

    • サービスにおいてLBAの各種状態が確認できる標準提供メトリクスを提供しております
    • 詳細はMonitoring操作マニュアルをお読みください
その他
  • LBAの内部で用いられるソフトウェアに対して、随時必要に応じセキュリティアップデートが適用されます

    • 用いられるソフトウェアについては公開されません
  • LBAの利用には、Computeを利用開始していることが前提です

  • セッションリカバリー機能は提供しておりません

  • Direct Server Return (DSR) 機能は提供しておりません

  • 重み付き負荷分散アルゴリズムは提供しておりません

  • 408エラーを返却いたしません

  • LBAを介したComputeでのクライアント証明書認証は未対応です

  • PROXY Protocolには未対応です

1.3. 事前に準備いただくもの

Cloudn LBAをご利用頂くにあたっては、以下のものをご用意ください。

インターネットに接続するための機器

パソコンやモデム等、イントラネット/インターネットに接続する為に必要な機器をご用意ください。

インターネットに接続するためのサービス

インターネットへ接続するためのサービスをご用意ください。
例: OCNダイヤルアクセスサービス、OCN ADSL接続サービス、スーパーOCN等の常時接続サービスなど

※他社のインターネット接続サービスでもご利用いただけます。
※プロキシサーバーを利用されている場合は、”https” (ポート番号443) が開放されていることをご確認下さい。

コントロールパネルを閲覧するためのソフト(ブラウザソフト)

Firefox18.0.1 以降が推奨となります。
それ以外のブラウザは、一部、正常に表示されない場合がありますのでご注意ください。

「 【クラウド・エヌ】ご利用内容のご案内 」メール

開通時に送付される「 【クラウド・エヌ】ご利用内容のご案内 」を用意してください。

サービス利用登録後にメール送付される、下記ご利用案内(タイトル「 【クラウド・エヌ】ご利用内容のご案内 」)を参照しながら、本ご利用ガイドに従ってセットアップを実施してください。

ご利用内容のご案内メール

ご利用内容のご案内:メール本文

必要情報の一覧
Cloudn ポータルURL https://portal.cloudn-service.com/comgi/login
Cloudn ポータルログインID メールに記載のある文字(お申し込み時に設定したログインID、上記例ではTest0001)
Cloudn ポータルパスワード お申し込み時に設定されたパスワード

注釈

LBAサービスはアカウント作成時点で自動的に「ご利用中」ステータスとなります。

実際のご利用にて初めて課金が発生します。 詳しくは クラウド・エヌ 料金 をご確認ください。 また、「ご利用中」ステータスになっているものを「未利用」に戻すことは出来ません。

1.4. サービスを利用開始する

以下の手順でLBAサービスを利用開始します。

手順

Cloudn ポータルにログインし、利用したいタイプ・リージョンの「LBA」アイコンへのマウスオーバーにて表示される、「利用開始」をクリックします。

利用開始ボタンをクリックする

Cloudn ポータルでの利用開始

Cloudn LBAサービスが利用開始されます。

利用開始完了

Cloudn ポータルでの利用開始完了画面

注釈

本手順は、コントロールパネル経由でのLBAの操作・API経由でのLBAの操作にかかわらず、 アカウントごとに必要な手順となります。 「ご利用中」のステータス出ない場合、コントロールパネル・API共にご利用をいただけません。

注釈

本手順により課金は発生しません。 実際のご利用にて初めて課金が発生します。 詳しくは クラウド・エヌ 料金 をご確認ください。 また、「ご利用中」ステータスになったものを「未利用」に戻すことは出来ません。

2. LBA コンソールを利用する

Cloudn LBAコンソールについて説明します

2.1. LBAコンソールを起動する

Cloudn LBAを管理するコンソールを起動します。

手順

Cloudn ポータルにログインし、LBAを利用するリージョン・タイプを選択します。
LBA機能概要

Cloudn ポータルの画面 - タイプ・リージョンの選択

その上で、「LBA」アイコンへのマウスオーバーにて表示される、「コンソールへ」をクリックします。
LBA機能概要

Cloudn LBAの選択

LBAコンソールが起動し、初期画面として「Load Balancing Advanced (LBA) 一覧」が表示されます。

LBA機能概要

Cloudn LBAコンソール画面

3. LBAを管理する

LBAを管理する方法について説明します。

3.1. LBAを新規開始 (基本設定) する

新規LBAを作成します。

手順

「新規作成 (基本設定) 」ボタンをクリックします。

新規作成

LBAの新規作成

LBA名を入力します。
リスナー (Listner) を追加したい場合は、リスナー設定 (LBAプロトコル、LBAポート、Computeプロトコル、Computeポート、SSL証明書) を入力し、「追加」ボタンをクリックします。
LBA情報の入力

LBA設定情報の入力

注釈

HTTPはデフォルトでリスナー設定に含まれます。不要な場合は削除いただけます。

LBAプロトコルにHTTPSまたはSSLを選択いただく場合、 SSL証明書は必須になります。 ComputeプロトコルにTCPを選択いただく場合、LBAプロトコルはTCPまたはSSLを選択いただきます。

注釈

SSL証明書の入力は、事前にSSL証明書登録を済ませておく必要があります。 詳細は下記を参照してください。

参考

LBA命名規則に関する制限は以下を参考にしてください。

リスナー設定を確認し、「確定」ボタンをクリックする。

設定の確認

設定の確認

「OK」をクリックするとLBAが作成されます。

LBA作成の確認

LBAの作成

ロードバランサーを選択、「編集(詳細設定)」->「セキュリティグループ適用」をクリックすると、画面下部に ソースセキュリティグループ (Source Security Group) 名が表示されます。
|brandname| LBA 機能概要

SourceSecurityGroupの確認

負荷分散させる Compute にソースセキュリティグループを適用することで、Compute が受ける通信をLBAのみに制限することができます。

危険

ソースセキュリティグループにはロードバランサーのIPアドレスが自動で追加削除されますので、 ルールの変更、削除はしないでください。

詳細については下記を参照してください

注釈

ソースセキュリティグループ (Source Security Group)は、ロードバランサー作成時に、お客様のComputeアカウントで自動的に作成されます。

ソースセキュリティグループを適用した仮想サーバーをロードバランサーに登録した時点で、セキュリティグループのルールが更新されます。

また、ソースセキュリティグループが不要になった場合はお客様ご自身でComputeコンソールより削除を実施可能です。 自動削除はされないことにご注意ください。

万が一、ソースセキュリティグループを削除してしまった場合、「SourceSecurityGroupの再作成」をクリックすることで再作成が可能です。

3.2. LBAを編集する (詳細設定 - リスナー)

リスナー (Listner) に関する設定を行います。

ポート・プロトコルの編集

「リスナー設定」リンクをクリックします。

リスナー設定

リスナー設定

LBAのリスナー設定(詳細設定)します。
プロトコルを選択し、「編集」ボタンをクリックする。
|brandname| LBA 機能概要

プロトコル設定の編集

セッション維持方法の設定

セッション維持の方法を選択します。

「ロードバランサークッキーによるセッション維持」は「有効期間」を入力します。
「アプリケーションクッキーによるセッション維持」は「クッキー名」を入力します。

設定を確認して、「確定」ボタンをクリックします。

参考

ロードバランサークッキー、アプリケーションクッキーなどの説明は以下を参照してください。

クッキーの設定

クッキーの設定

注釈

リスナー設定 (LBAプロトコル、LBAポート、Computeプロトコル、Computeポート、SSL証明書) も、 上記画面から変更することができます。

「OK」ボタンをクリックすると、設定変更されます。

設定の反映

設定の反映

設定変更後、上記、画面に戻ります。

危険

LBAには以下の2種類のヘルスチェックが存在します。

後者のLBAインスタンスへのヘルスチェック (運用上の弊社設備からの監視) はLBAに設定されたリスナーに向けて実施されます。

リスナーへのヘルスチェックが失敗する場合、LBIが故障したとみなし該当LBIをLBAの”DNS名”の登録から削除します そのため、リスナーへの通信がLBAに適用されたセキュリティグループにより遮断されている場合、 故障として検知され、LBIが”DNS名”から登録削除されます。

結果として、LBAの”DNS名”に紐づくLBIが存在しなくなり、通信が断絶することとなります。

そのため、必ずリスナーを追加した場合は該当リスナーへ 0.0.0.0/0 からの通信を許可してください。

なお、 ソースセキュリティグループ (Source Security Group) を登録Computeでご利用の場合はリスナー設定にもとづき、 自動的にセキュリティグループのルールが編集されるため、上記を意識する必要はありません。

3.3. LBAを編集する (詳細設定 - ヘルスチェック)

仮想サーバー (登録Compute) のヘルスチェック を設定します。

注釈

初期設定のヘルスチェック値はあくまで初期設定です。 お客様環境(Webサーバーの設定やお客様アプリケーションの設定)に合わせ、 設定を行う必要があります。

ヘルスチェック設定の編集

「ヘルスチェック設定」リンクをクリックします。

ヘルスチェック設定

ヘルスチェック設定

LBAからComputeのヘルスチェック方法を設定し、「確定」ボタンをクリックします。

ヘルスチェック設定の編集

ヘルスチェック設定の編集

「OK」ボタンをクリックすると、設定変更されます。

変更の反映

変更の反映

設定変更後も画面は遷移しません。

注釈

ヘルスチェックの各種設定値は以下の通りです。

  • 利用可能プロトコル

    • TCP

      • TCPコネクションのハンドシェイクが成功するかでヘルスチェックを行います
    • HTTP

      • LBAからのHTTP GETリクエストに対し200番台もしくは300番台のHTTPステータスコードが返ってくるかでヘルスチェックを行います
      • HTTPステータスコードが400番台や500番台であった場合、失敗と判定されます
    • HTTPS

      • LBAからのHTTPS GETリクエストに対し200番もしくは300番台のHTTPステータスコードが返ってくるかでヘルスチェックを行います
      • HTTPステータスコードが400番台や500番台であった場合、失敗と判定されます
      • SSL証明書の登録が必須です
    • SSL

      • LBAからのSSLハンドシェイクが成功するかでヘルスチェックを行います
  • 利用可能ポート

    • 1-65535 で任意の値を設定可能
  • パス

    • HTTP/HTTPSをプロトコルで利用した際に設定可能
    • Webサーバーのトップディレクトリからのパスを表します
    • 設定することで、HTTP/HTTPSのGETリクエストをLBAより発行し、そのHTTPステータスコードによりヘルスチェックを行います
  • ヘルスチェック受信待機時間

    • Computeからのヘルスチェックのレスポンスを受信し、読み込むまでの待機時間の上限です [単位:秒]
  • チェック間隔

    • 指定されたヘルスチェック方法にもとづき登録Computeの状態をチェックする間隔です [単位:秒]
  • 成功と判断する連続回数

    • この回数連続のヘルスチェックに対し成功であった場合、ヘルスチェック成功と判断します
    • すでにOutOfServiceと判断されている登録Computeに対し成功と判断された場合、負荷分散対象へ戻します
    • 成功と判断した場合、該当の登録Computeの状態はInServiceとなります
  • 失敗と判断する連続回数

    • この回数連続のヘルスチェックに対し失敗であった場合、ヘルスチェック失敗と判断します
    • 失敗と判断した場合、該当の登録Computeの状態をOutOfServiceと判断し、負荷分散対象より除外します

注釈

お客様アプリケーションにLBA経由でアクセスした際に504エラーが発生する際には、ヘルスチェック受信待機時間を調整して下さい。

3.4. LBAを編集する (詳細設定 - セキュリティグループ)

セキュリティグループ (Security Group) (送受信規制) をLBAに適用します。

注釈

本LBA用のセキュリティグループのルール編集、もしくは ソースセキュリティグループのルール設定などはComputeコンソール、Compute APIより 実施される必要があります。

ソールセキュリティグループの詳細については以下を参照してください。

ポート・プロコトルの編集

「セキュリティグループ適用」リンクをクリックします。

セキュリティグループ適用

セキュリティグループ適用

適用するセキュリティグループを選択し、「適用」ボタンをクリックします。

セキュリティグループの選択

セキュリティグループの選択

注釈

Compute FLATタイプで別途作成済みのセキュリティグループから選択します。

「OK」ボタンをクリックすると、設定変更されます。

変更の確定

変更の確定

設定変更後も画面は遷移しません。

3.5. LBAを編集する (詳細設定 - 登録Computeの選択)

以下では、 LBAを新規開始 (基本設定) する で作成したロードバランサーに、
別途Compute FLATタイプ上に作成した仮想サーバーを登録する方法について説明します。

注釈

仮想サーバーを作成する際に、Compute FLATタイプではセキュリティグループを選択しますが、 このセキュリティグループを仮想サーバー作成後に追加/削除することは出来ません。

そのため、LBA作成から仮想サーバー登録までの一般的な順序は以下となります。

  1. LBAの作成

  2. Compute 仮想サーバーの作成 (ソースセキュリティグループ、もしくはLBAからのアクセスを許可したセキュリティグループを付与)

    • セキュリティグループは複数の付与が可能です

      • 例えば、以下の2つを適用します

        • ソースセキュリティグループ

          • LBAからのアクセスを許可, LBAのリスナーに合わせルールは自動管理される
          • TCP Port 80/443へリスナを作成し、インターネットアクセスをLBA経由で許可する
        • お客様管理用セキュリティグループ

          • お客様の仮想サーバー管理用ルールとして利用
          • TCP Port 22などをお客様拠点CIDRからのみ許可する設定を追加しておく
    • 上記設定方法の詳細やセキュリティグループに係る仕様はCompute操作マニュアルを参照してください

  3. LBAへ仮想サーバーを登録

    • 登録されたComputeがInServiceになることを確認

手順

「編集(詳細設定)」ボタンをクリックします。

編集(詳細設定)

編集(詳細設定)

「Compute登録」をクリックします。

|brandname| LBA 機能概要

Compute登録

画面下部の「あなたのCompute (LBAに未登録のもの) 」から LBAに登録する仮想サーバーを選択し、「LBAに登録」ボタンをクリックします。

LBAへの登録

LBAへの登録

「OK」ボタンをクリックすると、仮想サーバーがLBAに登録されてます。
その後、「LBAに登録されたCompute」に登録された仮想サーバーが表示されます。
LBAへの登録完了

LBAへの登録完了

注釈

仮想サーバーのヘルスチェックで、仮想サーバーの状態を確認できます。
「InService」がHealthyなサーバーで「OutOfService」がUnHealthyなサーバーになります。

また、ヘルスチェック設定は事前に済ませて置く必要があります。

3.6. LBAを編集する (詳細設定 - Sorryページ)

Sorryページ をLBAに登録します。

Sorryページの登録

「Sorryページ登録」リンクをクリックします。

Sorryページの登録

Sorryページの登録

Sorryページの登録方法を選択する。

「他サーバにリダイレクトする場合」は「リダイレクト先」を入力します。
「SorryページをLBAに登録する場合」は「タイトル」および「本文」を入力します。

設定を確認して、「確定」ボタンをクリックします。
Sorryページ情報設定

Sorryページ情報設定

「OK」ボタンをクリックすると、設定変更されます。 設定変更後も画面は遷移しませんが、設定が反映されていることを確認してください。

注釈

SorryページをLBAに登録する場合, 登録するHTMLは W3C勧告 “HTML 4.01 Specification” に従い妥当 (Valid) なHTMLである必要があります。 事前に W3C Markup Validation Service などをご利用されることをおすすめします。

3.7. LBAを編集する (詳細設定 - その他設定)

その他設定 でLBAの詳細なチューニング項目を設定します。

注釈

お客様環境(Webサーバーの設定やお客様アプリケーションの設定)に合わせ、設定を行う必要があります。

タイムアウト設定の編集

LBAとクライアント(エンドユーザ)間、およびLBAと登録Compute間の通信における各種タイムアウト値を設定可能です。

「その他設定」リンクをクリックします。

その他設定

その他設定

各タイムアウト値を設定し、「確定」ボタンをクリックします。

タイムアウト設定の編集

タイムアウト設定の編集

「OK」ボタンをクリックすると、設定変更されます。

変更の反映
変更例

変更の反映

設定変更後も画面は遷移しません。

注釈

設定可能な各タイムアウト値は以下の通りです。

  • クライアント リクエスト受信待機時間

    • LBAがクライアントからのリクエストを受信して読み込みが完了するまでの待機時間の上限です。
    • デフォルト値: 60 [秒]
    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]
    • Compute レスポンス受信待機時間 と同一の値を設定することを推奨
  • Compute レスポンス受信待機時間

    • LBAが登録Computeからのレスポンスを受信して読み込みが完了するまでの待機時間の上限です。
    • デフォルト値: 60 [秒]
    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]
    • クライアント リクエスト受信待機時間 と同一の値を設定することを推奨
  • Compute 接続待機時間

    • 登録Computeに対するリクエスト送信やヘルスチェック実行時、LBAが登録Computeとの接続確立まで待機する時間の上限です。
    • デフォルト値: 10 [秒]
    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]
    • Compute 接続待機時間 がヘルスチェック設定のチェック間隔よりも大きい場合、ヘルスチェックのためのCompute接続確立のタイムアウトにはチェック間隔の値が採用されます。
  • トンネルモード接続待機時間

    • クライアントとComputeで双方向の接続が確立されている状態で通信が無くなった場合に、次の通信を待機する時間の上限です。
      本設定値は使用プロトコルがWebSocketに切り替わる等、コネクションがアップグレードされた場合に有効となります。したがって、WebSocket利用時に クライアント リクエスト受信待機時間 および Compute レスポンス受信待機時間 よりも長時間のタイムアウト値を使用したい場合に指定します。
    • デフォルト値: 空(指定無し)

    • 1-86400 の範囲で任意の値(整数)を設定可能 [単位:秒]

注釈

お客様アプリケーションにLBA経由でアクセスした際に504エラーが発生する際には、 Compute レスポンス受信待機時間 を増加するように調整して下さい。

注釈

各タイムアウト値には必要以上に長い時間を設定しないでください。 必要以上に長い時間を設定すると、LBAのパフォーマンスに影響する可能性があります。

3.8. LBAを削除する

LBAを削除します。

警告

削除後にたとえ同じLBA名のLBAを作成したとしても、同じ”DNS名”にはなりません。 削除された”DNS名”を指定し再度取得することは出来ません。

手順

削除するLBAを選択し、「削除」ボタンをクリックします。

LBAの削除

LBAの削除

「OK」ボタンをクリックすると、LBAが削除されます。

削除の実施

削除の実施

3.9. SSL証明書を登録する

SSL証明書を登録します。

参考

SSL終端機能については、下記を御覧ください

手順

注釈

SSL証明書はパスフレーズを設定していない (解除している) 証明書を登録する必要があります。 ご注意ください。

「SSL証明書登録」ボタンをクリックします。

SSL証明書登録

SSL証明書登録

「証明書名」「秘密鍵」「証明書」「中間CA証明書」を入力し、「登録」ボタンをクリックします。

証明書情報の入力と登録

証明書情報の入力と登録

注釈

SSL証明書の登録失敗時には以下をご確認下さい

  • 証明書チェーンは正しいか

  • 証明書はX.509 PEM形式か

    • 異なる場合、もしくは形式がわからない場合、ご利用のSSLサーバ証明書発行会社のナレッジベースやお問い合わせなどをご利用し、変換を行って下さい
  • コピーした証明書に余計な改行や文字が混入していないか

  • パスフレーズ付きの証明書でないか


一般的な変換方法は以下の通りです。

<秘密鍵> (${CertFileName}: 証明書ファイル名)

openssl rsa -in ${CertFileName} - outform PEM

<公開鍵> (${PubCertFileName}: 証明書ファイル名)

openssl x509 -inform PEM -in ${PubCertFileName}

<証明書チェーン> (${CertChainFileName}: 証明書チェーンファイル名)

openssl x509 -inform PEM -in ${CertChainFileName}

<証明書チェーンとは>

独自の証明書やテスト証明書などでチェーンが通常どおり認証出来ない場合に利用します。

中間証明書とルート証明書を空白行なしに結合したファイルを指します。
ルート証明書はオプショナルでの指定となります。
以下に例を示します。
-----BEGIN CERTIFICATE-----
${IntermediateCert1}
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
${IntermediateCert2}
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
${IntermediateCert3}
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
${RootCert}
-----END CERTIFICATE-----

注釈

“仕様 - SSL終端機能 “にある通り、1アカウントあたり100個までSSL証明書を登録可能です。 ただし、”仕様 - リスナー “の同一ポートに関する制限があるため、同じポートで異なるSSL証明書を 利用することは出来ません。

その場合、LBAを複数作成する必要があります。

3.10. LBAの複製を管理する

複製機能 を利用します。

LBAはトラフィックに合わせてオートスケールイン・アウトを実施しますが、あらかじめ莫大なトラフィックが見込まれる際はLBAの複製を行うことで、
スケールアウト/インに係る時間を短縮し、サービスの応答性を高めることが可能です。

手順

「複製管理」ボタンをクリックします。

複製管理

複製管理

「複製数」を指定し、「確定」ボタンをクリックします。

複製の実施

複製の実施

「複数セット数」が「0」から「1」になることを確認します。

複製の確認

複製の確認

注釈

複製の最大数はLBAあたり10個となります。

3.11. アクセス元IPログを記録する

Cloudn LBAではLBAそのものへのアクセスログは提供されませんが、 “X-Forwarded” ヘッダを利用することでアクセス元IPを登録Computeのアクセスログへ記録することが可能です。
(上記が未設定の場合、WebサーバーのログにはLBAのIPが記録されます。)

ここでは、アクセス元のIPを記録する方法について説明します。

警告

本章はWebサーバの設定など、サポート対象外の部分の記述を多く含みます。 必ずお客様ご自身で編集前設定のバックアップや設定項目の理解をされた上でのご実施をお願い致します。

注釈

登録Compute上のWebサーバーでSSLを終端している場合、アクセス元IPログを記録することは出来ません。

Linux利用の際の設定 (Apache)

例として、Linux (CentOS 6.5) でApacheを利用した場合の設定について示します。

httpd.confのバックアップ
$ cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
httpd.confの編集

Apacheの設定ファイルを編集します。

$ vim /etc/httpd/conf/httpd.conf

以下の一行をLogFormatディレクティブの記載してある箇所に追記します。

LogFormat "%{X-Forwarded-For}i"

Apacheに設定を反映します。

$ service httpd graceful

以上で完了です。

Windows利用の際の設定 (IIS)

以下の手順を実行ください。

  1. IIS 詳細ログ (64 ビット)のインストール (Microsoft Download Center - Download Details)

  2. 仮想サーバー再起動

  3. スタート⇒管理ツール⇒インターネットインフォメーションツール(IIS)より、「詳細ログ」を選択

  4. ログ記録フィールドの編集⇒フィールドの追加

    • フィールドID:X-Forwarded-For
    • カテゴリ:Default
    • ソースの種類:要求ヘッダー
    • ソース名:X-Forwarded-For
  5. ログ定義の編集⇒フィールドの選択⇒「X-Forwarded-For」をチェック

  6. 「適用」をクリック⇒「詳細ログを有効にする」をクリック

  7. 詳細ログが有効であることを確認して、IISを再起動

これによりデフォルトでは、「inetpub -> logs -> AdvancedLogs」配下にロギングされます

注釈

お客様仮想サーバー内部の設定に関しましてはサポートをいたしかねます。 ご了承下さい。

3.12. ログ設定(Logging連携)で取得可能なLBAログについて

ご用心

ログ提供機能は提供を終了いたしました。本ページは過去にログ提供機能によって取得したログの調査にご利用いただく目的で公開しております。

Cloudn LBAでは、LogForwarding によってお客様のロギングサーバーにLBAのログを転送することが可能です。

ここでは、ログ提供機能で取得可能なログメッセージについて説明します。

注釈

ログ提供機能の詳細な説明は LogForwarding および Spec-LogForwarding (技術仕様・制限)をご参照ください。

アクセスログ (HTTP/HTTPS)

LBAがクライアントからのリクエストを受け付けて登録Computeに転送し、登録Computeからのレスポンスをクライアントに転送したことを示すログです。
リスナー設定でLBAプロトコルにHTTPまたはHTTPSを指定した場合、LBAは以下のような形式のアクセスログが出力されます。
[${Log_Priority}] ${Client_IP}:${Client_Port} [${Accept_Date}] ${LBI_IP}:${LBA_Port} ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} ${Tq}/${Tw}/${Tc}/${Tr}/${Tt} ${Status_Code} ${Bytes_Read} ${Captured_Request_Cookie} ${Captured_Response_Cookie} ${Termination_State} ${ActConn}/${FEConn}/${BEConn}/${SrvConn}/${Retries} ${SrvQueue}/${BEQueue} "${HTTP_Request}"

(ex.)

[info] 10.0.1.2:54873 [19/Jun/2015:16:28:33.983] 192.168.10.10:80 192.168.10.10:80_instances/192.168.10.101:80 1/0/1126/2/1129 200 443 - - ---- 300/300/299/74/0 0/0 "GET /index.html HTTP/1.0"
Field Format Extract from the example above Description
1 [${Log_Priority}] [info] ログメッセージのプライオリティ
2 ${Client_IP}:${Client_Port} 10.0.1.2:54873 クライアントIPアドレスおよびポート番号
3 [${Accept_Date}] [19/Jun/2015:16:28:33.983] クライアント接続日時
4 ${LBI_IP}:${LBA_Port} 192.168.10.10:80 リクエストを受信したLBIのIPアドレスおよびLBAポート(リスナー設定)
5 ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} 192.168.10.10:80_instances/ 192.168.10.101:80 LBAの登録Computeの中で、本リクエストを転送したComputeの IPアドレスおよびComputeポート(リスナー設定)
6 ${Tq}/${Tw}/${Tc}/${Tr}/${Tt} 1/0/1126/2/1129 各種処理時間
7 ${Status_Code} 200 登録ComputeまたはLBAがクライアントに返却したHTTPステータスコード
8 ${Bytes_Read} 443 クライアントに返却されたレスポンスの総バイト数
9 ${Captured_Request_Cookie} - LBAでは使用しません
10 ${Captured_Response_Cookie} - LBAでは使用しません
11 ${Termination_State} ---- セッション終了時の状態
12 ${ActConn}/${FEConn}/${BEConn}/${SrvConn}/${Retries} 300/300/299/74/0 各種接続数
13 ${SrvQueue}/${BEQueue} 0/0 登録Compute1台および全体に対してLBIがキューしているリクエスト数
14 “${HTTP_Request}” “GET /index.html HTTP/1.0” クライアントから送信されたHTTPリクエスト
[${Log_Priority}]

ログメッセージのプライオリティです。 主に以下のようなプライオリティがあります。

  • [info]
  • [notice]
  • [warning]
  • [err]
  • [alert]

注釈

通常のアクセスログのプライオリティは [info] ですが、タイムアウト等が発生してリクエストやレスポンスの転送が 正常に終了しなかった場合はプライオリティが [err] のアクセスログが出力されます。

${Client_IP}:${Client_Port}

リクエストの送信元であるクライアントのIPアドレスおよびポート番号です。

注釈

LBAはSNATによってリクエストの送信元IPアドレスを書き換えて登録Computeに転送します。 ${Client_IP} で表示されるIPアドレスはLBAによってSNATされる前の送信元IPアドレスです。

[${Accept_Date}]
クライアントからのTCP接続を受け付けた日時です。
クライアントが実際にリクエストを送信したかどうかに関わらず、LBAがTCP接続を受け付けた時点の日時が記録されます。

記録される日時のタイムゾーンは 日本標準時(JST) です。

注釈

LBAのログに記録される日時は JST ですが、Logging(ロギングサーバー)がログを受信したタイミングで ” @timestamp “フィールドに付与する日時のタイムゾーンは UTC ですのでご注意ください。 ただし、Kibana はデフォルトでタイムゾーンをブラウザの設定から取得しますので、 グラフの生成や表示は JST をご利用いただけます。

${LBI_IP}:${LBA_Port}
クライアントからの接続を受け付けた LBI のIPアドレスおよびポート番号です。
ポート番号は基本的にいずれかの リスナー に設定されたLBAポートが記載されます。
また、LBAプロトコルがHTTPSの場合は末尾に with_ssl と記載されます。

LBAは複数のLBIから構成されるため、同一のLBAのログであっても異なるLBIのIPアドレスが記録される場合があります。
具体的には、下記のようなケースでは複数のLBIが存在します。
  • LBAで複数Zoneをまたいだ登録Computeに負荷分散しているとき
  • 複製機能によってLBAの複製セットを作成しているとき
  • LBAに一定以上の負荷がかかり、自動スケールアウトが発動しているとき

注釈

LBIのポート番号が 60001 となっている場合:
これはLBI同士のZone間転送によって出力されたログです。
クッキー (cookie) セッション維持機能を利用している場合において、セッション維持のためにZoneAの登録Computeに振り分けるべきリクエストをZoneBのLBIが受け付けてしまった場合、ZoneBのLBIからZoneAのLBIにポート番号 60001 を用いてリクエストを転送します。

注釈

LBAの複数Zone利用や複製を作成していない状態にも関わらず、LBIのIPアドレスがログに複数出力されていた場合、 自動スケールアウトによってLBIが作成されたと判断できます。

注釈

上記の契機によるLBIの増減に従って、ログに記録されるLBIのIPアドレスも増減します。 さらに、LBIのIPアドレスは予告無く変化する場合がありますので、ログの解析にあたってはご注意ください。

${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port}
LBAの登録Computeの中で、実際にリクエストを振り分けたComputeのIPアドレスおよびポート番号です。
ポート番号は基本的にいずれかの リスナー に設定されたLBAポートが記載されます。

登録Computeが存在しない場合や、全ての登録Computeがダウン状態もしくはヘルスチェックに失敗しており負荷分散先が存在しない場合、ComputeのIPアドレスとポート番号のかわりに <NOSRV> と表示されます。
${Tq}/${Tw}/${Tc}/${Tr}/${Tt}
クライアントからのリクエストおよび登録Computeからのレスポンスに関わる各種処理時間です。
${Tq}
クライアントから完全なHTTPリクエスト(ヘッダ)を受信するまでにLBAが待機した時間です。(単位:[ms])

LBAが完全なHTTPリクエストを受信するまでにクライアントがコネクションをクローズした場合、あるいはタイムアウト等によってコネクションが破棄された場合、${Tq}の値は -1 となります。
一般的にHTTPリクエストは単独のパケットで完結するため、${Tq}の値は小さくなります。
${Tq}の値が大きく増加した場合、クライアントとLBA間のネットワーク混雑(障害)などが疑われます。

注釈

${Tq}の値が 3000 程度に増加した場合、クライアントとLBAの間でパケットロスが発生したことが考えられます。遠隔地から大きなサイズのリクエストが送信された場合や突発的なトラフィック増が発生した場合などに、パケットロスが発生する確率が上昇します。

注釈

${Tq}と関連するタイムアウト値は クライアント リクエスト受信待機時間 です。

${Tw}
リクエストが登録Computeに振り分けられる前に、LBAでキューされていた時間です。(単位:[ms])

禁止あるいは無効化されているリクエストであった、あるいは負荷分散先の登録Computeが全てダウンしていた等の理由でリクエストが処理できず、キューに達するまでに破棄された場合、${Tw}の値は -1 となる場合があります。

注釈

LBAの内部仕様により、一部のリクエストは禁止あるいは無効化されている場合があります。 この内部仕様は公開されませんが、通常LBAをご利用いただく際には問題ありません。

${Tc}
LBAが最終的にリクエストを転送した登録Computeとの接続確立(ハンドシェイク)にかかった時間です。(単位:[ms])

接続のリトライが発生した場合、その時間も含みます。
登録Computeとの接続が確立できなかった場合、${Tc}の値は -1 となります。

注釈

登録Computeとの接続が確立できないケースとしては、登録Computeが接続を拒否した場合や接続がタイムアウトした場合などがあります。

注釈

${Tc}の値が 3000 程度に増加した場合、LBAと登録Compute間の接続確立時にパケットロスが発生したことが考えられます。遠隔地から大きなサイズのリクエストが送信された場合や突発的なトラフィック増が発生した場合などに、パケットロスが発生する確率が上昇します。

注釈

${Tc}と関連するタイムアウト値は Compute 接続待機時間 です。 ${Tc}が頻繁に -1 の値をとる場合は、タイムアウト値の設定が短すぎる可能性があります。

${Tr}
LBAと登録Computeの接続確立後、登録Computeから完全なHTTPレスポンス(ヘッダ)を受信するまでにLBAが待機した時間です。(単位:[ms])

タイムアウト等によってコネクションが破棄され、完全なHTTPレスポンスのヘッダ情報が取得できなかった場合、${Tr}の値は -1 となります。
${Tr}の値は、登録Computeでリクエストを処理するためにかかった時間と概ね一致しますが、リクエストがPOSTメソッドであった場合などは当てはまりません。
GETメソッドのリクエストにおいて${Tr}の値が大きく増加した場合、登録Computeの高負荷状態などが疑われます。

注釈

${Tr}の値が 3000 程度に増加した場合、LBAと登録Computeの間でパケットロスが発生したことが考えられます。遠隔地から大きなサイズのリクエストが送信された場合や突発的なトラフィック増が発生した場合などに、パケットロスが発生する確率が上昇します。

注釈

${Tr}と関連するタイムアウト値は Compute レスポンス受信待機時間 です。 ${Tr}が頻繁に -1 の値をとる場合は、タイムアウト値の設定が短すぎる可能性があります。

${Tt}
LBAがクライアントからのリクエストを受け付けてから、登録Computeからのレスポンスをクライアントに転送完了し、コネクションをクローズするまでにかかった総時間です。(単位:[ms])

LBAからクライアントへのレスポンスデータ転送にかかった時間を${Td}とすると、${Tt}の値は以下のようになります。
(ただし、${Tq}, ${Tw}, ${Tc}, ${Tr} の値がいずれも -1 ではないこと)
${Tt} = ${Tq} + ${Tw} + ${Tc} + ${Tr} + ${Td}

注釈

レスポンスデータの転送時間を考慮したとしても${Tt}の値が大きい場合、クライアントおよび登録Coumputeの双方がkeep-aliveモードの利用によってコネクションをクローズしないことが原因の可能性があります。

注釈

トラブルの解析において、${Tt}が その他設定 にて設定した各タイムアウト値のいずれかに近い値である場合、当該タイムアウトによってコネクションが破棄されている可能性があります。

${Status_Code}
クライアントに返却したHTTPステータスコードです。
通常は登録Computeからのレスポンスによって規定されますが、登録Computeからレスポンスが取得できなかった等の理由でLBAがクライアントにレスポンスを返す場合は、LBAによって規定されます。
${Bytes_Read}
ログが出力された時点でクライアントに送信したレスポンスの総byte数です。
${Termination_State}
セッションが終了した時点におけるセッション状態に関する情報です。

例えば、クライアント側と登録Compute側のどちらが契機となってセッションが終了されたのか、セッションが終了した理由は何であるのか、といったセッション終了情報が出力されます。
また、クッキー (cookie) セッション維持機能の動作に関する情報も出力されます。
セッション終了情報
${Termination_State}はハイフン(-)またはアルファベット4文字のフラグによって表されます。
フラグの先頭2文字はセッション終了情報(どちらがセッションを終了したのか、およびその理由)を表します。

以下の表に、フラグの先頭2文字が示す情報を記載します。
Flags Meaning Possible reasons
– – 正常終了  
CC 登録Computeとの接続が確立される前にクライアントがコネクションを破棄
– ダウンした直後で振り分け対象から除外されていない登録Computeに対してLBIが接続を試行し、 LBIが長時間待機している最中にクライアントがコネクションを破棄した
CD クライアントがデータ転送中に予期しない理由によってコネクションを破棄
– クライアントのブラウザがクラッシュ
– クライアントとLBIの間にあるいずれかの装置によってコネクションが切断された
– クライアントとLBIとの間において何らかのネットワークやルーティングの問題が存在する
– クライアントと登録Compute間のkeep-alive状態のセッションでクライアントからセッションを終了した
cD クライアントが クライアント リクエスト受信待機時間 内にACKやデータを送信しなかった
– クライアント側のネットワーク障害
– クライアントがクリーンにコネクションを切断しなかった
CH 登録Computeからのレスポンス待機中にクライアントがコネクションを破棄
– 登録Computeがレスポンスを返却するまでに時間がかかりすぎたため、クライアントが処理を中断した
cH クライアントからのPOSTメソッドによるリクエストの待機中に クライアント リクエスト受信待機時間 が経過したためにLBIがコネクションを破棄
– PPPoEなどにおいてTCPのMSSに大きすぎる値が設定されており、フルサイズのパケットが送信できなかった
クライアント リクエスト受信待機時間Compute レスポンス受信待機時間 よりも小さな値が設定されている場合に、 登録Computeがレスポンスを返すまでに時間がかかっている
CQ リクエストがキューされている状態でクライアントがコネクションを破棄
– 全ての登録Computeがリクエストを処理しきれず飽和状態である
– 振り分け先として選択された登録Computeがリクエストの処理に長時間を要している
CR クライアントが完全なHTTPリクエストを送信する前にコネクションを破棄
– telnet等で手動によるHTTPリクエスト中に早期にコネクションが破棄された(${Status_Code}=400)
cR クライアントが完全なHTTPリクエストを送信する前に クライアント リクエスト受信待機時間 が経過したためにLBIがコネクションを破棄
– PPPoEなどにおいてTCPのMSSに大きすぎる値が設定されており、フルサイズのパケットが送信できなかった
– telnet等で手動によるHTTPリクエストにてリクエストを送信するのが遅すぎた、もしくは リクエストの最後に空行を送信しなかった
– クライアントのブラウザでブラウジング速度を高速化するために pre-connect 機能が 利用されていたが、クライアント リクエスト受信待機時間 が経過するまでにデータが送信されなかった(${Status_Code}=408)
LR リクエストがLBI内部で処理された
– リクエストがリダイレクトであった
SC 登録ComputeがLBIからのTCP接続を明示的に拒否した
– 登録ComputeのセキュリティグループやACL等によって接続が拒否され、LBIがTCP/RSTやICMPメッセージを受信した
(${Status_Code}=502 or 503)
sC LBIから登録Computeへの接続が完了する前に Compute 接続待機時間 が経過したためにLBIがコネクションを破棄
– ダウンした直後で振り分け対象から除外されていない登録Computeに対してLBIが接続を試行し、 LBIが長時間待機している最中に Compute 接続待機時間 が経過した
SD データ転送中に登録Computeとのコネクションがエラーによって終了
– 登録Computeがクラッシュした等で登録ComputeからTCP/RSTが送信された
sD LBIが登録Computeからのデータ転送を待機中に、登録Computeが Compute レスポンス受信待機時間 内にACKやデータを送信しなかった
– 登録Computeの前段のL4ネットワーク装置のタイムアウトが小さすぎるため、クライアントと登録Computeとの keep-alive状態のセッションが破棄された
SH 登録Computeが完全なHTTPレスポンスヘッダを送信する前にコネクションを破棄
– 登録Computeがリクエスト処理中にクラッシュした
– 登録Compute上のリクエストを処理するアプリケーションのバグ
sH 登録Computeが完全なHTTPレスポンスヘッダを送信する前に Compute レスポンス受信待機時間 が経過したためにLBIがコネクションを破棄
– 登録Computeまたは登録Computeが利用するDBが高負荷状態となり、リクエストの処理が遅延した
– 登録Computeが必要とするリクエストの処理時間に対して Compute レスポンス受信待機時間 が小さすぎる
sQ 長時間キューされていたリクエストをタイムアウトによってLBIが破棄
Compute 接続待機時間 の値が大きすぎるため、新しい接続スロットが解放されない
– 登録ComputeのI/Oまたは登録Computeが利用するDBの高負荷
– DDoS攻撃等によるコネクションの飽和
PC LBIが登録Computeとの接続確立を拒否した
– 登録Computeへの接続試行中にLBIが許容する最大同時接続数に達した
PD LBIが登録Computeから完全なHTTPレスポンスヘッダを受信した後、 登録Computeからの不正なデータ転送(メッセージ)を遮断した
– 登録Computeがクライアントに対して無効なメッセージ(不正なフォーマットやエンコード)を送信した
– 登録Computeが2GB以上のチャンクデータを送信しようとした
PH LBIが登録Computeからのレスポンスを遮断した
– 登録ComputeからのHTTPレスポンスヘッダがSyntaxエラー等で無効あるいは不完全であった(${Status_Code}=502)
PR LBIがクライアントからのHTTPリクエストを遮断した
– クライアントからのHTTPリクエストがSyntaxエラー等で無効あるいは不完全であった(${Status_Code}=400)
– クライアントがLBAの内部仕様で禁止されているリクエストを送信した(${Status_Code}=403)
RC LBIのリソースが枯渇し、登録Computeとの接続確立が不可能であった
– 高負荷によってLBI内部のメモリ、接続スロット等のリソースが不足した
${ActConn}/${FEConn}/${BEConn}/${SrvConn}/${Retries}
ログが出力された時点におけるLBIの各種接続数です。
${ActConn}
ログが出力された時点でLBIが処理中であった同時接続数です。
${FEConn}
ログが出力された時点におけるクライアントとLBIとの間の同時接続数です。

注釈

${FEConn}の値が急激に増加した場合、高負荷や混雑によって登録Compute側のリクエスト処理が詰まっているケースやDDoS攻撃などの可能性があります。

${BEConn}
ログが出力された時点におけるLBIで振り分け処理済みの同時接続数です。

この接続数には登録Computeに対するアクティブな接続およびキューによって保留されている接続を含みます。

注釈

${BEConn}の値が急激に増加した場合、高負荷や混雑によって登録Compute側のリクエスト処理が詰まっているケースやDDoS攻撃などの可能性があります。

${SrvConn}
ログが出力された時点における、リクエストが振り分けられた登録ComputeとLBIとの間のアクティブな同時接続数です。

注釈

ある特定の登録Computeに振り分けられたリクエストのみ${SrvConn}の値が大きい場合、当該登録Computeにリクエスト処理の遅延を引き起こすようなトラブルが発生している可能性があります。

${Retries}
LBIから登録Computeに接続する際、LBIが接続をリトライした回数です。

接続の試行と同時に登録Computeがダウンする等の状況を除き、通常は 0 となります。

注釈

頻繁にリトライが発生し${Retries}が0より大きい値となる場合、LBIと登録Computeとの間でネットワーク障害が発生している可能性があります。

${SrvQueue}/${BEQueue}
登録Compute1台および全体に対してLBIがキューしているリクエスト数です。

LBIは内部のパラメータとして登録Compute1台あたりの最大接続数、それらを合計した登録Compute全体での最大接続数の両方を持ちます。これらの最大接続数に達した状態でリクエストを受け付けた場合、当該リクエストは接続スロットが解放されるまでLBIでキューされます。
${SrvQueue}は登録Compute1台あたりの最大接続数に達したためにキューされているリクエストの数を表します。
${BEQueue}は登録Compute全体に対して設定された最大接続数に達したためにキューされているリクエストの数を表します。

注釈

最大接続数に関するパラメータはLBIの性能によって設計されている内部パラメータであり、お客様がチューニングすることはできません。

“${HTTP_Request}”
クライアントから受信したHTTPリクエストです。 HTTPリクエストにはメソッド情報やHTTPバージョン情報が含まれます。
アクセスログに付与されるタグ
アクセスログには以下の通りの規則でタグが付与されます。
タグはログ(JSON形式)中の” tag “フィールドに記載されます。
タグはロギングサーバーの Kibana 上で確認することができます。
  • "cloudn.lba.${LBA_Name}.access.${LBI_IP}"

    • ${LBA_Name}: LBA名を表します
    • ${LBI_IP}: ログが出力されたLBIのIPアドレスを表します

ヘルスチェックログ

LBAから登録Computeに対するヘルスチェックの結果を記録したログです
以下の契機で記録されます
  • ヘルスチェックが成功していた状態からヘルスチェックが失敗した場合

  • ヘルスチェックが失敗していた状態からヘルスチェックが成功した場合

  • 下記の契機で初期ヘルスチェックが実行された場合
    • LBA編集(詳細設定)変更時
    • LBA複製セット数変更時
    • LBA自動スケールアウト/イン発動時
ヘルスチェック失敗時のログ
[${Date}] [${Log_Priority}] Health check for server ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} failed, reason: ${Reason}, check duration: ${Check_Duration}, status: ${Count} ${Status}.

(ex.)

[Jun 29 11:58:27] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 failed, reason: Layer4 timeout, check duration: 10001ms, status: 1/2 UP.
Field Format Extract from the example above Description
1 [${Date}] [Jun 29 11:58:27] イベント発生日時(JST)
2 [${Log_Priority}] [notice] ログメッセージのプライオリティ
3 ${LBI_IP}:${LBA_Port}_instances/ ${Compute_IP}:${Compute_Port} failed, 192.168.10.10:80_instances/ 192.168.10.101:80 failed, LBAの登録Computeの中で、ヘルスチェックが失敗した登録Computeの IPアドレスおよびComputeポート(リスナー設定)
4 ${Reason} Layer4 timeout ヘルスチェック失敗理由
5 ${Check_Duration} 10001ms ヘルスチェックにかかった時間
6 ${Count} 1/2 ヘルスチェック連続成功回数/死活状態を変更する判定回数
7 ${Status} UP ヘルスチェック完了時の登録Computeの死活状態(“UP” or “DOWN”)
ヘルスチェック失敗時の ${Count} と ${Status}
ヘルスチェック連続成功回数 / 死活状態を変更する判定回数 を表します。
以下にヘルスチェック成功時に${Count}および${Status}が変化する例を示します。

例: 仮想サーバー (登録Compute) のヘルスチェック 設定で、

  • 失敗と判断する連続回数: 2回
  • 成功と判断する連続回数: 3回

と設定されている場合において、

  • 登録ComputeがUP状態(${Status} = UP)のとき
    • ヘルスチェックが成功している場合、${Count}は 2/2
    • ヘルスチェックが1回失敗した場合、${Count}は 1/2
    • ヘルスチェックが2回失敗した場合、${Count}は 0/3 , ${Status}が DOWN に遷移
登録ComputeのDOWN判定ログ

ヘルスチェック失敗後、登録ComputeがDOWN(OutOfService)判定され、振り分け対象から除外されたときに出力されるログです。

[${Date}] [${Log_Priority}] Server ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} is DOWN. ${Healthy_Compute} active and ${Backup_LBI} backup servers left. ${Act_Sessions} sessions active, ${Requeued} requeued, ${Remaining} remaining in queue.

(ex.)

[Jun 29 11:58:57] [alert] Server 192.168.10.10:80_instances/192.168.10.101:80 is DOWN. 2 active and 1 backup servers left. 100 sessions active, 0 requeued, 0 remaining in queue.
Field Format Extract from the example above Description
1 [${Date}] [Jun 29 11:58:57] イベント発生日時(JST)
2 [${Log_Priority}] [alert] ログメッセージのプライオリティ(DOWN判定は alert)
3 ${LBI_IP}:${LBA_Port}_instances/ ${Compute_IP}:${Compute_Port} is DOWN. 192.168.10.10:80_instances/ 192.168.10.101:80 is DOWN. LBAの登録Computeの中で、DOWN状態となった登録Computeの IPアドレスおよびComputeポート(リスナー設定)
4 ${Healthy_Compute} active and 2 active and 同一ゾーンでUP(InService)状態の登録Computeの数
5 ${Backup_LBI} backup servers left. 1 backup servers left. 同一ゾーンのComputeが全てDOWN状態となった場合にリクエストの振り分け先となる他ゾーンのLBI
6 ${Act_Sessions} sessions active, 100 sessions active, DOWNした登録Computeで処理しようとしていたセッションのうち、他の登録Computeに振り分けられて確立されたセッション数
7 ${Requeued} requeued, 0 requeued 登録ComputeがDOWNしたことでキューに再振り分けされたセッション数
8 ${Remaining} remaining in queue. 0 remaining in queue. LBIのキューに残っているセッション数

注釈

本ログは、access タグおよび error タグが付与された2つのログが出力されます。

ヘルスチェック失敗時〜登録ComputeのDOWN判定ログの例

ヘルスチェックが失敗し、登録ComputeがDOWN判定されるまでの一連のログについて、出力例および読み方を以下に記載します。

[Jun 29 11:58:27] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 failed, reason: Layer4 timeout, check duration: 10001ms, status: 1/2 UP.
# → 登録Computeのヘルスチェック失敗1回目。登録ComputeをDOWNと判断するヘルスチェック失敗回数は2回であるため、まだ登録ComputeはUP状態のままであり、振り分け対象となっている。
#    また、失敗した原因はヘルスチェックのためのTCP接続が確立できないままCompute接続待機時間(10s)を超過し、タイムアウトしたことが記載されている。

[Jun 29 11:58:57] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 failed, reason: Layer4 timeout, check duration: 10001ms, status: 0/3 DOWN.
# → 30秒後、登録Computeのヘルスチェック失敗2回目。ヘルスチェックがDOWNと判断するヘルスチェック失敗回数は2回であるため、登録ComputeはDOWN状態に遷移し、振り分け対象から除外された。
#    再び登録ComputeがUPと判断されるためには、ヘルスチェックに3回成功する必要がある。

[Jun 29 11:58:57] [alert] Server 192.168.10.10:80_instances/192.168.10.101:80 is DOWN. 2 active and 1 backup servers left. 100 sessions active, 0 requeued, 0 remaining in queue.
# → ログプライオリティ[alert]にて、登録ComputeがDOWN状態と判断されて振り分け対象から除外されたことを出力している。
#    さらに同一ゾーンにて他に2つの登録ComputeがUP(InService)状態で稼働しており、それらが全てDOWN状態となった場合の振り分け先となる他ゾーンのLBIが1つ存在していることを示している。
#    DOWNした登録Computeで処理しようとしていたセッションは、100セッションがアクティブな状態で他の登録Computeに振り分けられており、LBIにてキューされたままの状態のものは存在しない。
ヘルスチェック成功時のログ
[${Date}] [${Log_Priority}] Health check for server ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} succeeded, reason: ${Reason}, check duration: ${Check_Duration}, status: ${Count} ${Status}.

(ex.)

[Jun 29 11:54:57] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 1/3 DOWN.
Field Format Extract from the example above Description
1 [${Date}] [Jun 29 11:54:57] イベント発生日時(JST)
2 [${Log_Priority}] [notice] ログメッセージのプライオリティ
3 ${LBI_IP}:${LBA_Port}_instances/ ${Compute_IP}:${Compute_Port} succeeded, 192.168.10.10:80_instances/ 192.168.10.101:80 succeeded, LBAの登録Computeの中で、ヘルスチェックが成功した登録Computeの IPアドレスおよびComputeポート(リスナー設定)
4 ${Reason} Layer4 check passed ヘルスチェック成功理由
5 ${Check_Duration} 0ms ヘルスチェックにかかった時間
6 ${Count} 1/3 ヘルスチェック連続成功回数/死活状態を変更する判定回数
7 ${Status} DOWN ヘルスチェック完了時の登録Computeの死活状態(“UP” or “DOWN”)
ヘルスチェック成功時の ${Count} と ${Status}
ヘルスチェック連続成功回数 / 死活状態を変更する判定回数 を表します。
以下にヘルスチェック成功時に${Count}および${Status}が変化する例を示します。

例: 仮想サーバー (登録Compute) のヘルスチェック 設定で、

  • 失敗と判断する連続回数: 2回
  • 成功と判断する連続回数: 3回

と設定されている場合において、

  • 登録ComputeがDOWN状態(${Status} = DOWN)のとき
    • ヘルスチェックが失敗している場合、${Count}は 0/3
    • ヘルスチェックが1回成功した場合、${Count}は 1/3
    • ヘルスチェックが2回成功した場合、${Count}は 2/3
    • ヘルスチェックが3回成功した場合、${Count}は 2/2 , ${Status}が UP に遷移
登録ComputeのUP判定ログ

ヘルスチェック失敗後、登録ComputeがUP(InService)判定され、振り分け対象に復帰したときに出力されるログです。

[${Date}] [${Log_Priority}] Server ${LBI_IP}:${LBA_Port}_instances/${Compute_IP}:${Compute_Port} is UP. ${Healthy_Compute} active and ${Backup_LBI} backup servers online. ${Requeued} sessions requeued, ${Remaining} total in queue.

(ex.)

[notice] Server 192.168.10.10:80_instances/192.168.10.101:80 is UP. 3 active and 1 backup servers online. 0 sessions requeued, 0 total in queue.
Field Format Extract from the example above Description
1 [${Log_Priority}] [notice] ログメッセージのプライオリティ(UP判定は notice)
2 ${LBI_IP}:${LBA_Port}_instances/ ${Compute_IP}:${Compute_Port} is UP. 192.168.10.10:80_instances/ 192.168.10.101:80 is UP. LBAの登録Computeの中で、UP状態となった登録Computeの IPアドレスおよびComputeポート(リスナー設定)
3 ${Healthy_Compute} active and 3 active and 同一ゾーンでUP(InService)状態の登録Computeの合計数(今回UP判定されたものを含む)
4 ${Backup_LBI} backup servers online. 1 backup servers online. 同一ゾーンのComputeが全てDOWN状態となった場合にリクエストの振り分け先となる他ゾーンのLBI
5 ${Requeued} sessions requeued, 0 sessions requeued, 登録ComputeがUPしたことでキューに再振り分けされたセッション数
6 ${Remaining} total in queue. 0 total in queue. LBIのキューに存在するセッション数

注釈

本ログは、access タグが付与されたログが出力されます。

ヘルスチェック成功時〜登録ComputeのUP判定ログの例

ヘルスチェックが成功し、登録ComputeがUP判定されるまでの一連のログについて、出力例および読み方を以下に記載します。

[Jun 29 11:54:57] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 1/3 DOWN.
# → 登録Computeのヘルスチェック成功1回目。登録ComputeをUPと判断するヘルスチェック成功回数は3回であるため、まだ登録ComputeはDOWN状態のままであり、振り分け対象ではない。
#    また、成功した理由としてヘルスチェックのためのTCP接続が確立できたことが記載されている。

[Jun 29 11:55:17] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 2/3 DOWN.
# → 登録Computeのヘルスチェック成功2回目。登録ComputeをUPと判断するヘルスチェック成功回数は3回であるため、まだ登録ComputeはDOWN状態のままであり、振り分け対象ではない。

[Jun 29 11:55:37] [notice] Health check for server 192.168.10.10:80_instances/192.168.10.101:80 succeeded, reason: Layer4 check passed, check duration: 0ms, status: 2/2 UP.
# → 登録Computeのヘルスチェック成功3回目。登録ComputeをUPと判断するヘルスチェック成功回数は3回であるため、登録ComputeはUP状態に遷移し、振り分け対象に復帰した。
#    再び登録ComputeがDOWNと判断されるのは、ヘルスチェックに2回連続で失敗した場合である。

[notice] Server 192.168.10.10:80_instances/192.168.10.101:80 is UP. 3 active and 1 backup servers online. 0 sessions requeued, 0 total in queue.
# → ログプライオリティ[notice]にて、登録ComputeがUP状態と判断されて振り分け対象に復帰したことを出力している。
#    さらに同一ゾーンにて合計3つの登録ComputeがUP(InService)状態で稼働しており、それらが全てDOWN状態となった場合の振り分け先となる他ゾーンのLBIが1つ存在していることを示している。
#    登録ComputeがUP状態となったことでキューに再振り分けされたセッションは存在せず、LBIにてキューされたままの状態のセッションも存在しない。
ヘルスチェックログに付与されるタグ
ヘルスチェックログには以下の通りの規則でタグが付与されます。
タグはログ(JSON形式)中の”tag”フィールドに記載されます。
タグはロギングサーバーの Kibana 上で確認することができます。
  • "cloudn.lba.${LBA_Name}.healthcheck.${LBI_IP}"

    • ${LBA_Name}: LBA名を表します
    • ${LBI_IP}: ログが出力されたLBIのIPアドレスを表します

エラーログ

アクセスログとヘルスチェックログのうち、ログメッセージのプライオリティがエラー([err])以上のものです。
エラーログは、アクセスログおよびヘルスチェックログメッセージに加えて、先頭にタイムスタンプが付与されております。
またアクセスログ、ヘルスチェックログとは別に重複して出力されます。例えば、プライオリティがエラーのアクセスログが出力された場合、 accessタグが付与されたログとerrorタグが付与されたログの両方がロギングサーバーに転送されます。
エラーログの契機
エラーログが出力される代表的な契機を下記に示します。
  • SSLハンドシェイク失敗

    • 何らかの原因でクライアントとLBAとの間のSSLハンドシェイクが失敗した場合、以下のようなエラーログが出力されます。
    [Jun 21 16:04:03] [err] 10.0.1.2:39641 [21/Jun/2015:16:04:03.695] 192.168.10.10:443_with_ssl/1: SSL handshake failure
    
  • 登録Computeからのレスポンスがタイムアウトした場合

  • 登録Computeがヘルスチェックに失敗し、負荷分散対象から除外された場合

エラーログに付与されるタグ
エラーログには以下の通りの規則でタグが付与されます。
タグはログ(JSON形式)中の”tag”フィールドに記載されます。
タグはロギングサーバーの Kibana 上で確認することができます。
  • "cloudn.lba.${LBA_Name}.error.${LBI_IP}"

    • ${LBA_Name}: LBA名を表します
    • ${LBI_IP}: ログが出力されたLBIのIPアドレスを表します

その他のログ

[notice] Proxy stats started.
[notice] Proxy 192.168.10.10:80 started.
[notice] Proxy 192.168.10.10:80_instances started.
[notice] Proxy 192.168.10.10:60001 started.
[notice] Proxy 192.168.10.10:60001_instances started.
[notice] Proxy 192.168.10.10:443_with_ssl started.
[notice] Proxy 192.168.10.10:443_with_ssl_instances started.
[notice] Proxy 192.168.10.10:60002_with_ssl started.
[notice] Proxy 192.168.10.10:60002_with_ssl_instances started.
[warning] Stopping proxy stats in 0 ms.
[warning] Stopping proxy 192.168.10.10:80 in 0 ms.
[warning] Stopping backend 192.168.10.10:80_instances in 0 ms.
[warning] Stopping proxy 192.168.10.10:60001 in 0 ms.
[warning] Stopping backend 192.168.10.10:60001_instances in 0 ms.
[warning] Stopping proxy 192.168.10.10:443_with_ssl in 0 ms.
[warning] Stopping backend 192.168.10.10:443_with_ssl_instances in 0 ms.
[warning] Stopping proxy 192.168.10.10:60002_with_ssl in 0 ms.
[warning] Stopping backend 192.168.10.10:60002_with_ssl_instances in 0 ms.
[warning] Proxy stats stopped (FE: 34542 conns, BE: 0 conns).
[warning] Proxy 192.168.10.10:80 stopped (FE: 917 conns, BE: 0 conns).

上記の一連のログはLBAの設定変更時などにおいて、設定を反映するためにLBAインスタンス内部の負荷分散ソフトウェアのリロード処理が実施された場合に出力されます。 主に以下の契機で出力されます。

  • LBA新規作成時

  • LBA編集(詳細設定)変更時

  • LBA複製セット数変更時

  • LBA自動スケールアウト/イン発動時

    注釈

    上記のログはほぼ同時に出力されますが、内部動作としては新しい設定が反映されたプロセスを起動した後に古いプロセスを終了することでリロード(graceful restart)処理を実現しております。 リロード処理によってLBAが処理中のセッションが強制的に切断されることはございません。