AWS Elastic Load Balancing(ELB)にEC2インスタンスを紐付ける

f:id:keiwt:20150211201703p:plain

EC2インスタンスの耐障害性を高めるためにはELBが必要です。
ELBは異常なインスタンスを検知して、正常なインスタンストラフィックをルーティングします。
つまり、EC2インスタンスが異常な状態になってもサービスの可用性は担保できます。
存在意義としては異常なインスタンストラフィックをルーティングさせないの一言になるのではと考えています(ヘルスチェックの設定が必要です)

http://aws.amazon.com/jp/elasticloadbalancing/

ユースケースとしては複数のAZに配置するようです。

内部ロードバランサーを作成することで、パブリック IP アドレスで、インターネットに接する層のみを公開できます
※多層アーキテクチャーで、アプリケーションインフラストラクチャは、プライベート IP アドレスおよびセキュリティグループを使用することができるため

Route53のDNSフェイルオーバーを使用することで、複数AWSリージョンでアプリケーションを稼働し、リージョンからリージョンにフェイルオーバーするための代替ロードバランサーを指定できるようです。
つまり、あるリージョン内に正常なインスタンスが存在しない場合は他のリージョンのロードバランサートラフィックをルーティングできるようです。
※Route53の設定です

また、同一のユーザーからのトラフィックを同一のインスタンスにルーティングする(Stickiness)ことも可能です。
※デフォルトはDisabledになっています

それでは手順の説明に入ります。

ロードバランサの作成と起動中のEC2インスタンスの紐付け

ロードバランサを作成する際に起動中の紐付けるインスタンスを設定できます

ヘルスチェックはデフォルトではindex.htmlになっていますが、
nginxのwelcomeページと被らせないためにhealth.htmlにします。

※このままではEC2インスタンスにヘルスチェックの設定が無いために0 of {{紐付けたインスタンスの数}} instances in serviceになります。そこで、インスタンスにヘルスチェックの設定をします

EC2インスタンスに対してヘルスチェックの設定をする

  • nginxの設定ファイルの編集
$ sudo vi /etc/nginx/conf.d/default.conf
location /health.html {
  empty_gif;
  access_log off;
  break;
}
  • nginxの再起動
$ sudo systemctl restart nginx
$ sudo systemctl status nginx

※activeになっていれば正常に再起動ができています

http://{{EC2インスタンスのEIP}}/health.htmlにアクセス

※titleがhealth.html(1×1)になっていればEC2インスタンスへのヘルスチェックの設定は完了です
※ELBにアクセスしても、EC2インスタンスにうまくルーティングされない場合は再紐付けなどを行ってみてください
※ちなみにヘルスチェックはデフォルトでは2回連続で失敗するとそのインスタンスはOut Of Serviceになります
※また、デフォルトではヘルスチェックが10回連続で成功するとそのインスタンスはIn Serviceになります

次にELBにドメインを紐付けます

Route53でAレコードを作成します

Aliasをyesにする
Alias TargetにELBのhttp://{{ELBのドメイン名}}/の{{ELBのドメイン名}}の部分を指定します

AレコードはIPとドメインを紐付けます。
ELBにはIPは割り振られません。
また、CNAMEレコードはZone Apex(ゾーンの階層の最上部)に対しては作成することができません。
つまり、サブドメインのCNAMEレコードを作成するのでしょうか。
いえ、Route53ではAレコードにAlias設定があります!

https://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/using-domain-names-with-elb.html

f:id:keiwt:20150211195252p:plain

ドメインにアクセス

f:id:keiwt:20150211195638p:plain