2015/12/16 elastic {on} TOURの、中原の講演資料になります

1. 0

2. 株式会社リクルートテクノロジーズ インフラソリューション部
中原 裕成
1
リクルート流Elasticsearchの使い方

3. 自己紹介
• 氏名
 中原 裕成
• 所属
 株式会社リクルートテクノロジーズ
ITソリューション統括部
インフラソリューション部
• 担当業務
 Elasticsearchを用いたサービスの運用など
2

4. もくじ
1. はじめに
 リクルート/リクルートテクノロジーズとは？
2. Elasticsearchの活用例
 Qass / Pusna / サービス可視化
3. Elasticsearchの運用ノウハウ
 Plugin
 Snapshot
 index
 バージョンアップ
4. さいごに
3

5. はじめに
4

6. リクルートテクノロジーズとは
リクルートキャリア
リクルートジョブズ
リクルートスタッフィング
リクルート住まいカンパニー
リクルートライフスタイル
リクルートマーケティングパートナーズ
スタッフサービス・ホールディングス
リクルートアドミニストレーション
リクルートコミュニケーションズ
事業会社
機能会社
インフラ部門
大規模プロジェクト推進部門
UI設計/SEO部門
ビッグデータ機能部門
テクノロジーR&D部門
事業・社内IT推進部門
リクルート
ホールディングス
リクルートとは、
主要７事業会社＋３機能会社
で構成されるグループ企業群
5

7. リクルートテクノロジーズの役割
6
開拓
実装、展開運用
テクノロジー
ライフサイクル
≪テクノロジーへの考え方≫
「開拓」「実装・展開」を経た「運用」でリクルートへの利益貢献を行う。

8. リクルートテクノロジーズの役割
7
広範囲のビジネスに装着
し、効果を最大化させる
ための改善を行い、事業
貢献利益を追究
Rグループのビジネスに短・
中期的に実活用の可能性があ
る技術をリサーチ
対象技術における事業化への
検証を行い、評価・選定する
開拓（実活用研究）
実際に事業へ適用し、
より広範囲に利用す
るための型化やス
キームを構築
実装・展開 運用
実施内容
リクルートテクノロジーズ（短・中期的視野）
利益を目的としない中長期的な視
点に立ち、新技術や新手法の研究/
発明を行い、論文発表することを
目指す
要素基礎技術の研究
社外（中・長期的視野）
技術数の
推移イメージ
年間約200の技術をリサーチし、
約30の技術を評価・選定
年間数個～10個の
技術を展開
運用フェーズまで
移行された技術が蓄積
無数の新技術を研究/発明

9. Elasticsearchの活用例
8

10. Elasticsearchを用いたサービス基盤
• 全社検索基盤
 サイト内検索に活用
9
• 全社プッシュ通知基盤
 リアルタイムな検索要
件に活用
• 各サービスの可視化
 検索行動の可視化に活
用
検索
条件抽出
データ取得

11. Elasticsearchを用いたサービス基盤
• 全社検索基盤
 サイト内検索に活用
10
• 全社プッシュ通知基盤
 リアルタイムな検索要
件に活用
• 各サービスの可視化
 検索行動の可視化に活
用
• 更新性能・検索性能向
上
• サイト毎のカスタマイ
ズ性
• リアルタイムな更新の
利用
• クラスタの運用負荷低
減
• 可視化の運用負荷低減
• アドホックな可視化要
望への対応

12. 全社検索基盤: Qass
Elasticsearchの活用例
11

13. 各サービスサイト 各サービス検索エンジン
検索
これまでのリクルートの検索
• Apache Solrをコアエンジンとした構成
 各サイトが独立した検索エンジンを持つ構成
12
各サービスサイト 各サービス検索エンジン
検索
サイトA
サイトB

14. これまでのリクルートの検索
• Apache Solrをコアエンジンとした構成
13
各サービスサイト
各サービス検索エンジン
更新
同じ更新を複数台に投げる必要がある
全ノードが全ドキュメントを持つ必要がある

