弊社ではRedshiftの負荷増大に伴いRedshiftSpectrumの導入を行っております。また既存のETL処理の置き換えも実施しており、Glue/Lambda/APIGatewayなど種々のAWSサービスを使用しています。本発表では、弊社の分析基盤の構成とその移行案、さらに移行に関して直面した課題などをより技術的な視点からご紹介いたします。 リクルートライフスタイル　秋本 大樹

1. 既存Redshift/ETLから
Spectrum/Glueへの移⾏を
徹底解明！
秋本 ⼤樹
ネットビジネス本部
データマネジメントグループ
データプラットフォームチーム
1

2. 秋本 ⼤樹
株式会社 リクルートライフスタイル
ネットビジネス本部
データマネジメントグループ
データプラットフォームT
Facebook: daiki.akimoto.50
2011年 ユーザ系SIerに⼊社
• 客先常駐でインフラ構築のPM
• 購買データを⽤いたデータ分析
2014年 ゲーム会社に転職
• ゲームデータ分析基盤の構築
• 社内KPI算出の⾃動化
2017年12⽉より現職
2/38

3. 3/38
会社紹介

4. 4/38
保持するデータ

5. 5/38
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Redshift (mirror)
BigQuery
Cloud Storage
アクセスログ
アプリログ Treasure Data
ORACLE
Exadata
データ分析基盤

6. 6/38
BigQuery
Cloud Storage
アプリログ Treasure Data
ORACLE
Exadata
CSV
外部データ
S3
Redshift
Redshift (mirror)
アクセスログ
事業データ
HPB HPG
JLN
今回はRedshiftにフォーカス

7. 7/38
実データ容量
約120TB
(クラスタは
ds2.8xlarge(16TB)*11node=176TB
で構成)
ユーザアカウント数
1,200
クエリ数
20,000/day
テーブル数(データマートも含む)
約4,000
Redshift利⽤状況

8. ETL処理
JP1によりETL処理を制御しており
オンプレDBデータをS3を経由して
RedshiftにCOPYしている
HPB HPG
JLN
S3
Redshift
JP1により
スケジュール実行
データ抽出
COPY
.end
オンプレサーバ
.endファイルを
ポーリングし
完了次第COPY
EC2
オンプレDB
アップロード
TSV
8/38

9. ETL処理の単位
複数テーブルを
事業領域と優先度でグループ化して
毎⽇のロードを⾏なっている。
後続のマート作成で使⽤するものの
優先度を⾼くしている。
HPG
優先度⾼
ロード
HPB
優先度⾼
ロード
HPG
優先度低
ロード
JP1
ロード開始
早朝 夜
ロード開始
HPG
マートA
作成
HPG
マートC
作成
HPG
マートB
作成
HPB
優先度低
ロード
HPB
マートAʼ
作成
HPB
マートCʼ
作成
HPB
マートBʼ
作成
…
9/38

10. マート作成処理
各優先ロードが完了次第
外部DWHからのデータマート抽出、
CTAS等を⽤いたマート作成処理が動く
優先ロードの完了を
トリガーにしてJP1から
マート作成処理を実行
Redshift
オンプレサーバ
ORACLE
Exadata
BigQuery
マートデータ
抽出
外部DWHから
抽出したマートデータを
書き込み
CTAS等を用いて
Redshift内部で
マートを作成
マートデータ
抽出
10/38

11. Redshiftに対する⼀⽇の処理
事業毎に並列して
複数の処理が動き
終⽇Redshiftに対する負荷を
引き上げている
HPG
優先度⾼
ロード
HPB
優先度⾼
ロード
HPG
優先度低
ロード
JP1
ロード開始
早朝 夜
ロード開始
HPG
マートA
作成
HPG
マートC
作成
HPG
マートB
作成
HPB
優先度低
ロード
HPB
マートAʼ
作成
HPB
マートCʼ
作成
HPB
マートBʼ
作成
…
11/38

12. Redshiftへの負荷は過⼤
Redshiftへの負荷が⾼く
例えばETL処理は夜23時過ぎまでかかる
ETL処理 マート作成処理
ユーザからの
アドホック
クエリ
Redshift
12/38

13. ⼀時間あたりのコミット数
⽇中帯のコミット数は⼀時間あたり300を超え
また待ち時間も30秒を超えることがある
0
10
20
30
40
50
60
70
80
90
100
0
100
200
300
400
500
600
700
800 6/50
6/56
6/512
6/518
6/60
6/66
6/612
6/618
6/70
6/76
コミット数
コミット平均待ち秒数
秒
13/38

