Elasticsearchの勉強会(CA.io#1)のメモ

CA.io vol.1 マッチングサービスを支えるElasticsearch

Elasticsearchに最近興味があって(自分で使ったことはまだない)、ちょうどよさそうな勉強会があったので行ってきた。そのときのメモ。

勉強会ページ: https://cyberagent.connpass.com/event/65002/

セッション1

『Elasticsearch 6.0 is coming』 by Jun Otani @johtani

• 自己紹介
  • elastic社
  • Apache Lucene-gosenコミッター
  • ElasticSearch Server日本語版の翻訳(<- これは今から勉強する人は読まないように。古い。)
• 宣伝
  • 6.0出ます。今preview release
  • 使ってバグ見つけて報告してね！
• Elasticsearch 6.0
  • 6.xにUpgradeするのはかなり楽
    • 1.x -> 2.xのUpgradeは苦行だった
    • 5.xにUpgrade 2.x -> 5.x deprecationが出せる。やるべき対応を洗い出してくれるプラグインがある。
    • 6にUpgrade 5.x -> 6は、クラスタ全部を落とさなくても一台ずつアップグレードしてまわればダウンタイムなしでいける。
  • 改善点
    • 中で使っているLuceneのバージョンが上がった(Lucene7)
      • Better for storing sarse fields
      • Save on disk space
    • ソート検索のクエリ速度改善
    • レプリケーションが早くなっている。
  • 破壊的変更
    • _type がなくなる
      • 今まで間違った使い方をされがちだった
      • 5.xで作ったものでアップグレードしている場合は使える。が、新しく6.xで作れなくなっている。
    • template が index_patterns にrename
  • その他の変更
    • Content-Type detection disabled
    • Deprecation of _all
    • Java High Level REST Client

セッション2

『タップル誕生がElasticsearchを導入した3つの理由』 by Valverde Antonio github:@toniov

• プロダクト紹介
  • 会員数 250万人
  • マッチング数 5500万組
  • ライク 6億件
  • App Annieランキングでアプリ収益第７位
  • フリック形式で恋人を探す
• masterデータをMongoDBにもたせてあり、検索用データをElasticsearchにもたせている
• 導入の理由
  • 検索のパフォーマンスのため
    • ユーザ検索
      • 絞り込み項目が多い
      • もともとMongoDBで検索 平均1,250ms
      • Elasticsearch 平均 231ms
  • より複雑な検索を実現するため
    • 今まで作れなかった機能が開発できた
    • パフォーマンスに余裕が出たので、マルチサーチができるようになった(例並び順:新規ユーザ60%,既存ユーザ40%)
  • 他の検索エンジンよりタップルに合っていた
    • Solrよりあっていた部分
      • Designd for the Cloud
      • Ease of deployment and use
      • JSON-based (サービスバックエンドがNode.js)
      • 社内である程度使われていた
      • トレンド

セッション3

『位置情報を用いたElasticsearchの活用事例』 by 川田 浩史

• 自己紹介
  • CA7年目
  • 担当サービス8個くらい、ほぼ新規
  • CROSSMEが一番担当長い
• プロダクト紹介 CROSSME
  • 「すれ違い」機能が付いたマッチングサービス
  • 近所で出会いやすいアプリという打ち出し方
• Elasticsearch x 位置情報を使った機能を3つ紹介
  • 「すれ違い」機能
    • ある時刻範囲内で特定距離内にユーザがいるのをすれ違いとする。単純。
    • mapping
      • typeをgeo_point型とすることで位置情報として扱うことができる
    • クエリ
      • get_distance
        • distance: miles,centimeters,kilometersを単位付きで指定
        • distance_type
  • 逆geo_location
    • 緯度経度から住所を検索するAPIは基本的に有料
    • しかし、国土交通省が配布しているCSVがあるので、それをElasticsearchに突っ込めば無料で同じものが作れる
  • すれ違いカバー画像
    • 自分の現在位置によってカバー画像が変わってくれる
      • 住所以外の場所名でも画像を変えたい
    • geo_shapeを使用して、範囲内にヒットするものを探す(?)

セッション4

『Elasticsearch活用&運用事例〜mimiの場合〜』 by 矢崎亮太

• miniの紹介
  • 2016年12月リリース
  • 好きな「顔」で検索できる
    • キレイ系/かわいい系
    • etc...
  • その他年齢、住所、趣味、その他もろもろの条件で検索可能
  • 男/女で検索に使える属性が違う
  • 完全一致で検索したい項目と、スコアマッチで検索したい項目がある
• インデックス再構築事例
  • インデックス定義やシャーディングはあとからの変更はできない
  • elasticsearchに格納されていないフィールドがあったり、想定と違うフィールドがあったりした。
    • ->インデクス再構築の必要性
  • 新形式のインデックスを作成、同期ツールを作って同期を保った
    • タイミングをみてアプリケーション側で旧->新へ向き先を変更

セッション5

『トルテが実践したマッチしたユーザーを除く3つの方法』 by 中川 武憲 github:@ww24

• レディファーストの恋アプリ
• マッチしたユーザを除く3つの方法
  • マッチしている場合、ブロックしている場合は表示してはいけない
  • 方法
    • 1:documentにもたせる
      • メリット
        • シンプル
        • 検索速い
      • デメリット
        • user documentが肥大化
    • 2:queryにもたせる
      • 検索クエリでexclude userを指定
      • メリット
        • シンプル
      • デメリット
        • 検索クエリが肥大化
    • 3:parent-childを使う
      • exclude user documentのchild documentをもたせる
      • メリット 比較的検索も更新も速い
      • デメリット
        • 複雑
        • document数が増加
        • Parent-childはES6で仕様変更が予定されている
• Elasticsearch on EC2
  • 2つの選択肢
    • Elastic Cloud
      • Elasticsearch社の公式サービス
      • X-Packも使えて全部入り
      • 最新のESが使える
      • GCPも選べる
    • Amazon Elasticsearch Service
      • AWSのフルマネージドサービス
      • ログ集計と可視化用途の色が濃い
  • 負荷試験
    • Gatling
  • 最終的な判断
    • EC2
      • 構築運用できるエンジニアがいればコストパフォーマンス最強
      • ansibleで管理して、横軸組織で共有
• 構成
  • master node 3
  • data node 4

---

memo

• アプリケーションの高度な検索を実現する基盤としてのElasticsearchの運用としては、マスターデータとしてRDBが使われていて、それをもとに検索用をElasticsearchに持たせる構成にするのがよさげ
• Amazon Elasticsearch Serviceは、マネージドサービスとはいえ障害が色々あったりとわりとツライことがあるのかなという印象。管理できるエンジニアがいる場合はElasticsearch on EC2がよさげ。
• Elasticsearch、アイデアしだいで面白いことができそう