The Design for Serverless ETL Pipeline (48:9)

The Design for Serverless ETL Pipeline
データ分析基盤のレガシーなデータロードを
サーバレスでフルリプレースするまでの道のり
株式会社リクルートライフスタイル
山田雄・秋本大樹・白鳥昇治

■山田　雄(ヤマダ　ユウ)
@nii_yan
株式会社　リクルートライフスタイル
ネットビジネス本部データマネジメントG
SIerにて主に組込み系の開発に従事したのち、フリーランスとして独立。フリーラ
ンスの間に、シミュレーションシステムの開発や、大手ECサイトのメールマーケ
ティング用分析基盤の構築を経験。2015年リクルートライフスタイルへ転職。リク
ルートライフスタイルの共通分析基盤を構築する傍ら、chatbotの開発や、メール
マーケティングにも関わる。
ビッグデータ周りの技術が好物。あと焼きそばも好物。

一生のうち、数回つかうサービス
LIFE EVENT
日常的に、つかうサービス
LIFE STYLE

リクルートライフスタイルの
データ分析基盤の歩み

2014
2015
2016
2017
2018
✔TreasureData を一部 BQ へ移行
✔RedshiftSpectrum 導入
✔Redshift をsingle クラスタへ
✔BigQuery 導入
✔NetezzaEOSL
✔DataLake 構成導入
✔Exadata 導入
✔Hadoop 除却
✔TreasureData 導入
✔Redshift のノード拡張
✔オンプレ- AWS 間に専用線導入
✔Netezza のスケール検討
✔Netezza のスケールアウト完了
✔Redshift の multi クラスタ導入
2013
✔リクルート分社化
✔独自の分析基盤 Hadoop 提供スタート
✔Netezza, Redshift 導入

Spectrum
Oracle
Exadata
SPSS
aginity
CHEETAH
DIGITAL
Adobe
Analytics
CSV
外部データ
アクセスログ
アプリログ
HPB
JLN
HPG
事業データ
BigQuery
IBM Watson
Campaign
Automation

■秋本　大樹(アキモト　ダイキ)
2011年新卒としてSIerに入社。
2014年にゲーム会社に転職。ゲームデータを集積する分析基盤の構築、および
社内KPI算出の自動化を行う。
2017年12月よりリクルートライフスタイルに転職。現在は次期ETL基盤の構築と
クラウドAIサービスの社内導入に奮闘中。
最近のいち推しサービスはGoogleColaboratory
趣味は将棋を見ること。竜王戦が楽しみすぎてしょうがない。

■白鳥昇治( シロトリショウジ)　　　　
インフラエンジニアとしてオンプレミスKubernetes環境の開発・運用に従事後、
2017年にリクルートライフスタイルに入社。
データエンジニアとしてデータ分析基盤やサーバーレスな機械学習基盤の開発・
運用などに携わる。
Docker ❤ Kubernetes ❤ CD/CI ❤ Serverless ❤ BigData
夢は山でペンション経営。
@irotoris

レガシーな構成のつらみ

技術のツギハギ ● 自前サーバで動くシェルで書かれたレガシーなコード
○ 800行を超えるシェルスクリプトファイル
● 複数システムをツギハギするスケジュール実行
○ 終了するタイミングを見計らって後続の処理を実行
● データ量に関連した処理の長時間化
Shell
Script
自前サーバ
AWS
GCP

データ間の依存関係 ● 後続のマート作成で用いるテーブルは優先度を高めてロード
する必要がある。
● データマート間にも依存関係がある。
● 現在はJP1での「イベント受信」機能を用いて優先度を実現し
ている。
優先度高
ロード
優先度低
ロード
マートA
作成
マートB
作成
マートC
作成
JP1

スケジュール実行での運用がつらい ● 障害発生時のリカバリが大変。
● 1つの実行単位に複数のテーブルを含めており、テーブル単
位でのロードができていない。
● 前の処理の時間をずらすと、後続の処理も合わせて時間を
ずらす必要がある。JP1

自前サーバでの開発がつらい ● テスト環境がないので気軽にテストできない。
● 本番に影響が出るので古いバージョンでの開発を強いられ
ている。
● 800行を超えるシェルスクリプトのメンテが辛すぎる。
古いパッケージシェルスクリプト
本番に影響が出る

つらみを解消したい
そう、それがMigaloo Project

