Mengukur domain OpenSearch Layanan Amazon

Tidak ada metode sempurna untuk mengukur domain OpenSearch Layanan Amazon. Namun, dengan memulai dengan pemahaman tentang kebutuhan penyimpanan Anda, layanan, dan OpenSearch dirinya sendiri, Anda dapat membuat perkiraan awal yang terdidik tentang kebutuhan perangkat keras Anda. Perkiraan ini dapat berfungsi sebagai titik awal yang berguna untuk aspek paling penting dari ukuran domain: mengujinya dengan beban kerja yang representatif dan memantau performanya.

Menghitung persyaratan penyimpanan

Sebagian besar OpenSearch beban kerja termasuk dalam salah satu dari dua kategori besar:

• Indeks berumur panjang: Anda menulis kode yang memproses data menjadi satu atau lebih OpenSearch indeks dan kemudian memperbarui indeks tersebut secara berkala saat data sumber berubah. Beberapa contoh umum adalah situs web, dokumen, dan pencarian e-commerce.

• Indeks bergulir: Data terus mengalir ke satu set indeks sementara, dengan periode pengindeksan dan jendela retensi (seperti sekumpulan indeks harian yang dipertahankan selama dua minggu). Beberapa contoh umum adalah analitik log, pemrosesan seri waktu, dan analitik aliran klik.

Untuk beban kerja indeks berumur panjang, Anda dapat memeriksa sumber data pada disk dan dengan mudah menentukan berapa banyak ruang penyimpanan mengonsumsinya. Jika data berasal dari berbagai sumber, cukup tambahkan sumber tersebut bersama-sama.

Untuk indeks bergulir, Anda dapat mengalikan jumlah data yang dihasilkan selama periode waktu yang representatif dengan periode retensi. Misalnya, jika Anda menghasilkan 200 MiB data log per jam, itu adalah 4,7 GiB per hari, yaitu 66 GiB data pada waktu tertentu jika Anda memiliki periode retensi dua minggu.

Namun, ukuran data sumber Anda hanyalah salah satu aspek dari kebutuhan penyimpanan Anda. Anda juga harus mempertimbangkan hal berikut:

• Jumlah replika: Setiap replika adalah salinan lengkap indeks dan kebutuhan jumlah ruang disk yang sama. Secara default, setiap OpenSearch indeks memiliki satu replika. Kami merekomendasikan setidaknya satu replika untuk mencegah kehilangan data. Replika juga meningkatkan performa pencarian, sehingga Anda mungkin ingin replika lebih banyak jika Anda memiliki beban kerja baca-berat. Gunakan PUT /my-index/_settings untuk memperbarui pengaturan number_of_replicas untuk indeks Anda.

• OpenSearch overhead pengindeksan: Ukuran indeks pada disk bervariasi. Ukuran total data sumber ditambah indeks seringkali 110% dari sumber, dengan indeks hingga 10% dari data sumber. Setelah mengindeks data, Anda dapat menggunakan _cat/indices?v API dan pri.store.size nilai untuk menghitung overhead yang tepat. _cat/allocation?vjuga memberikan ringkasan yang berguna.

• Ruang cadangan sistem operasi yang disediakan: Secara default, Linux mencadangkan 5% dari sistem file untuk root pengguna guna proses kritis, pemulihan sistem, dan untuk melindungi terhadap masalah fragmentasi disk.

• OpenSearch Layanan overhead: OpenSearch Layanan mencadangkan 20% dari ruang penyimpanan setiap instans (hingga 20 GiB) untuk penggabungan segmen, log, dan operasi internal lainnya.

  Karena maksimum 20 GiB ini, jumlah total ruang yang dicadangkan dapat bervariasi secara dramatis tergantung pada jumlah instans di domain Anda. Sebagai contoh, sebuah domain mungkin memiliki tiga instans m6g.xlarge.search, masing-masing dengan 500 GIB ruang penyimpanan, dengan total 1,46 TiB. Dalam hal ini, total ruang yang dicadangkan hanya 60 GiB. Domain lainnya mungkin memiliki 10 instans m3.medium.search, masing-masing dengan 100 GIB ruang penyimpanan, dengan total 0,98 TiB. Di sini, total ruang yang dicadangkan adalah 200 GiB, meskipun domain pertama adalah 50% lebih besar.

  Dalam rumus berikut, kami menerapkan perkiraan “kasus terburuk” untuk overhead. Perkiraan ini mencakup ruang kosong tambahan untuk membantu meminimalkan dampak kegagalan node dan pemadaman Availability Zone.

