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を変更できない 最大１分間は障害発生中のサーバー側へリクエストが流れることになります。 この間はSorryページは表示されないので注意してください。

最後に

いかがだったでしょうか？
AWSでは、このように可用性のあるサーバレスな環境を簡単に構築する事ができました。
インフラの運用にかかるコストや工数の削減に大いに貢献できると思います。
みなさんも是非、この機会にAWSを活用してみてはいかがでしょうか？？
場所: 日本、〒860-0012 熊本県熊本市中央区紺屋今町１−５ 熊本辛島公園ビル

コメント

コメントを投稿

このブログの人気の投稿

Windows 10に.NET Framework 3.5が入らない？

-
イメージ
こんにちは。 熊本事務所の庄村です。 今回は、実際の業務中に遭遇したトラブルとその解決法についてご紹介したいと思います。 弊社で開発し、お客様に納品しているアプリケーションについて、 最近、Windows 10上で動作するか検証する機会がありました。 対象のアプリケーションは.NET Framework 3.5を使用しており、 現在はWindows 7上で運用していますが、近日中にOSをWindows 10に移行する予定のため、 OS移行前に動作検証しておく必要がありました。 事前の調べでは、Windows 10では追加のインストールが必要なものの、 .NET Framework 3.5はサポート対象となっているため、特に問題は発生しないはずでした...。 しかし、業務アプリケーションのインストール時に、 自動で.NET Framework 3.5のダウンロードインストールが実行された際、途中でエラーが発生。 改めて、Microsoftのサポートサイトを確認すると、Windows 8以降で発生する現象の様でした。 しかし、今回発生したエラーコード:0x800F0954とそれに対応する直接の対策手順は確認できませんでした。 エラーが発生するタイミングから、ダウンロードの時点で失敗しているようなので、 その後の調査で判明した、コンポーネントのダウンロード元を変更するグループポリシーを設定することで、 何とか.NET Framework 3.5のインストールに成功しました。 以下にその際の対応手順を記します。 1. グループポリシーエディタを起動する。 Winキー＋Ｒキー押下で表示される、「ファイル名を指定して実行」に"gpedit.msc"を入力し、 [OK]ボタンを押して「グループ ポリシー エディター」を起動します。 2. オプションコンポーネントのインストール設定画面を開く。 上記選択行をダブルクリックします。 3. オプションコンポーネントのインストール設定を有効にする。 上記青枠を選択し、[OK]ボタンを押下します。 4. .NET Framework 3.5を有効化する。 上記1～3までの手順実施後に、コントロールパネルの
続きを読む

マリンメッセ福岡で開催された福祉用具機器展に弊社製品を出展しました

-
イメージ
こんにちは。 熊本事業所ヘルスケア事業部の上田です。 先日、7月3日(水)と4日(木)にマリンメッセ福岡で開催された 【CareTEX福岡2019】に睡眠見守りセンサー"まもる～の"を出展しました。 そもそも、"まもる～の"ってなあに？と思われますが、 介護施設向けに販売している睡眠見守りセンサーであり、 入居者様のベッド上の活動状態と居室環境をモニタリング出来ることが特徴です。 今までは介護施設向けの製品ラインナップしかなかったのですが、 介護施設向けから発展させた、在宅介護向けの見守りシステムを紹介すると 多くのお客様から反響がありリリースされたら積極的に検討したい等の声も頂きました。 展示会ではその場で説明をして、その場でフィードバックがもらえるので、 それまで自分が気付かなかった事や知らなかった事など、今後の営業で役立つ情報を得られました。 介護業界の事については勉強中ですが、 皆様の要望に応え、より良い製品にしてお役に立てるよう頑張って参ります。 遅くなりましたが、 会期中は天候が悪い中、弊社ブースに足を運んで頂きありがとうございました。 今後ともASD及び"まもる～の"をよろしくお願いいたします。 次回は、9月3日(火)と4日(水)に仙台国際センターで開催される 【CareTEXOne仙台2019】に出展します。 こちらも来場お待ちしております！ まもる～の公式ホームページはこちら。 http://mamoruno.miel.care/
続きを読む

AWSの消し忘れ

-
こんにちは、熊本事務所の菊池です。 先月ほど、社内の研修でAWSは料金が怖くて手が出せないという話がありました。 しかしながら、AWSの一部サービスは毎月ある程度の時間は無料で動かせたりします。 そのため学習で軽く動かす程度ならお金は掛かりません。 そこで、私個人のアカウントでどれだけ料金がかかっていたか確認することにしました。 各機能をざっと触ったぐらいなので500円にも満たないはずです。 11月合計：$46.44 こんなはずではなかった。 明細を見ていくとEC2とRDSが課金の大半を占めていた様子。 詳細(一部抜粋) 　EC2 　　EC2稼働(Unix) ：$0.18 　　ロードバランサー ：$17.51 　RDS 　　MySQLインスタンス ：$11.34 　S3 　　リクエスト  ：$0.02 　　ストレージ容量 ：$0.01 ロードバランサー配下のEC2インスタンスは、お試しで使った後すぐ止めたはずでした。 が、明細に記録された利用時間は1ヶ月フル稼働の約720時間。 ちゃんと消したはずなのになぜ？ 後で調べた結果、配下にEC2インスタンスがなくてもロードバランサーは単体で動いており、 アクセスが無くても稼働はしているので料金がかかるということが分かりました。 つまり、EC2インスタンスだけでなくロードバランサーも削除する必要がありました。 11ドル請求されたRDSも似たような感じで、 DBインスタンスを"停止"はさせましたが"削除"はしなかったため、 残っていたストレージの利用料金を取られています。 また、RDSインスタンスの停止は最大7日までという制約があり、知らない間に稼働していた分の請求も見られました。 色々な無駄が発覚しましたが、これらのミスが無ければ全料金が差引き4ドルに満たないことも判明。 母親が無駄に電気を使うなと言っていた理由が分かった気がしました。 AWSはお金がかかるのか？結果としてはお金がかかってしまいました。 正しく使うことができれば安価で色々できるとは思います。 皆さんも不要なAWSリソースは、こまめに消すように気を付けましょう。
続きを読む