The Design for Serverless ETL Pipeline

前回のServerlessconf Tokyo !!

● サーバーレスにしてサーバー管理を極力少なく
● イベントドリブンでオーケストレートする構成
● 自動リトライとアラートを作り込んで
● 運用0を目指しました

Q.「いま運用どうですか？」
データ量：増えてる
機械学習バッチのリソース使用量：増えてる

Q.「いま運用どうですか？」
データ量：増えてる
機械学習バッチのリソース使用量：増えてる
A.「全然、運用ないです」

A.「全然、運用ないです」
● Slackのアラート確認はしてるけど、だいたい自動リトライ済み
● データ量も処理量も増えてるけどデータ量に応じてスケールする
● システムモニタリング用途のAmazon Elasticsearch Serviceのリソー
ス見直しの運用を実施

うまくいったので今回もLet's Serverless!!

アーキテクチャ設計思想
● サーバー管理が極力少ないパイプラインと実行環境
● イベントドリブン & 疎結合なアーキテクチャ
● スケーラビリティと処理の並列数の管理
● イベント（データ）のステータス管理と活用
● 運用が楽になるロギング・モニタリング

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
Pipeline(Load to DataLake)
Pipeline(Load to Redshift)
Pipeline(Load to BigQuery)
EventStatus
Serverless ETL Pipeline
+Runtime
+Runtime

Runtime
EventStatus
+Runtime
+Runtime
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)

Runtime
EventStatus
+Runtime
+Runtime
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Data Source
Data Lake
Data
Warehouse

EventStatus
Data Lake (S3)
Redshift / Spectrum
BigQuery
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Runtime
+Runtime
+Runtime

EventStatus
Data Lake (S3)
Redshift / Spectrum
BigQuery
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Runtime
+Runtime
+Runtime
ETL Pipeline
+ Runtime
ETL Pipeline
+ Runtime
ETL Pipeline
+ Runtime

Runtime
Event
サーバーレスなパイプラインと実行環境
● パイプラインはStep Functionsなどのワークフローエンジンと
AWS Lambdaをベースに処理を定義
● 実行環境はスケーラブルなAWS Batch、Glue、GKE
● 要件により一部はオンプレサーバーを利用。これもワークフ
ローからイベントドリブンで実行可能な状態で設計
● ※オンプレのケース：大量データの圧縮処理してからデータ転送
スケール
スケールOKスケール

Runtime
Event
サーバーレスなパイプラインと実行環境
スケール
Runtime
スケールOKスケール
● パイプラインはStep Functionsなどのワークフローエンジンと
AWS Lambdaをベースに処理を定義
● 実行環境はスケーラブルなAWS Batch、Glue、GKE
● 要件により一部はオンプレサーバーを利用。これもワークフ
ローからイベントドリブンで実行可能な状態で設計
● ※オンプレのケース：大量データの圧縮処理してからデータ転送
パイプラインはフルサーバレスで定義
コンテナベースでオンデマンドに起動する実行環境
要件によりサーバーをサーバーレスっぽく使う

Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Event
Data

Redshift / Spectrum
BigQuery
+Runtime
+RuntimeEventStatus
Data Lake (S3)
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Runtime
Event
Data

Redshift / Spectrum
BigQuery
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Runtime
EventStatus
+Runtime
+Runtime
Data Lake (S3)
Event
Data

BigQuery
+RuntimeEventStatus
Data Lake (S3)
Runtime
Redshift / Spectrum
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
+Runtime
Event
Data

BigQuery
Runtime
EventStatus
File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Data Lake (S3)
+Runtime
+Runtime
Redshift / Spectrum
Event
Data

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
Runtime
Event
EventEvent
Event
Event
+Runtime
+Runtime
1イベント＝1データがどこかに到達したとき
イベントドリブン＝データが到達したときに次の処理が実行される

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
Event
Message
Event
Message
Event
Message
+Runtime
疎結合なパイプライン

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
Event
Message
+Runtime
Event
Message

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
リトライ上限を超え
て失敗したイベント
はDLQへ
別のパイプラインの
失敗は影響しない
後から来るイベント
には影響しない

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
ここだけ修正してデ
プロイ

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
ここだけ修正してデ
プロイ
各パイプラインの起動にSQSを挟むことで
パイプライン同士を疎結合に保ち
1. 障害発生時の影響を小さくする
2. 小さく素早い変更を可能にする