Singkatnya, jika Anda memiliki 66 GiB data pada waktu tertentu dan ingin satu replika, persyaratan penyimpanan minimum lebih dekat dengan 66 * 2 * 1.1 / 0.95 / 0.8 = 191 GiB. Anda dapat menggeneralisasi perhitungan ini sebagai berikut:

Data sumber* (1 + jumlah replika) * (1 + overhead pengindeksan)/(1 - Ruang cadangan Linux)/(1 - Overhead OpenSearch layanan) = persyaratan penyimpanan minimum

Atau Anda dapat menggunakan versi yang disederhanakan ini:

Sumber data* (1 + jumlah replika) * 1,45 = persyaratan penyimpanan minimum

Ruang penyimpanan yang tidak mencukupi adalah salah satu penyebab paling umum dari ketidakstabilan cluster. Jadi, Anda harus memeriksa ulang angka ketika Anda memilih jenis instance, jumlah instance, dan volume penyimpanan.

Pertimbangan penyimpanan lainnya ada:

• Jika persyaratan penyimpanan minimum melebihi 1 PB, lihat Skala petabyte di Layanan Amazon OpenSearch .

• Jika Anda memiliki indeks bergulir dan ingin menggunakan arsitektur panas-hangat, lihat. UltraWarm penyimpanan untuk Amazon OpenSearch Service

Memilih jumlah serpihan

Setelah memahami persyaratan penyimpanan, Anda dapat menyelidiki strategi pengindeksan. Secara default di OpenSearch Layanan, setiap indeks dibagi menjadi lima pecahan utama dan satu replika (total 10 pecahan). Perilaku ini berbeda dari open source OpenSearch, yang default ke satu pecahan primer dan satu replika. Karena Anda tidak dapat dengan mudah mengubah jumlah serpihan primer untuk indeks yang ada, Anda harus memutuskan tentang jumlah serpihan sebelum mengindeks dokumen pertama Anda.

Tujuan keseluruhan memilih sejumlah pecahan adalah untuk mendistribusikan indeks secara merata di semua node data di cluster. Namun, serpihan ini seharusnya tidak terlalu besar atau terlalu banyak. Pedoman umum adalah mencoba menjaga ukuran pecahan antara 10-30 GiB untuk beban kerja di mana latensi pencarian adalah tujuan kinerja utama, dan 30-50 GiB untuk beban kerja berat tulis seperti analitik log.

Pecahan besar dapat menyulitkan OpenSearch untuk pulih dari kegagalan, tetapi karena setiap pecahan menggunakan sejumlah CPU dan memori, memiliki terlalu banyak pecahan kecil dapat menyebabkan masalah kinerja dan kesalahan memori. Dengan kata lain, pecahan harus cukup kecil sehingga instance OpenSearch Service yang mendasarinya dapat menanganinya, tetapi tidak terlalu kecil sehingga mereka menempatkan tekanan yang tidak perlu pada perangkat keras.

Misalnya, anggap Anda memiliki 66 GiB data. Anda tidak mengharapkan angka itu meningkat dari waktu ke waktu, dan Anda ingin menyimpan serpihan Anda sekitar 30 GiB masing-masing. Oleh karena itu, jumlah serpihan Anda harus kira-kira 66 * 1,1/30 = 3. Anda dapat menggeneralisasi perhitungan ini sebagai berikut:

