「ElasticsearchのReindexをするために試行錯誤して分かったこと」 50回 Elasticsearch勉強会

by Jungwon Choi

Slide 1

Slide 1 text

ElasticsearchのReindexをするために試行錯誤して分かったこと 2022.10.26@第50回Elasticsearch勉強会　#elasticsearchjp NewsPicks Engineer / 崔井源

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

やりたかったこと ©NewsPicks Inc. All Rights Reserved.   ● 精度改善がしたい ○ クエリを改善する策は全て打ったのでanalyzerを改善したい ○ 例１）インデックス時に登録した同義語を変えたい・消したい ○ 例２）analyzerの定義を変えたい ● マネージド化がしたい（Amazon OpenSearch Service） ○ 仕様の問題で今のテンプレートは使えない ○ 例１）ユーザ辞書のファイル名をパッケージIDに変更する必要がある ● Reindexによる副作用はないか確認したい ○ 負荷はどれくらい高まるのか ○ Reindexの完了までどれくらいかかるのか ○ 本番ではどんな手順で行えばいいか 01

Slide 5

Slide 5 text

Elasticsearchの構成 ©NewsPicks Inc. All Rights Reserved.   02 ● Node：Elasticsearchが動作する各サーバ ● Cluster：複数のノードの束 ● Shard：Lucene Indexとしてディスクに保存 ○ Lucene Segmentファイルを定期的にマージすることで作成される ○ ↑のRefresh処理をすることで検索可能なデータになる ● Primary Shard：格納されたデータ ● Replica Shard：データのコピー

Slide 6

Slide 6 text

Reindexとは ©NewsPicks Inc. All Rights Reserved.   03 インデックスドキュメント [ { “token”: “環境”, “partOfSpeech”: “名詞-一般”, }, { “token”: “に”, “partOfSpeech”: “助詞-格助詞-一般”, }, { “token”: “優しい”, “partOfSpeech”: “形容詞-自立”, }, ... ] インデックスを作り直すこと！ ● analyzerで形態素解析の方法などを定義 ● 定義を変えるなどして再分析してもらうにはインデックスを作り直す必要がある { “title”: “環境に優しいオレンジジュース”, “summary”: “近年、オレンジジュース産業が...”, ... }

Slide 7

Slide 7 text

Slide 8

Slide 8 text

©NewsPicks Inc. All Rights Reserved.   本番環境の検索データのコピー ● Snapshot / Restore機能を利用する ○ S3のパスが同じであれば別のClusterからレポジトリーを作ってRestoreできる ○ Restore時に e”include_global_state”: truee オプションを付けることでインデックスのCluster 設定もコピーできる  本番で運用しているCluster 環境と近い環境を構築 ● 本番のReplica Shard数に合わせて Nodeを構成する ○ Replica Shardを持たないか、本番より少ない場合 eno_valid_shard_copye などのエラーによりNode Failureになる可能性がある ○ EC2でサーバを立てているので、EC2 Discovery Pluginで「EC2インスタンス1台 = Node1台」にする ● インデックスのPrimary Shard / Replica Shardの設定は e_settingse から確認できる  実験設定 ● 同時にReindexするインデックス数：1 ● インデックスが持つドキュメント数：約1,500万件 ○ Node1台あたり15GBを占める ● Cluster数：1 ● Node数：3 ○ 1台のディスク容量：40GB ○ SSDのGP2を使用 04 Reindexの実験実験環境づくり

Slide 9

Slide 9 text

©NewsPicks Inc. All Rights Reserved.   04 Reindexの実験 ● Primary Shard数：5 ● Replica Shard数：2 実験結果 ● CPU使用率はReindex実行直後急激に上がり、その後は90%程度を維持 ● ↑の状態で検索APIを連続で実行してもレスポンスが帰ってくるまでの時間に影響なし（0.5秒以下） ● Node1台あたり15GBを占めるインデックスで8時間がかかった実験1) Templateを変更せずインデックスをそのまま Reindexする 2分で全NodeのCPU使用率が92% ずっとその状態を維持

Slide 10

Slide 10 text

