【AWS】EC2インスタンスをELBでロードバランシング設定

  • 2019年5月26日
  • 2019年6月1日
  • AWS
AWS

ロードバランスって何?ラウンドロビン方式???何やる子なの??
はい。こんな知識0の状態からELBの構築設計を任された、ますのです。
AWSって本当にすごいですね。初心者エンジニアでもロードバランサー作れてしまうのですから!

ELB:構築する際の要件確認

  1. EC2インスタンス上にIISでWebサーバを2台構築している
  2. Webサーバへのアクセスは社内からのアクセスのみ
  3. 各WebサイトはWindows統合認証でアクセス制限を掛けている
  4. 可能であればSSL通信化を実施したい

EC2-ELB構成図

ロードバランス:ALB/NLB/CLBのうち【NLB】を選定した理由は「Windows統合認証」をしたいから!

2019年5月現在、ELB(Elastic Load Balancing)では3種類のロードバランサーが用意されています。

  • ALB(Application Load Balancer)
    HTTP トラフィックおよび HTTPS トラフィックの負荷分散に最適なロードバランサ。
    ALBにセキュリティグループを設定出来るため、ターゲットインスタンスとの通信においてアクセス制御も容易となる。
    スティッキーセッション時間の設定も可能であり、特に要件が無ければALBを推奨している。
  • NLB(Network Load Balancer)
    TCPトラフィックなどネットワーク系の負荷分散に最適なロードバランサです。
    NLBはIPアドレスが固定化されているため、Aレコードでの処理が可能となる。
    しかし、セキュリティグループの設定が出来ない点や、ターゲットインスタンスへ渡す情報がクライアントPCの情報となるため、行き帰りで通信が異なることがある。
  • CLB(Classic Load Balancer)
    複数のAmazon EC2インスタンスにおける基本的な負荷分散を行うのに最適なロードバランサです。
    2016年以前にELBと言われていた機能がCLBに値する。
    ALB/NLBと比べて利用料金が若干高くなるため、ALBを利用する人が多い印象。

今回の要件の肝である「Windows統合認証」を満たすためには、クライアント情報を保持する「NLB」の通信が必須でした。
ALBではターゲットインスタンスへ渡す際の情報がALB自身となります。そのためWindows統合認証時に、Webサーバは「お前だれや??」となってしまったのです。

参考:https://netblaze.biz/windows-authentication-fails-with-aws-application-elb/

ELBをAWS管理コンソールから作成する

  1. AWS管理コンソール>EC2>ロードバランシング:ロードバランサーをクリック
  2. 「ロードバランサーの作成」をクリック
  3. 今回の要件はNLB作成のため、NLBの「作成」ボタンをクリック
  4. 名前:任意の名称を設定
    スキーム:社内向けのWebサーバへ行うため「内部」を設定
  5. リスナー:NLBを選択した場合は「TCP」か「TLS」になります。
    ACMで証明書をまだ作っていないので、取り急ぎ「TCP」を設定しました。
  6. アベイラビリティゾーン:今回のロードバランスを行うインスタンスが作成されているAZを2つ指定します。
    ※1AZにつき最低1インスタンスの設定が必要です。
  7. タグ:てきとーでOK!
    私は名前でつけたものと同じで「internal-nlb」と自分がわかるものにしています。
  8. ターゲットグループ:名前も管理上わかりやすいものを設定。
    今回は「internal-nlb-tg」のように設定しています。
  9. ヘルスチェック:とりあえず初期値に設定。
    NLBの場合、接続できなくなるとすぐに別インスタンスへ切り替えるのでALBよりここはシビアに考えなくても良かったです。
  10. ターゲットの登録:ロードバランスの対象となるインスタンスを設定します。
    インスタンスを検索からインタンス名を検索し選択>「登録済みに追加」をクリックして設定する
  11. 最後に、設定値の確認画面が表示されます。
    「ロードバランサーを正常に作成しました。」という画面になればロードバランサーの作成が完了となります。

作成したNLBのIPアドレスをDNSにAレコード登録する

先程の作成したNLBのDNS名を確認し、DNSへAレコード登録します。
せっかくNLBで固定IP設定したのでDNSへはCネームじゃなくてIPで登録しておきたいところ。
Mac端末とかで検証したらAレコードでうまくいくことが多々あったので、NLB設定時はAレコードでDNS設定したほうが良さそうでした。

  1. AWS管理コンソール>EC2>ロードバランシング:ロードバランサーをクリック
  2. 作成したロードバランサー名をクリック>説明タブのDNS名をコピー
  3. コマンドプロンプト等で「nslookup」や「dig」コマンドでIPアドレスを確認する
  4. 3で確認したIPアドレスをDNSのAレコードへ設定し、アクセスが出来るか確認する

クライアントPC⇔ロードバランサー間をSSL通信にする

  1. AWS管理コンソール>EC2>ロードバランシング:ロードバランサーをクリック
  2. 作成したロードバランサー名をクリック>リスナータブ>リスナーの追加をクリック
  3. プロトコル:ポートで「TLS:443」を設定
  4. 転送先:現在設定しているターゲットグループを指定する
  5. セキュリティポリシー「ELBSecurityPolicy-TLS-1-1-2017-01」を選択
    ※セキュリティレベルが各々異なるため、自身の環境に良いものを選択することになります。

    参考:https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/create-https-listener.html

  6. デフォルトのSSL証明書:「ACMから」「(ACMで作成した証明書を選択)」を選択し保存する。
    ※IAMで証明書を作成出来る方はそちらからでもOK!お金がかかりますが、ACMで作成したほうが簡単だったので、わたしはこちらを選択。

ACM Private Certificate参考:https://dev.classmethod.jp/cloud/aws/tried-acm-private-certificate-authority/

これらの設定をすることで、「Windows統合認証」「https通信化」を行った状態でのロードバランシングが出来ました!!
ALBとNLBの違いについて細かな設定とかはありましたが、それはまた後ほど。

作成期間:調査〜検証〜構築まで…おおよそ2ヶ月

最新情報をチェックしよう!