15. ？
検索品質の継続的向上のために
• 個別検索エンジンを全社統一検索基盤へ
 情報を取りまとめて最適な検索結果の継続的提供
14
エンドユーザー 各サービスサイト
定期的(毎日)な
検索品質向上
商品検索
検索基盤へ検索サイトに合った検索結果
検索結果分析基盤

16. ？
検索品質の継続的向上のために
• 個別検索エンジンを全社統一検索基盤へ
 情報を取りまとめて最適な検索結果の継続的提供
15
エンドユーザー 各サービスサイト
定期的(毎日)な
検索品質向上
商品検索
検索基盤へ検索サイトに合った検索結果
Solr構成のままでは
求める検索性能・更新性能に耐えられない
検索結果分析基盤

17. Solr利用時の課題
16
検索性能
ドキュメント数増加時の
パフォーマンス劣化が心配
更新性能
クラスタ内のノード増加時の
更新結果の反映時間が心配
Solr Elasticsearch
クラスタリング機能を標準装備
ノード間での分散検索が可能※
ノードを跨いだShard同期を標準実装
ノード間での分散更新が可能※
Elasticsearchを採用した新検索基盤の構築へ
※: Solr/SolrCloudでも可能ですが、ES標準でクラスタリング機能があり採用
Solr4.0
リリース
当初
0.9
リリース
当初

18. 全社検索基盤: Qassとは？
• リクルートの全社検索基盤
 Elasticsearchを検索のコアエンジンとして利用
17
エンドユーザー 各サービスサイト
定期的(毎日)な
検索品質向上
商品検索
検索基盤へ検索サイトに合った検索結果
検索チーム
分析内容からの
チューニング
検索結果分析基盤

19. 全社検索基盤: Qassとは？
• 検索品質の継続的向上を行う全社基盤
 自己成長型の検索ソリューション
18
検索結果をQass基盤へ集約
• 検索に関連する情報を一箇所に集積
• 検索結果を横断的に専門家が集約・分析
• 機械学習による検索品質向上 ユーザー行動に応じて
検索品質向上を自動的に行う
検索結果分析基盤

20. サジェスト基盤
全社検索基盤: Qassとは？
• 検索結果の展開
19
検索結果分析基盤
集約された検索結果の知見を利用
あ 検索
アーモンド
アンテナ
改善効果可視化検索ロジック可視化

21. 検索ロジック可視化
QassでのElasticsearchの使い方
• Qassを中心とした検索エコシステム
20
検索結果分析基盤
改善効果可視化
あ 検索
アーモンド
アンテナ
サジェスト基盤
サイトA
サイトB

22. 全社プッシュ通知基盤: Pusna-RS
Elasticsearchの活用例
21

23. GCM
Google Cloud Messaging
全社プッシュ通知基盤：Pusna-RS
• プッシュ通知とは？
 スマートフォンアプリを起動していなくても通知を送ることの出来る仕組み
22
Push!
Push!
APNs
Apple Push Notification Service

24. プッシュ通知の効果
• プッシュ通知は開封率が高い
 メルマガに変わる販促ツールとして注目されている
23
メリット
• 休眠ユーザの再起
• ユーザのアクティブ率向上
• リアルタイムな情報配信
デメリット
• 実装の工数がかかる
• 過剰なプッシュによるユーザ離れのリ
スク
ここに対する取り組みとして、プッシュ
通知基盤を開発

25. リクルート
Pusna-RSの全体構成
24
デバイス管理
プッシュ配信管理
DynamoDB elasticsearch
登録API SQS 登録worker
配信worker SQS
操作用WebUI
管理API
配信担当者
データ基盤
APNs
GCM
事業サーバ

26. リクルート
Pusna-RSの全体構成
25
デバイス管理
プッシュ配信管理
DynamoDB elasticsearch
登録API SQS 登録worker
配信worker SQS
操作用WebUI
管理API
配信担当者
データ基盤
APNs
GCM
事業サーバ
デバイス情報や配信情報の
実データの索引として利用
(Doc数：億単位)

