はじめに
タダです。
AWS認定資格の試験勉強のためにELBの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※本記事では、Classic Load Balancerの情報をまとめていきます。
※随時アップデートがあれば更新していきます。
サービス概要
ELBは2つのタイプに分けられる
- Classic Load Balancer
- アプリまたはネットワークレベルのいずれかの情報に基づいてルーティングする
- 複数のEC2インスタンス間でシンプルなトラフィックのルーティングに適する
- Application Load Balancer
- リクエストパスまたはホストベースでルーティングする
- 複数のサービスにルーティングしたり、同じEC2インスタンスの複数のポート間で負荷分散するのに適する
特徴
- スケーラブル
- ELB自体も負荷に応じてスケールアウト
- 可用性向上
- 複数AZへの振り分け、インスタンスのヘルスチェック
- マネージドサービス
- ルーティング方式
- 基本はラウンドロビン
- コネクションタイムアウト
- クライアントからの無通信状態が続くと接続を自動で切断する(デフォルト60秒)
- ELB自体のスケーリング
- じんわりとしたトラフィックの増加には対応できる
- 逆に急激なトラフィックの増加にはスケーリング対応できないため、事前にPre-Warming(暖機運転)の申請をAWSに行う
- じんわりとしたトラフィックの増加には対応できる
- スティッキーセッション
- 同じユーザーから来たリクエストをすべて同じEC2に送信
- アプリケーションでのセッション情報、一時ファイルなどをEC2が保持する構成の場合に必要
- HTTP/HTTPSでのみ利用可能
- EC2の増減を柔軟に管理できるようセッション情報は別のDBやキャッシュサーバに保持させるのが好ましい
- Connection Draining
- EC2インスタンスとELB間の登録解除、ヘルスチェック失敗した時にルーティングを中止して、処理中のリクエスト終わるまで一定期間まつ
- X-Forwarded-For
- HTTPまたはHTTPSロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立つ
- Proxy Protocol
- ELBはProxy Protocolバージョン1をサポートしている
- Proxy Protocolヘッダーはバックエンド接続用にTCPを使う場合、クライアントのIPアドレスを識別するのに役立つ
- 有効化する場合の前提条件は以下の通り
- ELBの背後にプロキシサーバがいないこと
- インスタンスでProxy Protocol情報を処理できるか確認する
- リスナー設定でProxy Protocloがサポートされているかを確認する
- 他のサービスとの連携機能
- AutoScaling
- Route53
- CloudFormation
- OpsWorks
- Elastic Beanstalk
- CloudWatch
- EC2
- S3など
サポートプロトコル
Classic Load Balancerのサポートプロトコルは、以下の通り
- HTTP
- HTTPS
- SSL(セキュアTCP)
- TCP
ロードバランサーのタイプ
ロードバランサーのタイプとして、外向けロードバランサーと内向けロードバランサーがある
- 外向けロードバランサー : インターネットからアクセスできるELB
- 内向けロードバランサー : VPC内やオンプレ環境からのみアクセスできるELB
モニタリング
ELBの監視を行う場合は以下の方法がある
- CloudWatchメトリクス
- ELBのアクセスログ
- ELBへのリクエストの詳細情報をキャプチャしているので、確認する
- CloudTrailログ
トラブルシューティング
よくELBのトラブルシューティングでHTTPステータスから設定不足を確認することがあるので、ドキュメントの情報をまとめる
- HTTP 400: BAD_REQUEST
- 原因:クライアントが誤ったリクエストをしてしまったため発生
- 解決策:直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャする
- HTTP 405: METHOD_NOT_ALLOWED
- 原因:リクエストヘッダー内のメソッドの長さが127文字を超える
- 解決策:メソッドの長さを確認する
- HTTP 408: Request Timeout
- 原因:指定されたコンテンツのサイズが実際に創始されたコンテンツサイズと一致しないや、クライアントとの接続が閉じているため発生
- 解決策:リクエストを生成しているコードを調べ、リクエストをより詳細に調べることのできる登録済みインスタンスに直接送信する、レスポンスが送信される前にクライアントが接続を閉じないようにする
- HTTP 502: Bad Gateway
- 原因:インスタンスからの応答の形式が適切でないか、ロードバランサーに問題がある
- 解決策:インスタンスから送信された応答が HTTP 仕様に準拠していることを確認する
- HTTP 503: Service Unavailable
- 原因:ロードバランサーにリクエストを処理する能力が不足または、登録されたインスタンス(正常なインスタンス)が存在しない
- 解決方法:前者の場合は一時的な問題のため、一旦放置氏それでも解決しない場合はAmazon Web Servicesサポートへ問い合わせ
- 後者の場合、正常なインスタンスを登録する
- HTTP 504: Gateway Timeout
- 原因:アプリケーションの応答が、設定されているアイドルタイムアウトよりも長くかかっているまたは、録されたインスタンスがELBへの接続を終了させている
- 解決策:前者は、ELB側のアイドル接続のタイムアウト設定を伸ばす
- 後者の場合は、MWのKeepAlive設定を有効にしてELBのタイムアウト設定よりも大きい値を定義する
参考
更新日時
2017/05/01 初回投稿