さようならElasticsearch、よろしくElastic Cloud

2022/5/19 20:25 - 20:40

（明らかに15分で収まる内容の資料ではないですが、資料はモリモリで発表はスカスカでもScrapboxで盛り上がれるか、という仮説の検証を兼ねています）

Gyazoのプロジェクトマネージャー兼ソフトウェアエンジニアです

本日お集まりいただいたみなさん、ありがとうございます

https://gyazo.com/503119ac54a9b908e4f54a683279133c

本日お集まりいただいたみなさん

一応動いてるんだけどなんで動いてるのか誰もわかっていない状態

新しい検索の機能追加やアイデアを試行錯誤したいけど、変更方法が不明のため、諦める

いやそれはダメでしょということで、検索インフラ刷新を検討し、いろいろと模索はしていた

これまで通りのことができるようにする

高速な検索

オンデマンドなindexing

無料ユーザーの画像は検索を試そうとした時だけindexingすることでコスト節約

追加で実現したいこと

正確な検索

index mappingsを再定義・再構築できるようにする

移行におけるダウンタイムはゼロ

謎のロストテクノロジーにしない

これ全部話すと一時間になるので面白い話とお得な話だけします

Elastic Cloudに移行しようとしていた間、ハチャメチャに失敗していました

（科学においても、工学においても、医学においても、経営・事業においても、政治においても、etc）

Anyone who has never made a mistake has never tried anything new.

まず落ちるテストを書く＝まず失敗する

とはいえガンガンシステム壊しちゃいました！では困る

ググったらCFOがいる企業は実在する模様

最高財務責任者（Chief Financial Officer）では

「失敗に関する本も読んでいる」

影響範囲が限定されている

すばやく失敗前の状態に戻せる

発生条件がコントロールされている

Gyazoユーザーが検索できなくなってしまいましたみたいな事態は絶対に避ける

失敗：index mappings更新時にハチャメチャに負荷が跳ね上がってしまう

最高に過酷だった時

CPU Usage 200%超え！

Search Response Times 60k ms超え！

Index Response Times 60k ms超え！

https://gyazo.com/b5854840832f851c840ffe0f354918e0

だいぶ過酷だった時

CPU Usage 100%超え！

Search Respones Times 10k ms超え！

https://gyazo.com/e3ab80d825c59552afba3198035769e3

Elastic Cloudにこれよりも負荷かけたことあるぞという人がいたら是非ご連絡ください

結果：そんなことはない。小さいshardsを増やすと最高に過酷になる（後述）

?refresh=true

結果：そんなことはない。そしてずっとだいぶ過酷だったのは、おそらくこれが原因だった（後述）

複数のdata nodeでクラスタを構成する

検索indexをshardで分割して各data nodeで分散して持つ

shardはさらにreplicaごとにdata nodeに冗長化される

shardの実体はsegmentである

Luceneの概念

indexをファイルシステム上の小さいファイルとして持つ

リクエスト時に何が起きるか……

searchリクエスト時

全shardでindexを検索して、結果を統合する

indexingリクエスト時

メモリ上のIndexing Bufferから、指定したタイミングで、shardごとに、ファイルシステム上のsegmentに反映する

この処理がめちゃくちゃ重いので、可能な限り先延ばししたほうが良い

Elastic Cloudにおいて、Elasticsearchクラスタは、Deploymentと呼ばれる

たいていのクラウドインフラはAZはregionごとに3つ

data node超大量に立てて負荷分散させるみたいな力技はできない

Elastic Cloudとしてはdata nodeの性能を最大限引き出して3台のクラスタでスケールインすることを推奨

小さいdata nodeを大量に立ち上げるのは実は非推奨

data nodeのCPUとメモリがElasticsearchのパフォーマンスに大きく影響するため

----- ----- ここからは index settings お得情報です ----- -----

（index settingsとは、Elasticsearchがindexをどのように扱うかというindexに関するメタ的な設定項目です）

（公式ドキュメントに書いてある）

number_of_shardsのデフォルト値は1

data nodeが3台あっても、number_of_shardsの値が1だと、1台しか使われない

data nodeが3台あるなら、少なくとも3に変更しないと、意味がない

