Penyesuaian ukuran

Ukuran membantu Anda menentukan jenis instans yang tepat, jumlah node data, dan kebutuhan penyimpanan untuk lingkungan target Anda. Kami menyarankan Anda mengukur terlebih dahulu berdasarkan penyimpanan dan kemudian oleh CPUs. Jika Anda sudah menggunakan Elasticsearch atau OpenSearch, ukurannya umumnya akan tetap sama. Namun, Anda perlu mengidentifikasi jenis instance yang setara dengan lingkungan Anda saat ini. Untuk membantu menentukan ukuran yang tepat, sebaiknya gunakan pedoman berikut.

Penyimpanan

Ukuran cluster Anda dimulai dengan menentukan persyaratan penyimpanan. Identifikasi penyimpanan mentah yang Anda butuhkan untuk cluster Anda. Ini ditentukan dengan menilai data yang dihasilkan oleh sistem sumber Anda (misalnya, server yang menghasilkan log, atau ukuran mentah katalog produk). Setelah Anda mengidentifikasi berapa banyak data mentah yang Anda miliki, gunakan rumus berikut untuk menghitung kebutuhan penyimpanan. Anda kemudian dapat menggunakan hasilnya sebagai titik awal untuk PoC Anda.

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

Rumusnya mempertimbangkan hal-hal berikut:

• Ukuran indeks pada disk bervariasi, tetapi seringkali 10 persen lebih besar dari data sumber.

• Overhead sistem operasi sebesar 5 persen dicadangkan oleh Linux untuk pemulihan sistem dan untuk melindungi terhadap masalah defragmentasi disk.

• OpenSearch cadangan 20 persen dari ruang penyimpanan setiap instans untuk penggabungan segmen, log, dan operasi internal lainnya.

• Sebaiknya simpan 10 persen penyimpanan tambahan untuk membantu meminimalkan dampak kegagalan node dan pemadaman Availability Zone.

Gabungan, biaya overhead dan reservasi ini membutuhkan 45 persen ruang tambahan berdasarkan data mentah aktual di sumbernya. Itu sebabnya Anda mengalikan data sumber dengan 1,45. Selanjutnya, kalikan ini dengan jumlah salinan data (misalnya, satu primer ditambah jumlah replika yang akan Anda gunakan). Jumlah replika tergantung pada ketahanan dan kebutuhan throughput Anda. Untuk kasus penggunaan rata-rata, Anda mulai dengan satu primer dan satu replika. Terakhir, kalikan dengan jumlah hari yang ingin Anda simpan data di tingkat penyimpanan panas.

Amazon OpenSearch Service menawarkan tingkatan penyimpanan panas, hangat, dan dingin. Tingkat penyimpanan hangat menggunakan UltraWarm penyimpanan. UltraWarm menyediakan cara hemat biaya untuk menyimpan data hanya-baca dalam jumlah besar di Layanan Amazon. OpenSearch Node data standar menggunakan penyimpanan panas, yang berbentuk penyimpanan instans atau volume Amazon Elastic Block Store (Amazon EBS) yang dilampirkan ke setiap node. Penyimpanan panas memberikan kinerja tercepat untuk mengindeks dan mencari data baru. UltraWarm node menggunakan Amazon Simple Storage Service (Amazon S3) sebagai penyimpanan dan solusi caching canggih untuk meningkatkan kinerja. Untuk indeks yang tidak Anda tulis secara aktif, atau kueri lebih jarang, dan tidak memiliki persyaratan kinerja yang sama, UltraWarm menawarkan biaya per GiB data yang jauh lebih rendah. Untuk informasi selengkapnya UltraWarm, lihat dokumentasi AWS.

