AWS EC2インスタンスにデプロイしたアプリからの応答が不安定です。

Question

前提・実現したいこと

AWSにlaravelアプリをデプロイし、SSL化を行っています。

AWSのネットワーク構成は以下です。

【ELB】
・セキュリティグループ(インバウンド)
http 80 0.0.0.0/0
https 443 0.0.0.0/0
（httpはhttpsにリダイレクト）

【EC2インスタンス】
・nginx ポート80
・セキュリティグループ(インバウンド)
http 80　ソースはELBのセキュリティグループ

【RDS】
RDBMS MySQL
・セキュリティグループ
MySQL 3306 ソースはEC2のセキュリティグループ

発生している問題

接続が不安定です。アクセスした際にページが表示されるまでに数十秒を要する場合もあれば、瞬時に表示される場合もあります。また、時に502 Bad Gatewayになります。
また、リロードや通常のリンク移動でも同様に時間が掛かるケースと掛からないケースがあります。
原因の切り分けができず、詰まっています。

試したこと

メモリ使用率をcloudwatchから参照できるようにしました。
それも含め、１時間のEC2のモニタリング結果は以下です。この１時間の間に複数回サイトにアクセスしており、何度も上記の問題が発生しています。




以下はメモリです。

ELBのログを取得しました。

h2 [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.000 0.001 0.000 200 200 678 4440 "GET https://[アプリのドメイン]" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "200" "-" "-"

https [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.008 0.000 404 404 421 6854 "GET https://[アプリのドメイン]" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "404" "-" "-"

ELBのメトリクス

補足情報（FW/ツールのバージョンなど）

アプリ情報
バックエンド　　　言語 / FW : PHP / Laravel8
フロントエンド　　言語 / FW : JS / Vue.js2
RDBMS : MySQL

ご回答いただけると有り難いです。よろしくお願いします。

Comments

[AbeTakashi]

502のBad Requestはロードバランサー側で出しているのか？ それともEC2インスタンス上のnginxが出しているのか？ その場合のエラーログはどうなっているのか？ この辺の情報はいかがでしょうか？

[trigger]

ご回答ありがとうございます！
ロードバランサーのログを確認してみたところ、以下のログを見つけました。

h2 [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.000 0.001 0.000 200 200 678 4440 "GET https://[アプリのドメイン]" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "200" "-" "-"

https [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.008 0.000 404 404 421 6854 "GET https://[アプリのドメイン]" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "404" "-" "-"
また、ELBのメトリクスより、ClientTLSNegotiationErrorCountから1が検出されました。

[AbeTakashi]

なるほど、ロードバランサーのログはエラーは404ですね。同じURLにアクセスして200と404が出るのはちょっと不思議です。たとえばロードバランサーにターゲットが複数設定されていて、片方がちゃんとデプロイされていないとか？？？　nginx側にも何かしらログが出ていると思いますが、yu_1985さんの指摘と合わせてその辺も含めて精査されるといいかと思います。現状の情報だと私にはちょっと分からないです、すいません。

[trigger]

再度確認してみたところ、404エラーを返しているリクエストに、不審な点がありました。

httpsで送信されたリクエストに、何度も存在しないURLへのアクセスがありました。
例えば、GET https://ドメイン:443/category/indonesian-brides-186のように、ドメイン下にアプリとは全く関係の無い文字列で構成された存在しないディレクトリやファイルにアクセスしています。この文字列はhttpsリクエスト毎、毎度違っており、勿論それが存在しないために404エラーが返っているようです。

Answer 1

申し訳ないです。自己解決致しました。

原因は、サブネットとルーティングの設定に誤りがあったためでした。
２つあるサブネットのうち、片方にインターネットゲートウェイへのルーティングを設定していませんでした。
そのため、２つのサブネットのうち、設定されていない方に割り振られた通信は接続ができず、そうでない方は正常に応答があるため、動作が不安定という結果になっていたのだと思います。

それぞれの役割への認識が甘かったと痛感したので、勉強し直そうと思います。
回答と修正依頼をしてくださったお二方、大変ありがとうございました。

Answer 2

切り分けるためには、切り分ける必要のある先の情報をすべて見る必要があります。
リクエストが送られて、どこで受けてどこで送られてどこで処理されてクライアントに返されるか、
の流れのどこかで問題が発生していると思われますが、ここで見ているのは恐らくEC2の情報だけでしょう。
しかし上記の流れの中に登場するのはEC2だけではありません。
一応、502が発生しているということはクライアントではなくリクエストを受ける側でどこかエラーが発生しているのではないかと想像はできます。

貼られている情報でわかることはCPU使用率には全く問題がなさそうということぐらいです。
メモリ使用量を見られるようにしたと書いてありますが、スクショには含まれていません。
細かくいうと、どのリソースのメトリクスかがわかりません（恐らくEC2だと思って書いていますが…）

EC2のリソースについてはもちろん見るべきですが、他に見るべきはこんな感じだと思います。

• ALBのメトリクス、ログ
  ALBで502が出ていたり応答遅延が発生していないか。出ているならどこで出ているか
• nginxのログ
  nginxでエラーや応答遅延が出ていないか
  出ているならどのようなときに出ているかを他の各ログと突き合わせて確認する
  nginxがLaravelにリクエストを振り分けている時にエラーになっているなら振り分けた先のLaravelの応答でエラーになっている可能性も高い。
• Laravelのログ

　Laravelがエラーや応答遅延が出ていないか
出ているならどのようなときに出ているかを他の各ログと突き合わせて確認する

• RDSのメトリクス、必要があればクエリのログ
  RDSのリソース不足、応答遅延やスロークエリなど発生していないか
  発生しているならどのような時に発生しているか、を他の各ログと突き合わせて確認する
• 共通
  どのようなリクエストを送ったときに問題が発生しているかを発生時刻とログを突き合わせて確認する

ざっと書いたので抜けはあるかもしれません。

Comments

[trigger]

ご回答ありがとうございます。

ELBのログを取得してみたところ、httpsリクエストにおいて不審な点がありました。
以下のように、ドメインの後に存在しないファイルやディレクトリにアクセスしているように見えるログです。

https [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.008 0.000 404 404 421 6854 "GET https://[アプリのドメイン]/category/indonesian-brides-186 HTTP/1.1" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "404" "-" "-"

https [レスポンス生成時刻] [対象ロードバランサーのリソースID] [クライアントのIPアドレス:ポート番号] [リクエストを処理したターゲットのIPアドレス] 0.008 0.000 404 404 421 6854 "GET https://[アプリのドメイン]/cart?remove_item=[ランダムっぽい文字列] HTTP/1.1"" /省略/ "forward" "-" "-" "[リクエストを処理したターゲットのIPアドレスとポート]" "404" "-" "-"

不正アクセスのような匂いがするのですが、どう対処すれば良いのでしょうか。。

[yu_1985]

それは対処の必要があるところですが、質問の範疇外ではないでしょうか…。
インターネットに公開しているものはほぼ確実にそういったアクセスを受けます。
接続元IPを調べてどこからのアクセスかを確認したり、ALBを使っているならAWS WAFを使ってそのIPや場合によっては地域ごとアクセスを拒否するとかしてください。

それはそれとして、そのアクセスが応答が不安定なことと相関があるかはこれだけでは不明です。
これだけでは「404になるアクセスがあったという事実がわかっただけ」です。

応答に時間がかかったりBad Gatewayが発生したときにメトリクスになにか変化が起こっているか、そのときにログになにか出ているか、等を突き合わせてください。

[trigger]

ありがとうございます。
なるほど、必ずしも関係があるとは言えないんですね。。。
つい、これが原因なのかと思ってしまいました。

もう少し突き詰めてみます。

[yu_1985]

より正確には「原因とする根拠がない」ですね。

404が発生している時刻と応答が不安定になったタイミングが重なっていれば関係がある可能性はあるかもしれませんが、1時間分のCPU使用率にもメモリ使用率にも目立った変化がないので少なくともそれによってリソースが消費されて重くなったわけではないでしょう。
貼ってくれたスクリーンショットでは他のメトリクスも目立った変化はありません。
つまり、404の発生と応答遅延が起こったことを結びつけるものが今の所見いだせているとは言い難いです。

各ログ等を見て、404が発生している時刻に何か起こっていることがわかったらそれが関係あるかもしれません。
まずは現象が起こった時刻に合わせて何が記録されているか調べてみてください。
その結果、もしかしたら関係あることがわかるかもしれないし、逆に関係ないことがわかるかもしれません。