Route53+ELBを組み合わせたSEO対策版Sorryサーバの構築

はじめに

SorryサーバをS3版、EC2版、EC2+AutoHealing版の3パターン作ってみました。

Route53

SLA100%のDNSで、世界中にあるエッジロケーションから一番近いDNSサーバを見つけ出し名前解決をしてくれるため非常に高速であることと伝播の速度も非常に早いそうです。また、aliasが使えること、ヘルスチェックが行える点が特徴的です。

ELB(ElasticLoadBalancer)

ELBはソフトウェアロードバランサとなります。ELBはEndpointは一つですが、裏側では常に冗長化されているためその点利用者が考える必要がないことと、安価で簡単に使えることがメリットとなります。振り分け、Stikiness、切り離しなど基本的な機能は抑えていますが、F5などのロードバランサとは細かい所で機能が異なりますので注意が必要です。

S3でSorryサーバ

Route53とELBができること、できないことを抑えつつELB配下のEC2インスタンスがダウンした時にELBから切り離しを行い、用意していたSorryコンテンツを表示させてみました。
まずはSorryコンテンツをS3においた場合を実装します。
こんな構成になります。

SEO対策版Sorryサーバ

S3はSorryコンテンツを返却するときにはHTTPResponseCode200で返却することと、HTTPHeaderを変えることができないため、ロボット対策としては不十分です。
SEO対策として503で返却することとRetryAfterヘッダを付けてあげることで対策します。
こんな構成になります。

前提事項

VPCは10.0.0.0/16で構築し、public用のセグメントとして10.0.0.0/24のサブネット配下にEC2を配置しています。
EC2のインスタンスの作り方とかは省略します。

S3でSorryサーバ構築

Route53での設定はRoutingPolicyでPrimaryとSecondaryを設定します。
Primaryの設定にELBのEndpointの設定をいれるとRoute53はELBのヘルスチェックを見るようになります。ヘルスチェックがOutOfServiceになるとSecondaryに切り替えます。
SecondaryにSorryコンテンツが格納されているS3のEndpointを登録することでS3版Sorryサーバの出来上がりです。

手順

0.ELBは設定済という前提。
1.S3でSorryコンテンツを配置します。sorry.uzresk.jpというBucketを作成しstatic website hostingで公開しておきます。
2.Route53でホストゾーンの作成します。uzresk.jp.というホストゾーンを作りました。
3.ホストゾーンに対してRecordSetを設定します。まずはプライマリから設定します。

設定	設定値
Name	ホスト名を設定します(www.uzresk.jp)
Type	A
Alias	yes
Alias Target	ELBのEndpoint。正しく設定されていれば補完されるはずです
RoutingPolicy	Failover
FailOver RecordType	Primary
EvaluateTargetHealth	yes(HealthCheckするか？）
AssociateHealthCheck	no(Route53HealthCheck機能を使う場合はyes)
3.セカンダリの設定を行います。

設定	設定値
Name	プライマリと同じホスト名を設定します(www.uzresk.jp)
Type	A
Alias	yes
Alias Target	sorryサーバを配置したs3のEndpoint※
RoutingPolicy	Failover
FailOver RecordType	Primary
EvaluateTargetHealth	no(HealthCheckするか？）
AssociateHealthCheck	no(Route53HealthCheck機能を使う場合はyes)

※ここではS3のEndpointを設定しましたが、Sorryサーバ独自のドメインを利用することもできます。
AWS内のドメインであればaliasを利用することができますし、AWS外であればCNAMEを設定してあげます。aliasを利用するメリットはCNAMEであれば２回DNS問合せが発生しますがaliasであれば1回しかDNS問合せが発生しません。

EC2でSorryサーバ構築

EC2でElasticIPを振り、apache上にSorryコンテンツを構築してあげればOKです。
先ほどの※の部分をEC2のElasticIPを設定してあげます。
ちなみに私はこんな感じで設定しました。

レコードセット	設定値
sorry.uzresk.jp	EC2のElasticIP
www.uzresk.jp	Primary:ELB Endpoint
www.uzresk.jp	Secondary:sorry.uzresk.jp

apacheで503を返しつつRetry-Afterヘッダを設定

こんな感じ。こうしておくことでロボットに今は一時的に落ちてるからまたあとで来てね。ってお知らせします。

httpd.conf

ErrorDocument 503 /index.html

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} !=/index.html
  RewriteRule ^.*$ - [R=503,L]
</IfModule>

<IfModule mod_headers.c>
  Header set Retry-After "Mon, 1 Dec 2014 9:00:00 GMT"
</IfModule>

Sorryサーバがシングルポイントじゃない？

気になる場合、じゃあ冗長化しよう。ではなくてAutoHealingを使って常に１台だけ立ち上がっている状況を作っておきます。
そこまでやらんでも・・・という声は放っておいて勉強のためにやってみます。

こんな構成になります。

AutoHealingって？

AutoHealingとはAutoScalingの起動インスタンス数のminとmaxを同じ数にしておくことで落ちたらお化けのように復活することを指します。

手順

1. autoscalingするインスタンスを決める必要があります。今回は作ったSorryサーバのインスタンスのAMIイメージを取得しておきます。
2. ELBの設定を行います。(subnetの設定だけ気をつけましょう）
3. LaunchConfigurationの設定を行います。

Lanch Configuration - MyAMI - [1で作成したAMIを指定]

あとはEC2のインスタンスを作る手順と同じです。
4. AutoScalingGroupの設定を行います。

ここがポイントです。

設定値	解説
LoadBalancing	AutoScalingGroupをLB配下に置く場合チェック
HealthCheckType	EC2が正常か異常かを判断するポイントです。EC2とした場合runningとなったら正常と判断します。ELBとした場合ELBのHealthCheckを利用します。
Health Check Grace Period	EC2インスタンスがAutoScalingで立ち上がった後、ELBがヘルスチェックするまでのタイミングです。これが短すぎるとUnHealthy→EC2をTerminate→起動の無限ループに陥ります

5.ELB配下のサーバを管理画面でTerminateしてみて、自動でインスタンスが立ち上がってきたら成功です。起動、停止などの通知が欲しければ、SNSの設定をし、Notificationを追加しましょう。

勉強のためにやってみましたが・・・・

• MultiAZ構成のアーキテクチャではSorryページの存在すら必要なのか・・・とも正直思っています。2重障害は考えないっていう要件もありますのでここまでやることがベストなのかは微妙です。
• MultiAZ構成でシステムが構築されている場合、Sorryサーバは別リージョン(例えばシンガポール)に持っていくべきでしょうね。レイテンシが「もし」気になるならCloudFrontなどと組み合わせておいても良いかもしれませんがやり過ぎ感たっぷりです。