Saat membuat domain OpenSearch Layanan dan menggunakan penyimpanan panas, Anda mungkin perlu menentukan ukuran volume EBS. Itu tergantung pada pilihan tipe instance Anda untuk node data. Anda dapat menggunakan rumus persyaratan penyimpanan yang sama untuk menentukan ukuran volume instans yang didukung Amazon EBS. Kami merekomendasikan penggunaan volume gp3 untuk keluarga instans T3, R5, R6G, M5, m5G, C5, dan C6g generasi terbaru. Menggunakan volume Amazon EBS gp3, Anda dapat menyediakan kinerja independen dari kapasitas penyimpanan. Volume Amazon EBS gp3 juga memberikan kinerja dasar yang lebih baik, dengan biaya 9,6 persen lebih rendah per GB daripada volume gp2 yang ada di Layanan. OpenSearch Dengan gp3, Anda juga mendapatkan penyimpanan yang lebih padat pada keluarga instans R5, R6g, M5, dan M6g, yang dapat membantu Anda mengoptimalkan biaya lebih lanjut. Anda dapat membuat volume EBS hingga kuota yang didukung. Untuk informasi selengkapnya tentang kuota, lihat Kuota OpenSearch Layanan Amazon.

Untuk node data yang memiliki drive NVM Express (NVMe), seperti instance i3 dan r6gd, ukuran volume tetap, sehingga volume EBS bukanlah pilihan.

Jumlah node dan tipe instance

Jumlah node didasarkan pada jumlah yang CPUs diperlukan untuk mengoperasikan beban kerja Anda. Jumlah CPUs didasarkan pada jumlah pecahan. Indeks dalam OpenSearch terdiri dari beberapa pecahan. Saat Anda membuat indeks, Anda menentukan jumlah pecahan untuk indeks. Karena itu, Anda perlu melakukan hal berikut:

1. Hitung jumlah pecahan total yang ingin Anda simpan di domain.

2. Tentukan CPU.

3. Temukan jenis dan hitungan node yang paling hemat biaya yang memberi Anda jumlah CPUs dan penyimpanan yang diperlukan.

Ini biasanya merupakan titik awal. Jalankan pengujian untuk menentukan bahwa ukuran estimasi memenuhi persyaratan fungsional dan nonfungsional Anda.

Menentukan strategi pengindeksan dan jumlah pecahan

Setelah Anda mengetahui persyaratan penyimpanan, Anda dapat memutuskan berapa banyak indeks yang Anda butuhkan dan mengidentifikasi jumlah pecahan untuk masing-masing. Umumnya, kasus penggunaan pencarian memiliki satu atau beberapa indeks, masing-masing mewakili entitas yang dapat dicari atau katalog. Untuk kasus penggunaan analisis log, indeks dapat mewakili file log harian atau mingguan. Setelah Anda memutuskan berapa banyak indeks, mulailah dengan panduan skala berikut, dan tentukan jumlah pecahan yang sesuai:

• Cari kasus penggunaan — 10—30 GB/shard

• Kasus penggunaan analisis log - 50 GB/shard

Anda dapat membagi total volume data dalam satu indeks dengan ukuran pecahan yang Anda tuju dalam kasus penggunaan Anda. Ini akan memberi Anda jumlah pecahan untuk indeks. Mengidentifikasi jumlah total pecahan akan membantu Anda menemukan jenis instance yang tepat yang sesuai dengan beban kerja Anda. Pecahan tidak boleh terlalu besar atau terlalu banyak. 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. out-of-memory Selain itu, ketidakseimbangan dalam alokasi pecahan ke node data dapat menyebabkan kemiringan. Ketika Anda memiliki indeks dengan beberapa pecahan, cobalah untuk membuat pecahan menghitung kelipatan genap dari jumlah node data. Ini membantu memastikan bahwa pecahan didistribusikan secara merata di seluruh node data, dan mencegah node panas. Misalnya, jika Anda memiliki 12 pecahan primer, jumlah node data Anda harus 2, 3, 4, 6, atau 12. Namun, jumlah pecahan adalah sekunder dari ukuran pecahan — jika Anda memiliki 5 GiB data, Anda tetap harus menggunakan pecahan tunggal. Menyeimbangkan jumlah pecahan replika secara merata di seluruh Availability Zone juga membantu meningkatkan ketahanan.

Pemanfaatan CPU

Langkah selanjutnya adalah mengidentifikasi berapa banyak yang CPUs Anda butuhkan untuk beban kerja Anda. Sebaiknya mulai dengan jumlah CPU 1,5 kali lipat dari pecahan aktif Anda. Pecahan aktif adalah pecahan apa pun untuk indeks yang menerima penulisan substansional. Gunakan jumlah pecahan primer untuk menentukan pecahan aktif untuk indeks yang menerima permintaan baca atau tulis substansif. Untuk analisis log, hanya indeks saat ini yang umumnya aktif. Untuk kasus penggunaan pencarian, semua pecahan primer akan dianggap sebagai pecahan aktif. Meskipun kami merekomendasikan 1,5 CPU per pecahan aktif, ini sangat bergantung pada beban kerja. Pastikan untuk menguji dan memantau pemanfaatan CPU dan skala yang sesuai.

