Q&A
ヘルスチェック失敗したりしてませんか？
解決したい課題
Web-serverへのアクセスをCloudFrontで高速化させたい。
負荷分散されている構成
◆負荷分散について
ELB→Web-serverへは負荷分散されアクセスできる。
web-serverは2台用意しており、web-server-1とweb-server-2と名前を付けている。
web-server-1のindex.htmlに「Welcome-1」、web-server-2のindex.htmlに「Welcome-2」と記載したファイルを作成し、リロードするたびに交互に「Welcome-1」と「Welcome-2」が表示されている。
◆名前解決について
Route53のAレコードのエイリアスに「-ELB Application LoadBalancer-」に表示されているものを選択し、購入したドメイン名を紐づけている。
負荷分散されない設定
◆負荷分散について
設定内容は上記同様。
Web-server-1のみアクセスされ、負荷分散されていない。
◆名前解決について
Route53の設定でAレコードのエイリアス設定を「-CloudFrontディストリビューション-」に表示されているものを選択している。
◆CloudFrontについて
SSL Certificateは取得している。
オリジンサーバはELBを選択している。
CNAMEに購入したドメイン名を選択している。
設定したTTLの時間経過後に挙動を確認している。
DistributionStatusはDeployedになっている。
うーん、前はできたのですが、今回は何故できないのか。。。
どなたかアドバイスいただけませんでしょうか。
ずっと、解決できず困っております。つらたん(´･･`)
以上、よろしくお願いいたします(><)
追記
Route53のエイリアスの設定をCloudFrontからELBに戻して、ドメイン名でアクセスしても負荷分散されなくなりました。
Route53のエイリアスの設定をCloudFrontからELBに戻したら、負荷分散されます。
やはり、CloudFrontを介すると、負荷分散されないようですね。。。(´･_･`)
ご回答ありがとうございます！yu_1985さん☺
ロードバランサのターゲットグループのステータスを確認すると、どちらもhealthyとなっているため。ヘルスチェックは問題なさそです。
よく考えたら、そもそもALBにアクセスが行ってなくて、CloudFrontのキャッシュにアクセスしているのでは…と思ったんですが、追記のところの挙動がよくわかりませんね…。
CloudFront、ELB、Webサーバのログを見ながらどこにどうアクセスが記録されるかを実際にアクセスをさせながら見てみてください。
追記の箇所、改めて確認したところ、きちんと負荷分散されるようになりました。CloudFrontを介すと負荷分散されない原因は、ご指摘の通り、CloudFrontのキャッシュにアクセスされている可能性ありますね！
ぐぬぬ、設定が足りていないのかな。。。
CloudFrontのキャッシュにアクセスされた結果ELBにアクセスが来ないのであれば、それは正しい挙動なのではないでしょうか…。
何度もアクセスを繰り返しても負荷分散されませんか？
はい。リロードを繰り返しておりますが、画面は変わりません。
高速化させるためにキャッシュさせているので、画面は変わらないで正しい挙動ですね。。
私の認識が間違っていたということですね。
失礼しました。
てことで、問題解決かな。
ルータを再起動させてグローバルIPを意図的に変え、アクセスしてみて画面が変わるか検証してみよかと思います。今改めて環境構築中です。しかし、現在なぜかRoute53で名前解決されない事象にハマってしまい、頓挫してしまいました。毎回、何かしらの問題が発生します。私はテクノロジーに嫌われています。
> ルータを再起動させてグローバルIPを意図的に変え、アクセスしてみて画面が変わるか検証してみよかと思います。
それは意味ないと思います。CloudFrontのキャッシュが有効な間はオリジンまでリクエストは届きません。
あと、ちゃんとアクセスされながら個々のログを見てください。
きちんと調べえるならアクセスしたときにどこまでリクエストが届いていてどこにはアクセスがないか、というのをそれぞれ見比べてください。
問題が発生するのは仕方ないですが、調査には情報が必要です。
すいません。yu_1985さんの仰っている内容を私が正しく理解できていないかもしれませんが、
もしかしてサーバ側のグローバルIPを変更するという解釈をされてますでしょうか。
言葉足らずですいません。私がイメージしているのは、PC側のグローバルIPを変更することで、別のPCからアクセスさせる状況を疑似的に作り出そうと思てます。
これならweb-server-1と2で負荷分散される認識です。
アクセスログ見ないとですね。
今の検証環境にCloudwatchを設定して確認できるようにしてみます。
自宅のルータを再起動してもグローバルIPは変更されなかたです。
検証不可能ですね。ザンネンだ。
回答1件
0
一応回答の方に
負荷分散元が異なる静的サイトならエッジロケーションにキャッシュされた方にアクセスし続けるはずなので、そもそもオリジンに設定したロードバランサーまでアクセスが届かないのは正常な動作です。
それは「負荷分散できてない」のではなく「CDNのキャッシュにアクセスさせることによって負荷を軽減している」という状態です。
投稿2020/07/04 13:23
総合スコア7588
CloudFrontとELBを接続した構成の正常試験方法がわかりません。
今回構築したシステムが想定通りの挙動になるか確認したいのですが、プライベートの検証環境では難しそうですね(>_<)
検証方法としては、自宅でアクセスした場合とスタバなど行ってそこでアクセスした場合では別々でキャッシュされる想定なので、画面もweb-server-1とweb-server-2で負荷分散されるのではーと考えております。私の認識間違いでしたら申し訳ございません。
そうだ、スマホをルータと切り離してアクセス確認してみます！
あれ？
スマホで確認したらリロードする度にweb-server-1とweb-server-2を交互にアクセスできております。
また、PCでも同様にweb-server-1とweb-server-2を交互にアクセスできております。
つまり、反映されるまでに時間がかかるということでしょうか。
しかし、そするとキャッシュされていないことになりますね。
うーむ。
CloudFrontの設定で最小TTLと最大TTLを変更して確認してみます！
> 検証方法としては、自宅でアクセスした場合とスタバなど行ってそこでアクセスした場合では別々でキャッシュされる想定
いえ、キャッシュされる先はエッジロケーションなので、関係ありません。
CDNについてもう少し調べるとよいかと。
https://knowledge.sakura.ad.jp/19191/
正常試験の前に「何が正常な状態なのか」がわからないと試験になりません。
CloudFrontに静的コンテンツをキャッシュさせることによって物理的に表示速度を高速化したり、オリジンへのアクセスを減らしたりするのが目的のはずなので。
ただ、オリジン側で更新をしたのであればその際にキャッシュを削除しないとキャッシュされた古いコンテンツをキャッシュの有効期限が切れるまでアクセスし続けます。
キャッシュにヒットしなかったときにオリジンへのアクセスがあることになります。
再三書いているとおりですが「アクセスできている」の判断を画面表示でやるのではなく、きちんとそれぞれのログを見比べてください。
でないと、今どこにアクセスして何を参照しているのかが正確に把握できません。
夜分にもかかわらず、たくさんのアドバイスありがとうございます。
ご指摘いただきました通り、再度調べてみますね。
画面表示だけでは正確に判別できないんですね。
現在、nslookupで引けているIPと負荷分散しているweb-serverのIPが一致していないので、もしかしたら想定と違うサーバにアクセスされている可能性もあるのかな。(フシギダナ)
DNSの紐づけを強制的に解除できれば良いのですが、、、
・CloudFrontのキャッシュ
・ELB配下にあるインスタンスA
・ELB配下にあるインスタンスB
のどれにアクセスしたか、画面だけでは判別できないからです。
ログを見ましょう。
単にELBにアクセスして別のサーバに振り分けられていることを確認したいだけだったら画面見るだけでも十分ですが。
> nslookupで引けているIPと負荷分散しているweb-serverのIPが一致していない
それはELBとCloudFrontを噛ませている以上当然ではないでしょうか…。
そか、nslookupで表示されているIPはELBではなくCloudFrontのIPだたんですね！失礼しました。
ログの設定含め、改めて検証環境を作って確認してみます。アクセスログが想定通り出力される環境を構築しないとですね。
アドバイスありがとうございました！????
ねます！
あなたの回答
tips
プレビュー