Runtime
Event
パイプラインとスケーラビリティ
● マネージドなパイプラインにより無限のスケーラビリティを確
保
Event
Event
スケールします
×1,000
スケールします
×1,000
×1,000

Runtime
Event
保
● しかしデータロード先がRedshiftなど処理がスケールしない
場合、イベントの同時処理の制御が必要
Event
Event
しんどい

Event
保
● SQSの処理中のメッセージ数をポーリングし、処理中の同時
実行数を確認、指定された同時実行数の場合は処理しない
制御を実現
Event
Event
いま処理が最大並列数に達し
てるので、このメッセージはまた
後で実行しよ。
セーフ
×1,000

Event
保
● SQSの処理中のメッセージ数をポーリングし、処理中の同時
実行数を確認、指定された同時実行数の場合は処理しない
制御を実現
Event
Event
いま処理が最大並列数に達し
てるので、このメッセージはまた
後で実行しよ。
セーフ
×10,000
DWH、RDBMSなどの処理がスケールしない環境の場合
SQS + Lambda + CloudWatch Eventで
パイプラインの並列度をコントロール

Event
保
● もちろんロード処理の宛先がスケールする場合は並列度を
気にせず実行できる ×1,000
Event
Event
一気に1,000イベント
いくぞッ！
余裕

Event
イベントとデータのステータス管理
● 各パイプラインで、現在のイベントと処理ステータスを一元的
にDynamoDBで管理
○ システム：Lamndaの2重発火による重複起動を制御
○ システム：データロード後のマート作成実行を制御
○ ユーザー：データロード完了時間（＝データ鮮度）を確認
EventStatus
このデータは
処理中だよ
このデータは
処理完了だよ
UpdateStatus

Event
● イベントとステータスの変更履歴をRDSで管理・分析
● DynamoDB Streamsでアイテムの変更をRDSへストリーミン
グインサート
● メンバのスキル的にSQLによる分析が可能→RDSに決定
EventLogEventStatus
Update

Event
● イベントとステータスの変更履歴をRDSで管理・分析
● DynamoDB Streamsでアイテムの変更をRDSへストリーミン
グインサート
● メンバのスキル的にSQLによる分析が可能→RDSに決定
EventLogEventStatus
Update
システム間連携、ユーザビリティのためステータスを管理
ステータスログはデバッグ用に正規化して保全しておく

アプリケーションログとシステムモニタリング
● ログはDatadogに集約。重要な通知はSlackへ。
● Lambda、AWS Batch、On-Premiseの様々な実行環
境のプログラムログを一元的に検索可能。
Logging Alert

● マネージドサービスのメトリクスのアラートもDatadogに集
約。重要な通知はSlackへ。
Metrics Alert

● マネージドサービスのメトリクスのアラートもDatadogに集
約。重要な通知はSlackへ。
Metrics Alert
Datadogでログとメトリクスを
一元的に管理・検索・モニタリング

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift / Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
● サーバー管理が極力少ないパイプラインと実行環境
● イベントドリブン & 疎結合なアーキテクチャ
● スケーラビリティと処理の並列数の管理
● イベント（データ）のステータス管理と活用
● 運用が楽になるロギング・モニタリング

リプレースの際の教訓

既存の運用に設計が引きずられる ● 運用をなるべく変えないようにすると、既存のインターフェー
スに引きずられてサーバ依存の設計になりがち。
● 運用も含めてリプレースの対象だという共通認識を作る。た
だしこれには運用者の同意も必要なので事前の調整が必
須。
慣れた運用からの脱却
ログの保存先の変更
新しいツールの学習

スコープの肥大化 ● システムのリプレースにおいては、今までのつらみを解消し
ようとしてスコープが肥大化しがち。
● 要望を明文化して残しておき「やるやらない」の判断をしてか
らプロジェクトを進めるようにする。
新しいシステムが全てを叶えてくれるわけではない。
スコープスコープ
あれもやりたい
これもやりたい
一度リストに集約
そのままだと
膨れ上がる
スコープの範囲を
明確化する

エンジニア募集中！！
It’s easier to ask forgiveness than
it is to get permission.
Development follows your heart.

The Design for Serverless ETL Pipeline (48:9)

More Related Content

What's hot (20)

Similar to The Design for Serverless ETL Pipeline (48:9) (20)

The Design for Serverless ETL Pipeline (48:9)