The Design for Serverless ETL Pipeline　データ分析基盤のレガシーなデータロードをサーバレスでフルリプレースするまで道のり

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

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

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

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

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

分析基盤の概要
Spectrum
Oracle
Exadata
SPSS
Treasure
Data
aginity
CHEETAH
DIGITAL
Adobe
Analytics
CSV
外部データ
アクセスログ
アプリログ
HPB
JLN
HPG
事業データ
BigQuery
IBM Watson
Campaign
Automation
S3
Redshift

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

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

レガシーな構成のつらみ

技術のツギハギ
● 自前サーバで動くシェルで書かれたレガシーなコード
○ 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
+Runtime
+Runtime
Serverless ETL Pipeline

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

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

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

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

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

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

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

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

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

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

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

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

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

File/Log (CSV/JSON)
HPB
JLN
HPG
Database
Redshift /
Spectrum
BigQuery
Data Lake (S3)
Runtime
EventStatus
+Runtime
+Runtime
Event
Message
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
Eve
nt
Eve
ntEvent
スケールします
×1,000
スケールします
×1,000
×1,000

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

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

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

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

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

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

● イベントとステータスの変更履歴をRDSで管理・分析
● DynamoDB Streamsでアイテムの変更をRDSへストリーミン
グインサート
● メンバのスキル的にSQLによる分析が可能→RDSに決定
Event
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
●サーバー管理が極力少ないパイプラインと実行環境
●イベントドリブン & 疎結合なアーキテクチャ
●スケーラビリティと処理の並列数の管理
●イベント（データ）のステータス管理と活用
●運用が楽になるロギング・モニタリング

リプレースの際の教訓

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

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

エンジニア募集中！！

The Design for Serverless ETL Pipeline　データ分析基盤のレガシーなデータロードをサーバレスでフルリプレースするまで道のり

More Related Content

What's hot (20)

Similar to The Design for Serverless ETL Pipeline　データ分析基盤のレガシーなデータロードをサーバレスでフルリプレースするまで道のり (20)

More from Recruit Lifestyle Co., Ltd. (20)