24時間365日フルマネージドホスティングサービスのデイーネット

「ニフクラ」導入無料キャンペーン

【CloudDesignPattern】Sorry Pageパターンを作ってみる

こんにちは。下地です。

先日AWS認定プロフェッショナル資格に挑戦したのですが、難しすぎて撃沈しました。

まだまだAWSマスターへの道は遠いですね。めげずに勉強を続けます。

さて、今日はAWSクラウドデザインパターン(以下CDP)から、Sorry Pageパターンを構築してみようと思います。

宜しくお願いいたします。

Sorry Page パターンとは

SorryPageパターンはざっくり言うと、メインサイトで障害などが発生した場合に自動でバックアップサイトに切り替える構成です。

具体的には以下の感じになります。

Sorrykousei.JPG

Route53のヘルスチェック及びフェイルオーバー機能と、S3のウェブサイトホスティング機能を組み合わせて実装します。

Route53にてメインサイトをプライマリ、S3のバックアップサイトをセカンダリとすることで、メインサイトへのアクセスができなくなった際に、S3へ自動でフェイルオーバーさせます。

メインサイトを作る

では最初にEC2でメインサイトを作成します。

ドメインを用意

今回は検証で使う適当なドメインを取得しました。

お名前.comで「mytest08.work」を1円で取得。

こちらの手順は割愛します。

domain1.png

EC2を置くVPCを作成

メインサイトはEC2に置くので、その配置用にVPCを作成します。

vpc1.png

名前を「mytestingvpc01」とし、CIDRは「10.0.0.0/16」としました。

vpc2.png

これでVPCができました。

vpc3.png

サブネットの作成

次にサブネットを作成します。

subnet1.png

名前を「mytestingsubnet01」とし、CIDRは「10.0.0.0/24」にしました。

AZは自動設定にします。

subnet2.png

サブネットが作成されました。

subnet3.png

 

インターネットゲートウェイの作成

このサブネットにはインターネットから接続させるEC2を配置する予定なので 、インターネットゲートウェイをVPCに設置します。

IGW1.png

名前を「mytestingigw01」とします。

IGW2.png

これで作成ができました。

IGW3.png

ただ、このままですとVPCに紐づいていませんので、先ほど作成したmytestingvpc01にアタッチします。

IGW4.png

プルダウンからmytestingvpc01を選択。

IGW6.png

これで以下の様にVPCにインターネットゲートウェイをアタッチできました。

IGW7.png

ルートテーブルの設定

VPCにIGWをアタッチしましたら、サブネットに紐付くルートテーブルの設定を修正します。

具体的には、0.0.0.0/0宛てのトラフィックをIGWに向ける必要があります。

これでこのサブネットをパブリックサブネットとして利用できます。

まず変更前の設定は以下の通りです。

route1.png

ここからルートテーブルの「rtb-03cade4f8187bc25c」のリンクをクリック。

「ルートテーブルの関連付けの編集」ボタンをついつい押したくなりますが、これではないので注意しましょう。

すると、ルートテーブルのメニューに飛びますので、こちらから編集していきます。

route2.png

「Routes」タブから「Edit routes」をクリック。

route3.png

これで「Add route」にてルートを追加します。

route4.png

以下のように0.0.0.0/0宛てをIGWに設定します。

route5.png

これで新たにルートが設定され、このサブネット内からのインターネットへの経路設定ができました。

route6.png

メインサイト用のEC2作成

NW周りの設定ができましたので、ここにWebサイト用のEC2を1つ作成します。

VPC及びサブネットは先ほど作成したものを指定しています。

ec21.png

名前は「mytestingwebserver01」としました。

ec22.png

セキュリティグループは、自分のIPからのSSHと任意IPからのHTTPを許可します。

ec23.png

EIPの払い出しと設定

1つEIPを払い出して、今作成したEC2に紐づけます。

ec24.png

VPC用として払い出し。

ec25.png

名前を「mytestingeip01」としました。

ec26.png

これをEC2に紐付けます。

アクションメニューから「アドレスの関連付け」

ec27.png

インスタンスIDを指定して設定します。

ec28.png

これで設定OKです。

EC2の画面からIPが確認できました。

ec29.png

Webサーバの設定

EC2にApacheをインストールして、簡易的なWebサイトを構築します。