(Data sumber+ruang untuk tumbuh) * (1 + overhead pengindeksan)/ukuran pecahan yang diinginkan = perkiraan jumlah pecahan primer

Persamaan ini membantu mengimbangi pertumbuhan data dari waktu ke waktu. Jika Anda mengharapkan 66 GiB data yang sama menjadi empat kali lipat selama tahun depan, perkiraan jumlah serpihan adalah (66 + 198) * 1,1/30 = 10. Ingat, Anda belum memiliki data ekstra 198 GiB data. Periksa untuk memastikan bahwa persiapan untuk masa depan ini tidak membuat serpihan kecil yang tidak perlu yang menghabiskan banyak CPU dan memori saat ini. Dalam hal ini, 66 * 1,1 / 10 serpihan = 7,26 GiB per serpihan, yang akan mengonsumsi sumber daya tambahan dan berada di bawah kisaran ukuran yang disarankan. Anda dapat mempertimbangkan middle-of-the-road pendekatan lebih dari enam pecahan, yang membuat Anda memiliki pecahan 12-GiB hari ini dan pecahan 48-GiB di masa depan. Kemudian lagi, Anda mungkin lebih memilih untuk memulai dengan tiga serpihan dan mengindeks ulang data Anda ketika serpihan melebihi 50 GiB.

Masalah yang jauh lebih jarang melibatkan pembatasan jumlah serpihan per simpul. Jika Anda ukuran serpihan Anda tepat, Anda biasanya kehabisan ruang disk lama sebelum menghadapi batas ini. Misalnya, instans m6g.large.search memiliki ukuran disk maksimum 512 GiB. Jika Anda tetap di bawah 80% penggunaan disk dan ukuran serpihan Anda pada 20 GiB, maka dapat menampung sekitar 20 serpihan. Elasticsearch 7. x dan yang lebih baru, dan semua versi OpenSearch, memiliki batas 1.000 pecahan per node. Untuk menyesuaikan pecahan maksimum per node, konfigurasikan cluster.max_shards_per_node pengaturan. Sebagai contoh, lihat Pengaturan cluster.

Mengukur serpihan dengan tepat hampir selalu membuat Anda berada di bawah batas ini, tetapi Anda juga dapat mempertimbangkan jumlah serpihan untuk setiap GiB heap Java. Pada node tertentu, memiliki tidak lebih dari 25 pecahan per GiB heap Java. Misalnya, sebuah m5.large.search instance memiliki tumpukan 4-GiB, sehingga setiap node harus memiliki tidak lebih dari 100 pecahan. Pada hitungan serpihan tersebut, setiap serpihan berukuran sekitar 5 GiB, yang jauh di bawah rekomendasi kami.

Memilih tipe instans dan pengujian

Setelah menghitung kebutuhan penyimpanan dan memilih jumlah serpihan yang Anda butuhkan, Anda dapat mulai membuat keputusan perangkat keras. Persyaratan perangkat keras bervariasi secara dramatis oleh beban kerja, tetapi kami masih dapat menawarkan beberapa rekomendasi dasar.

Secara umum, batas penyimpanan untuk setiap tipe instans dipetakan dengan jumlah CPU dan memori yang mungkin Anda butuhkan untuk beban kerja ringan. Misalnya, instans m6g.large.search memiliki ukuran volume EBS maksimum 512 GiB, 2 core vCPU, dan 8 GiB memori. Jika klaster Anda memiliki banyak serpihan, melakukan pajak agregasi, sering memperbarui dokumen, atau memproses sejumlah besar kueri, sumber daya tersebut mungkin tidak cukup untuk kebutuhan Anda. Jika cluster Anda termasuk dalam salah satu kategori ini, coba mulai dengan konfigurasi yang mendekati 2 core vCPU dan 8 GiB memori untuk setiap 100 GiB dari kebutuhan penyimpanan Anda.

Tip

Untuk ringkasan sumber daya perangkat keras yang dialokasikan ke setiap jenis instans, lihat harga OpenSearch Layanan Amazon.

