リクルートテクノロジーズにおける EMR の活用とコスト圧縮方法

(C) Recruit Technologies Co.,Ltd. All rights reserved.
リクルートテクノロジーズにおける
EMR の活用とコスト圧縮方法
2017/7/5
株式会社リクルートテクノロジーズ
ビッグデータ部
渡部徹太郎
AWS Solution Days 2017

BIG DATA Department自己紹介
 ID: fetaro
 名前: 渡部徹太郎
 所属: リクルートテクノロジーズビッグデータ部
 略歴:
 学生: 東京工業大学でデータ工学の研究
 SIer 前半: 大手証券会社のオンライントレードシステム基盤
 SIer 後半: オープンソース技術部隊 NoSQL, MongoDB
 現職:
 全社横断分析基盤: Oracle Exadata, Hortonworks
 個社向け分析基盤: AWS EMR
 趣味: 自宅サーバ、麻雀
 エディタ: emacs派
1
AWS
ビッグデータ
ユーザ会

BIG DATA Departmentリクルートテクノロジーズビッグデータ部での業務
 リクルートのサービス
 ビジネスモデル
 「リボンモデル」
2
カスタマ
（ユーザ）
クライアント
（企業）
 主業務
 分析
• KPIのモニタリング
• 仮説検証
 施策
• ユーザ属性推定
• マッチング
• レコメンデーション
 適材適所で高速にインプリ
・・・１００以上のサービス

BIG DATA Departmentアジェンダ
 Hadoopの説明
 EMRの紹介
 リクルートテクノロジーズでの使い方
 活用事例
3

Hadoopの説明
4

BIG DATA Departmentデータ処理技術を分類する軸：重視する性能
5
 レスポンスを重視 →主にオペレーション用途
 スループットを重視 →主に分析用途
アプリケーションサーバ
オペレーション
用途
データベース
登録画面
リクエスト参照
更新
挿入
参照画面
編集画面
即時応答
マスタ
データベー
ス
ＢＩツール
集計
バッチ
ロード
分析用途
データベース
レポート生成
ジョブ
抽出
ＣＳV
バッチ
ロード
レポート
２０分で全件集計
１０秒で全件取得
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢性別
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢性別
行志向アクセス
列志向アクセス

BIG DATA Departmentデータ処理技術を分類する軸：性能拡張方式
6
スケール
アップ
スケール
アウト
app app app app app appapp app app
一般的なハードウェアを
複数並べて並列処理
単一HWハードウェアを強化
性能限界
CPU↑
ディスク↑
NW↑
 スケールアップ or スケールアウト

BIG DATA Departmentデータ処理技術の分類
7
レスポンス重視
(オペレーション用途)
スループット重視
（分析用途)
スケールアップ
スケールアウト

BIG DATA Department
BigQuery
Spanner
データ処理技術の分類
8
（分析用途)
DynamoDB
Redshift
Athena
Aurora/RDS
RDB(OLTP)
KVS(NoSQL)
RDB(DWH)
Kinesis
Analytics
マイクロ
バッチ
SQL
クエリサービス

BIG DATA Department
BigQuery
Spanner
データ処理技術の分類
9
（分析用途)
DynamoDB
Redshift
Athena
Aurora/RDS
RDB(OLTP)
KVS(NoSQL)
RDB(DWH)
Kinesis
Analytics
マイクロ
バッチ
SQL
クエリサービス
Hadoopそのもの Hadoopで動く

BIG DATA DepartmentHadoopの特徴
 ひとことで言うと
 分散したファイルに、様々な
分散処理をできるソフトウェ
ア群
 Hadoopはプロジェクト名
 アーキテクチャの特徴
 データはファイル
 ストレージと計算が分離
 クエリは非同期
 途中でノードがダウンしても
処理を継続
10
ABC
A B C
HDFS
クライアント
コンテナコンテナコンテナ
アプリケーションマスタ
①データの配布
②プログラム
の提出
計算
結果
プログラム
プログラム
hadoop
クライアント
プログラムプログラム
分散ファイルシステム
HDFS
分散処理
MapReduce等

BIG DATA DepartmentHadoopの種類
 Hadoopの種類
