12
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【AWS完全に理解したへの道】 ELB 基本編

Posted at

【AWS完全に理解したへの道】 ELB 基本編

スクリーンショット 2020-01-13 10.16.00.png

AWS過去記事

IAM 基本編
VPC 基本編
S3 基本編
データベース(RDS/ElastiCache/DynamoDB)基本編
EC2 基本編

ELB(Elastic Load Balancing)

ELBの全体的なイメージは以下の画像のようになる。
スクリーンショット 2020-01-13 10.22.24.png

AWS Black Belt Online Seminar Elastic Load Balancing (ELB)より画像引用

  • リスナー
    ロードバランサ自体がListenするプロトコルとポート番号。
    さらにロードバランサからターゲットへの接続用のプロトコルとポート番号も設定可能。
スクリーンショット 2020-01-13 10.29.38.png
  • ターゲット
    ロードバランサがトラフィックを転送するEC2インスタンスなどのリソースやエンドポイントを設定する。
スクリーンショット 2020-01-13 10.32.15.png

そもそもなぜロードバランサ(LB)が必要なの?

大きくは以下の2点。

  1. 冗長化/可用性
    例えば、1台のみサーバで構成している場合、そのサーバがダウンした時にサービスを継続できない。
    よって複数台のサーバ(冗長化)とトラフィックをコントロールするLBを組み合わせることによってサービスの安定稼動につなげる(可用性)

  2. 負荷分散/スケール
    バックエンドEC2インスタンスのリクエスト数やコネクション数が均等になるようにすることでトラフィックを効率的にする。
    EC2インスタンス一箇所にリクエストなどが集中するとトラフィックの効率が悪い(レイテンシーの増加など)。

最適なロードバランサーの選択

選択できるELB製品は以下の3つ。

  1. Application Load Balancer(ALB)
  2. Network Load Balancer(NLB)
  3. Classic Load Balancer(CLB)
スクリーンショット 2020-01-13 9.58.01.png

1. Application Load Balancer

パスベースのルーティングやHTTPメソッドベースのルーティング、リダイレクトなど柔軟なアプリケーション管理をしたい場合はこれ。

2. Network Load Balancer

非常に高度なパフォーマンスと静的IPが必要な場合はこれ。

3. Classic Load Balancer

EC2-Classicネットワーク内で構築された既存のアプリケーションがある場合はこれ。
VPCの前の古いやつらしいので、今から始めるなら使う必要はなさそう。

※各々の詳細は別記事で掘り下げる予定。

ELBの基本機能

高可用性と負荷分散

負荷分散は以下の2ステップで行われる。

  1. DNSラウンドロビン(均等負荷分散)で各AZ内のELBに振り分けられる。
    2)負荷が均等になるようにバックエンドのEC2にそれぞれのルーティングアルゴリズムで振り分ける。

スクリーンショット 2020-01-13 16.53.12.png

AWS Black Belt Online Seminar Elastic Load Balancing (ELB)より画像引用

  • ゾーンごとのフェイルオーバー
  • クロスゾーン負荷分散
  • 同一インスタンスで複数ポートに負荷分散
  • IPアドレスをターゲットに設定
  • ELB自体のスケーリング

負荷に応じて、ELBを自動でスケールアップ、スケールアウトする

注意点

  • リクエストが瞬間的に急増した時にELBのスケーリングが間に合わない場合があり、その時HTTP503が返ってくる。 
  • NLB以外のELB(ALB/CLB)がスケールするときはIPアドレスが変化するので、ELBヘアクセスするときは必ずDNS名でアクセスすること。
回避方法

事前にALB/CLBをスケールさえておく。

  • Pre-Warmingの申請をサポートケースで行う。
    ※ 要Business/Enterpriseサポート
    ※NLBはPre-Warming不要で突発的な数百万リクエスト/秒のトラフィックも捌ける。
  • 自前で負荷を段階的にかけてスケールさせておく

モニタリング・ログ

ヘルスチェック

ELBが正常なターゲットのみをトラフィックするようにルーティングできているかチェックする。

スクリーンショット 2020-01-13 12.04.21.png
  • 正常のしきい値
    異常なターゲットが正常であると見なされるまでに必要なヘルスチェックの連続成功回数

  • 非正常のしきい値
    ターゲットが異常であると見なされるまでに必要なヘルスチェックの連続失敗回数

  • タイムアウト
    ヘルスチェックを失敗とみなす、ターゲットからレスポンスがない時間の設定(秒単位)
    2~60秒の範囲で設定可能。

  • 間隔
    個々のターゲットのヘルスチェックの概算間隔(秒単位)
    5~300秒の範囲で設定可能。

運用のモニタリング

Auto Scalingによるインスタンス増減時のELBへの追加・削除が可能
(Auto Scalingについては別記事に書く予定)

アクセスログの記録
  • 最短5分間隔でELBのアクセスログを取得可能
  • 指定したS3バケットに簡単にログを自動保管可能
  • ELBの種類によってアクセスログの出力フィールドも異なる

セキュリティ関連

SSL/TLSサポート

ELB側でSSL/TLS認証ができる。(基本的にはTLSプロトコル)

通信パターン

  1. ELBでSSL Terminationし、バックエンドとはSSLなし(推奨はこれらしい)
    バックエンドのEC2インスタンスでSSL処理をしなくて良いので、EC2側の負荷軽減できる。

  2. ELBでSSL Terminationし、バックエンドとは別途SSL

  3. SSLをバイパスしてバックエンドにTCPで送信
    クライアント証明書認証などを利用するためにはTCPとして扱う

||ELB|バックエンド(EC2など)|
|---|---|---|---|
|1|HTTPS|HTTP|
|2|HTTPS/SSL|HTTPS/SSL|
|3|TCP|TCP|

Server Name Indication(SNI)

通常はTLS証明書を1つしか設定できないが、複数のTLS証明書を1つのALB/NLBのListenerに設定可能になる。

  • SNIをサポートするクライアントには、適切な証明書を選択してTLSで通信を行うことができる。

  • SNIをサポートしないクライアントにはデフォルト証明書が使用される。

  • ALB毎にMAX25証明書まで(デフォルト証明書を除く)設定可能。

  • ACMまたはIAMの全ての証明書が利用可能。

コネクション

ELBのコネクションタイムアウト

  • ALB/CLBはデフォルト設定ではコネクションタイムアウト値は60秒(1~4000秒の間隔で設定可能)
  • NLBのデフォルト設定ではコネクションタイムアウト値は350秒固定

Connection Draining(登録解除の遅延)

スティッキーセッション

  • 同ユーザから来たリクエストを全て同じEC2インスタンスに送信
  • デフォルトでは無効
  • HTTP/HTTPSのみで利用可能

ステートレスな設計が望ましいので、セッション情報などはキャッシュサーバやDBサーバに持たせるのが望ましい。したがって、この機能は使わなくてよさそう。

12
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?