クラスターを過負荷にせずbulk indexingを高速化するには？

Question

IT Interview Practice · Accepted Answer

Bulkは1つのリクエストで複数のインデックス操作を送ります。送信リクエスト数を最大化するのではなく、クラスターの応答性を保ちながら成功操作の速度を改善します。

## 一度に1つの軸を調整する

代表的なドキュメントの控えめなbatchから始めます。スループット改善が止まるか、メモリーやレイテンシーが悪化するまでbatchのバイト数を増やします。その後、同時送信者数を別に調整します。小さなイベント1,000件と大きなドキュメント1,000件は大きく異なるbatchです。

## HTTP成功レスポンスにも失敗項目があり得る

簡略化した説明用bulkレスポンスを考えます。

```json
{
  "errors": true,
  "items": [
    {"index":{"_id":"a","status":201}},
    {"index":{"_id":"b","status":429}},
    {"index":{"_id":"c","status":400}}
  ]
}
```

- 項目aは成功しています。別項目が失敗したという理由だけで再送しません。
- bのエラー詳細を調べます。一時的な過負荷拒否なら速度を落とし、待ってから回数を制限して再試行します。
- cの詳細も確認します。永続的なmappingエラーにはデータまたはmappingの修正が必要で、無限のretryでは解決しません。

## 再試行が別の過負荷を生まないようにする

retryの待ち時間を段階的に増やし、ランダムなずれを加えてクライアントが一斉再試行しないようにします。キューを制限し、満杯ならproducerを減速させます。これがbackpressureです。

ネットワークの結果が不明な場合、安定したdocument IDは重複回避に役立ちますが、scriptによる加算や古い更新には追加対策が必要です。拒否された書き込み、メモリー、ディスク、検索レイテンシーを監視します。refresh頻度を下げるのは、検索への反映が遅くなっても製品が許容できる場合だけです。

[公式ドキュメント](https://www.elastic.co/docs/deploy-manage/production-guidance/optimize-performance/indexing-speed).

一度に1つの軸を調整する

HTTP成功レスポンスにも失敗項目があり得る

関連する質問

再試行が別の過負荷を生まないようにする