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

Transcript

1. ElasticsearchのReindexをするために 試行錯誤して分かったこと 2022.10.26@第50回Elasticsearch勉強会　#elasticsearchjp NewsPicks Engineer / 崔 井源
2. 00 自己紹介 ©NewsPicks Inc. All Rights Reserved. 
 崔 井源（ちぇ じょんうぉん） NewsPicks エンジニア Data/Algorithm Unit で主に検索周りを担当中 • 検索データの整形・管理 • 検索失敗をモニタリング • 検索の精度改善 • インフラの開発・メンテ @jonlpstudy
3. 1. やりたかったこと 2. Elasticsearchの構成 3. Reindexとは 4. Reindexの実験 5. 実験でわかったこと 目次 ©NewsPicks Inc. All Rights Reserved. 
 00
4. やりたかったこと ©NewsPicks Inc. All Rights Reserved. 
 • 精度改善がしたい ◦ クエリを改善する策は全て打ったのでanalyzerを改善したい ◦ 例１）インデックス時に登録した同義語を変えたい・消したい ◦ 例２）analyzerの定義を変えたい • マネージド化がしたい（Amazon OpenSearch Service） ◦ 仕様の問題で今のテンプレートは使えない ◦ 例１）ユーザ辞書のファイル名をパッケージIDに変更する必要がある • Reindexによる副作用はないか確認したい ◦ 負荷はどれくらい高まるのか ◦ Reindexの完了までどれくらいかかるのか ◦ 本番ではどんな手順で行えばいいか 01
5. Elasticsearchの構成 ©NewsPicks Inc. All Rights Reserved. 
 02 • Node：Elasticsearchが動作する各サーバ • Cluster：複数のノードの束 • Shard：Lucene Indexとしてディスクに保存 ◦ Lucene Segmentファイルを定期的にマー ジすることで作成される ◦ ↑のRefresh処理をすることで検索可能な データになる • Primary Shard：格納されたデータ • Replica Shard：データのコピー
6. Reindexとは ©NewsPicks Inc. All Rights Reserved. 
 03 インデックス ドキュメント [ { “token”: “環境”, “partOfSpeech”: “名詞-一般”, }, { “token”: “に”, “partOfSpeech”: “助詞-格助詞-一般”, }, { “token”: “優しい”, “partOfSpeech”: “形容詞-自立”, }, ... ] インデックスを作り直すこと！ • analyzerで形態素解析の方法などを定義 • 定義を変えるなどして再分析してもらうにはインデッ クスを作り直す必要がある { “title”: “環境に優しいオレンジジュース”, “summary”: “近年、オレンジジュース産業が...”, ... }
7. Reindexの実験 ©NewsPicks Inc. All Rights Reserved. 
 この実験のゴール 04 • Reindex実行中の負荷がどれくらい高まるかを調べ、ユーザが検索するのに支障がないか 確認する • 各インデックスをReindexして終わるまでかかる時間を確認する • 実際本番でどのような手順で作業すればいいかを知り、考慮漏れがないようにする
8. ©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の実験 実験環境づくり
9. ©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% ずっとその状態を維持
10. ©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
11. ©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 }
12. ©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の実験
13. ©NewsPicks Inc. All Rights Reserved. 
 • Node1台のShard数が増えるとReindexの速度は低下する • Reindexする際は最初 CPU 使用率がぐっと上がり、終わるまでその状態がつづく ◦ Node1台あたりのShard数が多くない場合は、Reindex中の CPU 使用率が60％程度に留まる • Reindex中に既存インデックスに対して検索を連続で行っても、レスポンスは問題なくスピーディー に返し、負荷もかからない • Templateを変更してのReindexは場合によっては、ディスクを多く占めるので、e既存 index サイズ * 3e のディスク容量を用意するのが安全である 05 実験でわかったこと 3つの実験からの気づき
14. ©NewsPicks Inc. All Rights Reserved. 
 • Reindex中に既存インデックスに追加・更新・削除されるドキュメントの追い更新処理の方法を考え る必要がある ◦ もしリアルタイムで追加・更新・削除している場合は、それをしばらく止めてReindex後にでき るようにする • 問題が生じ、巻き戻す場合を考える ◦ インデックスの更新を止め、スナップショットをとっておく • ディスク容量的に問題ないか確認し、問題がある場合は解決策を考える • Template を変える場合の諸事項を考慮する • 更に高速化できる方法がないか考える ◦ Refreshの頻度を下げるなど ◦ Shardの構成を再考する 05 実験でわかったこと Reindex時に発生する付随作業・気をつけること
15. ©NewsPicks Inc. All Rights Reserved. 
 ご視聴ありがとうございました！ ブログ記事：https://tech.uzabase.com/entry/2022/04/18/193513