2013年の分社からリクルートライフスタイルにおける分析基盤の成長の軌跡をご紹介します。 リクルートライフスタイル　白子　佳孝

1. ビックデータ分析基盤の成⻑の軌跡
⽩⼦ 佳孝
リクルートライフスタイル
データマネジメントG
#mastercloud

2. リクルートライフスタイルの分析基盤の歴史から、
皆さんの基盤成⻑戦略の参考になれば(いいな)
本発表で伝えたいこと

3. Index
1. リクルートライフスタイルについて
2. 成⻑の軌跡

4. Index
1. リクルートライフスタイルについて
2. 成⻑の軌跡

5. 会社紹介

6. Data
もちろん、データを利活⽤して。
ユーザーとクライアントがマッチングする場を提供

7. Data
• サービスアクセスログ
• トランザクションログ
• 会員属性情報
• etc...
• マスタデータ
• ⼊稿データ
• 営業接点データ
• 勘定データ
• etc...
ユーザー側だけではなく、クライアント企業側にも広⼤な世界が
広がっている点は、リクルートグループの⼤きな特徴
リボンモデルの交差点から取得されるデータとは

8. Index
1. リクルートライフスタイルについて
2. 成⻑の軌跡

9. 2013
2014
2015
2016
2017
2018
✔TresureData導⼊
✔Hadoop除却
✔Redshiftのノード拡張
✔分社化に伴い、RLS独⾃の分
析基盤提供スタート
✔Netezza, Redshift導⼊
✔オンプレ-AWS間にDC導⼊
✔Redshiftのノード拡張
✔Netezzaを別途導⼊
✔新Netezzaへの移⾏完了
✔Mirror-Redshift誕⽣
✔Redshiftのノード拡張
✔BigQuery導⼊
✔Exadata導⼊
✔Netezza除却
✔TreasureData脱却
✔Spectrum導⼊
✔Mirror-Redshift除却
Timeline

10. 4クラスタのHadoop(MapR)から時代が始まる
リクルートテクノロジーズが提供するプライベートクラウド「RAFTEL」にある⾼性能なサーバ４台
のクラスタからなるHadoopを利⽤開始
クォーターサイズのNetezza(Twin Fin3)導⼊
IBMが提供している据え置き型のDWHアプライアンスであるNetezzaを導⼊
分析や統計解析などの処理環境としてユーザに徐々に開放していった
Redshift導⼊
AWSが提供するDWHサービスのRedshiftを導⼊
最初は、ds1.xlargeの4ノード構成だった
Netezzaの利⽤者が増えたことにより、リソースが枯渇し始めたので、レポーティング・モニタリン
グ⽤途として導⼊を決定
2013 2014 2015 2016 2017 2018

11. 2013 2014 2015 2016 2017 2018
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
アクセスログ
Neteeza
Hadoop

12. Redshiftノードのスケールアウト
Redshiftのノードを4→7に増強
この頃から、アドホックな分析はRedshift、売上直結のバッチ処理はNetezzaでと役割分担が明確に
なってきた。
Hadoop除却に伴い、TreasureDataに移⾏
プライベートクラウド「RAFTEL」のインフラを丸ごと⼊れ替えるという壮⼤なプロジェクトが発⾜
その際に⾊々あった様で、 カスタマーの⾏動ログデータの⼀次加⼯で利⽤していたHadoopを⼀気に
TresureDataに置き換え
TDにしたことで、 HDFSのディスクの⼼配が必要なくなった
ここで、当時のインフラ担当から⼀⾔：
このときメインでここを担当していた⼈が驚くほど資料を残しておらず、後任が地獄を⾒た…
みなさんも仕様書はちゃんと書きましょう！
2013 2014 2015 2016 2017 2018

13. 2013 2014 2015 2016 2017 2018
S3
Redshift
Neteeza
Treasure Data
HPB HPG
JLN
事業データ
CSV
外部データ
アクセスログ

