Elasticsearch:Beban Tidak Seimbang pada Kluster

Skenario

Sebuah kluster memiliki 3 dedicated master node dan 9 data node. Master node: 16 vCPU, memori 32 GiB. Data node: 32 vCPU, memori 64 GiB. Selama jam sibuk (16.21–18.00), kluster menangani ~2.000 QPS baca dan 1.000 QPS tulis. Utilisasi CPU pada dua node mencapai 100%, sehingga menurunkan performa kueri.

Analisis

1. Periksa Instance Elastic Compute Service (ECS) dan pemantauan jaringan. Selama jam sibuk, QPS kueri melonjak dan utilisasi CPU meningkat tajam pada node yang terdampak. Hal ini mengonfirmasi bahwa node berbeban tinggi memproses sebagian besar traffic kueri.

2. Jalankan `GET _cat/shards?v` untuk memeriksa distribusi shard. Output menunjukkan shard dari indeks test terkonsentrasi pada node berbeban tinggi. Penggunaan disk pada node tersebut juga lebih tinggi. Alokasi shard yang tidak merata menyebabkan penyimpanan tidak merata, dan node dengan lebih banyak data menangani lebih banyak traffic baca dan tulis.

3. Jalankan `GET _cat/indices?v` untuk memeriksa konfigurasi indeks. Indeks test memiliki 5 primary shard dan 1 replica per primary. Shard tidak terdistribusi secara merata, dan beberapa dokumen ditandai .del. Saat Elasticsearch melakukan pencarian, sistem memindai dokumen yang ditandai .del lalu memfilternya — pekerjaan tambahan yang mengurangi efisiensi pencarian. Jalankan force merge selama jam sepi untuk menghapus dokumen-dokumen tersebut.

   pri rep docs.count docs.deleted store.size pri.store.size
   1   1        8640            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1      297847          488    688.7mb        344.8mb
   1   1       93230          364    222.1mb          111mb
   1   1      297803          588    693.5mb        346.1mb
   1   1      297756          540    697.5mb        348.5mb
   1   1      297852          536    687.9mb        343.4mb
   1   1      297750          588    693.1mb        344.2mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1           2            0     19.3kb          8.3kb
   3   1           0            0      1.1kb           576b
   3   1    71888299     15614684      124gb         64.6gb
   3   1           0            0      1.1kb           576b
   1   1        2661            0      2.2mb          1.1mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.6mb          3.3mb
   1   1      297732          540    700.5mb        349.9mb
   1   1      297795          540    691.6mb        344.7mb

4. Tinjau log kluster dan slow log. Semua kueri merupakan term query normal tanpa error pada log kluster. Akar masalahnya adalah distribusi shard, bukan isu pada level kueri.

Akar Masalah

Alokasi shard yang tidak merata memusatkan penyimpanan dan traffic pada sebagian node, menyebabkan ketidakseimbangan CPU.

Setelah dilakukan penyeimbangan ulang shard, utilisasi CPU menjadi merata di seluruh node:

Solusi

Rencanakan jumlah shard sebelum membuat indeks. Lihat Panduan perencanaan shard di bawah.

Skenario

Satu node dalam kluster mengalami lonjakan tiba-tiba pada utilisasi CPU, sehingga memengaruhi performa kueri. Indeks test memiliki 3 primary shard dan 1 replica per primary, terdistribusi merata di seluruh node. Indeks tersebut berisi banyak dokumen yang ditandai delete.doc. Instance ECS telah dikonfirmasi normal.

Analisis

1. Tambahkan `"profile": true` ke body kueri. Output profiling menunjukkan Shard 1 dari indeks test membutuhkan waktu lebih lama untuk dikueri dibandingkan shard lainnya.

2. Jalankan kueri dengan `preference=_primary` dan `preference=_replica`, keduanya dengan "profile": true. Primary shard dari Shard 1 lebih lambat daripada replikanya. Hal ini mengisolasi Shard 1 sebagai penyebabnya.

