cloudfrontの設定がうまくいきません

Question

###前提・実現したいこと
route53→ロードバランサ→ec2→RDS（Mysql）
上記のような構成で稼働しているサイトにcloudfrontを導入したいのですがエラーが出てしまいます。
route53→cloudfront→ロードバランサ→ec2→RDS

アプリケーションはwordpressで下記ページを参考にさせていただいています。
http://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13#wp-admin%E3%82%92%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%95%E3%81%9B%E3%81%AA%E3%81%84

サーバはnginx+phpfpm
ドメインはexample.comと仮定させていただきます。

route53の設定は以下のようにしています。
◆example.com ●A-IPv4 address
●Alias Target:dualstack.example-xxxxxxxxx.xxxxxxx.elb.amazonaws.com
(ELBのアドレスを設定）

◆cf.example.com ●A-IPv4 address
●Alias Target:xxxxxxxxxxx.cloudfront.net.
(上記参考サイトにならって設定）

◆www.example.com ●CNAME
●Value:xxxxxxxxxxx.cloudfront.net.
(よくわからずカンで設定）

設定が完了して確認したらロードバランサがOutOfServiceになっていたので
ec2を再起動して再度ロードバランサ側でも定義したのですがOutOfServiceのままです。

###発生している問題・エラーメッセージ
キャッシュを削除してoperaのプライベートブラウザでテストしています。

example.comにアクセスした場合
--------------------------------------------------------------------
ページは機能していません
example.com では現在このリクエストを処理できません。

cf.example.comにアクセスするとexample.comにリダイレクトされ
--------------------------------------------------------------------
ページは機能していません
example.com では現在このリクエストを処理できません。

www.example.comにアクセスすると
--------------------------------------------------------------------
ERROR
The request could not be satisfied.
Bad request. 
Generated by cloudfront (CloudFront)

xxxxx.cloudfront.netにアクセスするとwww.example.comにリダイレクトされ
--------------------------------------------------------------------
ERROR
The request could not be satisfied.
Bad request. 
Generated by cloudfront (CloudFront)

ec2のPublic DNS(IPv4)にアクセスすると少し長めにローディングした後
--------------------------------------------------------------------
ec2-xxxx-xxx-xx-xx.compute.amazonaws.com からの応答時間が長すぎます。

次をお試しください:
接続を確認する
プロキシとファイアウォールを確認する
Windows ネットワーク診断ツールを実行する
インターネットの接続を確認してください。
ケーブルの接続を確認し、ご利用のルーター、モデム、その他のネットワークデバイスを再起動してください。

ファイヤウォールあるいはウイルス対策の設定で、Opera にネットワークへのアクセスを許可してください。
ネットワークへのアクセスを許可されたプログラムとして既に表示されている場合は、 いったんリストから削除し、もう一度追加してみてください。

プロキシ サーバーを使用している場合…
プロキシ設定を確認するか、ネットワーク管理者に連絡してプロキシサーバーが機能しているかを確認してください。プロキシサーバーを使用するべきではないと考えられる場合： メインメニュー > 設定 > プロキシ設定の変更… > LAN 設定にアクセスし、「LAN にプロキシサーバーを使用」のチェックを外してください。

ec2のIPv4パブリックIPにアクセスすると少し長めにローディングした後
--------------------------------------------------------------------
xxx.xxx.xxx.xxxx からの応答時間が長すぎます。

次をお試しください:
接続を確認する
プロキシとファイアウォールを確認する
Windows ネットワーク診断ツールを実行する
インターネットの接続を確認してください。
ケーブルの接続を確認し、ご利用のルーター、モデム、その他のネットワークデバイスを再起動してください。

ファイヤウォールあるいはウイルス対策の設定で、Opera にネットワークへのアクセスを許可してください。
ネットワークへのアクセスを許可されたプログラムとして既に表示されている場合は、 いったんリストから削除し、もう一度追加してみてください。

プロキシ サーバーを使用している場合…
プロキシ設定を確認するか、ネットワーク管理者に連絡してプロキシサーバーが機能しているかを確認してください。プロキシサーバーを使用するべきではないと考えられる場合： メインメニュー > 設定 > プロキシ設定の変更… > LAN 設定にアクセスし、「LAN にプロキシサーバーを使用」のチェックを外してください。

xxxx-xxxx.elb.amazonaws.comにアクセスすると
--------------------------------------------------------------------
ページは機能していません

###試したこと
route53のAレコード設定を変えてみたりしましたが
上手くいきませんでした。
また色々変えている過程でリダイレクトループが発生した際に
wordpressのwp-config.phpに以下を追記し、現状もそのままです。

$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

###捕捉情報
現在前述の参考サイトを基にwordpressのサイトURL、homeURLをcf.example.comに変更しています。
設定直後はページも表示できていました。

###疑問点
route53の設定を変更した際に反映されるまでにタイムラグが5分くらいある気がしました。
cloudfrontもそうですがこれはTTLの秒数で大体反映されるという認識で大丈夫でしょうか。
またCNAME等はTTLの設定欄がないのですがこういった項目の変更は即時反映されるものなのでしょうか。

VPCのACLを設定するという記事も見つけましたがどこから設定するかわかりましたらご教授お願いいたします。
http://www.slideshare.net/hz_ouchi/cloud-front-30133315

Answer 1

ロードバランサがOutOfServiceになっているというのは、CFと関係なく以下ではないでしょうか？

１．ELBのヘルスチェックが失敗している
⇒セキュリティグループの再確認、ヘルスチェックのURLをローカルから叩いて正常なものが返ってくるかを確認

２．ELBが正常にヘルスチェックを実施できていない
⇒時々発生します。ELBからインスタンスの登録を解除し、再登録で解決します

Comments

[ruuusaamarki]

ご回答ありがとうございます！
セキュリティグループについて再度確認してみました。

EC2に設定しているセキュリティグループ
インバウンド
HTTP | TCP | 80 | sg- xxxxxx(LB)
LBに設定しているセキュリティグループsg- xxxxxx(LB)
HTTP(80) | TCP(6) | 80 | 0.0.0.0/0

またVPCに関してもロードバランサとEC2は同一のVPC内に設置されている状態です。

cloudfrontに関しましてはVPCの外に設置するためVPC,セキュリティグループの設定がないと
認識しておりますがこちらは正しいでしょうか。

cloudfrontを設置する前はロードバランサもInServiceでしたが
いつの間にかOutOfServiceになってしまっておりました。
（route53のaレコードを設定したからでしょうか。。。）

また何かお気づきの点がありましたら
ぜひご教授いただけましたら幸いです。

[moonphase]

CFはオリジンサーバからコンテンツを取得するだけとなりますので、そもそもオリジンサーバがコンテンツを返せないとどうしようもできません。

サーバ上から
curl -i http://localhost:ポート/path/to/health_check
した結果はどうなっていますか？
これが想定と異なる場合は、インスタンス上のプロセスがダウンしている可能性があります。

Route53のAレコードを設定してもELBとEC2には何の関係もありません。

CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。
ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、HTTPのみは制限なくアクセス可能です。

厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .'

[ruuusaamarki]

ありがとうございます！早速以下実行してみた結果になります。
curl -i http://localhost:80/path/to/health_check

HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.3
Date: Thu, 23 Feb 2017 03:36:18 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.6.24
Location: http:///

その後いろいろ試していまして
CnameとAレコードの設定を変えており
現在はroute53にNS,SOAと下記Aレコードが設定されているだけの状態です。
◆cf.example.com ●A-IPv4 address
●Alias Target:xxxxxxxxxxx.cloudfront.net.

リダイレクトされているのはそのせいでしょうか。。。

＞Route53のAレコードを設定してもELBとEC2には何の関係もありません。
＞CFからオリジンELBへのアクセスは、ELBのセキュリティグループが適用されます。
＞ELBのセキュリティグループは 0.0.0.0/0 80で設定しているのであれば、
＞HTTPのみは制限なくアクセス可能です。
＞厳密に制限する場合は以下コマンドでCFで利用するIPアドレスの情報がわかります。
貴重な知識ありがとうございます。このあたりが検索しても見つけられませんでした。

＞curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select(.service=="CLOUDFRONT") | .'
こちらのコマンドも実行できましたが
これはcroudfrontが設置されているIPという事なのでしょうか。
他に確認するポイントなどありましたら度々で恐縮ですがまたぜひお願いいたします。

[moonphase]

ELBのヘルスチェックは 200 以外のコードが返ってくると失敗と判定したはずです。
"/path/to/health_check"についてはruuusaamarkiさんの環境に合わせて変更してください。

サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。
例えばserverディテクティブで明示的に指定を行うと、リクエストヘッダのHost:に一致しないリクエストが来た場合、そのブロックのサービスにはアクセスできなかったような・・・
nginxの設定ファイルがあるともう少しわかるかもしれません。

AWS IP範囲の情報は以下にあります。
http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
この内容に従ってCFで利用している情報をjqで抜いただけとなります。
おわかりかと思いますが、IPではなくCIDR IPです。（念のため）

[ruuusaamarki]

確認が遅くなりまして申し訳ありません。書き込みありがとうございます！
curl -i http://localhost:80/index.phpとしてみましたが結果は前述のものと同じでした。

nginxのconfファイルを２つ確認してみました。
server_nameがexample.comだったのでcf.example.comに変えてみました。
またlistenに関しても80;だったものをlisten *:80;に変えてみました。
その後nginxの再起動、php-fpmの再起動をしました。
がこれでcf.example.comにアクセスしてみてもエラーも表示されず
マウスの横の読み込みが何回転かしてそのまま画面も変わらずという状況です。

現状整理してみます。
route53のAレコードcf.example.comのエイリアスにxxxxxxxxxxx.cloudfront.net. を設定
nginxのconfファイルのserver_nameにcf.example.comを設定、listen *:80;を設定
listen *:80;
server_name cf.example.com
wordpressのサイトURL、homeURLにcf.example.comを設定。

＞サーバのローカルから実行して301 RedirectしているのはNginxもしくはAPの設定かと思います。
すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。

＞http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html
＞この内容に従ってCFで利用している情報をjqで抜いただけとなります。
＞おわかりかと思いますが、IPではなくCIDR IPです。（念のため）
すみません、このあたりは全く分かってない状態です。
少し関連記事を読んでみたいと思います。

php-fpmに関しても少し関連がありそうなものがあるか調べてみたのですが
それっぽい情報も見つけられていない状態です。
他に関連がありそうなポイントなどありますでしょうか。

[moonphase]

listen 80;
server_name _;

にしてください。
server_nameはApacheでいうところのVirtual Serverの設定になるかと思います。

> すみません、APの設定はapacheの設定ということで大丈夫でしたでしょうか。

APの設定はこの場合Wordpressに相当するのかな？
php-fpm等使っているならそちらの設定も何か影響してるのかな・・・。
Wordpressをお使いならWordpress側がリダイレクトしていそうです。

CIDRは127.0.0.1/32 という感じで、IPアドレスとマスクでIPアドレスを指定する形式です。

[ruuusaamarki]

コメントありがとうございます！

やっと表示されました。
が、自分でも原因がよくわかっておりませんで
実施したことを書かせていただきます。

・nginxのconfigファイルに以下を設定しました。
listen 80;
server_name _;
・結果はまたリダイレクトループになってしまい、おっしゃる通り原因はwordpress,php-fpm関連かと予想してまずwordpressを切り離して、index.phpをecho "hello";のみに設定したところ表示されました。
ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。
・原因はwordpressの設定と予想してwp-configの設定、データベースでのサイトURL、wordpressURL等を確認、wp-configに設定した下記記述を最下部から最上部に移動しました。
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
・その後数分経ったのちサイトが表示されていました。
ヘッダー情報のX-Cache:RefreshHit from cloudfrontも確認できました。

おそらく最終段階で原因になっていたのはwordpressのwp-config部分で、途中設定を色々変えたりAWS側やnginx等でも間違った設定が残っていたりで複数個所に問題が発生していたんだと予想しています。

長い間お付き合いいただきましてありがとうございました。
今回は本当に色々勉強させていただきました。

[moonphase]

wordpressは本体の設定、プラグインの設定次第ですぐにリダイレクトループになってしまいますよね、私も触っていてよくわからない部分が多いように感じます。
何より解決されてよかったです。