Download as PDF, PPTX
More Related Content
リクルート流Elasticsearchの使い方
- 1.
- 2.
- 3. 自己紹介 • 氏名 中原裕成 • 所属 株式会社リクルートテクノロジーズ ITソリューション統括部 インフラソリューション部 • 担当業務 Elasticsearchを用いたサービスの運用など 2
- 4. もくじ 1. はじめに リクルート/リクルートテクノロジーズとは？ 2.Elasticsearchの活用例 Qass / Pusna / サービス可視化 3. Elasticsearchの運用ノウハウ Plugin Snapshot index バージョンアップ 4. さいごに 3
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. Elasticsearchを用いたサービス基盤 • 全社検索基盤 サイト内検索に活用 9 •全社プッシュ通知基盤 リアルタイムな検索要 件に活用 • 各サービスの可視化 検索行動の可視化に活 用 検索 条件抽出 データ取得
- 11. Elasticsearchを用いたサービス基盤 • 全社検索基盤 サイト内検索に活用 10 •全社プッシュ通知基盤 リアルタイムな検索要 件に活用 • 各サービスの可視化 検索行動の可視化に活 用 • 更新性能・検索性能向 上 • サイト毎のカスタマイ ズ性 • リアルタイムな更新の 利用 • クラスタの運用負荷低 減 • 可視化の運用負荷低減 • アドホックな可視化要 望への対応
- 12.
- 13. 各サービスサイト 各サービス検索エンジン 検索 これまでのリクルートの検索 • ApacheSolrをコアエンジンとした構成 各サイトが独立した検索エンジンを持つ構成 12 各サービスサイト 各サービス検索エンジン 検索 サイトA サイトB
- 14.
- 15. ？ 検索品質の継続的向上のために • 個別検索エンジンを全社統一検索基盤へ 情報を取りまとめて最適な検索結果の継続的提供 14 エンドユーザー各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 検索結果分析基盤
- 16. ？ 検索品質の継続的向上のために • 個別検索エンジンを全社統一検索基盤へ 情報を取りまとめて最適な検索結果の継続的提供 15 エンドユーザー各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 Solr構成のままでは 求める検索性能・更新性能に耐えられない 検索結果分析基盤
- 17.
- 18. 全社検索基盤: Qassとは？ • リクルートの全社検索基盤 Elasticsearchを検索のコアエンジンとして利用 17 エンドユーザー 各サービスサイト 定期的(毎日)な 検索品質向上 商品検索 検索基盤へ検索サイトに合った検索結果 検索チーム 分析内容からの チューニング 検索結果分析基盤
- 19. 全社検索基盤: Qassとは？ • 検索品質の継続的向上を行う全社基盤 自己成長型の検索ソリューション 18 検索結果をQass基盤へ集約 • 検索に関連する情報を一箇所に集積 • 検索結果を横断的に専門家が集約・分析 • 機械学習による検索品質向上 ユーザー行動に応じて 検索品質向上を自動的に行う 検索結果分析基盤
- 20. サジェスト基盤 全社検索基盤: Qassとは？ • 検索結果の展開 19 検索結果分析基盤 集約された検索結果の知見を利用 あ検索 アーモンド アンテナ 改善効果可視化検索ロジック可視化
- 21.
- 22.
- 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.
- 29.
- 30.
- 31. 検索基盤の可視化 30 • 検索基盤チーム側で指標の可視化 利用者からのフィードバックを検索基盤へ反映 検索効果の可視化 •検索改善施策で 効果の高いもの は… • 高頻度な検索の ものは… 可視化からの解析 検索基盤へのFB
- 32. プッシュ基盤の可視化 31 • デバイス登録状況・配信状況のリアルタイム可視化 利用者が次のプッシュ配信への改善に活用 •プッシュ後アプ リ起動の高い時 間帯は… • アプリ起動の高 いプッシュ内容 は… 可視化からの解析 次回プッシュ配信 への活用 • 配信時間改善 • メッセージ改善 配信担当者
- 33. 可視化の横展開 32 • 可視化で得た知見を別のデータソースへ横展開 分析・知見獲得 可視化 Reports &Analytics Webサーバログ サーバメトリクス Webビーコン 検索結果 プッシュ利用実績 新たなデータソースの可視化 ログ分析基盤
- 34.
- 35. Elasticsearch運用ノウハウ • Plugin機構の利用 Plugin機構を利用した 検索クエリ改善 Pluginの動的ロード PluginでのA/Bテスト 34 • Snapshot機構の利用 オンラインバックアッ プ 本番環境の複製 • 環境に合わせたIndex 作成 AWS(クラウド上)環境 オンプレミス環境 Qass Plugin ICU Plugin Kuromoji Plugin … Plugin Alias Alias
- 36.
- 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.
- 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.
- 44. 環境に合わせたIndex作成方法 • 環境によって異なるIndex作成方法を採用 どのような環境でもサービス影響出さず安全な更新が可能 43 AWS環境 サービス用クラスタ (Blue面) サービス用クラスタ (Green面) Blue-GreenDeploy でクラスタ切替 オンプレミス環境 Index A Index B Doc Alias Alias River:差分更新 Aliasで Index切替 サービスノードサービスノード
- 45.
- 46. 現行Index現行Index オンプレミス環境でのIndex作成 • Indexの切替をAliasを用いて実現 サービス影響を出さずに新しいIndexをデプロイ 45 Index A Index B Doc AliasAlias River:差分更新 Indexer 初期投入 Index A Index B Alias Alias
- 47.
- 48.
- 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.
- 52.
- 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.
- 55.
- 56.
- 57.