Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSのマネージドサービスをつかったバッチ処理の実装 / Develop Batch proc...
Search
Ryohei Sogo
May 14, 2022
Programming
0
250
AWSのマネージドサービスをつかったバッチ処理の実装 / Develop Batch processing by using AWS managed services
NCDC Dev Meetpup
AWSなんでもLT#5で発表した内容です。
AWSの各種マネージドサービス、サーバレスのサービスを組み合わせてバッチ処理を実装しました。
Ryohei Sogo
May 14, 2022
Tweet
Share
More Decks by Ryohei Sogo
See All by Ryohei Sogo
フルリモートワークでのエンジニアマネージャーの悩み
rsogo
0
43
振り返りで続ける勉強会
rsogo
0
1.5k
Other Decks in Programming
See All in Programming
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
200
ある日突然あなたが管理しているサーバーにDDoSが来たらどうなるでしょう?知ってるようで何も知らなかったDDoS攻撃と対策 #phpcon.2024
akase244
2
400
テストコード書いてみませんか?
onopon
2
210
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
160
Kaigi on Railsに初参加したら、その日にLT登壇が決定した件について
tama50505
0
110
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
360
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
300
毎日13時間もかかるバッチ処理をたった3日で60%短縮するためにやったこと
sho_ssk_
1
350
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
340
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
4
350
良いユニットテストを書こう
mototakatsu
8
3.1k
テストコード文化を0から作り、変化し続けた組織
kazatohiei
2
1.5k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
The Cult of Friendly URLs
andyhume
78
6.1k
A better future with KSS
kneath
238
17k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
A Tale of Four Properties
chriscoyier
157
23k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Mobile First: as difficult as doing things right
swwweet
222
9k
Transcript
マネージド・サービスと サーバレスでバッチ処理を実装した話 NCDC Dev Meetup AWSなんでもLT会#5 2022年5月13日 十川 亮平
自己紹介 NCDC株式会社 十川 亮平 (そごう りょうへい) IoTプラットフォーム製品の プロダクトマネージャー。 AWS関連のアーキテクチャの 設計や、バックエンドを 担当しています。
やりたかったこと 別システム FTPでファイル受 信 重たい データ変換処理 変換後のデータを WebアプリのDBに 入れる EC
サイトで別システムから 各種マスタファイルが来るので、変換 処理を行い、 Web アプリケーションから 使用する DB に投入する
極力インフラ運用やりたくない! サーバー障害とかAWSさんに任せたい スケール勝手にして欲しい
こういう構成で実現しました 別システム AWS Transfer family for SFTP S3 受信ファイル 置き場
EventBridge ファイルが 置かれたことを 契機に起動 StepFunctions 処理フロー 制御 1. 前処理 2.データ変換 変換用Aurora Serverless DynamoDB Webアプリケーショ ンから利用 3.データ登録
他システムからのファイルの受信 ファイルはS3に送って欲しいけ ど他システムはSFTP、 FTPS、FTPしか対応できな いって言ってる・・・
そんなときはAWS Transfer Family 別システム AWS Transfer family for SFTP S3
受信ファイル 置き場 FTPサーバー 管理しなくて良 くて楽〜 SFTP, FTPS, FTPでファイルを受け付け、 AWS S3、EFSにファイルを配置してくれるサービス
処理フロー制御と実行基盤:StepFunctions + Lambda バッチ処理の実行基盤の候補は沢山ありますが、 StepFunctions + Lambdaで行いました。 S3 受信ファイル 置き場
EventBridge ファイルが 置かれたことを 契機に起動 StepFunctions 処理フロー 制御 1. 前処理 2. データ変換 3. データ登録
StepFunctions + Lambdaを選択した理由① • このバッチ処理はファイルが来たら動くので、常にインス タンスが存在する必要はない S3 受信ファイル 置き場 EventBridge
ファイルが 置かれたことを 契機に起動 StepFunctions 処理フロー 制御 1. 前処理 2. データ変換 3. データ登録 • マネージド・サービスと サーバレスの組み合わ せでメンテナンスがかな り楽 • 変換処理に使用する データベースもAurora Serverlessにし、コスト を抑えることができた
StepFunctions + Lambdaを選択した理由② • 複数の処理を順番に実施したり、 一部は並列処理するのでフロー制御はやりたかった • StepFunctionsの実行結果とLambdaのログをCloudWatchにて監視 StepFunctions の
処理失敗を CloudWatch から監視 SNS topic 経由でメール通知 CloudWatch
StepFunctions + Lambdaを選択した理由③ 実行基盤はLambdaを利用しました • Lambdaの実行時間の制約である15分以内に1ステップ分の処理が 完了できる見込みがあったので、コンテナでやる必要がなかった • 変換処理のロジックはスクラッチで書きたかった (データ変換用のツール、フレームワークを使うほどでもなかった)
EventBridge まとめ AWSの各種マネージドサービス、サーバレスなサービスを組み合わせた バッチ処理は開発時も、運用時も非常に楽ができました。 アプリケーションの実行基盤はAWS Lambdaを使いましたが、 ここは用途に合わせていんな組み合わせがありそうだなと思います。 Transfer family S3
StepFunctions Lambda Aurora Serverless
ありがとうございました