Step-3ではWebサーバとアプリケーションレイヤの水平分散、データベースレイヤの冗長化を行います。具体的にはStep-2の環境にロードバランサを配置しEC2インスタンスを2つのアベイラビリティゾーンに水平分散、プライベートサブネットに配置されたデータベースAuroraを同様に2つのアベイラビリティゾーンに配置(MultiA-Z構成)し冗長構成とします。
ここではStep-2で作成したAuroraインスタンスをMultiA-Zの機能を用いて冗長化します。サービスからRDSを選択しましょう
左側のインスンタンスリンクをクリックし、作成したAuroraインスタンス(wp-userXX)をチェックし、インスタンスの操作のプルダウンからAuroraレプリカの作成を選択しましょう
アベイラビリティゾーンはap-northeast-1cを選択、インターネットゲートウェイからのアクセスは抑止するためパブリックアクセス可能では"いいえ”を選択
下にスクロールし、インスタンスの仕様は"db.t2.small"が選択されていること、設定でのDBインスタンス識別子では「wp-user05-slave」としましょう
更に下にスクロールし、設定内容は変更せず、Auroraレプリカの作成ボタンを押下
約5分ほどでAuroraのレプリカは作成されます。画面中央上のリロードボタンを押して「利用可能」になるまで待ちましょう
水平分散について調べてみましょう(10分)
AWS MultiA-Zについて調べてみましょう(10分)
追加で作成したAuroraインスタンス含めクラスターエンドポイント、読み取りエンドポイントが利用可能か確認しましょう。左のクラスターリンクをクリックしStep-2で作成したDBクラスター識別子のリンクをクリックしましょう
クラスターエンドポイント、読み込みエンドポイントの確認をしましょう
EC2サーバにSSH接続し、EC2サーバからAuroraに接続してみましょう。また作成したAuroraインスタンスが意図したセグメントに配置されているかも確認しましょう。
$ ssh -i 1day-userXX.pem -o StrictHostKeyChecking=no [email protected]
[ec2-user@ip-10-0-0-65 ~]$
クラスタエンドポイントを使用してAuroraに接続しましょう。
注意 wp-userXX-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.comは各自のクラスタエンドポイントに直すこと。パスワードはAurora作成時に設定した内容(この資料ではvg1daypasswordなっています)を指定すること
$ mysql -u admin -p -hwp-user05-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
mysql> select @read_only;
+------------+
| @read_only |
+------------+
| NULL |
+------------+
1 row in set (0.00 sec)
mysql> exit
続いてクラスタエンドポイントが存在するネットワークセグメントの確認をしましょう。10.0.2.XXXなら正しい設定です
$ nslookup wp-user05-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
wp-user05-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com canonical name = wp-user05.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com.
Name: wp-user05.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Address: 10.0.2.226
読み込みエンドポイントを使用してAuroraに接続しましょう。
注意 wp-userXX-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.comは各自の読み込みエンドポイントに直すこと。パスワードはAurora作成時に設定した内容を指定すること
$ mysql -u admin -p -hwp-userXX-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
mysql> select @read_only;
+------------+
| @read_only |
+------------+
| NULL |
+------------+
1 row in set (0.01 sec)
mysql> exit
続いて読み込みエンドポイントが存在するネットワークセグメントの確認をしましょう。10.0.3.XXXなら正しい設定です
$ nslookup wp-user05-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
wp-user05-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com canonical name = wp-user05-slave.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com.
Name: wp-user05-slave.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Address: 10.0.3.217
冗長構成となったAuroraのクラスターエンドポイントを切り替えてみましょう。左のインスタンスリンクをクリックし、Step-2で作成したAuroraインスタンスにチェック、インスタンスの操作プルダウンからフェイルオーバーを選択しましょう
フェイルオーバーボタンを押下
フェイルオーバー選択ごインスタンスが表示されている項目右端のレプリケーションロール「書き込み」「読み込み」が入れ代わればフェイルオーバー成功です。中央上のリロードを押し確認しましょう。数分掛かります
書き込み」「読み込み」が入れ代わればフェイルオーバー成功です
EC2サーバにSSH接続し、EC2サーバからAuroraに接続してみましょう。フェイルオーバーにて作成したAuroraインスタンスが意図したセグメントに配置されているかも確認しましょう
$ ssh -i 1day-userXX.pem -o StrictHostKeyChecking=no [email protected]
[ec2-user@ip-10-0-0-65 ~]$
クラスタエンドポイントが存在するネットワークセグメントの確認をしましょう。10.0.3.XXXなら正しい設定です
$ nslookup wp-user05-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
wp-user05-cluster.cluster-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com canonical name = wp-user05-slave.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com.
Name: wp-user05-slave.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Address: 10.0.3.217
読み込みエンドポイントが存在するネットワークセグメントの確認をしましょう。10.0.2.XXXなら正しい設定です
$ nslookup wp-user05-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
wp-user05-cluster.cluster-ro-cenae7eyijpr.ap-northeast-1.rds.amazonaws.com canonical name = wp-user05.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com.
Name: wp-user05.cenae7eyijpr.ap-northeast-1.rds.amazonaws.com
Address: 10.0.2.226
ここではWebサーバの水平分散にて必要となるEC2サーバのAMIを作成しましょう。AMIを作成することでここまでEC2サーバに設定した内容など全て反映された状態(Auroraの接続情報等)で水平分散が可能になります。
サービスからEC2を選択
左のインスタンスを選択し、Step-1で作成したEC2インスタンス「webserver#1-userXX」にチェック、アクションプルダウンからイメージとイメージの作成を選択しましょう
イメージ名、イメージの説明ともに「sampleapp ユーザ名」で設定、設定後イメージの作成ボタンを押下
閉じるボタンを押下
左下AMIを選択しAMIが作成されれば完了です。数分で作成が完了します
インターネットゲートウェイ、ロードバランサーからHTTPリクエストを受け付けるWeb+APサーバであるEC2インスタンスを先ほど作成したAMIも用いて作成しましょう
左下AMIリンクを選択、作成したAMIをチェック
アクションプルダウンから作成を選択
t2.microが選択されていることを確認し、次の手順：インスタンスの詳細の設定ボタンを押下
以下を設定しましょう
| 項目 | 設定値 |
|---|---|
| ネットワーク | Step-1で作ったvpcを指定。vpc-userXX |
| サブネット | パブリックサブネット ap-northeast-1c 10.0.1.0を指定 |
| 自動割り当てパブリックIP | 有効化 |
特に設定せず、次の手順：タグの追加を押下
タグの追加ボタンを押下
キー「Name」、値「webserver#2-userXX」XXはユーザIDを設定し、次の手順：セキュリティグループの設定を押下
Step-1で作成したインターネットゲートウェイからリクエストを許可するWebサーバ用のセキュリティグループを割り当て、確認と作成ボタンを押下
作成ボタンを押下
Step-1で作成したキーペアであることを確認し、「選択したプライベートキーファイル (1day-user05.pem) へのアクセス権があり、このファイルなしではインスタンスにログインできないことを認識しています。」にチェック後、インスタンス作成ボタンを押下
右下インスタンスの表示ボタンを押下
作成したインスタンスが表示され、作成完了であるステータスチェック「2/2 のチェックに合格しました」となるまで待ちましょう。作成完了まで数分掛かります
作成した#2のインスタンスをチェックし、パブリックDNS(IPv4)のあたいをメモしブラウザでサンプルアプリが参照できるか確認しましょう
サンプルアプリが表示されれば成功です
作成した2台目のEC2サーバにログイン(サンプルアプリを表示したパブリックDNSを使用)しIPアドレス、ゲートウェイ、ネームサーバなどを確認しましょう
$ ssh -i 1day-userXX.pem -o StrictHostKeyChecking=no [email protected]
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0a:03:16:a3:6b:fa brd ff:ff:ff:ff:ff:ff
inet 10.0.1.205/24 brd 10.0.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::803:16ff:fea3:6bfa/64 scope link
valid_lft forever preferred_lft forever
$ ip r
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.205
169.254.169.254 dev eth0
$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 10.0.0.2
ここでは各EC2インスタンスにインターネットゲートウェイから直接アクセスするのではなく、ロードバランサー(ELB,ALB)経由でアクセスさせるために、作成した2台のEC2インスタンスの前段にアクセスを振り分けるELB(ALB)の作成を行います
左下ロードバランサーリンクをクリック、ロードバランサーの作成ボタンを押下
左の「Application Load Balancer」の作成ボタンを押下
名前は「elb-ユーザ名」を設定し、下にスクロールしましょう
Step-1で作成したVPCを選択するとアベイラビリティゾーンの選択ができます。ap-northeast-1c、ap-northeast-1dの両方にチェックし、表示されたパブリックサブネットを両方選択しましょう
ap-northeast-1c、ap-northeast-1dのパブリックサブネットが表示されていれば成功です。次の手順：セキュリティ設定の構成ボタンを押下
次の手順：セキュリティグループの設定を押下
新しいセキュリティグループを作成するをチェック、セキュリティグループ名と説明は「alb-ユーザ名」を設定、タイプを「HTTP」に変更し、次の手順：ルーティングの設定ボタンを押下
名前は「tg-elb-ユーザ名」を設定し、次の手順：ターゲットの登録ボタンを押下
下部に表示された2つのインスタンスを2つともチェックしましょう。チェックすると登録済みに追加ボタンが有効化されるので押下
登録済みターゲットに2つのパブリックネットワーク上に存在するインスタンスが存在すること。次の手順：確認ボタンを押下
作成ボタンを押下
閉じるボタンを押下
作成したELB(ALB)をチェックし下部の説明タブの内容をスクロールさせDNS名をメモしましょう。最終的にはインターネットゲートウェイからのアクセスはこのDNS名のみになります
先ほどメモしたELB(ALB)のDNS名でブラウザを開きましょう。サンプルアプリが表示されれば成功です。ALBの設定から反映され、表示されるまで少し時間が掛かる可能性があります
現在HTTPリクエストはインターネットゲートウェイを経由後ELB、各EC2インスタンスの全てが受け付けています。この設定をインターネットゲートウェイからELBを経由し各EC2インスタンスに振り分けられるようにし、合わせてEC2インスタンスへ直接HTTPアクセスは禁止するようセキュリティグループの変更をしましょう
確認：パブリックDNSを確認(メモ)しブラウザでサンプルアプリを開きましょう
確認：パブリックDNSを確認(メモ)しブラウザでサンプルアプリを開きましょう
確認：DNS名を確認(メモ)しブラウザでサンプルアプリを開きましょう
現時点ではEC2インスタンス2台のパブリックDNS、ELB(ALB)のDNS名の全てでサンプルアプリが表示(HTTPリクエストが通る)できるはずです。これをELB(ALB)のDNS名のみアクセス許可にします
左下のセキュリティグループから作成したEC2インスタンス用のセキュリティグループ「web-userXX」をチェックし、インバウンドタブで表示されるルールを確認しましょう。この中にあるHTTPのルールを変更します。編集ボタンを押下
インバウンドの一つ目のHTTPのルールのソースの値に「al」と入力しましょう。ELB(ALB)用に作成したセキュリティグループが補完して表示されたら選択しましょう。合わせて二つ目のHTTTPのルールはバツボタンにて削除しましょう
HTTPのルールは1つにし、ELB(ALB)のセキュリティグループが指定できたら、保存ボタンを押下
ELB(ALB)経由でアクセス出来れば設定成功です
2台のEC2に直接アクセスした場合はタイムアウトなどでエラーとなれば設定成功です
作成した2台のEC2環境にELB(ALB)からアクセスが振り分けられているかアクセスログから確認してみましょう
$ sudo tail -f /var/log/nginx/access.log
今回の作業、作成した環境で不足してると思われるもの、アプリケーションなどで見られる細かい不具合などを各自調べてみましょう。その後振り返りをしましょう(10分)
ここまでで全てのStepが完了です！お疲れ様でした！