1. リクル トにおけるHadoop活⽤と
リクルートにおけるHadoop活⽤と
技術調査について
Takeshi NAKANO
Marketing & IT Div
Div.
Recuruit Co., Ltd.
1

2. アジェンダ
1. はじめに
2. 技術的な話(Solr/Cache-module/Hadoop)
3. エンジニアとして考えること
4. まとめとこれから
れ
2

3. はじめに
3

4. 自己紹介
• 中野 猛 (NAKANO Takeshi / @tf0054)
• リクルート＝社会⼈歴11年⽬
• 6年情報⼯学を学び⼊社後もずっとエンジニア
• イ
インフラ等基盤系の部署からスタート
等基盤系 部 タ ト
• 新ビジネス検討をお⼿伝いし
• 新技術検討のチームをリード
4

5. リクル トご紹介
リクルートご紹介
5

6. リクル トご紹介
リクルートご紹介
■ Human Resources
6

7. リクル トご紹介
リクルートご紹介
■ Further education and Learning
7

8. リクル トご紹介
リクルートご紹介
■ Housing
8

9. リクル トご紹介
リクルートご紹介
■ Bridal & Baby
9

10. リクル トご紹介
リクルートご紹介
■ Travel
10

11. リクル トご紹介
リクルートご紹介
■ Automobiles
11

12. リクル トご紹介
リクルートご紹介
■ Coupons
12

13. リクル トご紹介
リクルートご紹介
■ Lifestyle and Others
13

14. 事業形態
• MIT(Marketing&IT) ≒ 情報システム部
• 各事業にはそれぞれ専属のMIT(システム担当G)
• 基盤/PMO系の機能はMIT内横断
⾃動⾞ ゼクシィ ・・・ リクナビ
MIT MIT MIT
MIT (PMO / Infra etc.)
14

15. 独自採用の技術
15

16. ①SOLR
16

17. システム概要
• 多くのサイトでドリルダウン検索、⽂字列検索の実
相が急務に
• ここにプロプライエタリな商⽤ミドルを導⼊ 案件
ここにプロプライエタリな商⽤ミドルを導⼊、案件
個別に対応されていた
• ただ、⾼価に過ぎ、事業収益に影響を及ぼしていた
• そこでOSSの検索エンジンを検証 約2年かけ全サ
そこでOSSの検索エンジンを検証、約2年かけ全サ
イトの検索機能を⼊れ替え
17

18. 事例
• DBとの連携
• 通常のS l
通常のSolr
• 更新データ準備 → インデクシング → Commit → 検索に反映
この間のデ タ更新に時間を要する
この間のデータ更新に時間を要する ※
※ データサイズにより異なる
• コネクションサーチ
• 在庫DBを更新 → 検索に反映
DBの更新のみ
在庫数や、画⾯への表⽰有無のみの変更であればより理想的
① 検索クエリ発行 ② SQL発行
Solr DB
ユーザ ④ 結果の返却 ③ ResultSet
①の結果と③をマージ この結果が少ないほど⾼速
18

19. 効果
• サイトの使い勝⼿向上(操作性＋レスポンス)
• 商⽤ミドルを駆逐し、保守ラインセンス費を削減。
• シノニム検索等、ミドル⾃体の動作掌握が不可⽋な
機能の利⽤レベル向上に寄与。
• Solr本の共同執筆でノウハウ整理。
19

20. ②CACHE-MODULE
20

21. システム構成
• ウェブサイトのリソース消費が問題に
ウェブサイトのリソ ス消費が問題に
• 同時に体感速度の重要性も確認されてきた
• Apacheの追加モジュールを社内開発して対応
• (Apacheの機能ゆえ)基本的に開発⾔語も問わない
機能ゆ 基本的 発 わ
• 基本は組まれたHTMLをキャッシュするもの
• 独⾃タグにてHTMLの⼀部を動的差し替え
(カート機能、〜さんこんにちわ等)
カ ト機能 さん んにちわ等
21

22. システム構成
• アプリ(前提)
• ページのメインどころはキャッシュから
• 個別部分(パーツ)は独⾃タグで都度動的作成
個別部分( ツ) 独⾃タグ 都度動的作成
• これらをApacheでマージしブラウザへ パーツ
パーツ
■独⾃タグの例
<lcs:include src="cache:///test/p01 jsp"
src= cache:///test/p01.jsp
expires="every 5 minutes" />
22