14. ユーザレスポンス
軽い分析クエリでも
10秒以上かかることがあり
体感的にもかなり遅い
14/38

15. 退避Redshiftの導⼊
2013年にRedshift導入
2016年にユーザレスポンス悪化
業務に影響が出始める
ユーザクエリとバッチ処理を
一時的に分離する措置が取られる
ユーザクエリ実行を一時的に退避する
退避クラスタを構築
(現在はds2.8xlarge(16TB)*6node=96TBで構築)
15/38

16. 退避Redshiftの仕組み
S3
本番
Redshift
⼀⽇⼀回
ロード
退避
Redshift
毎週⼟曜
同期
毎週⼟曜に本番Redshiftの
スナップショットを⽤いて
退避Redshiftを作成する
16/38

17. 退避Redshift
S3
本番
Redshift
⼀⽇⼀回
ロード
鮮度を求めないデータに関しては
退避を使うことで
ユーザはレスポンスを早くできる
退避
Redshift
毎週⼟曜
同期
本番Redshift
(⼀⽇⼀回)
退避Redshift
(毎週⼟曜)
データの
鮮度
新鮮なデータ 古いデータ
負荷 ⾼い 低い
レスポンス 遅い 速い
17/38

18. Slackによるデータロード
本番Redshift
(⼀⽇⼀回)
退避Redshift
(毎週⼟曜)
データの
鮮度
新鮮なデータ
負荷 ⾼い 低い
レスポンス 遅い 速い
ユーザがSlackで呟くことで
S3を介して新鮮なデータが
退避Redshiftにも⼊る
呟く
Slack
S3
新鮮なデータ
18/38

19. 退避Redshiftの課題
• 約100TBのRedshiftを⼀時的な環境として
持ち続けている
コスト増
• データが⼀元化されてないことの管理の負担
• 週に⼀度の作り変え作業の負担
運⽤の負担増
• アドホックなクエリはBigQueryで実⾏する
ようになっており役割が失われつつある
BigQueryとの競合
19/38

20. よし、
Spectrumを使おう
20/38

21. 昨年発表されたSpectrum
• Redshift上で外部スキーマと外部テーブルを
定義することで使える
• 結合処理についてはRedshift本体を⽤いるため
遅くなる傾向がある
RedshiftからS3に直接クエリ
• 他のRedshiftクラスタからも参照可能
GlueCatalogによる⼀元管理
• 1TBのS3読み出しあたり5ドルかかる
クエリ課⾦
21/38

22. マート作成に⽤いるテーブルは
結合処理に多く⽤いるために
Spectrumを使⽤せずに本体に持つ
Spectrumの導⼊(本番)
HPB HPG
JLN
S3
本番Redshift
JP1により
スケジュール実行
データ抽出
優先度高のみ
COPY
オンプレサーバオンプレDB
アップロード
TSV
or
Parquet
マートは作成後
UNLOAD
優先度低テーブルは
Spectrum参照
22/38

23. 全てのテーブルがS3に配置されるので
検証クラスタからは
全テーブルをSpectrum参照する
Spectrumの導⼊(検証)
HPB HPG
JLN
S3
検証Redshift
JP1により
スケジュール実行
データ抽出
全テーブルを
Spectrum参照
オンプレサーバオンプレDB
アップロード
TSV
or
Parquet
23/38

24. ETL負荷の変化推測
Spectrum参照により
COPYに関するコミットが減るので
ETL処理による負荷は半分になるはず
事業側DBより
テーブルデータ抽出
S3にアップロード
RedshiftにCOPY
Spectrumテーブルの
S3Pathを付け替えるのみ
約2000テーブル
優先度低
約1000テーブル
優先度⾼
約1000テーブル
24/38

25. Spectrum化に伴う⽅針
• コミット数を減らし負荷を下げる
負荷を下げる
• 数年前に書かれたものであり変更が困難
• ETLの失敗による業務影響が⼤きい
既存のETL処理への影響を
最⼩限にする
• ETL処理が23時まで及んでおりスケジュール
での実⾏が困難
イベントドリブンな
データパイプラインの構築
25/38

26. Spectrum実践上の課題1
Aginityで外部スキーマが認識されないので
Late Binding Viewを⽤いて
通常スキーマから参照可能にしている
26/38