11
プロダクト分散ファイル
システム
分散処理
オンプ
レ
MapR-FS
クラウ
ド EMR
S3
MapReduce
SQL
機械学習
グラフ演算
GraphX
SQL
MLLib
＋

EMRの説明
12

BIG DATA DepartmentEMRの特徴
 OSSのApache Hadoopをラッピングしたマネージド・サービス
 データをS3に格納し、Hadoopは計算だけを行う「使い捨て分散計算環境」
 １クリックでクラスタ構築
 S3にデータを入れるため、コールドデータの保管が低コスト
 AWSにある他のサービスとの連携が容易
 最新のHadoopエコシステムがかなり早く使える
13
S3
(データ保管)EMR
(Hadoop制御)
RDS
(Hiveメタストア)
マスタ
Hadoopクラスタ
（使い捨て）
クラスタ
制御
コアノード群

BIG DATA Department
core core core
HDFS(MapR-FS)
EMRの特徴
 計算(Hadoop)と、ストレージ(S3)の分離
 計算ノードの台数を即時増減可能
 クラスタは使った分だけ払えば良い（１時簡単位で課金）
 一時的に計算能力が欲しい時に、増やせる
14
S3
Master
データデータ
コンテナ
データデータ
コンテナ
データデータデータデータ
core
コンテナ
Master
コンテナ
core
コンテナ
core
コンテナ
Hadoop EMR
NEWNEW
データ移動
が必要
データ移動
不要

BIG DATA DepartmentEMRはオンプレHadoopの課題を解決
15
オンプレHadoop EMR
構築 ✕
非常に複雑で手間がかかる
◯
APIコールのみ
運用 ✕
高い技術力と重厚な体制が必要
△
H/Wの面倒を見なくて良くなる
コードによる構成管理ができる
破棄可能になる
スケールアウト・ス
ケールイン速度
△
H/Wの調達が必要
データの移動が必要
◯
即時
データの移動は不要
スケールアウトの限
界
✕
DCの物理的な限界がある
◯
ほぼ無限
開発環境 ✕
H/Wの購入が必要
◯
必要なときだけ従量課金できる

リクルートテクノロジーズでの使い方
16

BIG DATA Departmentリクルートテクノロジーズ独自拡張
 リクルートテクノロジーズではEMRの使いにくい部分を補う独自拡張を実施
17
独自拡張部分
元データ
S3
(データ保管)
Hadoop
(分散処理)
EMR
(Hadoop制御)
EC2
クラスタ
スケジューラ
RDS
(Hiveメタストア)
独自
クライアント
WebUI用
ELBコネクタ
bash
(ジョブ)
ELB
ジョブ
状況確認
Direct Connect
踏み台
ジョブ開発
スケジューラ
ジョブ実行
クラスタ制御

BIG DATA Department独自拡張：WebUI用コネクタ
 なぜ必要か？
 ジョブの開発者はジョブの進捗が見たい
• →HadoopのWebUIを固定のFQDNで公開する必要がある
 しかし、EMRのマスターノードはIPアドレスが固定できない
 解決策
 固定FQDNを持つELBを立て、定期的にマスターノードと紐付ける
• ELBをロードバランサとしてではなく、簡易リバースプロシキとして使っている
18
WebUI用
ELBコネクタ
ELB
固定FQDN
Hadoopマスタノード
リソースマネージャWebUI
タイムラインサーバWebUIELB

BIG DATA Department独自拡張：独自クライアント
 普通のEMRではHiveクエリの実行が面倒→開発効率が非常に悪い
 解決策
 独自クライアントにより、対話的にクエリ実行
19
S3
EMR
Step
Hive
クエリ
Hive
タスク
2.APIコールにより実行
EMR
結果
core
Master
core
デー
タ
デー
タ
１.クエリ格納
3.結果確認
S3
独自クライアント
core
Master
デー
タ
デー
タ
EC2
core
独自クライアント
結果クエリ実行
masterのIP取得
EMR
API

BIG DATA Department独自拡張：独自クライアント
 使い勝手
 特徴
 pythonのライブラリとして導入
 マスターノードを探し出して、SSHで接続して処理を実行
 hive, hadoopクライアントと同等の使い勝手
• 結果がすぐに確認できる。bashでエラーハンドリングできる
 引数を変えるだけで、クエリを実行するクラスタを変えられる
