こんにちは！在宅カエルです！
今回もAWS SysOps Administrator Associate（SOA）受験に向けて学習を進めます。
主に自分の勉強用ですが、SOAを受験する方も
是非参考にしてみてください！
・AWS SysOps Administrator Associate を勉強中の方
・AWS ELBの機能について知りたい方
前回はELBの概要についてまとめました。
ELBとはなんだろう？という方はまずこちらの記事からお読みください！
どうぞよろしくお願いします。
ELBの機能 – 共通機能
ELBは当初CLBに相当するサービスでしたが、
その後ALBやNLBがリリースされたことで、AWS上のロードバランサーの総称になりました。
まずはELB全体で共通する機能について理解を深めていきましょう。
独自ドメインの利用
ELBへのアクセスは基本的にはDNS名を利用して行います。
DNS名はELBを作成するとAWSが保有するドメイン名から自動で生成されます。
AWSが保有するドメイン名ではなく独自ドメイン名を利用したいという場合、
Route53（AWSのDNSサービス）もしくは自社のDNSサーバーに登録することで
実現可能です。
Route53に登録する場合エイリアスレコード、
DNSサーバーに登録する場合CNAMEレコードを利用します。
ELBのサービスは自動でスケーリングする関係上、IPアドレスが可変になります。
そのため、こういったサービスはIPアドレスを利用した名前解決ができません。AWSがデフォルトで持っているDNS名をIPアドレスの代替として名前解決できるのが、
エイリアスレコードになります。
複数アベイラビリティゾーンへの負荷分散
ELBは複数アベイラビリティゾーン（以下AZ：AWSのデータセンターのこと。）に対してのトラフィックの分散を行うことができます。
前提として、
AWS上にシステムを構築する際には複数AZを利用し、冗長化することが推奨されています。
これは１つのAZが障害によって落ちた際にも問題なくシステムを稼働させるためです。
（実際に2019/08/23にAWSの東京リージョン内のAZで障害が発生しました。）
AZ１とAZ２という複数のAZからなる冗長化されたEC2を利用したシステムがあった場合、
それぞれのAZに２つのELBを配置することができます。
なお、各AZのELBへのトラフィックの振り分けはユーザーが
アクセスするDNS名により解決されたAWSのELBサービスが行います。
これにより仮にどちらかのAZで障害が発生した場合にも、
正常なAZに配置されているサーバを利用することができます。
どのAZにロードバランサーを配置するという設定はコンソールなどから行えます。
単一のAZのみで構築することも可能ではあるのですが（非推奨の構築です）、
ALBの場合２つ以上のAZに配置する設定が必須になります。
マルチAZ構成の場合コストの観点から
AZ１にはサーバー３台、AZ２にはサーバー２台
といったようにAZ内のサーバー構成が不均等なケースがあります。
『クロスゾーン負荷分散』を有効にすることでサーバー単位で負荷を均一化できます。
下記画像左がクロスゾーン負荷分散無効、右が有効です。
スケーリング
ELB自体の負荷が高まると、負荷に応じてELBは自動でスケーリングします。
ただし、短時間にアクセスが急増するとスケーリングが間に合わず、
リクエストに対して503エラーを返す可能性があります。
アクセスの増加が事前に予想できる場合は、AWSサポートに連絡し、
ELBをあらかじめスケーリングしておく、暖気運転(Pre-Warming)申請を行います。
なお、NLBは申請不要で数百万リクエスト/秒のトラフィックに耐えることができます。
・申請はコンソールではなくAWSサポートに連絡する。
※ビジネス以上のサポートプランで利用可能！
ヘルスチェック
ELBは負荷分散を行うEC2インスタンスが、
設定値に基づき正常にレスポンスを返すかどうかを自動でチェックすることができます。
チェックの結果、異常とみなされたインスタンスを負荷分散の対象から外し、リクエストを振り分けないようにします。
ELBのヘルスチェック機能とAutoScalingのヘルスチェック機能を組み合わせると、
運用中のEC2インスタンスのヘルスチェックをより正確にすることができます。
ELBとAutoScalingのヘルスチェックを併用した場合、
片方のヘルスチェックで正常と判断されたとしても、もう一方のヘルスチェックにて
異常とされるとインスタンスを終了し、新しいインスタンスを起動します。
Amazon EC2 ステータスチェックの結果を使用してインスタンスのヘルスステータスを確認します。インスタンスステータスがrunning以外であれば異常と判断します。ELBヘルスチェック：
設定値に基づき正常にレスポンスを返すかを判断します。
Connection Draining
ELBはAutoScalingと連携してヘルスチェックを行うことで、
異常とみなされたインスタンスを切り離すことができます。
Connection Drainingとは
EC2を切り離すタイミングで、新規リクエストは正常なインスタンスに振り分けつつ
切り離し対象のインスタンスで処理中のリクエストがあれば待機する機能です。
Connection Drainingは最初から有効化されており、
待機時間を指定することができます。
待機時間のデフォルトの指定秒数は300秒で最大3600秒まで指定することができます。
ELBの機能 – ALB/CLB/NLB
ここまでELBの共通的な機能について確認しました。
ELBとは前述の通り、AWSのロードバランサーサービスの総称です。
ここではALB/CLB/NLBの各ロードバランサーの特徴についてまとめていきます。
ALB/CLB
ALB（Application Load Balancer）は対象のプロトコル、プラットフォーム以外はCLB（Classic Load Balancer）で実現できる機能を全て提供しています。
| ALB | CLB | |
|---|---|---|
| プロトコル | HTTP, HTTPS, HTTP/2 | HTTP, HTTPS, TCP |
| プラットフォーム | VPC | EC2-Classic, VPC |
ALBは、HTTP・HTTPS トラフィックの負荷分散に最適で、
マイクロサービスやコンテナなど最新のアプリケーションアーキテクチャを対象とした
高度なリクエストルーティングを実現できます。
CLBはEC2-Classic用のロードバランサーとして用いられます。
アクセスログの記録
ALB/CLBへのアクセスログはS3へと出力することができます。
アクセスログの保管と分析を可能にします。
ログの情報としてはクライアントのIPアドレスではなく、ALB/CLBのプライベートIPアドレスがアクセス元として記録されます。
スティッキーセッション
Sticky Session（スティッキーセッション）とは、セッションの維持を行う機能です。
クライアントからのリクエストを毎回同じインスタンスに転送します。
EC2がセッション情報や一時ファイルを保持する必要がある
アプリケーション構成の場合に利用します。
スティッキーセッションには期間ベースの Cookie とアプリケーションベースの Cookie の２種類があります。
アプリケーションベースの Cookie の場合、ターゲットグループごとに Cookie 名を個別に指定する必要があります。
NLB
NLB（Network Load Balancer）とは、
きわめて高いパフォーマンスが必要な通信に利用される
ロードバランサーです。
NLBは1秒間に数百万件ものリクエストを処理できます。
NLBはALB/CLBが高負荷に耐えるためにスケーリングすると
IPアドレスが変わってしまうという制約を
解決するためにリリースされました。
よって、NLBでは暖機運転申請なども不要になります。
まとめ
・共通して以下のような機能を持っている
〈独自ドメインの利用、複数AZへの負荷分散、スケーリング、ヘルスチェック〉
・ALBはCLBで実現できる機能を全て利用できる
・NLBはALB/CLBの制約を解決するためにリリースされた
以上、ELBの機能についてまとめました。
ヘルスチェックの結果はモニタリング方法も重要になりそうなので、
次回以降ELBとCloudWatchの連携など
他サービスとの連携についても勉強していきたいですね。
最後までお付き合いいただき、ありがとうございました。
コメント