27. Pusna-RSでのElasticsearchの使い方
26
DynamoDB
• Pusna-RSでは複雑なデータ構造が不要
• RDBを使わずに全てのデータをKVSで管理
• DynamoDBはAWSにて提供されるNoSQL
• 信頼性・高速性・高スケーラビリティからマスタとして採用
• 並列スキャンによる高速な全件データ抽出が可能
elasticsearch
• DynamoDBはデータの検索を苦手とする
• 補完するための検索エンジンとして使用
• Solrと同じLuceneベースだが、リアルタイム更新が可能なことから採用。

28. Pusna-RSでのElasticsearchの使い方
27
登録worker
device/
hotpepper
device/
jalan ・・・
elasticsearch
Device情報Table
hotpepper
Device情報Table
jalan
DynamoDB
管理API
＆
配信worker
• 同じデータをDynamoDBとElasticsearchに保存
 用途に応じて適したデータソースを利用
単件＆全件
条件指定＆検索

29. 各サービスの可視化
Elasticsearchの活用例
28

30. 各サービスの可視化
29
• 各サービスの定量的な指標確認
 用途に応じてデータを整理・投入・可視化
検索結果の分析
検索効果の可視化
サービスノード
log
サービスメトリクス
の可視化
検索結果分析基盤

31. 検索基盤の可視化
30
• 検索基盤チーム側で指標の可視化
 利用者からのフィードバックを検索基盤へ反映
検索効果の可視化
• 検索改善施策で
効果の高いもの
は…
• 高頻度な検索の
ものは…
可視化からの解析 検索基盤へのFB

32. プッシュ基盤の可視化
31
• デバイス登録状況・配信状況のリアルタイム可視化
 利用者が次のプッシュ配信への改善に活用
• プッシュ後アプ
リ起動の高い時
間帯は…
• アプリ起動の高
いプッシュ内容
は…
可視化からの解析
次回プッシュ配信
への活用
• 配信時間改善
• メッセージ改善
配信担当者

33. 可視化の横展開
32
• 可視化で得た知見を別のデータソースへ横展開
分析・知見獲得
可視化
Reports & Analytics
Webサーバログ
サーバメトリクス
Webビーコン
検索結果
プッシュ利用実績
新たなデータソースの可視化
ログ分析基盤

34. Elasticsearchの運用ノウハウ
33

35. Elasticsearch運用ノウハウ
• Plugin機構の利用
 Plugin機構を利用した
検索クエリ改善
 Pluginの動的ロード
 PluginでのA/Bテスト
34
• Snapshot機構の利用
 オンラインバックアッ
プ
 本番環境の複製
• 環境に合わせたIndex
作成
 AWS(クラウド上)環境
 オンプレミス環境
Qass Plugin
ICU Plugin Kuromoji
Plugin
…
Plugin
Alias Alias

36. Plugin機構の利用
Elasticseachの運用ノウハウ
35

37. Plugin機構を利用したクエリ改善
• ElasticsearchのPlugin機構を利用
 公式サポートのPluginでIndexing内容を最適化
 Qass独自のPluginでクエリ最適化を実施
36
各サービスサイト
Qass Plugin
• 検索クエリの最適化
• ソート順最適化
などを動的に実施
• 検索クエリは従来通り
ICU/Kuromoji
Plugin
• Indexing内容の最適化

38. Plugin機構を利用したクエリ改善
• Qass独自のPlugin機構
 独自の機構により無停止のモジュール更新
 サイト運営に影響を与えず検索改善
o 高速な検索軸でのA/Bテスト可能な基盤を整備
37
各サービスサイト
Qass Plugin
検索チーム
検索ロジックA v1
検索ロジックB v1 検索ロジックB v2
検索チームで動的切替

39. Snapshot機構の利用
Elasticsearchの運用ノウハウ
38

40. Elasticsearchのバックアップ - Snapshotの内部利用例
• Elasticsearch標準装備のバックアップ機能
 REST API実行で差分バックアップを自動的に実施
39
S3
Disk
プラグインを通して
様々なストレージへ保存可能
REST API
XXXX/XX/01
XXXX/XX/02
差分
差分保存で使用容量効率化
完了までの負荷軽減

