※ 当ページには【広告/PR】を含む場合があります。
2019/12/14
普段は正常動作していたServerlessフレームワークでデプロイしたサービスから、突如として502のステータスエラーコードで異常停止するようになりました。サーバー側で何か起こっているようなので、今回のエラーの原因を調査し、解決してみます。
【AWS独習術】AWSをじっくり独学したい人のためのオススメ書籍＆教材特集
AWSでの502 Bad Gatewayエラー
Mozillaのドキュメントによると、通常、502 Bad Gatewayは、ゲートウェイとして機能しているサーバーより上流のサーバーから無効なレスポンスが返ってきた時に出るエラーとのこと。この場合、何かしらのサーバーエラーが起こっているのは間違いないので、まずは何はともあれ、AWS CloudWatchのコンソールで、エラーの詳細をログから確認することから始めます。
【AWS独習術】AWSをじっくり独学したい人のためのオススメ書籍＆教材特集
AWS CloudWatch
AWS CloudWatchはAWSで稼働しているアプリケーションやリソースの稼働状況を監視し、ログやメトリクス、アラームなどで、異常を感知したり、問題解決の糸口を与えてくれる最も重要なサービスの一つです。早速、CloudWatchのダッシュボードにアクセスすると、問題の起こったと思しきAPIに、502が出現した時刻が刻まれております。次に問題が起こった時刻から、その時のエラーの詳細をログから解析していきます。すると、エラーの詳細が以下のように得られました。…これは上流のLambdaが10秒を超えたのでタイムアウトしてしまった、という内容が記録されているようです。
【AWS独習術】AWSをじっくり独学したい人のためのオススメ書籍＆教材特集
Lambdaを調べる
では上流で機能させているLambdaの関数インスタンスをLambdaのダッシュボードで確認します。するとLambdaの設定で、というように、そう言えば現在割り振っているメモリサイズ192MBとタイムアウト時間10秒に気付きました。今回の502エラーの原因は、Lambdaの処理時間の上限に引っかかって処理未完了で落ちていたことにあったようです。対処法
今回は以下の主に3つのどれかで解決できそうです。手っ取り早く、この問題を解決させるなら、項目1 & 2で対処するすべきかと思います。どのくらいスケールアップさせるかは、以下のLambdaの料金表とにらめっこしながら、自身のサービスにあったメモリサイズとタイムアウト時間を選択します。AWS Lambda 料金早急な対応が求められない状況で、時間に余裕があり、コーディングレベルでどうにかなりそうなら、項目3で対処するのも良いと思います。今回は、Lambdaで読み込んだ画像リソースの数が多かったようなので、画像の読み出し数を減らすと、502のエラーが出なくなりました。
【AWS独習術】AWSをじっくり独学したい人のためのオススメ書籍＆教材特集
まとめ
AWSを利用する場合には、CloudWatchをうまく活用することで、効率の良いトラブルシューティングを可能になります。サーバー側で何か起こったら、すぐさまCloudWatchのコンソール画面を確認しましょう。
