株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

AWS : Application Load Balancer (ALB) の構築方法

こんにちは!ネットワールド西日本技術部の小川です。今回は、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アクセスログのクエリ方法」に詳細を記載しましたので、是非こちらの記事も参照下さい。

blogs.networld.co.jp

 

 

以上、AWS ALB の設定方法、動作確認方法について紹介致しました。

読んで頂き、ありがとうございました。