リクルート流Elasticsearchの使い方

リクルート流Elasticsearchの使い方

1. 1. 0
2. 2. 株式会社リクルートテクノロジーズ インフラソリューション部 中原 裕成 1 リクルート流Elasticsearchの使い方
3. 3. 自己紹介 • 氏名  中原 裕成 • 所属  株式会社リクルートテクノロジーズ ITソリューション統括部 インフラソリューション部 • 担当業務  Elasticsearchを用いたサービスの運用など 2
4. 4. もくじ 1. はじめに  リクルート/リクルートテクノロジーズとは？ 2. Elasticsearchの活用例  Qass / Pusna / サービス可視化 3. Elasticsearchの運用ノウハウ  Plugin  Snapshot  index  バージョンアップ 4. さいごに 3
5. 5. はじめに 4
6. 6. リクルートテクノロジーズとは リクルートキャリア リクルートジョブズ リクルートスタッフィング リクルート住まいカンパニー リクルートライフスタイル リクルートマーケティングパートナーズ スタッフサービス・ホールディングス リクルートアドミニストレーション リクルートコミュニケーションズ 事業会社 機能会社 インフラ部門 大規模プロジェクト推進部門 UI設計/SEO部門 ビッグデータ機能部門 テクノロジーR&D部門 事業・社内IT推進部門 リクルート ホールディングス リクルートとは、 主要７事業会社＋３機能会社 で構成されるグループ企業群 5
7. 7. リクルートテクノロジーズの役割 6 開拓 実装、展開運用 テクノロジー ライフサイクル ≪テクノロジーへの考え方≫ 「開拓」「実装・展開」を経た「運用」でリクルートへの利益貢献を行う。
8. 8. リクルートテクノロジーズの役割 7 広範囲のビジネスに装着 し、効果を最大化させる ための改善を行い、事業 貢献利益を追究 Rグループのビジネスに短・ 中期的に実活用の可能性があ る技術をリサーチ 対象技術における事業化への 検証を行い、評価・選定する 開拓（実活用研究） 実際に事業へ適用し、 より広範囲に利用す るための型化やス キームを構築 実装・展開 運用 実施内容 リクルートテクノロジーズ（短・中期的視野） 利益を目的としない中長期的な視 点に立ち、新技術や新手法の研究/ 発明を行い、論文発表することを 目指す 要素基礎技術の研究 社外（中・長期的視野） 技術数の 推移イメージ 年間約200の技術をリサーチし、 約30の技術を評価・選定 年間数個～10個の 技術を展開 運用フェーズまで 移行された技術が蓄積 無数の新技術を研究/発明
9. 9. Elasticsearchの活用例 8
10. 10. Elasticsearchを用いたサービス基盤 • 全社検索基盤  サイト内検索に活用 9 • 全社プッシュ通知基盤  リアルタイムな検索要 件に活用 • 各サービスの可視化  検索行動の可視化に活 用 検索 条件抽出 データ取得
11. 11. Elasticsearchを用いたサービス基盤 • 全社検索基盤  サイト内検索に活用 10 • 全社プッシュ通知基盤  リアルタイムな検索要 件に活用 • 各サービスの可視化  検索行動の可視化に活 用 • 更新性能・検索性能向 上 • サイト毎のカスタマイ ズ性 • リアルタイムな更新の 利用 • クラスタの運用負荷低 減 • 可視化の運用負荷低減 • アドホックな可視化要 望への対応
12. 12. 全社検索基盤: Qass Elasticsearchの活用例 11
13. 13. 各サービスサイト 各サービス検索エンジン 検索 これまでのリクルートの検索 • Apache Solrをコアエンジンとした構成  各サイトが独立した検索エンジンを持つ構成 12 各サービスサイト 各サービス検索エンジン 検索 サイトA サイトB
14. 14. これまでのリクルートの検索 • Apache Solrをコアエンジンとした構成 13 各サービスサイト 各サービス検索エンジン 更新 同じ更新を複数台に投げる必要がある 全ノードが全ドキュメントを持つ必要がある
15. 15. ？ 検索品質の継続的向上のために • 個別検索エンジンを全社統一検索基盤へ  情報を取りまとめて最適な検索結果の継続的提供 14 エンドユーザー 各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 検索結果分析基盤
16. 16. ？ 検索品質の継続的向上のために • 個別検索エンジンを全社統一検索基盤へ  情報を取りまとめて最適な検索結果の継続的提供 15 エンドユーザー 各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 Solr構成のままでは 求める検索性能・更新性能に耐えられない 検索結果分析基盤
17. 17. Solr利用時の課題 16 検索性能 ドキュメント数増加時の パフォーマンス劣化が心配 更新性能 クラスタ内のノード増加時の 更新結果の反映時間が心配 Solr Elasticsearch クラスタリング機能を標準装備 ノード間での分散検索が可能※ ノードを跨いだShard同期を標準実装 ノード間での分散更新が可能※ Elasticsearchを採用した新検索基盤の構築へ ※: Solr/SolrCloudでも可能ですが、ES標準でクラスタリング機能があり採用 Solr4.0 リリース 当初 0.9 リリース 当初
18. 18. 全社検索基盤: Qassとは？ • リクルートの全社検索基盤  Elasticsearchを検索のコアエンジンとして利用 17 エンドユーザー 各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 検索チーム 分析内容からの チューニング 検索結果分析基盤
19. 19. 全社検索基盤: Qassとは？ • 検索品質の継続的向上を行う全社基盤  自己成長型の検索ソリューション 18 検索結果をQass基盤へ集約 • 検索に関連する情報を一箇所に集積 • 検索結果を横断的に専門家が集約・分析 • 機械学習による検索品質向上 ユーザー行動に応じて 検索品質向上を自動的に行う 検索結果分析基盤
20. 20. サジェスト基盤 全社検索基盤: Qassとは？ • 検索結果の展開 19 検索結果分析基盤 集約された検索結果の知見を利用 あ 検索 アーモンド アンテナ 改善効果可視化検索ロジック可視化
21. 21. 検索ロジック可視化 QassでのElasticsearchの使い方 • Qassを中心とした検索エコシステム 20 検索結果分析基盤 改善効果可視化 あ 検索 アーモンド アンテナ サジェスト基盤 サイトA サイトB
22. 22. 全社プッシュ通知基盤: Pusna-RS Elasticsearchの活用例 21
23. 23. GCM Google Cloud Messaging 全社プッシュ通知基盤：Pusna-RS • プッシュ通知とは？  スマートフォンアプリを起動していなくても通知を送ることの出来る仕組み 22 Push! Push! APNs Apple Push Notification Service
24. 24. プッシュ通知の効果 • プッシュ通知は開封率が高い  メルマガに変わる販促ツールとして注目されている 23 メリット • 休眠ユーザの再起 • ユーザのアクティブ率向上 • リアルタイムな情報配信 デメリット • 実装の工数がかかる • 過剰なプッシュによるユーザ離れのリ スク ここに対する取り組みとして、プッシュ 通知基盤を開発
25. 25. リクルート Pusna-RSの全体構成 24 デバイス管理 プッシュ配信管理 DynamoDB elasticsearch 登録API SQS 登録worker 配信worker SQS 操作用WebUI 管理API 配信担当者 データ基盤 APNs GCM 事業サーバ
26. 26. リクルート Pusna-RSの全体構成 25 デバイス管理 プッシュ配信管理 DynamoDB elasticsearch 登録API SQS 登録worker 配信worker SQS 操作用WebUI 管理API 配信担当者 データ基盤 APNs GCM 事業サーバ デバイス情報や配信情報の 実データの索引として利用 (Doc数：億単位)
27. 27. Pusna-RSでのElasticsearchの使い方 26 DynamoDB • Pusna-RSでは複雑なデータ構造が不要 • RDBを使わずに全てのデータをKVSで管理 • DynamoDBはAWSにて提供されるNoSQL • 信頼性・高速性・高スケーラビリティからマスタとして採用 • 並列スキャンによる高速な全件データ抽出が可能 elasticsearch • DynamoDBはデータの検索を苦手とする • 補完するための検索エンジンとして使用 • Solrと同じLuceneベースだが、リアルタイム更新が可能なことから採用。
28. 28. Pusna-RSでのElasticsearchの使い方 27 登録worker device/ hotpepper device/ jalan ・・・ elasticsearch Device情報Table hotpepper Device情報Table jalan DynamoDB 管理API ＆ 配信worker • 同じデータをDynamoDBとElasticsearchに保存  用途に応じて適したデータソースを利用 単件＆全件 条件指定＆検索
29. 29. 各サービスの可視化 Elasticsearchの活用例 28
30. 30. 各サービスの可視化 29 • 各サービスの定量的な指標確認  用途に応じてデータを整理・投入・可視化 検索結果の分析 検索効果の可視化 サービスノード log サービスメトリクス の可視化 検索結果分析基盤
31. 31. 検索基盤の可視化 30 • 検索基盤チーム側で指標の可視化  利用者からのフィードバックを検索基盤へ反映 検索効果の可視化 • 検索改善施策で 効果の高いもの は… • 高頻度な検索の ものは… 可視化からの解析 検索基盤へのFB
32. 32. プッシュ基盤の可視化 31 • デバイス登録状況・配信状況のリアルタイム可視化  利用者が次のプッシュ配信への改善に活用 • プッシュ後アプ リ起動の高い時 間帯は… • アプリ起動の高 いプッシュ内容 は… 可視化からの解析 次回プッシュ配信 への活用 • 配信時間改善 • メッセージ改善 配信担当者
33. 33. 可視化の横展開 32 • 可視化で得た知見を別のデータソースへ横展開 分析・知見獲得 可視化 Reports & Analytics Webサーバログ サーバメトリクス Webビーコン 検索結果 プッシュ利用実績 新たなデータソースの可視化 ログ分析基盤
34. 34. Elasticsearchの運用ノウハウ 33
35. 35. Elasticsearch運用ノウハウ • Plugin機構の利用  Plugin機構を利用した 検索クエリ改善  Pluginの動的ロード  PluginでのA/Bテスト 34 • Snapshot機構の利用  オンラインバックアッ プ  本番環境の複製 • 環境に合わせたIndex 作成  AWS(クラウド上)環境  オンプレミス環境 Qass Plugin ICU Plugin Kuromoji Plugin … Plugin Alias Alias
36. 36. Plugin機構の利用 Elasticseachの運用ノウハウ 35
37. 37. Plugin機構を利用したクエリ改善 • ElasticsearchのPlugin機構を利用  公式サポートのPluginでIndexing内容を最適化  Qass独自のPluginでクエリ最適化を実施 36 各サービスサイト Qass Plugin • 検索クエリの最適化 • ソート順最適化 などを動的に実施 • 検索クエリは従来通り ICU/Kuromoji Plugin • Indexing内容の最適化
38. 38. Plugin機構を利用したクエリ改善 • Qass独自のPlugin機構  独自の機構により無停止のモジュール更新  サイト運営に影響を与えず検索改善 o 高速な検索軸でのA/Bテスト可能な基盤を整備 37 各サービスサイト Qass Plugin 検索チーム 検索ロジックA v1 検索ロジックB v1 検索ロジックB v2 検索チームで動的切替
39. 39. Snapshot機構の利用 Elasticsearchの運用ノウハウ 38
40. 40. Elasticsearchのバックアップ - Snapshotの内部利用例 • Elasticsearch標準装備のバックアップ機能  REST API実行で差分バックアップを自動的に実施 39 S3 Disk プラグインを通して 様々なストレージへ保存可能 REST API XXXX/XX/01 XXXX/XX/02 差分 差分保存で使用容量効率化 完了までの負荷軽減
41. 41. Elasticsearchのバックアップ - Snapshotの内部利用例 • Snapshot/Restore APIをJenkinsで定期実行  実際の検索結果を元に検索改善を実施するクラスタを複製 40 Snapshot API Snapshots サービス用クラスタ 検索改善用クラスタ Restore API 本番同等の内容で 検索改善結果を確認可能な 環境を自動的に生成
42. 42. Elasticsearchのバックアップ - Snapshotの内部利用例 • 検索改善用クラスタをデータサイエンティストに提供  データサイエンティストが自由に検索アルゴリズムを操作、確認可能 41 検索改善用クラスタ データサイエンティスト アルゴリズムの操作 結果の確認
43. 43. 環境に合わせたIndex作成 Elasticsearchの運用ノウハウ 42
44. 44. 環境に合わせたIndex作成方法 • 環境によって異なるIndex作成方法を採用  どのような環境でもサービス影響出さず安全な更新が可能 43 AWS環境 サービス用クラスタ (Blue面) サービス用クラスタ (Green面) Blue-Green Deploy でクラスタ切替 オンプレミス環境 Index A Index B Doc Alias Alias River:差分更新 Aliasで Index切替 サービスノードサービスノード
45. 45. AWS環境でのIndex作成 • AWSの特性を活かしてクラスタごと再構築  Indexing時のサービスへの負荷なくデプロイ 44 サービス用クラスタ (Blue面) サービス用クラスタ (Green面) 分析基盤 サービス用クラスタ (Blue面) サービス用クラスタ (Green面) 分析基盤 結果分析 クラスタ構築＆ 分析結果Indexing 結果分析 クラスタ構築＆ 分析結果Indexing
46. 46. 現行Index現行Index オンプレミス環境でのIndex作成 • Indexの切替をAliasを用いて実現  サービス影響を出さずに新しいIndexをデプロイ 45 Index A Index B Doc Alias Alias River:差分更新 Indexer 初期投入 Index A Index B Alias Alias
47. 47. Elasticsearch運用時の注意点 46
48. 48. Elasticsearchの利用バージョン 47 Qass Pusna 利用 バージョン 0.9 1.4 1.5 1.7 出来るだけ最新バージョンを 利用するようにしているが、 リリースサイクルが早く 追いつききれていない バージョンアップの際はどのような対応が必要か？
49. 49. Elasticsearchのバージョンアップ • 0.9 -> 1.7へのバージョンアップ  2バージョンのクラスタを用意してリアルタイムで移行 48 v0.9 クラスタ v1.7 クラスタ 両方へ書込 v0.9 クラスタ v1.7 クラスタ 片バージョンを切り離し
50. 50. Elasticsearchのバージョンアップ • 0.9 -> 1.7へのバージョンアップ  2バージョンのクラスタを用意してリアルタイムで移行 49 v0.9 クラスタ v1.7 クラスタ 両方へ書込 v0.9 クラスタ v1.7 クラスタ 片バージョンを切り離し APIやレスポンスが変わっているため、 そのままの移行は不可能
51. 51. まとめ 50
52. 52. まとめ リクルートテクノロジーズではElasticsearchを積極活用中し ています！ @johtaniが主催するElasticsearch勉強会のスペースも提供して おり、得られたノウハウはその場で共有していきます！ まずは今回お話した詳しい内容を、次回高林(@tatakaba)が話 す予定です！ 51
53. 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. 54. おわりに 53
55. 55. 54 リクルートテクノロジーズでは、 Elasticsearchを始めとした、 “先端技術”を使って一緒に仕事をする仲間を募集しています！
56. 56. 55
57. 57. www.elastic.co 56