Namun, bahkan sumber daya tersebut mungkin tidak cukup. Beberapa OpenSearch pengguna melaporkan bahwa mereka membutuhkan sumber daya berkali-kali untuk memenuhi persyaratan mereka. Untuk menemukan perangkat keras yang tepat untuk beban kerja Anda, Anda harus membuat perkiraan awal yang terdidik, menguji dengan beban kerja yang representatif, menyesuaikan, dan menguji lagi.

Langkah 1: Buat anggaran awal

Untuk memulai, kami merekomendasikan minimal tiga node untuk menghindari OpenSearch masalah potensial, seperti keadaan otak terbelah (ketika selang komunikasi mengarah ke cluster yang memiliki dua node master). Jika Anda memiliki tiga simpul utama khusus, kami masih merekomendasikan minimal dua data simpul untuk replikasi.

Langkah 2: Hitung persyaratan penyimpanan per simpul

Jika Anda memiliki persyaratan penyimpanan 184-GiB dan jumlah minimum tiga node yang disarankan, gunakan persamaan 184/3 = 61 GiB untuk menemukan jumlah penyimpanan yang dibutuhkan setiap node. Dalam contoh ini, Anda dapat memilih tiga m6g.large.search contoh, di mana masing-masing menggunakan volume penyimpanan EBS 90-GiB, sehingga Anda memiliki jaring pengaman dan beberapa ruang untuk pertumbuhan dari waktu ke waktu. Konfigurasi ini menyediakan 6 core vCPU dan memori 24 GiB, sehingga cocok untuk beban kerja yang lebih ringan.

Untuk contoh yang lebih penting, pertimbangkan persyaratan penyimpanan 14 TiB (14.336 GiB) dan beban kerja yang berat. Dalam hal ini, Anda dapat memilih untuk memulai pengujian dengan 2 * 144 = 288 core vCPU dan 8 * 144 = 1152 GiB memori. Angka-angka ini bekerja untuk sekitar 18 instans i3.4xlarge.search. Jika Anda tidak memerlukan penyimpanan lokal yang cepat, Anda juga dapat menguji 18 r6g.4xlarge.search instans, masing-masing menggunakan volume penyimpanan EBS 1-TiB.

Jika klaster Anda mencakup ratusan terabyte data, lihat Skala petabyte di Layanan Amazon OpenSearch .

Langkah 3: Lakukan pengujian perwakilan

Setelah mengonfigurasi klaster, Anda dapat menambahkan indeks menggunakan jumlah pecahan yang Anda hitung sebelumnya, melakukan beberapa pengujian klien representatif menggunakan kumpulan data realistis, dan memantau CloudWatch metrik untuk melihat bagaimana klaster menangani beban kerja.

Langkah 4: Berhasil atau ulangi

Jika kinerja memenuhi kebutuhan Anda, pengujian berhasil, dan CloudWatch metrik normal, cluster siap digunakan. Ingatlah untuk mengatur CloudWatch alarm untuk mendeteksi penggunaan sumber daya yang tidak sehat.

Jika performa tidak dapat diterima, percobaan gagal, atau CPUUtilization atau JVMMemoryPressure tinggi, Anda mungkin perlu memilih tipe instans yang berbeda (atau menambahkan instans) dan melanjutkan pengujian. Saat Anda menambahkan instance, OpenSearch secara otomatis menyeimbangkan kembali distribusi pecahan di seluruh cluster.

Karena lebih mudah untuk mengukur kelebihan kapasitas dalam cluster yang dikuasai daripada defisit pada cluster yang kurang bertenaga, kami sarankan memulai dengan cluster yang lebih besar dari yang Anda pikir Anda butuhkan. Selanjutnya, uji dan turunkan skala ke klaster efisien yang memiliki sumber daya ekstra untuk memastikan operasi yang stabil selama periode peningkatan aktivitas.

Klaster produksi atau klaster dengan status kompleks mendapat manfaat dari simpul utama khusus, yang meningkatkan performa dan keandalan klaster.