• 本番、開発環境の打ち分けも引数だけで可能
 非同期オプションを使えば、SSH通信が切れても問題なし
 工夫点
 APIの結果をキャッシュ
 EMRマスターノードのSSH接続数を増加
 Hiveのクエリのエスケープ
20
$ rhive cluster1 -e "select * from table1;"

BIG DATA Department独自拡張：クラスタスケジューラ
 起動しっぱなしは高コスト
 ジョブが50以上あり、Step実行による
「クラスタ生成→ジョブ→クラスタ破棄」
といった単純な制御では業務要件を満たさない
（加えて、Step実行は使いにくい）
 解決策
 スケジューラを自作
• 曜日・時刻でクラスタの台数を制御
 JSONの設定ファイルを変えるだけで変更可能
• スポットインスタンスを利用可能
21
0:00 6:00 12:00 18:00
ク
ラ
ス
タ
台
数
オンプレ
Hadoop
0:00 6:00 12:00 18:00
金曜土曜
EMR
計算に必要なリソース
スケジューラ設定ファイル

 スポットインスタンス活用
 最大80%OFFでEC2を利用できる
 費用対スペックの一番良いインスタンスタイプを自動計算
• １時間前までの平均価格を算出し、毎日一番コスパの良いインスタンスタイプを使う
• スポットインスタンスがオンデマンドより高い場合はオンデマンドを利用
 相場が高くなるとスポットインスタンスは落とされてしまうが、、
• Hadoopの特性によりジョブはスローになるだけで止まらない
• 落とされたEC2はクラスタスケジューラにより自動的に元の台数に復元
 スポットインスタンスの注意点
 入札してからインスタンスを獲得するまでが遅い５〜１０分かかる
 入札価格でコストが計上されるわけではない
22
オンデマンド
スポットスポット
時間
リソース夜間
日中
夜間
日中

 SpotFleetでいいんじゃないの？？
 SpotFleetが出る１年前から実装して使ってます！！
23

活用事例
24

BIG DATA Department活用事例：カスタマとクライアントのマッチングを機械学習で支援
 業務
 バッチによりカスタマ(約1万アクティブユーザ)とクライアント(約1万件)のマッチングのス
コアを計算
→営業業務の大幅な工数削減に寄与
 KPIモニタリングデータをBIツールに連携
→データドリブンな意思決定を支援
 仕組み
 毎晩50以上のジョブ
 データ量は30TB以上(ORC+Snappy圧縮)
 オンプレHadoopの課題
 施策の領域によって、対象のカスタマの量が変わるので、キャパシティのプランニングが困難
 クラウド移行を検討するも、既存のSQLベースの分析技術では自然言語解析や機械学習がで
きない
 EMRの選択
 必要な分だけクラスタを使える
 Hadoopの強力な分散計算能力(自然言語解析、機械学習)を利用できる
 オンプレHadoopのプログラムがほぼそのまま動くため、移行工数が低い
25

BIG DATA Department活用事例：カスタマとクライアントのマッチングを機械学習で支援
 EMRに移行したことによる効果
 期待通りのスケーラビリティを獲得
• 案件の範囲の増加に合わせてスケールアップ
• 入力データの到着が遅くなっても、クラスタを増やしてバッチウインドウを死守
• 開発を加速したい時に、一時的にクラスタの台数を増す通称「界王拳」により、開発効率UP
 S3に格納することによりデータ容量の制限がなくなり、定期的な棚卸しが不要に
 完全に本番と同じ開発環境を持つことができ、テスト品質向上
 スポットインスタンス活用のコスト削減効果
26
台数増減のみ台数増減＋スポット
1日の
金額
$258 $167
5台
28台
$0.79/h
2:00 11:00
コアノードr3.2xlarge台数
5台
28台
$0.79/h
$0.23/h
2:00 11:00
コアノードr3.2xlarge台数
10台
平均して、
オンデマンドの
37%価格で利用
36%削減

リクルートテクノロジーズ における EMR の活用とコスト圧縮方法

More Related Content

What's hot

Similar to リクルートテクノロジーズ における EMR の活用とコスト圧縮方法

More from Tetsutaro Watanabe