23. システム構成
• 構成概要
Internet apache Tomcat
設定ファイル
設定 イル
TokyoTyrant Batch
(memcached)
キャッシュデータ
23

24. システム構成
• 構成詳細 クローラの変なUAなど、
クロ ラの変なUAなど
IPレンジで判定できない
キャリア４つ＋C(google
＋C(Y!)＋C(goo)など個別
もののみを書く ファイル化
apache
mod_mobile_door キャリアを判別しENVに定義(例:X_CLIENT_TYPE=AU)
1.ENV(X_CLIENT_TYPE)＋UAを⾒て適切なCAパラメータを付与
mod_rewrite 2.付与されたCAから適切なENV(X_LCS_CONTENT_TYPE)をセット
書き換え後URLをキーにKVSを検索
mod_rec_cache
mod rec cache (Tomcatに回る場合も書き換え後URLで回す)
mod_proxy
CAパラメータはバッチか
TokyoTyrant mod_p y_ajp
proxy jp らしか発⽣しえない
Tomcat
mod_template indefiniteだったら動く
Cache0(fake filter) ?CA=AUを外しUAを偽装
mod_deflate
_
RFW(mobile filter)
Cache1(cache filter)
24

25. 効果
• ウェブサーバのリソース削減に寄与（４割程度）
ウェブサ バのリソ ス削減に寄与（４割程度）
• DBサーバのリソース削減に寄与（２割程度）
• キャッシュ有効期間調整による⾼負荷時対応等
25

26. ③HADOOP
26

27. システム構成
• いくつかの事業でバッチ処理時間がひっ迫
• DBの垂直拡張だけでは限界＋コスト⾼に
• その打開策としてBigデータ処理に着⽬
• 各種
各種DWH的ツールを含めて調査しHadoopに
的 を含 査
• バッチ⾼速化の⽤途だけでなく、
マイニング⽤途が利⽤の拡⼤を牽引
27

28. ログ集計本番 個別PV
個別
単純
事例1：バッチ処理の高速化 集計 集計
流⼊回 集計ログ
step1_01
数（初
A.sh
期表
流⼊回
⽰）集 個別PV集計
アクセスロ step1_02
数（前計B.sh
グ 画⾯不 流⼊回数集計
約1100万レ 明）集 step1_02 ⼀覧表⽰回数
コード ⼀覧表計C.sh 集計
⽰回数 アクション
⾏動履歴反響情報
⾏動 情報 （100） アク
集計step1_03 実⾏回数集計
ション
xxx_PAGE 10並列 A.sh
実⾏ 成果集計
約80分 前画⾯ 回数集
step1_04 約50万レ
エリア 計 D.sh コード
２－１． データ
⾏動履歴リクエスト情報 ター step2_05_
yyy_SITE
yyy SITE ログ集計 （
（160）
） 成果抽
抽出
ゲット1.sh
1 sh Temporary
下準備 1並列×10回 出 エリア その他 エリア抽 集計
ター
データstep2_05_
(100)
step2_05_
マスター系 出データ
約30分 0.sh ゲット
抽出①2.sh step3_
SQLをHive@Hadoop化
(110) SYUKEI_
エリア 05.sh
⾏動その他履歴集計ログ データ
TEMP
アクセスロ
zzz_LOG Temporary step2_05_
抽出② 3.sh
対象範囲
グ
近く 事例も
成果抽出
モバイル
x10〜x100近くでる事例も データ
ACCESS_LOG
_TEMP
２－３．
集計
⾏動履歴 ２－３． ２－２．
ログ集計
その他DB ログ集計
アクセスログ 集計ログ キャッ
取込
込 本番 集計キャッシュ
xxx_ACCESS_LOG bbb_LOG シュ作成
(120) (140)
(150)
モバイル
⾏動その他履歴
1並列 1並列 5並列×2回
1分 144分 約20分
１バッチ 2時間22分
ｘｘｘ系バッチ全体で約6時間
28

29. 事例2：アソシ
事例2：アソシエーション分析
ション分析
どの施策(左記だとキャンペーンA、 1回⽬の訪問
検索、ブックマ ク)が最もコンバ
検索、ブックマーク)が最もコンバー キャンペーンA
キャンペ ンA サイト閲覧 離脱
ジョンに貢献したかを、貢献度で評
価したい。 2回⽬の訪問
検索 サイト閲覧 離脱
Hadoop＋Webのアクセスログで、
Hadoop＋Webのアクセスログで
サイトを越えた集計が可能に。
3回⽬の訪問
ブックマーク サイト閲覧 コンバージョン
流 ア
⼊ ク
シ
ョ
ン
どの施策からアクセス どの施策がアクションに キャンペーンAで捕捉したユーザは、
キャンペ ンAで捕捉したユ ザは
したユーザが多い？ 貢献している？ 何⼈がコンバージョンしたか？
・この広告は⽌める？ ・キャンペーンAを続ける？
・ポイント付与とメール配信に⼒を⼊れる？ ・キャンペーンAを⽌める？
29