27. Spectrum実践上の課題2
schema.table
コミットを減らすつもりだったのに
Redshift上でS3Pathを付け替えようとすると
なぜかコミットも⾛る
schema.table
27/38

28. Spectrum実践上の課題2
直接GlueCatalogを修正する
APIを書くことでRedshiftを経由せずに
S3Pathを変更しコミット数を削減
変更後のPathを
Spectrum参照
オンプレサーバ
アップロード
TSV
or
Parquet Redshift
S3
Glue
Catalog
Lambda
API
Gateway
S3Pathとテーブル名で
CURL
GlueAPIを⽤いて
Catalogを変更
28/38

29. Spectrum実践上の課題3
COPYコマンドでは
NULL AS句でNULL⽂字の指定ができたが
SpectrumではNULL⽂字の指定ができない
Redshift本体ではNULL AS ʻ<NL>ʼ
とすることでNULLと認識される
Spectrumでは単なる⽂字列として
解釈されてしまう
NULLにするためにはʼ¥Nʼを
⽤いる必要がある
29/38

30. Spectrum実践上の課題3
抽出されたtsvがS3に置かれた時点で
Lambdaを発⽕し
⽂字列を置き換える変換を加えて
再配置する
S3
Redshift
.end
オンプレサーバ
アップロード
TSV
Lambda
TSV
LambdaでTSVの⽂字列を置き換え
.end
StepFunction
全てのTSVに対する変換が完了したら
endファイルを配置する
Spectrum参照
30/38

31. Spectrum実践上の課題4
SpectrumのBestPracticeとして
S3上のデータをParquetにするのが良いと
⾔われているが
気軽にParquetに変換できるツールが無い
Batch
Lambda EMR
Glue
いずれかにてParquet変換を⾏いたい
TSV
S3
Parquet
S3
31/38

32. 仮にGlueで変換すると
GlueCatalogからDynamicFrameを
作成することで
わずか2⾏でシンプルに変換することができる
Glue
32/38

33. 仮にGlueで変換すると
最低課⾦が10分からとなっており
仮に2000テーブルを1ヶ⽉間変換すると
$0.44(DPU*h) * 2DPU * 1/6h * 2000tbl * 30days
= $8,800(約100万)
最低でも約100万かかる
※DPU(DataProcessingUnit) Glueのコンピュータリソースの単位
・
・
・
・
・
・
イベントドリブンで設計すると
1テーブルにつき1ジョブが⾛る
Glue
S3
33/38

34. Spectrum実践上の課題4
良い点 悪い点
実装が簡単(4⾏で書ける) 最低10分課⾦になっておりコスト
がとても⾼い(サイズの⼩さいも
のでも10分間のコスト)
コストが安い
使い慣れている
Parquet変換を⾃前で実装
サイズが⼤きいとLambdaのリソー
スに収まらない
使い慣れていない ロードが23時まで及ぶので常時起
動させなければならずコストが⾼
い
使い慣れている Parquet変換を⾃前で実装
ジョブ間のオーバーヘッドが⼤き
いBatch
Lambda
EMR
Glue
34/38

35. Spectrum実践上の課題4
ファイルサイズが⼤きいテーブルは
Glueを⽤いてSpectrum化させ
それ以外のテーブルは
直接TSVで⾒せるようにする
オンプレサーバ
アップロード
TSV
Redshift
S3
GlueJob
Lambda
Parquet
小さいサイズのものは
TSVで参照
大きいサイズのものは
Parquetで参照
ファイルサイズを判定し
GlueにてParquetに変換
35/38

36. Spectrum/Glueを⽤いた
最終的な構成案
36/38
オンプレサーバ
アップロード
TSV
本番Redshift
S3
GlueJob
Lambda
Parquet
TSV
検証RedshiftNULL文字変換
Parquet変換
優先度高テーブルのみ
COPY
小さいテーブルは
TSVでSpectrum参照
大きいテーブルは
ParquetでSpectrum参照
Spectrum参照

37. まとめ
• NULL⽂字の変換をS3上でかける必要あり
• ⼿軽にParquetに変換できるツールがない
Spectrumの導⼊には課題も多い
• 直接S3Pathを書き換えることでRedshiftへの
負荷を下げられる
• GlueCatalogで⼀元管理されるため他クラスタ
でも容易に参照可能
負荷の低減とデータの可搬性には
⼤きな効果あり
37/38

38. 38/38
http://engineer.recruit-lifestyle.co.jp/recruiting/
⼤募集！！
⼀緒に分析基盤を作ろう！