【504 Gateway Time-out】【Bad Request】でブログがつながらない!AWSのELBをチェック

504 Gateway Time-out ブログ
この記事は約7分で読めます。

こんにちは。
当ブログは、AWS(Amazonクラウド)の無料枠で運営しています。
今回は、ブログにアクセスできなくなった問題と、解決までの手順をご紹介します。

ブログ作成中。画像をアップしている最中にエラー発生
→URLにアクセスできなくなり「Bad Request」表示
WordPressダッシュボードは「504 Gateway Time-out」

AWSのサーバー障害情報は無いので、私の問題(–;)

・AWSのコンソールにログイン
・直IPアドレスでアクセスを試す
 →つながらない
・ELB(ロードバランサー)を調べるDNS名でアクセスを試す
 →アクセスできた!!そして復活した!(なぜか)

私の場合は、AWSのロードバランサーをチェックして復活しました。
なぜ復活したか分かりませんが、手順をまとめました。参考になれば幸いです。

【追記】
この1週間後、Google砲を機に、完全にブログサーバーが死ぬことになりました。
実は、今回の問題は予兆に過ぎず、
後日「サーバーエラー」があったことを知りました。
なんとなくつながったからOK!ではやばいです。
予兆に気づいたら、本気で取り組みましょう・・・。

Bad Request、504 Gateway Time-outの【問題発生】


当ブログは、問題発生時、アクセスは1日約1,000PV。
だいたい毎日ブログ更新していました。

2020/5/20。朝活でブログ作成中。画像をアップロードしている過程で、エラー!

エラー名は覚えていませんが「 not available picture・・」のようなエラーだったような。

とりあえずブログ下書き保存しようとしたら、保存できない!
そして、次のようなエラーメッセージが表示されることに。

Bad Request

Your browser sent a request that this server could not understand.
Reason: You’re speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

なんと、WordPressのダッシュボードにアクセスできなくなりました。

ブログホームのURLにアクセスしようとすると、

504 Gateway Time-out

終わりました・・・。ブログが見れません。

AWSの障害を願いましたが(笑)、Twitterトレンドに、そんな情報は無く。
私個人の問題。自分で解決するしかありません

後ろ髪を引かれる思いで、この日は本業に出かけました(><)

【原因?】2日前に「 AWS Free Tier limit alert 」メール

帰宅後、思い当たる節をいろいろ試しました。

まずは、2日前に「 AWS Free Tier limit alert 」メールが届いていたこと

【警告】15LCUs for Application load balancersの85%超えた

無料枠(15LCU)の85%超えたよ! って警告です。
「LCU」、「Application load balancers」がキーワード

【注意】英語が出ます!
太字部分だけ、ちら見して。

他は読み飛ばして。帰らないでください

AWS Free Tier usage limit alerting via AWS Budgets 05/18/2020

Your AWS account 447682145526 has exceeded 85% of the usage limit for one or more AWS Free Tier-eligible services for the month of May.

AWS Free Tier Usage as of 05/18/2020 AWS Free Tier Usage Limit

12.84549507 LCU-Hrs | 15 LCUs for Application load balancers

To learn more about your AWS Free Tier usage, please access the AWS Billing & Cost Management Dashboard. You can find more information on AWS Free Tier here.
This alert is provided by AWS Budgets. AWS automatically tracks your service usage and will alert you if you have reached 85% of the usage limit for one or more AWS Free Tier-eligible services. To unsubscribe from these alerts or to change the email address to which you would like your alerts to be sent, please visit the Cost Management Preferences.

LCUとは

メールをみると、LCUが問題っぽいので、LCUとは何か調べる

LCU は Application Load Balancer がトラフィックを処理するディメンションを測定します

https://aws.amazon.com/jp/elasticloadbalancing/pricing/

(中略) また、ロードバランサーは登録されているターゲットの状態を監視して、トラフィックが正常なターゲットにのみルーティングされるようにします。ロードバランサーは、異常なターゲットを検出すると、そのターゲットへのトラフィックのルーティングを中止します。その後、ターゲットが再び正常になったことを検出すると、そのターゲットへのトラフィックのルーティングを再開します。

https://docs.aws.amazon.com/
ja_jp/elasticloadbalancing/
latest/userguide/how-elastic-load-balancing-works.html

なるほど分かりません!

でも今回の原因らしきことが書いてある気がします。
入り口の門番らしきモノですね、たぶん。
とりあえずAWSでそのあたりを見てみます

【一旦解決?】AWSコンソールから、ロードバランサーをチェック

AWSコンソールログイン → できた!

AWSのコンソールにログイン →できた!

AWSのEC2などのサービスは、available や active

とりあえずサーバーは、生存確認です(==; )

続いて、直接IPアドレスでアクセスできるか確認

→ダメです。Bad Request

AWSのロードバランサーを確認

一部伏せます

状態エラーは出ていないようです。

モニタリングを見ると、「Time-out」の件数が、問題発覚以降、大量に発生しています。分かっていますよ。。

なんとなく、「DNS名」の項目にあるアドレスをコピーして、直接アクセス(上図参照)

ブログにつながりました!
14時間ぶりにアクセスできました(^^)

その後、なぜかIPアドレス直打ちでも、ドメイン名でアクセスもできるように!

よくわかりませんが、復活です!

ターゲットが正常になったことを検知したのでしょうか?

もやっとですが、ブログにアクセスできるようになったので、とりあえずインシデント解決!

ちなみに、 AWS Billing & Cost Management Dashboard をみると、

LCUは、93.8%になってました。今月はもうヤバイです。

発端となった、画像の大量アップロードは控えて、 しばらく 恐る恐るテキスト中心に記事更新します。

Bad Request、504 Gateway Time-out 問題まとめ

AWSの場合、これで一旦つながるかもしれません。
・コンソール画面に入り、サーバーが死んでないかまずは確認。
・ELB(ロードバランサー)を確認
・検索画面に「直IPアドレス」や「DNS名」を入力して検索

【後日談】
これは、問題の予兆に過ぎず、本当の戦いはここから始まりました。
直後にGoogle砲をもらいました。

Google砲じゃん!と気づいた裏では

サーバーダウンを繰り返してました。
サーバーのCPU残
左からポコッとへこんだのが、今回のエラー
一気に0になったのがGoogle砲後のエラー
その後、3つの小さな山がありますが、
夜はアクセス減ってCPU回復、昼になるとCPU0になるを3日繰り返しました。

実は、サーバーエラーがあったことを知ります。
TwitterやLineオープンチャットで、AWSに詳しい人に相談しながら
毎晩、深夜3時に手当てしては、昼には死ぬを繰り返しました。

後日書きます!