Slide 1

Slide 1 text

Lambdaの特徴を 理解して活用する 次世代本部 次世代会計Eチーム 前場 佑太

Slide 2

Slide 2 text

Agenda • 取引情報取込サービスをLambdaで作りました • こんな理由でLambdaを選びました • Lambdaでよかったこと • Lambdaでイマイチだったこと • どんなときにLambdaを選ぶようにしたいか

Slide 3

Slide 3 text

取引情報取込サービスをLambdaで作りました • SMART分割プロジェクトにおける取引情報取込サービスを Lambdaで開発することにしました • 取引情報取込サービスとは • 取引の元情報を非同期で会計Nextへ連携するサービス

Slide 4

Slide 4 text

こんな理由でLambdaを選びました • LambdaとするかECSとするか • メッセージングサービス(SQS)を介した 非同期のデータ連携を行うことは決まっていた • Lambdaを利用することで実装ボリュームを減らすことができる • 複雑な処理をするわけではないので、実行時間も問題はなし • スループットについても問題なし • LambdaでNGな理由がない

Slide 5

Slide 5 text

Lambdaでよかったこと • 実装ボリュームが抑えられた • 並列処理 • ポーリング • CDにおいても柔軟にデプロイ方法を設定することができた

Slide 6

Slide 6 text

Lambdaでイマイチだったこと • 実装 • New RelicのAPM関連のライブラリが利用できなかった(C#) • Secrets Managerの情報を取得するのに手間がかかる(実装が必要) • ECSだったら不要。。

Slide 7

Slide 7 text

• 実行時間の制限 • Lambdaの最大実行時間は15分 • RDSへのデータ登録処理がデータ件数に比例して増加した • 最大実行時間を超えてしまうようなデータ量で連携された場合、 手動でのリカバリー対応が必要になってしまう Lambdaでイマイチだったこと

Slide 8

Slide 8 text

• リトライ • SQSの可視性タイムアウトを利用してリトライを実現 • 可視性タイムアウトは二重処理を防ぐためにLambdaの 想定実行時間より長くとる • →可視性タイムアウト時間=リトライ待機時間 • 非同期ではあるものの、レスポンスタイムを気にする必要はあった Lambdaでイマイチだったこと

Slide 9

Slide 9 text

どんなときにLambdaを選ぶようにしたいか • Lambdaで問題がないと確信できたときに、Lambdaを利用する • データ数、サイズなど、処理時間が一定以下であることが保証される場合 • サービスの動作観点だけでなく、オブザーバビリティやCI/CDなど 運用面についても検討済 • アカウント内の同時実行数制限についても検討済 • 期待するスループットが出せるか • アカウント内に他にLambdaがないか