{
  "$type": "site.standard.document",
  "canonicalUrl": "https://blog.nove-b.dev//posts/deploy-nestjs-aws-lambda",
  "path": "/posts/deploy-nestjs-aws-lambda",
  "publishedAt": "2023-06-25T00:00:00.000Z",
  "site": "at://did:plc:2atly2y5kfyjcj5zap6pv4wd/site.standard.publication/3mmxeqr2tcb2k",
  "tags": [
    "aws",
    "lambda",
    "nestjs",
    "作業ログ"
  ],
  "textContent": "個人開発プロジェクトのバックエンドをNestJSで作成した。 公開したいので、awsのLambdaに乗せて動かしてみることにした。\n\n初めてのaws、いつかの自分のために記録として一挙手一投足のログを残しておくことにする。\n\n前提\n\nバージョンは上記の通り。\n\nで、Dockerの設定ファイルを諸々作ったが、使っていないので、ない前提でいく。\n\nさて、それでは進めていく。\n\nAWSアカウントの作成\n\nAWSの公式ウェブサイトでアカウントを作成する必要がある。\n\nで新規アカウント作成ができる。\n\nその後、認証コードを経て、\n\nAWS アカウント作成の流れを参考にすればいけるけど、意外と時間画かかったし、アカウント作成時にクレジットカードを登録することはいい気がしない。\n\nとりあえず、これでアカウント作成が完了した。\n\n必要なパッケージのインストール\n\nここからはNestJS-サーバーレスの公式を参考にしていく。\n\n> 説明のために、Nest\n> (@nestjs/platform-express完全に機能する HTTP ルーター全体を使用して起動) をサーバーレスフレームワーク (この場合は AWS\n> Lambda をターゲットとしています) と統合します。\n\n公式もawsで説明してくれているので、ありがたい。\n\nまずは上記の通り、必要なパッケージをインストールする。\n\n上記のようなバージョンがインストールされた。\n\n次に、serverless.ymlファイルを作成する。\n\nとりあえず公式をコピペしたやつ。\n\nという風にpackage.jsonに合わせた。\n\nnode.jsのバージョンも揃えたほうがいいのかもだけど、いったんこのままで進める。\n\n次にmain.tsを編集する。\n\nのように変更した。\n\n最後にtsconfig.jsonのesModuleInteropを有効にする。\n\nで、下記コマンドを打つと\n\n> アプリケーションが実行されたら、ブラウザを開いてhttp://localhost:3000/dev/ANY_ROUTE\n> に移動します。\n\nということなので、やってみる。\n\nが、「このサイトにアクセスできません」になる。\n\nそもそもサーバーを立ち上げてないので動くわけがない。\n\nじゃあどうするのか。\n\nいらいらググると、\n\nというコマンドを叩く必要がありそう。てかドキュメントにも書いてあった。\n\nそういうことなので実行してみる。\n\nなんか出たけど、y。\n\n入っていないパッケージを参照するよ、ということらしい。\n\nなんかタイムアウトしてるけど、動いているっぽい。\n\nタイムアウトの原因をデータベースとの接続と考え、データベースを介さない、ただ文字列を返却するだけのエンドポイントを作成し、テストする。\n\n変わらず、タイムアウトした。\n\n仕方ないので、main.tsをまるっとドキュメントのコピペにした。\n\nこれで動けばmain.tsに問題がある。\n\n動かない。\n\n次にserverless.ymlのservice: serverless-exampleを戻したら、データベースを介さないやつは動いた。\n\nそしてまた何回か繰り返すとタイムアウトした。\n\n再度起動しなおしたら、データベースの値を取得出来た。\n\nそういうわけで、main.tsをもとに戻してみる。\n\nタイムアウトした。\n\nmain.tsの原因を探る。\n\nこれにしたら動いた。\n\nの実行場所が問題だったっぽい。\n\nというわけでservice: serverless-exampleをservice: backendに戻した。\n\nこれでサーバーレスのテストをローカルでできた。\n\n追記:2023年6月30日\n\nローカルでテストする際に、timeoutが頻発するので調べたところ、\n\n> プロバイダーの下にタイムアウトを追加します。ラムダのタイムアウトの最大値は 900 秒です。実行時間に応じて 30 秒などに設定し、何が起こるかを確認してください。\n\nという記事を見つけた。\n\n実際に\n\nにしたところ、タイムアウトしなくなった。\n\nAWSにデプロイ\n\n次にawsにデプロイする必要があると思っている。\n\nその為に何をすればいいのか調べて実行していく。\n\nもしかして、コンソールに入り関数を作成し、zipファイルをアップロードすればいいだけ？\n\nそんな気がするのでそれでやってみる。\n\nLambdaの関数作成\n\nAWS Lambda ダッシュボードの 関数を作成をクリックする。\n\n一から作成を選択し、関数名を決める。\n\n次に、関数の記述に使用する言語を選択します。ということでNode.js 14.xを選択した。理由してはローカルでサーバレスのテストをした時のランタイムにNode.js 14.xを使用したので。\n\nよく考えたら18で作ってるんだけど、今回は気にしないことにする。\n\n（※このログを書いた後にNode.js 18.xにした。）\n\nアーキテクチャっていうのは\n\nのふたつがあってよくわからないので、x86_64を選択した。\n\n一応調べてみると下記に詳しい。\n\nhttps://docs.aws.amazon.com/ja\\_jp/lambda/latest/dg/foundation-arch.html\n\nどうやら値段が違うようで、arm64の方が安そうな気がする。\n\nということで、arm64を選択することにした。\n\n（※このログを書いた後にx86_64にした。）\n\nで、関数の作成を終了する。\n\nZip のアップロード\n\n作成後遷移したページでコードタブをクリックし、npm run buildで作成されたdistフォルダをzip化し、アップロードする。\n\nAPI Gatewayの構築\n\n次に API Gatewayのダッシュボードにいき、HTTP APIの構築を行う。\n\n統合で先ほど作成した関数を選択する。API名は特に決まりないよう。\n\n次にルート設定でリソースパスを/{proxy+}に変更する。\n\n最後に「ステージを設定」は変更せず、そのまま 作成をする。\n\nどうやら次に権限の設定があるらしい。\n\nAPI Gateway\nコンソールで、先ほど作成した API の詳細ページを開く。左のタブから、「統合」を選択し、ルートの統合の詳細を見る。\n\nアクセス許可を呼び出すのポリシーステートメント例の、source-arn内の文字列をコピーしておく。\n\nまたLambdaに戻り、設定→アクセス権限、リソースベースポリシー内の アクセス権限を追加をクリック。\n\nAWSのサービス を選択し、下の画像のように入力して保存します。ソースARNに先ほどの文字列を追加。\n\nアクションはlambda:InvokeFunctionを選択する。\n\nURLにアクセスするが、{\"message\":\"Internal Server Error\"}になる。謎が深い。\n\nserverless.ymlにならい、dist/main.handlerにハンドラを変更したが変わらない。\n\n検索するとHTTP API Lambda 統合に関する問題のトラブルシューティングのページにたどり着いたので、見ていく。\n\n最近気が付いたけど、結局公式見るのが一番早い。\n\n急がば回れ、誰が考えたか知らないけど、先人の知恵ほど偉大なものはない。\n\n> 内部サーバーエラーのトラブルシューティングを行うには、ログ形式に $context.integrationErrorMessage ログ記録変数を追加し、HTTP\n> API のログを表示します。これを達成するには、次の操作を行います。\n\nという操作をするらしいけど、何言ってるのか全くわからない。\n\nとりあえず、下記公式の通り進める。\n\nやろうと思ったけど、既にグループがあったので、「ロググループの Amazon リソースネーム (ARN) を書き留めます。」だけやった。\n\n次に下記の公式通りの手順を行う。\n\nNetwork Failureでできない（※ 今思えば、タイムアウトしていた？）。謎が深い。\n\n諦めて、ロググループにあった既存のグループのログを見てみると、@nestjs/coreモジュールを見つけることができない的なことが書いてある。\n\nそれをchat\nGPTに聞くとnode_modulesもアップロードしろという返答が返ってきたので試してみる。\n\n重すぎてあげられない。\n\ns３を使えとのこと。\n\nそういうことであればと思うのだが、お金発生しているのか不安になる。\n\n調べるとAWS 無料利用枠があるっぽいので行ってみる。\n\nアップロードしたs3のデータをLambdaにアップロードする。\n\nリレージョンが異なるので無理っぽい ??\n\nよくよく見ると、Lambdaのリレージョンシドニーでやってた。\n\n東京に作り直す。\n\n東京に作り直したけど、s3のファイルサイズが大きすぎると怒られた。\n\nたぶん、node_modulesにdevDependenciesも含まれているからなので、Dependencies\nのみのパッケージをインストールするnpm install --productionコマンドでnode_modulesを作成する。\n\nついでにzipファイルにpackage.jsonとpackage.look.jsonも入れてみる(結果的に正しかった)。\n\nでも無理で、色々試した結果、distフォルダがダメだということに気が付いた。\n\nつまり、\n\n- package.json\n- node_modules\n- main.ts etc\n\nという構成にしなければならないことに気が付いた。\n\nかつ、bcryptが使用できないいっぽいのでbcryptjsを使用するこにした。\n\nで、あげたら今度はタイムアウトになった。 すこしづつ進んでいるが、まだできない。\n\n基本設定でタイムアウトを30秒にした。\n\n次に秘密鍵のエラーが出た。\nJWTの秘密鍵をenvで管理しているのだからそりゃそうだ。\n\n環境変数を設定すると、ログからエラーが消えたが、{\"message\":\"Service Unavailable\"}という結果になる。\n\n新しい。\n\nログを見るとUnable to connect to the databaseということなのでデータベースに接続てきていないらしい。\n\nローカルのMySQLに接続できないだろし、これを機にRDSの構築をすることにした。\n\nRDSの作成\n\nやり方は公式に詳しかったのでそのようにした。\n\n同時にLambdaの環境変数を編集した。\n\nでエンドポイントを叩いたが、\n\nうまくいかない。\n\n色々と調べてみると、IMAロールとVPCの設定が必要とのこと。\n\nhttps://qiita.com/kobayashi\\_0226/items/d8f97c652873d80b1367\n\n上記記事を見つつ、ぽちぽちやっているとできた。\n\nただ、どうも接続できないエンドポイントがある。\n\n調べてみるとNestJSのsynchronizeオプションをTrueにしたままだったのが原因っぽい。\n\n次は踏み台サーバーを作成し、RDSの中身を見てみる。",
  "title": "NestJsで作成したプロジェクトをAWSのLambdaにあげて動かすまでの作業ログを残しておく"
}