3. Jalankan perintah berikut untuk memeriksa segmen pada Shard 1:

   Perbedaan jumlah dokumen antara primary shard dan replikanya dapat terjadi karena dua alasan: - Latensi sinkronisasi: Jika dokumen terus ditulis, replika mungkin sementara tertinggal. Setelah penulisan berhenti, jumlahnya akan konvergen. - ID dokumen yang di-generate otomatis dengan penghapusan bersamaan: Jika Anda menulis dokumen menggunakan ID yang di-generate otomatis dan mengirim permintaan Delete by Query untuk dokumen yang baru saja ditulis, penghapusan tersebut dijalankan pada primary shard sebelum penulisan tersebar ke replika. Replika kemudian menerima penulisan tanpa penghapusan, sehingga memiliki lebih banyak dokumen. Selain itu, primary mengumpulkan dokumen yang ditandai doc.delete.

   GET _cat/segments/index?v&h=shard,segment,size,size.memory,ip
   GET _cat/shards?v

   Output menunjukkan Shard 1 memiliki segmen yang lebih besar dan lebih banyak dokumen daripada shard replikanya. Perbedaan ukuran segmen inilah yang menyebabkan ketidakseimbangan beban.

Solusi (pilih salah satu)

• Selama jam sepi, panggil force merge untuk mengompaksi segmen kecil dan menghapus dokumen delete.doc.

• Mulai ulang node yang menghost primary shard. Hal ini akan mempromosikan replika menjadi primary dan menghasilkan replika baru darinya, sehingga kedua shard memiliki struktur segmen yang identik.

Setelah dioptimalkan, beban menjadi merata di seluruh node:

Skenario

Sebuah kluster diterapkan di dua zona: Zona B dan Zona C. Node di Zona C secara konsisten menanggung beban lebih tinggi daripada node di Zona B. Ketidakseimbangan ini bukan disebabkan oleh perbedaan perangkat keras atau distribusi data yang tidak merata.

Analisis

1. Lihat utilisasi CPU selama 4 hari terakhir. Data pemantauan menunjukkan utilisasi CPU berubah signifikan pada titik waktu tertentu.

   

2. Periksa koneksi TCP pada setiap node. Jumlah koneksi TCP sangat berbeda antara Zona B dan Zona C, mengarah pada isu distribusi koneksi jaringan.

   

3. Periksa perilaku koneksi klien. Klien menggunakan koneksi persisten dan membuat sedikit koneksi baru. Pada arsitektur multi-zona, setiap unit penjadwalan secara independen memilih node optimal saat membuat koneksi. Ketika volume koneksi baru rendah, beberapa unit penjadwalan mungkin memilih node yang sama. Selain itu, node klien Elasticsearch cenderung meneruskan permintaan ke node dalam zona yang sama, sehingga memusatkan traffic pada satu zona.

Solusi (pilih salah satu)

• Tetapkan time-to-live koneksi pada klien. Gunakan httpClientBuilder.setConnectionTimeToLive() untuk memaksa pembaruan koneksi secara berkala. Misalnya, untuk menetapkan TTL 5 menit:

  Gunakan setConnectionTimeToLive() untuk tujuan ini. setKeepAliveStrategy() kurang efektif dalam mendistribusikan ulang koneksi.

  httpClientBuilder.setConnectionTimeToLive(5, TimeUnit.MINUTES)

  Untuk detailnya, lihat HttpAsyncClientBuilder.

• Mulai ulang klien secara bersamaan untuk memaksa pembuatan koneksi baru ke semua node secara simultan.

• Gunakan dedicated client node untuk mengarahkan traffic. Node klien meneruskan permintaan ke data node, sehingga memisahkan lapisan routing dari lapisan penyimpanan. Bahkan jika node klien menjadi sangat sibuk, data node tidak terpengaruh.

Setelah dioptimalkan, beban terdistribusi merata di seluruh zona:

Skenario

Shard tampak terdistribusi merata di seluruh node, tetapi indeks tertentu memiliki lebih banyak shard — atau shard yang lebih besar — pada node berbeban tinggi.

Solusi

Tetapkan index.routing.allocation.total_shards_per_node untuk membatasi jumlah shard dari satu indeks yang dapat ditempatkan pada satu node.

Hitung nilainya dengan rumus: (primary shard + replica shard) / jumlah data node. Bulatkan ke atas jika hasilnya bukan bilangan bulat.

PUT index_name/_settings
{
  "index.routing.allocation.total_shards_per_node": "3"
}