DNSフェイルオーバー

Markdown to HTML 初めまして、ASD堤です。
今回はAWSのDNSフェイルオーバー機能を利用して、サーバレスなSorryページの構築を紹介したいと思います。

Sorryページとは、Webサイトなどが障害やメンテナンスなどで停止している際に、アクセスしてきた利用者にその旨を告げるページのことです。

DNSフェイルオーバーとは?

そもそも、DNSフェイルオーバーとは何なのかを軽く説明します。
DNSは、たとえば
  • example.com = XXX.XXX.XXX.XXX (IPアドレス)
のように、「ドメイン名」と「サーバのIPアドレス等」を紐付けています。 この時に、XXX.XXX.XXX.XXX(Webサーバ)に何らかの障害が発生し、 サービスを継続できない状態に陥った場合に、
  • example.com = ZZZ.ZZZ.ZZZ.ZZZ (別のIPアドレス)
に自動で変更する仕組みをDNSフェイルオーバーといいます。
つまり、あるドメインへのリクエストを受けたサーバに何らかの障害が発生していた場合に、ドメイン名を変更せずにそのドメインへのリクエストの受け先を変更する仕組みのことです。


※ Route53が返却するIPアドレス 正常時: Primary ServerのIPアドレス 異常時: Secondary ServerのIPアドレス

サーバレスなSorryページの構築

以下のような構成で構築していきましょう。


Route53がELBのヘルスチェックのステータスを確認し、ELBがhealthy(正常)ならばELB側のレコードを、ELBがunhealthy(異常)ならばCloudFront側のレコードをアクセス元に返すようになっています。

構築手順

ELB または EC2

ELBやEC2インスタンス等の特別な設定はありません。

S3

S3では以下の対応を行います。
  • Sorryページ用のBucketの作成 (Bucket名はドメイン名と同様)
  • SorryページのHTMLをBucket直下に配置してアクセス権限をパブリックに変更

CloudFront

CloudFrontでは以下の対応を行います。
  • CloudFront Distributionの作成 [Origin Domain Name] にS3のドメインを設定しましょう。 [Alternate Domain Names]にサービスドメイン名を指定しますが、 公開するサーバのドメイン名と同様としてください、Route53で設定する際にAlias targetとして選択できる様にするためです。 そもそもRegionが異なる場合や、Regionが同じでもサービスドメイン名とRoute53で指定したドメイン名が異なる場合にはAlias targetに表示されないので注意してください。
  • Error Responseの設定 どんなURLでリクエストしても、S3 Bucketにそのファイルが存在しないため403のステータスコードをCloudFrontへ返します。 CloudFront側で、S3から403で返ってきた場合のみアクセス元に503のステータスコードとSorryページのキャッシュを返すように設定しましょう。
  • SSL証明書の設定 SSL証明書は[SSL Certificate]で設定できます。 AWSのCertificate Managementで無料で発行できますが、現在バージニア北部リージョンで発行したものでないとCloudFrontでは選択できない様です。

Route53

Route53では、DNSフェイルオーバーの設定を行います。
  • レコードの作成 Routing Policyを[Failover]に設定したAレコードを、ELB(Primary)とCloudFront(Secondary)の2レコード作成しましょう。 また、ELB(Primary)側にRoute53からヘルスチェックの確認を行うために[Evaluate Target Health]を有効にしてください。

動作検証

これでサーバレスな環境を構築できました。
確認のために、Primary ServerのApache等を停止させてみましょう。
1~2分後にSorryページが表示されたらOKです。

メリット・デメリット

メリット
  • サーバレス S3やCloudFrontが動作しているサーバはAWSが管理・保守を行なっているため、自分でサーバ(EC2)を管理・保守するより楽です。
  • 維持費がかからない 正常動作時はS3やCloudFrontへのデータ転送は発生しないので料金はほぼ0となっています。かかる費用としてはS3への保存量への課金のみです。最大でも$1未満となっています。
デメリット
  • Route53のAliasはDNSのTTLを変更できない 最大1分間は障害発生中のサーバー側へリクエストが流れることになります。 この間はSorryページは表示されないので注意してください。

最後に

いかがだったでしょうか?
AWSでは、このように可用性のあるサーバレスな環境を簡単に構築する事ができました。
インフラの運用にかかるコストや工数の削減に大いに貢献できると思います。
みなさんも是非、この機会にAWSを活用してみてはいかがでしょうか??

コメント

このブログの人気の投稿

AWSの消し忘れ

ASD、ブログはじめるってよ。

サーバの中の魔法のランプ