💬

Lambdaで開発をする時に気をつけるシリーズ⑤

2022/04/24に公開約1,600字

15分という壁、しかしその壁は超えなくてよい

みなさんどうも、jey_desunですん
どうですか?つかってますか?Lambda
今回はWebサービスを構築する上で気をつけるほどでもないんだけど、ぶち当たった時に意外にめんどくさくなるのでぶち当たらないようにこういうふうにしてるとかっていうお話

実行時間のタイムアウト

https://aws.amazon.com/jp/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/
まぁ、記事に書いてある通り、Lambdaの実行時間の最大は15分になります。
一見15分って聞くと、えっていう感覚になりそうですが、記事にもある通り、15分を必要とするプログラムは「ビッグデータ分析、バルクデータ変換、バッチイベント処理、統計計算」こういうのかと思います。

そもそも

前述した通り、1起動に15分も実行時間を要するプログラムはビックデータ〜とかになるのでただのWebサービスであれば15分かかるものはそうそうないなと。

でもでも

でもたまに、時間がかかりそうな要件がある時があります。
よく僕が聞くのは、ユーザー連携とかに多いバッチ処理で「数百万行とかあるcsvのデータを加工してDBにレコードを作成する」みたいな。そういう時に、1関数だけでやろうとするとざっくり考えても

  1. CSV読み込み開始処理開始という状態でDB更新
  2. S3から特定のディレクトリから数百万行のを読み込んで1行ずつ加工(※わかりやすいようにディレクトリって言ってます)
  3. 加工したデータをデータベースに保存
  4. 読み込んだCSVをS3内の読み込み済み用のディレクトリに移動
  5. DBにインポート終了みたいな状態で更新
    みたいなことをやっちゃっている。
    (Lambdaじゃないけど、ひどい時とかだとCSV何回も読み込んでるとかあったなぁ。。。)

分けて分けて分けまくる

処理をリスト化した通り、リスト1個をLambda関数一個がやる処理にして分けてあげれば、15分なんてそうそういかないです。
さっきの例で考えると

  1. 関数A: CSV読み込み開始処理開始という状態でDB更新
  2. 関数B: CSV読み込んで、500行区切りで分ける(500は適当なので、ここは1行が持つデータ量だったり負荷との相談)
  3. 関数C: 500行の処理を行う
  4. 関数D: 500行の処理済みデータをDBに保存する ※関数C,Dは行数/500分起動する
  5. 関数E: 全データがDBに入ったことを確認して、CSVを移動させる
  6. 関数F: 読み込み完了という状態にDBを更新する
    みたいな感じにすれば、ひとつひとつの関数がやることは少なくなるので15分は超えることはありませんね。
    唯一、関数Bが行の量によるって感じですが、数百MBくらいであれば全然大丈夫です。
    そもそも数百MBあるcsv開くのなんてむちゃくそしんどいのでそんな要件はほぼあり得ない、プログラム上でしか扱わないCSVであれば、要件として最大行数を設けるなどしましょう。
    それでもそうなりそうだったらありとあらゆる手を使って全力で阻止しましょう。
    そしてそれ以上のことに関してはそれはもうLambdaでは無理なので、Glueなど別のサービスを使うのがいいでしょう。
    実際に僕が作っているサービスでは、ログデータなどをS3、Glue、Athenaなどを使って解析みたいなことしています。

結論

壁を超えるために頑張る時代は終わり、壁を越えないために頑張る時代になっているという

シリーズ一覧

https://zenn.dev/jey_desun/articles/a50d991c9e012d

Discussion

ログインするとコメントできます