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
330
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
67
振り返りで続ける勉強会
rsogo
0
1.7k
Other Decks in Programming
See All in Programming
ZeroETLで始めるDynamoDBとS3の連携
afooooil
0
140
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
1
260
バイブスあるコーディングで ~PHP~ 便利ツールをつくるプラクティス
uzulla
1
310
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
36
11k
フロントエンドのパフォーマンスチューニング
koukimiura
7
2.4k
JetBrainsのAI機能の紹介 #jjug
yusuke
0
170
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
3
770
Comparing decimals in Swift Testing
417_72ki
0
160
変化を楽しむエンジニアリング ~ いままでとこれから ~
murajun1978
0
650
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
5
740
中級グラフィックス入門~効率的なメッシュレット描画~
projectasura
4
2.3k
Claude Code と OpenAI o3 で メタデータ情報を作る
laket
0
100
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
A Tale of Four Properties
chriscoyier
160
23k
Building Applications with DynamoDB
mza
95
6.5k
Optimizing for Happiness
mojombo
379
70k
Facilitating Awesome Meetings
lara
54
6.5k
Building Adaptive Systems
keathley
43
2.7k
How to Ace a Technical Interview
jacobian
278
23k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
A better future with KSS
kneath
238
17k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
870
Practical Orchestrator
shlominoach
190
11k
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
ありがとうございました