リクルートテクノロジーズにおける - amazon s3 · s3 emr step hive クエリ hive...

(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 app app 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 Department Hadoopの特徴

ひとことで言うと

分散したファイルに、様々な分散処理をできるソフトウェア群

Hadoopはプロジェクト名

アーキテクチャの特徴

データはファイル

ストレージと計算が分離

クエリは非同期

途中でノードがダウンしても処理を継続

10 ABC

A B C

HDFS

クライアント

コンテナコンテナコンテナ

アプリケーションマスタ

①データの配布

②プログラムの提出

計算結果

プログラム

プログラム

hadoop

クライアント

プログラムプログラム

分散ファイルシステム

HDFS

分散処理

MapReduce等


BIG DATA Department Hadoopの種類

Hadoopの種類

11

プロダクト分散ファイルシシステム

分散処理

オンプレ

MapR-FS

クラウド

ド

EMR S3

MapReduce

SQL

機械学習

グラフ演算 GraphX

SQL

MLLib

＋


EMRの説明

12


BIG DATA Department EMRの特徴

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

NEW NEW

データ移動が必要

データ移動不要


BIG DATA Department EMRはオンプレ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

タイムラインサーバWebUI ELB


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%削減

リクルートテクノロジーズにおける - amazon s3 · s3 emr step hive クエリ hive...

Documents