30. 補足：githubにて公開中
https://github.com/recruitcojp
htt // ith b / it j
• WebHive
• ウェブ上からHiveQLを流せる
• ログイン管理や実⾏記録等セキュリティ機能が充実
• OdbcHive
• Hadoop(Hive)をより⾝近にする
• MS-Accessから直接使えるように作成(≠JDBC)
• α版
30

31. これから、で考えていること
から、 え
＊リアルタイム処理
31

32. リアルタイム処理
• 今気にしているもの
• 貯めてから処理→出たところから処理?
• Y!のS4
32

33. エンジニア同士のシナジー
ンジ ア同士のシナジ
• 各事業を深く理解しているエンジニア
• 競合事例の把握と対応を検討
• 各事業システムの構造を把握
• チーム内のエンジニア
• マイニングなど応⽤技術を把握
グ
• OSSソース⾃体を読み構造を理解/確認
33

34. 非 ンジ アとのシナジ
非エンジニアとのシナジー
• 分析やマイニングの専⾨家
• リコメンドロジックの設計と評価
• 予測分析の設計と評価
• 事業/マーケティングの専⾨家
• ⾏動ターゲティングの設計と評価
グ
• 営業⾏動のチューニング
34

35. エンジニアとして考えること
35

36. どうしてゆくとよいか
• 良い⼈⽣と⾔われても
• 楽しい/良い仕事をやってゆくには
• “居つかない”こと
• 「試合中に精神的機能が⼀時⽌って瞬間的動作の出
来ない状態」(by weblio / 剣道⽤語 / 内 樹
来な 状態 内⽥樹)
36

37. ①ス シャリストｘゼネラリスト
①スペシャリストｘゼネラリスト
• スペシャリストとしての進化
• ゼネラリストとは何か
• 出来るようになるハズ
37

38. ②こだわりｘ柔軟さ
• 深く理解する価値
• 9:1くらい(?)にはに飽きるべき
• コミュニケーション時にも注意が必要
38

39. ③アプリの知識ｘインフラの知識
• 軸⾜の話
• アプリは作っちゃうもの(アイデア/発想)
• クラウド時代のインフラ知識
39

40. ④オ プンソ スｘプ プラ タリ
④オープンソースｘプロプラエタリ
• 作りを確認できることは⼤きな価値
• 相談できる(という意味で)サポートも⼤きな価値
• どちらも使い切り替えてゆく
40

41. まとめとこれから
41

42. エンジニアとは(まとめ)
ンジ アとは(まとめ)
• 内部ベース/”居つかない”こと＝プロ?
内部ベ ス/ 居つかない こと プロ?
• 場は変化する。その時々に適当な解を
• 外部ベ ス/出⼒量 感謝され量 価値?
外部ベース/出⼒量＝感謝され量＝価値?
• 説明を作る/考えることも、ある意味エンジニアリング!?
• 仕掛けるエンジニア！
• テクノロジードリブン
テクノロジ ドリブン
42

43. ( ンジ アが)未来を創る
(エンジニアが)未来を創る
• インターネットがそもそも
インタ ネットがそもそも
• スマートフォンもそう
• Hadoopなどデータマーケティングも本格化
• 未来を作
未来を作ってゆきましょう!
ゆき
43

44. END
44

45. カンファレンス準備中
• “Hadoop Conference 2011 Fall”
Hadoop Fall
• Hadoopユーザ会の皆さまと企画中！
• 9/26＠汐留
45