Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Jungwon Choi

October 26, 2022
Tweet

Other Decks in Technology

Transcript

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

    View Slide

  2. 00 自己紹介
    ©NewsPicks Inc. All Rights Reserved. 

    崔 井源(ちぇ じょんうぉん)
    NewsPicks エンジニア
    Data/Algorithm Unit で主に検索周りを担当中
    ● 検索データの整形・管理
    ● 検索失敗をモニタリング
    ● 検索の精度改善
    ● インフラの開発・メンテ
    @jonlpstudy

    View Slide

  3. 1. やりたかったこと
    2. Elasticsearchの構成
    3. Reindexとは
    4. Reindexの実験
    5. 実験でわかったこと
    目次
    ©NewsPicks Inc. All Rights Reserved. 

    00

    View Slide

  4. やりたかったこと
    ©NewsPicks Inc. All Rights Reserved. 

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

    View Slide

  5. Elasticsearchの構成
    ©NewsPicks Inc. All Rights Reserved. 

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

    View Slide

  6. Reindexとは
    ©NewsPicks Inc. All Rights Reserved. 

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

    View Slide

  7. Reindexの実験
    ©NewsPicks Inc. All Rights Reserved. 

    この実験のゴール
    04
    ● Reindex実行中の負荷がどれくらい高まるかを調べ、ユーザが検索するのに支障がないか
    確認する
    ● 各インデックスをReindexして終わるまでかかる時間を確認する
    ● 実際本番でどのような手順で作業すればいいかを知り、考慮漏れがないようにする

    View Slide

  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の実験
    実験環境づくり

    View Slide

  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%
    ずっとその状態を維持

    View Slide

  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

    View Slide

  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
    }

    View Slide

  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の実験

    View Slide

  13. ©NewsPicks Inc. All Rights Reserved. 

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

    View Slide

  14. ©NewsPicks Inc. All Rights Reserved. 

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

    View Slide

  15. ©NewsPicks Inc. All Rights Reserved. 

    ご視聴ありがとうございました!
    ブログ記事:https://tech.uzabase.com/entry/2022/04/18/193513

    View Slide