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においた場合を実装します。
こんな構成になります。

![image](https://qiita-image-store.s3.amazonaws.com/0/57686/c1eade2f-7773-4ab2-8602-cca9c3a5cfd7.png)

## SEO対策版Sorryサーバ
S3はSorryコンテンツを返却するときにはHTTPResponseCode200で返却することと、HTTPHeaderを変えることができないため、ロボット対策としては不十分です。
SEO対策として503で返却することとRetryAfterヘッダを付けてあげることで対策します。
こんな構成になります。
![image](https://qiita-image-store.s3.amazonaws.com/0/57686/e0337577-488c-03ef-dc76-66dd487c2998.png)

# 前提事項

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を使って常に１台だけ立ち上がっている状況を作っておきます。
そこまでやらんでも・・・という声は放っておいて勉強のためにやってみます。

こんな構成になります。

![image](https://qiita-image-store.s3.amazonaws.com/0/57686/7f7f095c-f1fd-f0d8-41da-4973a5409da8.png)


## 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などと組み合わせておいても良いかもしれませんがやり過ぎ感たっぷりです。