AWS Lambda & API Gatewayを利用したサーバレスアプリのエラーコード502(Bad Gateway)が出たときの対処法


2019/12/14

普段は正常動作していたServerlessフレームワークでデプロイしたサービスから、突如として
502のステータスエラーコードで異常停止するようになりました。

サーバー側で何か起こっているようなので、今回のエラーの原因を調査し、解決してみます。


502 Bad Gateway

Mozillaのドキュメントによると、502 Bad Gatewayは、ゲートウェイとして機能しているサーバーより上流のサーバーから無効なレスポンスが返ってきた時に出るエラーとのこと。

まずは何はともあれ、
AWS CloudWatchのコンソールで、エラーの詳細をログから確認することから始めます。


AWS CloudWatch

AWS CloudWatchはAWSで稼働しているアプリケーションやリソースの稼働状況を監視し、ログやメトリクス、アラームなどで、異常を感知したり、問題解決の糸口を与えてくれる最も重要なサービスの一つです。

早速、CloudWatchのダッシュボードにアクセスすると、

合同会社タコスキングダム|蛸壺の技術ブログ

問題の起こったと思しきAPIに、502が出現した時刻が刻まれております。

次に問題が起こった時刻から、その時のエラーの詳細をログから解析していきます。

すると、エラーの詳細が以下のように得られました。

合同会社タコスキングダム|蛸壺の技術ブログ

…これは上流のLambdaが
10秒を超えたのでタイムアウトしてしまった、という内容が記録されているようです。


Lambda側を調べる

では上流で機能させているLambdaの関数インスタンスをLambdaのダッシュボードで確認します。

するとLambdaの設定で、

合同会社タコスキングダム|蛸壺の技術ブログ

というように、そう言えば現在割り振っているメモリサイズ
192MBとタイムアウト時間10秒に気付きました。

今回の
502エラーの原因は、Lambdaの処理時間の上限に引っかかって処理未完了で落ちていたことにあったようです。


対処法

今回は以下の主に3つのどれかで解決できそうです。

            
            1. メモリサイズを増やす:
    Lambda自体の計算処理速度を向上させます。

2. タイムアウト時間を延ばす:
    処理時間はそのままにして、タイムアウトまでの上限時間を増やします。

3. 処理させる負荷を軽減する:
    重い処理になっているリソースそのものをコンパクトに最小化するか、
    もしくは、リソースそのものを取り除くことで、処理時間を減らす。
        
手っ取り早く、この問題を解決させるなら、項目1 & 2で対処するすべきかと思います。

どのくらいスケールアップさせるかは、以下のLambdaの料金表とにらめっこしながら、自身のサービスにあったメモリサイズとタイムアウト時間を選択します。

AWS Lambda 料金

早急な対応が求められない状況で、時間に余裕があり、コーディングレベルでどうにかなりそうなら、項目3で対処するのも良いと思います。

今回は、Lambdaで読み込んだ画像リソースの数が多かったようなので、画像の読み出し数を減らすと、
502のエラーが出なくなりました。


まとめ

AWSを利用する場合には、CloudWatchをうまく活用することで、効率の良いトラブルシューティングを可能になります。

サーバー側で何か起こったら、すぐさまCloudWatchのコンソール画面を確認しましょう。
記事を書いた人

記事の担当:taconocat

ナンデモ系エンジニア

主にAngularでフロントエンド開発することが多いです。 開発環境はLinuxメインで進めているので、シェルコマンドも多用しております。 コツコツとプログラミングするのが好きな人間です。