カテゴリー
AWS Lambda & API Gatewayを利用したサーバレスアプリのエラーコード502(Bad Gateway)が出たときの対処法
※ 当ページには【広告/PR】を含む場合があります。
2019/12/14
普段は正常動作していたServerlessフレームワークでデプロイしたサービスから、突如として
502サーバー側で何か起こっているようなので、今回のエラーの原因を調査し、解決してみます。
AWSでの502 Bad Gatewayエラー
Mozillaのドキュメントによると、通常、
この場合、何かしらのサーバーエラーが起こっているのは間違いないので、まずは何はともあれ、
AWS CloudWatchAWS CloudWatch
早速、CloudWatchのダッシュボードにアクセスすると、
問題の起こったと思しきAPIに、502が出現した時刻が刻まれております。
次に問題が起こった時刻から、その時のエラーの詳細をログから解析していきます。
すると、エラーの詳細が以下のように得られました。
…これは上流のLambdaが
10秒を超えたのでタイムアウトLambdaを調べる
では上流で機能させているLambdaの関数インスタンスをLambdaのダッシュボードで確認します。
するとLambdaの設定で、
というように、そう言えば現在割り振っているメモリサイズ
192MB10秒今回の
502対処法
今回は以下の主に3つのどれかで解決できそうです。
1. メモリサイズを増やす:
Lambda自体の計算処理速度を向上させます。
2. タイムアウト時間を延ばす:
処理時間はそのままにして、タイムアウトまでの上限時間を増やします。
3. 処理させる負荷を軽減する:
重い処理になっているリソースそのものをコンパクトに最小化するか、
もしくは、リソースそのものを取り除くことで、処理時間を減らす。
手っ取り早く、この問題を解決させるなら、項目1 & 2で対処するすべきかと思います。
どのくらいスケールアップさせるかは、以下のLambdaの料金表とにらめっこしながら、自身のサービスにあったメモリサイズとタイムアウト時間を選択します。
早急な対応が求められない状況で、時間に余裕があり、コーディングレベルでどうにかなりそうなら、項目3で対処するのも良いと思います。
今回は、Lambdaで読み込んだ画像リソースの数が多かったようなので、画像の読み出し数を減らすと、
502まとめ
AWSを利用する場合には、CloudWatchをうまく活用することで、効率の良いトラブルシューティングを可能になります。
サーバー側で何か起こったら、すぐさまCloudWatchのコンソール画面を確認しましょう。
記事を書いた人
ナンデモ系エンジニア
主にAngularでフロントエンド開発することが多いです。 開発環境はLinuxメインで進めているので、シェルコマンドも多用しております。 コツコツとプログラミングするのが好きな人間です。
カテゴリー