©NewsPicks Inc. All Rights Reserved.   ● Node1台のPrimary Shard数が多くなるにつれ遅くなるので、実験1)よりPrimary Shard数を少なくした ○ Primary Shard数：1 ○ Replica Shard数：0 ○ e(replica shard 数 + 1) * primary shard 数 = (0 + 1) * 1 = 1e になり、Shardは1つのみ実験結果 ● 実験1)よりReindexにかかる時間が3倍短縮できた ● Replica Shard数が本番より少ない場合、Node Failureが起きる ○ 実験に使ったインデックスはNode1台当たり15GBだが、40GBのNode1台に収まらない実験2) Templateを修正しReplica Shardは持たさずReindexする 04 Reindexの実験 [2022-03-31T03:52:53,741][WARN ][o.e.c.r.a.AllocationService] [ip-{node_ip_address}] failing shard [failed shard, shard [some_index][0], node[{node_id}], relocating [{id}], [P], recovery_source[peer recovery], s[INITIALIZING], a[id={id} rId={id}], expected_shard_size[18148402752], message [shard failure, reason [index]], failure [IOException[No space left on device]], markAsStale [true]]java.io.IOException: No space left on device

Slide 11

Slide 11 text

©NewsPicks Inc. All Rights Reserved.   ● データを書き込む空間が足りないと、インデックスは読み込みのみが可能になる ○ 空間確保後も ecluster_block_exceptione エラーになったら ecluster.blocks.read_onlye をnullにする ● Reindex失敗後のディスク容量は74%しか占めていなかった ○ Lucene Segmentファイルの統合に瞬間的にディスク容量を多めに使ってしまうのが原因実験2) Templateを修正しReplica Shardは持たさずReindexする 04 Reindexの実験 { "error": { "root_cause": [ { "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" } ], "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" }, "status": 403 }

Slide 12

Slide 12 text

©NewsPicks Inc. All Rights Reserved.   ● 実験1)より高速化するためShard数を減らし、正常終了するようReplica Shardを持たせた ○ Primary Shard数：2 ○ Replica Shard数：2 ○ e(replica shard 数 + 1) * primary shard 数 = (2 + 1) * 2 = 6e になり、Shardは6つ ■ Node1台が2つのShardを持つ実験結果 ● 90%進んだ時点で実験2)と同様のエラーで異常終了した ● 保存すべき品詞の種類の数を増やしたことで、実験1)で使用したTemplateよりディスクをより占めるようになったと推測される ● 実験1)と違い、CPU使用率は60%で維持 ● 異常終了まで3時間かかった ● Node1台のディスク容量を40GB→60GBにしたら、3時間で正常終了した実験3) Templateを修正しReplica Shardを持たせReindexする 04 Reindexの実験

Slide 13

Slide 13 text

©NewsPicks Inc. All Rights Reserved.   ● Node1台のShard数が増えるとReindexの速度は低下する ● Reindexする際は最初 CPU 使用率がぐっと上がり、終わるまでその状態がつづく ○ Node1台あたりのShard数が多くない場合は、Reindex中の CPU 使用率が60％程度に留まる ● Reindex中に既存インデックスに対して検索を連続で行っても、レスポンスは問題なくスピーディーに返し、負荷もかからない ● Templateを変更してのReindexは場合によっては、ディスクを多く占めるので、e既存 index サイズ * 3e のディスク容量を用意するのが安全である 05 実験でわかったこと 3つの実験からの気づき

Slide 14

Slide 14 text

©NewsPicks Inc. All Rights Reserved.   ● Reindex中に既存インデックスに追加・更新・削除されるドキュメントの追い更新処理の方法を考える必要がある ○ もしリアルタイムで追加・更新・削除している場合は、それをしばらく止めてReindex後にできるようにする ● 問題が生じ、巻き戻す場合を考える ○ インデックスの更新を止め、スナップショットをとっておく ● ディスク容量的に問題ないか確認し、問題がある場合は解決策を考える ● Template を変える場合の諸事項を考慮する ● 更に高速化できる方法がないか考える ○ Refreshの頻度を下げるなど ○ Shardの構成を再考する 05 実験でわかったこと Reindex時に発生する付随作業・気をつけること