サマリ

LINE Music のバックエンドで使っている ES のお話。レーベルさん向けに提供している CMS と API サービスがあり、それぞれパフォーマンス問題があったので改善してみた。

自分なりに重要そうなトピックを抜粋すると以下

検索に用いるフィールドが非常に多岐にわたり、データ件数も 85M を数える規模感のユースケースが前提になっている
wildcard/ match query をこう使った、というケーススタディ
ノード数とシャード数＋レプリカ数の関係にはゆるい不等式があり、それを目安にある程度それぞれの数を見積もれる
結局はワークロードを実際に負荷試験してみようぜという話（内部構造に踏み込んで分析して机上でキャパシティを計画する／できるような話ではなかった）

hassaku63

memo

前提事項

Web アプリやネイティブ (iOS) で提供しているサブスク型サービス "LINE Music"
レーベル向けに検索サービス “Meta search API” を提供している。これの裏側を紹介する
85M 規模の曲数を扱っている

事例(1) - CMS

問題意識

これまでは楽曲名のみ検索できた。部分一致で評価する
- アルバムやアーティストでの検索ができない
- 同名の曲が他に存在する場合のさらなる絞り込みができない
- 同一の検索フォームでもっと多様な属性で検索したい
機能追加によって↑をサポートするようになった、しかし...
- 1sec 程度だった検索が 5sec になってしまった
- なにが悪かったのか？（本発表の内容）

従来構成では、 keyword タイプを wildcard で検索 していた。これは当時サービスを早くリリースするのを優先したためであり、パフォーマンスに関する検討は優先度が低かった。

なぜ遅かったのか／どうすれば速くなるのか

遅かった理由は、keyword 型と wildcard query が理由。

keyword は生の文字列を持っていて、とくになんの処理もされていない
wildcard クエリは後方一致が遅い（これは公式ドキュメントにも記述があるらしい。要追記）

文字列の検索を高速にするなら tokenize 処理が必要。ただし、LINE Music で登場するテキストは固有名詞が多いため、一般的なコーパスに基づく tokenize は不向きだった（これをきちんと検討・対策するための工数がリリース当初はなかった）

どうしたのか

楽曲名を text 型に変更
クエリを Full text query の一種である match query に変更

これによって、転置インデックスが使用できるようになり、検索が高速化した。

また、tokenize には n-gram (3)を使用した（形態素解析ベースのアプローチは前述の理由、データ特性により難しい）。

動画 8:22

n-gram の問題は、検索対象文字列の順序が崩れてしまうこと。tokenize したタームの出現順序は反映できない。この問題の対策として、n の数字を大きくすることが検討できる。今回は tri-gram (=3) が丁度良かった。3 文字分で tokenize することで、実用上順序の問題が（無視できる出現頻度となるため）クリアできる。ただ、4文字にすると index が大きくなってしまうので 3文字 (tri-gram) が最適と判断した

ポイントは、