Praktik terbaik untuk mempertahankan pemanfaatan CPU Anda adalah memastikan bahwa domain OpenSearch layanan memiliki sumber daya yang cukup untuk melakukan tugasnya. Sebuah cluster yang memiliki pemanfaatan CPU yang tinggi secara konsisten dapat menurunkan stabilitas cluster. Ketika klaster Anda kelebihan beban, OpenSearch Layanan akan memblokir permintaan yang masuk, yang menghasilkan penolakan permintaan. Ini untuk melindungi domain dari kegagalan. Pedoman umum tentang penggunaan CPU akan sekitar 60 persen rata-rata, 80 persen pemanfaatan CPU maks. Lonjakan sesekali 100 persen masih dapat diterima dan mungkin tidak memerlukan penskalaan atau konfigurasi ulang.

Tipe instans

Amazon OpenSearch Service memberi Anda pilihan beberapa jenis instans. Anda dapat memilih jenis instance yang paling sesuai dengan kasus penggunaan Anda. Amazon OpenSearch Service mendukung keluarga instance R, C, M, T, dan I. Anda memilih keluarga instans berdasarkan beban kerja: memori dioptimalkan, komputasi dioptimalkan, atau campuran. Setelah Anda mengidentifikasi keluarga instance, pilih jenis instance generasi terbaru. Umumnya, kami merekomendasikan Graviton dan generasi selanjutnya karena dibuat untuk memberikan peningkatan kinerja dengan biaya lebih rendah dibandingkan dengan instans generasi sebelumnya.

Berdasarkan berbagai pengujian yang dilakukan untuk analisis log dan kasus penggunaan pencarian, kami merekomendasikan hal berikut:

• Untuk kasus penggunaan analisis log, pedoman umum adalah memulai dengan keluarga R instance Graviton untuk node data. Kami menyarankan Anda menjalankan pengujian, menetapkan tolok ukur untuk kebutuhan Anda, dan mengidentifikasi ukuran instans yang sesuai untuk beban kerja Anda.

• Untuk kasus penggunaan penelusuran, sebaiknya gunakan instance Graviton keluarga R dan C untuk node data, karena kasus penggunaan pencarian memerlukan lebih banyak CPU dibandingkan dengan kasus penggunaan analitik log. Untuk beban kerja yang lebih kecil, Anda dapat menggunakan instance Graviton keluarga M untuk pencarian dan log. Instance keluarga I menawarkan NVMe drive dan digunakan oleh pelanggan dengan persyaratan pencarian pengindeksan cepat dan latensi rendah.

Cluster terdiri dari node data dan node pengelola cluster. Meskipun node master khusus tidak memproses permintaan pencarian dan kueri, ukurannya sangat berkorelasi dengan ukuran instans dan jumlah instance, indeks, dan pecahan yang dapat mereka kelola. Dokumentasi AWS menyediakan matriks yang merekomendasikan jenis instans pengelola klaster khusus minimum.

AWS menawarkan tujuan umum (m6g), pengoptimalan komputasi (C6g), dan memori yang dioptimalkan (R6g dan R6gd) untuk Amazon OpenSearch Service versi 7.9 atau yang lebih baru yang didukung oleh prosesor AWS Graviton2. Contoh ini dibuat menggunakan silikon khusus yang dirancang oleh Amazon. Mereka adalah inovasi perangkat keras dan perangkat lunak yang dirancang Amazon yang memungkinkan pengiriman layanan cloud yang efisien, fleksibel, dan aman dengan multi-tenancy terisolasi, jaringan pribadi, dan penyimpanan lokal yang cepat.

Rangkaian instans Graviton2 mengurangi latensi pengindeksan hingga 50 persen dan meningkatkan kinerja kueri hingga 30 persen jika dibandingkan dengan instans berbasis Intel generasi sebelumnya yang tersedia di OpenSearch Layanan (M5, C5, R5).