14. Redshiftノードの再スケールアウト
Redshiftの利⽤がだいぶ進み、ノードを7から⼀気に32に増強
ノード数の上限に到達してしまったため、スケールアウトができなくなる
オンプレ-AWS間にDC導⼊
Redshiftへの通信が増加の⼀途をたどり、AWSのVPN接続ルーターをハングさせるという事態に陥っ
たため、専⽤線を導⼊
⼤量通信が⽬⽴ったtableau-Redshift間の通信を専⽤線経由に切り替えた
ハーフサイズのNetezza(Twin Fin 6)の導⼊
リクルートテクノロジーズが利⽤していた中古Netezzaを購⼊
（なぜいらなくなったのかは不明）
今まで使っていたNetezzaからデータや処理を移⾏するプロジェクトが発⾜
2013 2014 2015 2016 2017 2018

15. 2013 2014 2015 2016 2017 2018
S3
Redshift
Neteeza
Treasure Data
HPB HPG
JLN
事業データ
CSV
外部データ
アクセスログ
アプリログ

16. Redshiftノードのスケールアップ
Redshiftの利⽤がさらに進み、32ノードではこれ以上のパフォーマンス改善が⾒込まれなかったため、
検証を重ねた結果、最終的にds2.8xlargeの11ノードにスケールアップ
Mirror-Redshift誕⽣
現⾏Redshiftの速度が利⽤者に追い付かなくなってきたため、データ鮮度を求めないクエリなどを逃
がすクラスタを新設
毎週末、本番Redshiftから取得したSNAPSHOTよりクラスタを再作成
新Netezzaへの移⾏完了
2015年に購⼊したNetezzaへのデータおよびバッチ処理の移⾏が完了
クオーターサイズのNetezzaはスタンバイマシンになった
2013 2014 2015 2016 2017 2018

17. 2013 2014 2015 2016 2017 2018
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Mirror-Redshift
Neteeza
アクセスログ
アプリログ
Treasure Data

18. BigQueryの導⼊
Googleが提供するDWHサービスのBigQueryを導⼊
年々、利⽤者もデータも増えてきており、移⾏や代替環境作成などを⾏なっていた。
そのため、どんなにデータやユーザが増えても、性能劣化が起きない・キャパプラ不要なDWHに乗
り換えていこうという⽬的でBigQueryが導⼊された
また、今までを教訓に共通ルール整備、命名規則なども初めからしっかり設計した
さらに、リクルートテクノロジーズもBigQueryを利⽤し始めたので、プロジェクト共有機能により
データ共有が容易になった
Netezza除却からのExadata導⼊
NetezzaのEOSLを迎えるにあたり、代替としてExadataを導⼊
PureData(Netezza後継機)とどちらにするか検討されたが、リクルートテクノロジーズが持つ
ExadataとでDataGuardによる冗⻑構成が取れるという点でExadataに決定
2013 2014 2015 2016 2017 2018

19. 2013 2014 2015 2016 2017 2018
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Mirror-Redshift
BigQuery
アクセスログ
アプリログ Treasure Data
Exadata
Cloud Storage

20. TreasureData脱却
カスタマーの⾏動ログデータの⼀次加⼯処理をBigQueryに移⾏し、TreasureDataから脱却
⼀部アプリログの連携はTDを未だ利⽤中
Spectrum導⼊
S3のファイルを直接参照できるRedshift Spectrumを導⼊
数百のテーブルロード処理がSpectrumに置き換えられたことで、Redshiftの負荷がかなり軽減され
た
Mirror-Redshift除却
アドホックな分析はBigQueryやSpectrumに寄せる様にし、クエリを逃していたクラスタを除却
データ鮮度が新しいデータを参照できるため、分析者からも喜びの声が
2013 2014 2015 2016 2017 2018

21. 2013 2014 2015 2016 2017 2018
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Spectrum
BigQuery
アクセスログ
アプリログ Treasure Data
Exadata
Cloud Storage

22. Google AnalyticsのBigQuery連携
Snowflakeの検証・導⼊
データのワークロード統⼀
データカタログの整備
2013 2014 2015 2016 2017 2018