リクルートテクノロジーズにおける - amazon s3 · s3 emr step hive クエリ hive...
TRANSCRIPT
(C) Recruit Technologies Co.,Ltd. All rights reserved.
リクルートテクノロジーズにおける
EMR の活用とコスト圧縮方法
2017/7/5 株式会社リクルートテクノロジーズ
ビッグデータ部
渡部徹太郎
AWS Solution Days 2017
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 自己紹介
ID: fetaro
名前: 渡部 徹太郎
所属: リクルートテクノロジーズ ビッグデータ部
略歴:
学生: 東京工業大学でデータ工学の研究
SIer 前半: 大手証券会社のオンライントレードシステム基盤
SIer 後半: オープンソース技術部隊 NoSQL, MongoDB
現職:
全社横断分析基盤: Oracle Exadata, Hortonworks
個社向け分析基盤: AWS EMR
趣味: 自宅サーバ、麻雀
エディタ: emacs派
1
AWS
ビッグデータ
ユーザ会
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department リクルートテクノロジーズ ビッグデータ部での業務
リクルートのサービス
ビジネスモデル
「リボンモデル」
2
カスタマ(ユーザ)
クライアント
(企業)
主業務
分析
• KPIのモニタリング
• 仮説検証
施策
• ユーザ属性推定
• マッチング
• レコメンデーション
適材適所で高速にインプリ
・・・100以上のサービス
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department アジェンダ
Hadoopの説明
EMRの紹介
リクルートテクノロジーズでの使い方
活用事例
3
(C) Recruit Technologies Co.,Ltd. All rights reserved.
Hadoopの説明
4
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department データ処理技術を分類する軸:重視する性能
5
レスポンスを重視 →主にオペレーション用途
スループットを重視 →主に分析用途
アプリケーションサーバ
オペレーション
用途
データベース 登録画面
リクエスト 参照
更新
挿入
参照画面
編集画面
即時応答
マスタ
データベース
BIツール
集計
バッチ
ロード 分析用途
データベース
レポート生成ジョブ
抽出
CSV バッチ
ロード レポート
20分で全件集計
10秒で全件取得
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢 性別
1 1982年生
2 1967年生
3 2000年生
4 2000年生
男
女
女
男
ID 年齢 性別
行志向アクセス
列志向アクセス
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department データ処理技術を分類する軸:性能拡張方式
6
スケール
アップ
スケール
アウト
app app app app app app app app app
一般的なハードウェアを複数並べて並列処理
単一HWハードウェアを強化
性能限界
CPU↑
ディスク↑
NW↑
スケールアップ or スケールアウト
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department データ処理技術の分類
7
レスポンス重視
(オペレーション用途)
スループット重視
(分析用途)
スケールアップ
スケールアウト
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department
BigQuery
Spanner
データ処理技術の分類
8
レスポンス重視
(オペレーション用途) スループット重視
(分析用途)
スケールアップ
DynamoDB
Redshift
Athena
Aurora/RDS
RDB(OLTP)
KVS(NoSQL)
RDB(DWH)
スケールアウト
Kinesis
Analytics
マイクロ
バッチ
SQL
クエリサービス
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department
BigQuery
Spanner
データ処理技術の分類
9
レスポンス重視
(オペレーション用途) スループット重視
(分析用途)
スケールアップ
DynamoDB
Redshift
Athena
Aurora/RDS
RDB(OLTP)
KVS(NoSQL)
RDB(DWH)
スケールアウト
Kinesis
Analytics
マイクロ
バッチ
SQL
クエリサービス
Hadoopそのもの Hadoopで動く
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department Hadoopの特徴
ひとことで言うと
分散したファイルに、様々な分散処理をできるソフトウェア群
Hadoopはプロジェクト名
アーキテクチャの特徴
データはファイル
ストレージと計算が分離
クエリは非同期
途中でノードがダウンしても処理を継続
10 ABC
A B C
HDFS
クライアント
コンテナ コンテナ コンテナ
アプリケーションマスタ
①データの配布
②プログラムの提出
計算結果
プログラム
プログラム
hadoop
クライアント
プログラム プログラム
分散ファイルシステム
HDFS
分散処理
MapReduce等
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department Hadoopの種類
Hadoopの種類
11
プロダクト 分散ファイルシシステム
分散処理
オンプレ
MapR-FS
クラウド
ド
EMR S3
MapReduce
SQL
機械学習
グラフ演算 GraphX
SQL
MLLib
+
(C) Recruit Technologies Co.,Ltd. All rights reserved.
EMRの説明
12
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department EMRの特徴
OSSのApache Hadoopをラッピングしたマネージド・サービス
データをS3に格納し、Hadoopは計算だけを行う「使い捨て分散計算環境」
1クリックでクラスタ構築
S3にデータを入れるため、コールドデータの保管が低コスト
AWSにある他のサービスとの連携が容易
最新のHadoopエコシステムがかなり早く使える
13
S3 (データ保管) EMR
(Hadoop制御)
RDS (Hiveメタストア)
マスタ
Hadoopクラスタ
(使い捨て)
クラスタ
制御
コアノード群
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department
core
core
core
HDFS(MapR-FS)
EMRの特徴
計算(Hadoop)と、ストレージ(S3)の分離
計算ノードの台数を即時増減可能
クラスタは使った分だけ払えば良い(1時簡単位で課金)
一時的に計算能力が欲しい時に、増やせる
14
S3
Master
データ データ
コンテナ
データ データ
コンテナ
データ データ データ データ
core
コンテナ
Master
コンテナ
core
コンテナ
core
コンテナ
Hadoop EMR
NEW NEW
データ移動が必要
データ移動不要
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department EMRはオンプレHadoopの課題を解決
15
オンプレHadoop EMR
構築 ✕
非常に複雑で手間がかかる
◯
APIコールのみ
運用
✕
高い技術力と重厚な体制が必要
△
H/Wの面倒を見なくて良くなる
コードによる構成管理ができる
破棄可能になる
スケールアウト・スケールイン速度
△
H/Wの調達が必要
データの移動が必要
◯
即時
データの移動は不要
スケールアウトの限界
界
✕
DCの物理的な限界がある
◯
ほぼ無限
開発環境 ✕
H/Wの購入が必要
◯
必要なときだけ従量課金できる
(C) Recruit Technologies Co.,Ltd. All rights reserved.
リクルートテクノロジーズでの使い方
16
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department リクルートテクノロジーズ独自拡張
リクルートテクノロジーズではEMRの使いにくい部分を補う独自拡張を実施
17
独自拡張部分
元データ
S3 (データ保管)
Hadoop (分散処理)
EMR (Hadoop制御)
EC2 クラスタ
スケジューラ
RDS (Hiveメタストア)
独自
クライアント
WebUI用
ELBコネクタ
bash
(ジョブ)
ELB
ジョブ
状況確認
Direct Connect
踏み台
ジョブ開発
スケジューラ
ジョブ実行
クラスタ制御
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 独自拡張:WebUI用コネクタ
なぜ必要か?
ジョブの開発者はジョブの進捗が見たい
• →HadoopのWebUIを固定のFQDNで公開する必要がある
しかし、EMRのマスターノードはIPアドレスが固定できない
解決策
固定FQDNを持つELBを立て、定期的にマスターノードと紐付ける
• ELBをロードバランサとしてではなく、簡易リバースプロシキとして使っている
18
WebUI用
ELBコネクタ
ELB 固定FQDN
Hadoopマスタノード
リソースマネージャWebUI
タイムラインサーバWebUI ELB
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 独自拡張:独自クライアント
なぜ必要か?
普通のEMRではHiveクエリの実行が面倒→開発効率が非常に悪い
解決策
独自クライアントにより、対話的にクエリ実行
19
S3
EMR
Step
Hive クエリ
Hive タスク
2.APIコールにより実行
EMR
結果
core
Master
core
データ
データ
1.クエリ格納 3.結果確認
S3
独自クライアント
core
Master
データ
データ
EC2
core
独自クライアント
結果 クエリ実行
masterのIP取得 EMR
API
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 独自拡張:独自クライアント
使い勝手
特徴
pythonのライブラリとして導入
マスターノードを探し出して、SSHで接続して処理を実行
hive, hadoopクライアントと同等の使い勝手
• 結果がすぐに確認できる。bashでエラーハンドリングできる
引数を変えるだけで、クエリを実行するクラスタを変えられる
• 本番、開発環境の打ち分けも引数だけで可能
非同期オプションを使えば、SSH通信が切れても問題なし
工夫点
APIの結果をキャッシュ
EMRマスターノードのSSH接続数を増加
Hiveのクエリのエスケープ
20
$ rhive cluster1 -e "select * from table1;"
(C) Recruit Technologies Co.,Ltd. All rights reserved.
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
計算に必要なリソース
スケジューラ設定ファイル
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 独自拡張:クラスタスケジューラ
スポットインスタンス活用
最大80%OFFでEC2を利用できる
費用対スペックの一番良いインスタンスタイプを自動計算
• 1時間前までの平均価格を算出し、毎日一番コスパの良いインスタンスタイプを使う
• スポットインスタンスがオンデマンドより高い場合はオンデマンドを利用
相場が高くなるとスポットインスタンスは落とされてしまうが、、
• Hadoopの特性によりジョブはスローになるだけで止まらない
• 落とされたEC2はクラスタスケジューラにより自動的に元の台数に復元
スポットインスタンスの注意点
入札してからインスタンスを獲得するまでが遅い 5〜10分かかる
入札価格でコストが計上されるわけではない
22
オンデマンド
スポット スポット
時間
リソース 夜間
日中
夜間
日中
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 独自拡張:クラスタスケジューラ
SpotFleetでいいんじゃないの??
SpotFleetが出る1年前から実装して使ってます!!
23
(C) Recruit Technologies Co.,Ltd. All rights reserved.
活用事例
24
(C) Recruit Technologies Co.,Ltd. All rights reserved.
BIG DATA Department 活用事例:リクルートスタッフィング分析環境
カスタマとクライアントのマッチングを機械学習で支援
業務
バッチによりカスタマ(約1万アクティブユーザ)とクライアント(約1万件)のマッチングのスコアを計算 →営業業務の大幅な工数削減に寄与
KPIモニタリングデータをBIツールに連携 →データドリブンな意思決定を支援
仕組み
毎晩50以上のジョブ
データ量は30TB以上(ORC+Snappy圧縮)
オンプレHadoopの課題
施策の領域によって、対象のカスタマの量が変わるので、キャパシティのプランニングが困難
クラウド移行を検討するも、既存のSQLベースの分析技術では自然言語解析や機械学習ができない
EMRの選択
必要な分だけクラスタを使える
Hadoopの強力な分散計算能力(自然言語解析、機械学習)を利用できる
オンプレHadoopのプログラムがほぼそのまま動くため、移行工数が低い 25
(C) Recruit Technologies Co.,Ltd. All rights reserved.
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%削減