41. Elasticsearchのバックアップ - Snapshotの内部利用例
• Snapshot/Restore APIをJenkinsで定期実行
 実際の検索結果を元に検索改善を実施するクラスタを複製
40
Snapshot API
Snapshots
サービス用クラスタ
検索改善用クラスタ
Restore API
本番同等の内容で
検索改善結果を確認可能な
環境を自動的に生成

42. Elasticsearchのバックアップ - Snapshotの内部利用例
• 検索改善用クラスタをデータサイエンティストに提供
 データサイエンティストが自由に検索アルゴリズムを操作、確認可能
41
検索改善用クラスタ
データサイエンティスト
アルゴリズムの操作
結果の確認

43. 環境に合わせたIndex作成
Elasticsearchの運用ノウハウ
42

44. 環境に合わせたIndex作成方法
• 環境によって異なるIndex作成方法を採用
 どのような環境でもサービス影響出さず安全な更新が可能
43
AWS環境
サービス用クラスタ
(Blue面)
サービス用クラスタ
(Green面)
Blue-Green Deploy
でクラスタ切替
オンプレミス環境
Index
A
Index
B
Doc
Alias Alias
River:差分更新
Aliasで
Index切替
サービスノードサービスノード

45. AWS環境でのIndex作成
• AWSの特性を活かしてクラスタごと再構築
 Indexing時のサービスへの負荷なくデプロイ
44
サービス用クラスタ
(Blue面)
サービス用クラスタ
(Green面)
分析基盤
サービス用クラスタ
(Blue面)
サービス用クラスタ
(Green面)
分析基盤
結果分析
クラスタ構築＆
分析結果Indexing
結果分析
クラスタ構築＆
分析結果Indexing

46. 現行Index現行Index
オンプレミス環境でのIndex作成
• Indexの切替をAliasを用いて実現
 サービス影響を出さずに新しいIndexをデプロイ
45
Index
A
Index
B
Doc
Alias Alias
River:差分更新
Indexer
初期投入
Index
A
Index
B
Alias Alias

47. Elasticsearch運用時の注意点
46

48. Elasticsearchの利用バージョン
47
Qass Pusna
利用
バージョン
0.9
1.4
1.5
1.7
出来るだけ最新バージョンを
利用するようにしているが、
リリースサイクルが早く
追いつききれていない
バージョンアップの際はどのような対応が必要か？

49. Elasticsearchのバージョンアップ
• 0.9 -> 1.7へのバージョンアップ
 2バージョンのクラスタを用意してリアルタイムで移行
48
v0.9 クラスタ v1.7 クラスタ
両方へ書込
v0.9 クラスタ v1.7 クラスタ
片バージョンを切り離し

50. Elasticsearchのバージョンアップ
• 0.9 -> 1.7へのバージョンアップ
 2バージョンのクラスタを用意してリアルタイムで移行
49
v0.9 クラスタ v1.7 クラスタ
両方へ書込
v0.9 クラスタ v1.7 クラスタ
片バージョンを切り離し
APIやレスポンスが変わっているため、
そのままの移行は不可能

51. まとめ
50

52. まとめ
リクルートテクノロジーズではElasticsearchを積極活用中し
ています！
@johtaniが主催するElasticsearch勉強会のスペースも提供して
おり、得られたノウハウはその場で共有していきます！
まずは今回お話した詳しい内容を、次回高林(@tatakaba)が話
す予定です！
51

53. 参考資料
• Qass
 Elasticsearch＋Hadoopベースの大規模検索基盤大解剖
 http://www.atmarkit.co.jp/ait/kw/elastic_hadoop.html
• Pusna-RS
 大規模プッシュ通知基盤大解剖
 http://www.atmarkit.co.jp/ait/kw/pushinfra.html
• リクルートテクノロジーズについて
 http://blog.recruit-tech.co.jp/
52

54. おわりに
53

55. 54
リクルートテクノロジーズでは、
Elasticsearchを始めとした、
“先端技術”を使って一緒に仕事をする仲間を募集しています！

56. 55

57. www.elastic.co
56