まずSSHでEC2に接続してhttpdをインストール

[root@ip-10-0-0-131 ~]# yum install httpd

httpd.confを修正してバーチャルホスト設定をします。

[root@ip-10-0-0-131 ~]# cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.org
[root@ip-10-0-0-131 ~]# diff /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.org
363,370d362
< 
< NameVirtualHost *:80
< 
< 
< ServerName www.mytest08.work
< ServerAlias mytest08.work
< DocumentRoot /var/www/html
< 
[root@ip-10-0-0-131 ~]# 

設定したドキュメントルートのディレクトリにメインサイト用のindex.htmlを配置しました。

[root@ip-10-0-0-131 ~]# vim /var/www/html/index.html                                 
[root@ip-10-0-0-131 ~]# cat /var/www/html/index.html
This is a mainpage of www.mytest08.work
[root@ip-10-0-0-131 ~]#

ここまで設定したら、ブラウザからEC2のEIPを直接指定してアクセス確認します。

ec210.png

ちゃんと表示されました。OKです。

更に、自分のPCのhostsファイルを設定し、ドメインでもアクセスしてみます。

ec211.png

これもOKです。

ただし、この状態ですとまだDNSサーバの設定がされていないため、hostsファイルを修正した自分のPCからしかドメイン名でのアクセスができません。

そこで次にRoute53の設定をしていきます。

Route53で名前解決できるようにする

用意したドメイン「mytest08.work」について、EC2のEIPで名前解決できるように設定します。

ちなみに設定とは関係無いのですが、Route53はサービスレベルアグリーメントが「100%」です。

初めて見たとき100%って本当なのか?99%とかじゃなくて?と思いました。

参考:https://aws.amazon.com/jp/route53/sla/

では設定に戻って、まずRoute53からHosted zonesを選択し、Create Hosted Zoneと進みます。

route531.png

ドメイン名を入力します。

route532.png

これでホストゾーンが作成されました。

作成時点で、NSレコードとSOAレコードが登録されています。

route533.png

ここにAレコードを新規で作成します。

Dreate Redord Setから実施。

route534.png

Nameは「www.mytest08.work」とします。

ValueはEC2に紐付けたEIPを入力し、Routeing Policyは一旦Simpleにします。

route535.png

Aレコードが作成されました。

route536.png

次に、ドメインを取得したお名前.com側の設定で、Route53のネームサーバを指定する必要があります。

ここからはAWSのマネコンではなくて、お名前.comのコントロールパネルになります。

onamae1.png

このように、ネームサーバ情報入力欄に、Route53のNSレコードで表示されていたネームサーバ情報を登録しています。

これでネームサーバとしてRoute53を登録することができました。

ただDNSの浸透に時間がかかるのですぐには名前解決ができません。

試しにすぐにアクセスしてみると「504 Gateway Timeout」となりました。

これで数日待つことにします。

EC2はオンデマンドで作成したので、一旦停止しておきました。

----2日後----

では名前解決を確認してみます。

namaekaiketu1.png

大丈夫みたいですね。

停止しておいたEC2も再度起動します。

ec2error1.png

おや?

あまり見たことのないエラーが出ました。

google翻訳で見てみると、

現在、ご希望のアベイラビリティーゾーンに十分なt2.micro容量がありません(ap-northeast-1d)。

当社のシステムは、追加容量のプロビジョニングに取り組んでいます。 

現在リクエストでアベイラビリティーゾーンを指定しないか、またはap-northeast-1c、ap-northeast-1aを選択することで、

t2.microの容量を取得できます。

とのこと。

うーん、そうなんですね。

ちょっと困ってなんどかポチポチしているとなぜか起動しました。

おそらくどなたかがどいてくれたのでしょう。

良かったです。

ec2error2.png

DNSが設定されたので、hostsファイルに設定せずともブラウザからアクセスができるにようなりました。

ec2error3.png

SorryページをS3に準備

ここからは、メインサイトのEC2で障害が発生したときのフェイルオーバー先になるメンテナンスページを、S3に作成していきます。

バケットの作成

名前を設定して進めます。

ここで注意ですが、S3に独自ドメインを割り当てるためには「バケット名は割り当てるドメインと同じにする」ということです。