shardのサイズが50GBを超えそうだったら、6, 9, 12, 15...にする

後から変更不可能なので、見積もって設計する必要がある

indexingもsearchも、shardごとに実行される

data nodeの台数が少ないのに、小さいshardsが大量にあると、処理がメッチャ遅くなる

number_of_replicasのデフォルト値は1

number_of_shardsが3でnumber_of_replicasが1だと、indexing時に6つのshardに書き込む必要がある

indexing時は0にしておくとパフォーマンスが向上する

bulk APIでindexingのリクエスト数を減らす

余談：bulk APIのリクエストボディが巨大すぎるとそれはそれでElasticsearchがご機嫌斜めになる

（！！！公式ドキュメントに書いてない！！！）

GyazoではCircleCI上でElasticsearchを立ち上げて実際にindexingやsearchをリクエストしてテストしている

https://gyazo.com/d5c19d9aa1118dae0a0c437e9e7a6b59

Indexingリクエストが殺到していても検索レスポンスが150ms以下

----- ----- ここからは index mappings お得情報です ----- -----

（index mappingsとは、検索対象のドキュメントを実際にどのようなデータ型とデータ構造でindexingするかという設定項目です）

（公式ドキュメントに書いてある）

Elasticsearchの気持ちになって考えてみてください

code:ruby

everything: {

type: 'text',

analyzer: 'ngram_analyzer',

}

code:ruby

title: {

type: 'text',

analyzer: 'ngram_analyzer',

copy_to: 'everything',

},

desc: {

type: 'text',

analyzer: 'ngram_analyzer',

copy_to: 'everything',

},

ocr: {

type: 'text',

analyzer: 'ngram_analyzer',

copy_to: 'everything',

},

code:ruby

{

match_phrase: {

everything: term

}

}

逆にこれをやらないですべてのフィールド内の文字列を全文検索しようとするとどうなる…？

code:ruby

{

multi_match: {

query: term,

}

}

フィールド数が多い場合はこのテクニックは重要

Gyazoは様々な画像のメタデータを持っているため、この場合にあたる

Gyazoの全文検索はこれで実現されている

（公式ドキュメントに書いてある）

旧Elasticsearchでは、全て、kuromojiインデックスによる全文検索だった

実は検索できない単語があった

Elastic Cloudではn-gramインデックスで、1文字単位で全文検索できるようになった

意図しないTokenizeが行われてしまったり辞書に無い単語では検索できないという問題が解決できた

（使えるけど精度が微妙）

n-gramとは別にkuromojiのインデックスを持つことで、いいとこ取りできる

code:ruby

everything: {

type: 'text',

analyzer: 'ngram_analyzer',

fields: {

kuromoji: {

type: 'text',

analyzer: 'kuromoji_analyzer',

}

}

}

もちろんこのフィールドに対して任意の検索クエリが実行できる

code:ruby

{

more_like_this: {

like: [

{

_index: "index-name",

_id: "document-id"

}

]

}

}

Elastic Cloudに移行して良かった点

Elastic Cloudでハチャメチャな失敗をしたことで、ElasticsearchやLuceneについての理解が深まってよかった

ゼロダウンタイムでElasticsearchからElastic Cloudへ移行できた

ElasticsearchのマイナーバージョンアップはElastic Cloudで管理画面でボタンを押すだけで可能になった

Elastic Cloudで困っている点

Kuromojiの辞書を簡単にカスタマイズできない

新語に対応できない

Elastic Cloudの方と話をしたら仕様的には頑張れば辞書カスタマイズできるらしいです

追加できるカスタムプラグインの形式や容量が制限されている

（Elastic Cloudが機械学習による自然言語処理に対応したらしいけど全然大変）

type:gif

Gif画像を検索

app:"Google Chrome"

site:scrapbox.io

Scrapbox経由で貼り付けた画像を検索

title:typescript

ocr:Gyazo

https://gyazo.com/f445820427f5379bc570c38d31bd923a

まあscrapboxもそんな感じですし

関連リンク

https://gyazo.com/a68a9407024069c9592c2349aa5d1b08 https://amzn.to/3lmGLRq