こんにちは!ネットワールド西日本技術部の小川です。今回は、AWSのElastic Load Balancing (ELB)の基本的な設定方法と動作確認の手順についてご紹介します。ELBをまだ使ったことがない方も、設定は簡単なので、ぜひ参考にしてください!
はじめに
ELBには大きく分けて4種類あり、ここではApplication Load Balancer (ALB)に焦点を当てます。ALBはL7ロードバランサーの機能を持ち、主にWebサーバーの負荷分散に最適です。なお、Classic Load Balancerは旧世代のもので、現在は推奨されていません。
料金について
基本的な考え方は、「基本料金 + 従量課金」です。
詳細な料金は以下のURLから確認下さい。
https://aws.amazon.com/jp/elasticloadbalancing/pricing/
アジアパシフィック(大阪)で利用した場合の例:
- ALB 時間 (または 1 時間未満) あたり、USD 0.0243(基本料金)
- LCU 時間 (または 1 時間未満) あたり、USD 0.008 (従量課金)
1LCU の単位の目安は以下のとおりです。以下の項目から LCUが最も多いものが選択され、その料金が発生します。
- 新規接続数: 25/sec
- Active 接続数 3,000/min
- 帯域: 2.2Mbps (1GB/hour)
- Ruleの評価数 1,000/sec
トラストストア検証を使ったクライアント証明書認証の使用やEC2へのデータ転送料金は考慮していませんので、ご注意下さい。
ALB構成について
ALB は複数のアベイラビリティゾーン(AZ)に跨る負荷分散をサポートしています。
「クロスゾーン負荷分散」とも呼ばれ、デフォルトで有効になっています。
Elastic Load Balancing の仕組み - Elastic Load Balancing
ここでは、AZに跨るWebサーバー(HTTP)2台を負荷分散する構成を紹介し、AWS Certificate Manager (ACM)のサーバー証明書を使ってSSLアクセラレータとして設定します。
ALB作成手順
サーバー証明書の作成
- AWSコンソールにログインして、検索フィールドから [ACM]を入力して検索して、[Certificate Manager] を選択します。
- [リクエスト]をクリックします。
- [パブリック証明書をリクエスト]を選択して、[次へ]をクリックします。
- ドメイン名(FQDN), 検証方法、キーアルゴリズムの値をいれて、[リクエスト]をクリックします。
- 証明書が保留中の状態になりますが、しばらく待ちます。
- ステータスが[発行済み]になれば完了です。
ターゲットグループの作成
- EC2 コンソールから、[ロードバランシング]-[ターゲットグループ]をクリックして、[ターゲットグループの作成]をクリックします。
- ターゲットタイプを選択しますが、今回は[インスタンス]を選択します。(※オンプレミスのサーバーをターゲットにする場合は、IPアドレスを選択します。)
- [ターゲットグループ名]を入力します。ターゲットサーバーの[プロトコル]を選択します。(※ ALBは HTTP か HTTPS のいずれかの選択となります。HTTPを選択した場合は、インスタンスに対して平文のHTTPで接続します。)
- ターゲットインスタンスが配置されている [VPC] を選択します。
- ヘルスチェック方法を選択して、[次へ]をクリックします。(※ ALBは HTTP か HTTPS のいずれかの選択となります。ヘルスチェックは詳細設定で細かく設定できます。今回は割愛しますが、ターゲットグループを作成した後に設定の調整は可能です。)
- インスタンスを選択して、[保留中として以下を含める]をクリックします。[ターゲットグループの作成]をクリックします。
- ターゲットグループが作成されたこと確認します。
ロードバランサーの作成
- EC2 コンソールから、[ロードバランシング]-[ロードバランサー]をクリックして、[ロードバランサーの作成]をクリックします。
- Application Load Balancer の [作成]をクリックします。
- ロードバランサー名を入力します。今回は、[インターネット向け]、[IPv4 ]を選択しますが、環境に合わせて設定します。
- VPC を選択し、アベイラビリティゾーン(AZ)を選択します。
- セキュリティグループを選択します。
- リスナーの設定項目です。プロトコルとターゲットグループを選択します。(今回はSSLアクセラレータとして構成するため、HTTPSを選択します。)
- セキュリティポリシーでは、SSLネゴシエーション時の暗号化の種類を選択できます。詳細については、AWSドキュメントを参照を下さい。Application Load Balancer のHTTPSリスナーを作成する - Elastic Load Balancing
- [ACMから]を選択して、事前に作成した証明書を選択します。
- 設定した内容を確認して、[ロードバランサーの作成]をクリックします。
ALB動作確認
DNS 名の確認
ロードバランサーのステータスを確認します。
一般的なロードバランサーとは違い、仮想IPアドレスの設定はありません。代わりにDNS名が設定されます。
"nslookup" すると、AZ毎のグローバルアドレスがラウンドロビンで応答します。
ALBでロードバランサーを設定した後は、別途外部DNSにCNAMEレコードを追加するか、エイリアスレコードを使用したAWS Route53で名前解決を出来るようにします。
エイリアスレコードと非エイリアスレコードの選択 - Amazon Route 53
HTTPSの接続確認
HTTPS接続をします。デフォルトでは、セッション維持の設定は入っていません。(今回の環境では、セッション維持の有無を分かりやすくするため、サーバ毎にコンテツ内容を変えています。)
セッション維持の設定
ターゲットグループの属性を編集します。
[維持設定をオンにする]を有効にします。
[ロードバランサーがCookieを生成しました。]では、クライアントにリプライを返す際に、セッション維持用のCookieを挿入します。Cookie情報を元に2回目以降の接続は同じサーバーに振り分けられます。
ヘルスチェックの確認
ロードバランサーの [リソースマップ - 新規]をクリックします。
ターゲットが[正常] になっていることを確認します。
インスタンスを1台停止させ、ヘルスチェックのステータスは以下のようになります。
ヘルスチェックの結果、正常でないサーバーにはセッションは振り分けされません。先ほどの確認では Web01 のコンテンツが応答していましたが、インスタンスを停止しましたので、Web02 の別のサーバーが応答するようになりました。
アクセスログ
アクセスログはS3バケットに保存することができます。ただし、S3バケットに保存するのみではアクセスログの確認は難しいです。AWS Athena のクエリを使ってログ閲覧することをお奨めします。
「AWS Athena : ELBアクセスログのクエリ方法」に詳細を記載しましたので、是非こちらの記事も参照下さい。
以上、AWS ALB の設定方法、動作確認方法について紹介致しました。
読んで頂き、ありがとうございました。