この先の手順でRoute53にセカンダリサイトとしてこのS3バケットを指定しますが、その際にS3バケットが表示されない(No Targets Availavle)になる場合は、この名前を確認してみてください。

s31.png

これで作成できました。

s32.png

次にこのバケットでWebサイトホスティング設定を有効化します。

s33.png

これで有効化されました。

s34.png

このバケットにメインサイトからフェールオーバーした際に表示されるデータを置きます。

まず自分のPCでエラーページ用のindex.htmlを作成します。

s35.png

中身は簡単な文字列にしています。

s36.png

これをアップロード。

s37.png

保存できました。

s38.png

ただ、このままですとパブリックアクセスが拒否されているためブラウザから確認ができません。

アクセス権限を変更してブラウザから見えるようにします。

まずバケットの権限を変更。

s39.png

続いてオブジェクトをパブリックアクセス(読み取り)許可にします。

「公開する」ボタンをクリックするだけです。

s310.png

これでブラウザから確認すると、以下の通り表示できました。

s311.png

これでOKです。

Route53でヘルスチェックとフェールオーバーを設定

メインサイトとフェールオーバー先のサイトが用意できましたので、ここからRoute53でヘルスチェック設定と、それに基づくフェールオーバー設定をします。

ヘルスチェック作成

先にメインサイトをチェックするためのヘルスチェック設定を作成します。

Route53メニューの「ヘルスチェック」から作成できます。

health1.png

名前を「mytestinghealthcheck01」としました。

チェック対象はEC2に作成したメインサイトのindex.htmlです。

health2.png

またアラームは今回は無しにしています。

health3.png

これでヘルスチェックが作成されました。

health4.png

少し待つとチェックが実行されて、ステータスが「正常」に変化しました。

health5.png

DNSレコードの作成と一部修正

ヘルスチェックを作成したので、これをDNSレコードに組み込みます。

まず先に設定してあるwww.mytest08.workのAレコードですが、Routeing PolicyをSimpleからFailOverに変更します。

Record TypeはPrimaryです。

合わせて、Associate with Health CheckをYesにして、先ほど作成したヘルスチェックを指定します。

zone1.png

これでプライマリ側のAレコードは設定完了です。

次に、セカンダリのAレコードを新規作成します。

Create Record Setから以下の通り作成。

AliasをYesとすると、プルダウンメニューから先ほど作成したS3バケットが選択できます。

zone2.png

Routing PolicyはFailoverで、Failover Record TypeはSecondaryにします。

zone3.png

これでレコードセットの設定が完了です。

zone4.png

動作確認

それでは本当にメインサイトが落ちるとフェールオーバーするのかをチェックします。

まず正常の状態ですと、ブラウザからアクセスするとメインサイトが表示されます。

check1.png

ここからメインサイトをホストしているEC2を停止します。

check2.png

EC2が停止しました。

check3.png

すると先ほど設定したRoute53のヘルスチェックが「異常」に変化します。

check4.png

再度ブラウザからサイトにアクセスすると、ちゃんとフェールオーバー先のS3バケットでホストされているページが表示されました。

check5.png

では、再度EC2を起動します。

check6.png

起動の完了。

check7.png

Route53のヘルスチェックが再び「正常」に変化しました。

モニタリンググラフからも正常に変化していることが分かります。

check8.png

サイトを確認するとEC2のメインサイトに切り戻されていました。

これで動作確認もOKです。

check9.png

まとめ

記事がすごく長い上に、大半がEC2立てる部分になってしまいました(汗

ただ、こんな感じで手軽にフェールオーバーを考慮した構成を組めるのは便利だと思います。

今後も各サービスを含め、構成設計についても情報をお届けできればと思います。

お読み頂きありがとうございました。

  • このページの先頭へ

  • 東京本社
    〒105-0001東京都港区虎ノ門2-3-22 第一秋山ビル5F
    TEL:03-3591-8887 FAX:03-3591-8886
  • 大阪本社
    〒541-0041 大阪市中央区北浜2-6-11北浜エクセルビル5F
    TEL:06-6231-8887 FAX:06-6231-8897

  • 認証範囲はこちらをご覧ください。

Denet logo

クラウドサービス・データセンタ・高機能専有サーバ・共有サーバホスティングサービス 株式会社ディーネット
dot_bar