Konfigurasikan Layanan Amazon OpenSearch untuk ketersediaan tinggi | Layanan Web Amazon

Konfigurasikan Layanan Amazon OpenSearch untuk ketersediaan tinggi | Layanan Web Amazon

Stempel Waktu: 31 Mei 2023 12
Node Sumber: 2691649

Layanan Pencarian Terbuka Amazon adalah mesin pencari dan analitik sumber terbuka sepenuhnya yang secara aman membuka pencarian real-time, pemantauan, dan analisis data bisnis dan operasional untuk kasus penggunaan seperti mesin rekomendasi, situs e-niaga, dan pencarian katalog. Untuk menjadi sukses dalam bisnis Anda, Anda membutuhkan sistem Anda untuk menjadi sangat tersedia dan berkinerja, meminimalkan downtime dan menghindari kegagalan. Saat Anda menggunakan Layanan OpenSearch sebagai alat utama untuk memantau infrastruktur, Anda juga perlu memastikan ketersediaannya. Waktu Henti untuk Layanan OpenSearch dapat berdampak signifikan pada hasil bisnis Anda, seperti hilangnya pendapatan, hilangnya produktivitas, hilangnya nilai merek, dan banyak lagi.

Grafik standar industri untuk mengukur ketersediaan adalah kelas sembilan. Layanan OpenSearch menyediakan 3 9 ketersediaan, saat Anda mengikuti Praktik Terbaik, yang berarti menjamin downtime kurang dari 43.83 menit per bulan. Dalam postingan ini, Anda akan mempelajari cara mengonfigurasi domain Layanan OpenSearch untuk ketersediaan dan performa tinggi dengan mengikuti praktik terbaik dan rekomendasi saat menyiapkan domain Anda.

Ada dua elemen penting yang memengaruhi ketersediaan domain Anda: pemanfaatan sumber daya domain Anda, yang sebagian besar didorong oleh beban kerja Anda, dan peristiwa eksternal seperti kegagalan infrastruktur. Meskipun yang pertama dapat dikontrol melalui pemantauan berkelanjutan terhadap kinerja dan kesehatan domain dan menskalakan domain yang sesuai, yang terakhir tidak bisa. Untuk mengurangi dampak peristiwa eksternal seperti pemadaman Availability Zone, kegagalan instans atau disk, atau masalah jaringan pada domain, Anda harus menyediakan kapasitas tambahan, didistribusikan ke beberapa Availability Zone, dan menyimpan beberapa salinan data. Kegagalan untuk melakukannya dapat mengakibatkan penurunan kinerja, ketidaktersediaan, dan, dalam situasi terburuk, kehilangan data.

Mari lihat opsi yang tersedia bagi Anda untuk memastikan bahwa domain tersedia dan berperforma baik.

Konfigurasi cluster

Di bawah bagian ini kita akan berbicara tentang berbagai opsi konfigurasi yang harus Anda siapkan untuk klaster Anda dengan benar yang mencakup menentukan jumlah AZ untuk penerapan, menyiapkan node master dan data, menyiapkan indeks dan shard.

Penerapan multi-AZ

Node data bertanggung jawab untuk memproses pengindeksan dan permintaan pencarian di domain Anda. Menerapkan node data Anda di beberapa Availability Zone meningkatkan ketersediaan domain Anda dengan menambahkan penyimpanan dan pemrosesan data per zona yang redundan. Dengan penerapan Multi-AZ, domain Anda dapat tetap tersedia meskipun Availability Zone lengkap tidak tersedia. Untuk beban kerja produksi, AWS merekomendasikan penggunaan tiga Availability Zone untuk domain Anda. Gunakan dua Availability Zone untuk Wilayah yang hanya mendukung dua untuk ketersediaan yang lebih baik. Ini memastikan bahwa domain Anda tersedia jika terjadi kegagalan Single-AZ.

Manajer cluster khusus (master node)

AWS merekomendasikan penggunaan tiga node cluster manager (CM) khusus untuk semua beban kerja produksi. Node CM melacak kesehatan klaster, status dan lokasi indeks dan pecahannya, pemetaan untuk semua indeks, dan ketersediaan node datanya, serta mengelola daftar tugas tingkat klaster yang sedang dalam proses. Tanpa node CM khusus, klaster menggunakan node data, yang membuat klaster rentan terhadap tuntutan beban kerja. Anda harus mengukur node CM berdasarkan ukuran tugas—terutama, jumlah node data, jumlah indeks, dan jumlah shard. Layanan OpenSearch selalu menerapkan node CM di tiga Availability Zone, bila didukung oleh Wilayah (dua di satu Availability Zone dan satu di Availability Zone lainnya jika wilayah hanya memiliki dua Availability Zone). Untuk domain yang sedang berjalan, hanya satu dari tiga node CM yang berfungsi sebagai pemimpin terpilih. Dua node CM lainnya berpartisipasi dalam pemilihan jika node CM terpilih gagal.

Tabel berikut menampilkan rekomendasi AWS untuk ukuran CM. Node CM berfungsi berdasarkan jumlah node, indeks, pecahan, dan pemetaan. Semakin banyak pekerjaan, semakin banyak komputasi dan memori yang Anda butuhkan untuk menyimpan dan bekerja dengan status cluster.

Hitungan Instance Ukuran RAM Node Pengelola Cluster Hitungan Shard Maksimum yang Didukung Jenis Instans Manajer Klaster Khusus Minimum yang Direkomendasikan
1-10 8 GiB 10,000 m5.large.search atau m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search atau c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search atau c6g.4xlarge.search
76 - 125 64 GiB 75,000 r5.2xlarge.search atau r6g.2xlarge.search
126 - 200 128 GiB 75,000 r5.4xlarge.search atau r6g.4xlarge.search

Indeks dan pecahan

Indeks adalah konstruksi logis yang menampung kumpulan dokumen. Anda mempartisi indeks untuk pemrosesan paralel dengan menentukan jumlah shard utama, di mana shard mewakili unit fisik untuk menyimpan dan memproses data. Di Layanan OpenSearch, pecahan dapat berupa pecahan utama atau pecahan replika. Anda menggunakan replika untuk ketahanan—jika shard utama hilang, Layanan OpenSearch mempromosikan salah satu replika menjadi yang utama—dan untuk meningkatkan throughput pencarian. Layanan OpenSearch memastikan bahwa shard utama dan replika ditempatkan di node yang berbeda dan di Availability Zone yang berbeda, jika diterapkan di lebih dari satu Availability Zone. Untuk ketersediaan tinggi, AWS merekomendasikan untuk mengonfigurasi setidaknya dua replika untuk setiap indeks dalam pengaturan tiga zona untuk menghindari gangguan pada kinerja dan ketersediaan. Dalam penyiapan Multi-AZ, jika sebuah node gagal atau dalam kasus terburuk yang jarang terjadi, Availability Zone gagal, Anda masih memiliki salinan datanya.

Pemantauan dan pengelolaan klaster

Seperti yang telah dibahas sebelumnya, memilih konfigurasi Anda berdasarkan praktik terbaik hanyalah setengah dari pekerjaan. Kami juga perlu terus memantau pemanfaatan dan kinerja sumber daya untuk menentukan apakah domain perlu diskalakan. Domain yang kurang disediakan atau digunakan secara berlebihan dapat mengakibatkan penurunan kinerja dan akhirnya tidak tersedia.

Utilisasi CPU

Anda menggunakan CPU di domain Anda untuk menjalankan beban kerja Anda. Sebagai aturan umum, Anda harus menargetkan penggunaan CPU rata-rata 60% untuk setiap node data, dengan puncak pada 80%, dan mentolerir lonjakan kecil hingga 100%. Saat Anda mempertimbangkan ketersediaan, dan terutama mengingat tidak tersedianya zona penuh, ada dua skenario. Jika Anda memiliki dua Availability Zone, maka setiap zona menangani 50% lalu lintas. Jika sebuah zona menjadi tidak tersedia, zona lain akan mengambil semua lalu lintas itu, menggandakan penggunaan CPU. Dalam hal ini, Anda harus menggunakan sekitar 30–40% penggunaan CPU rata-rata di setiap zona untuk mempertahankan ketersediaan. Jika Anda menjalankan tiga Availability Zone, setiap zona menggunakan 33% lalu lintas. Jika sebuah zona menjadi tidak tersedia, masing-masing zona akan mendapatkan sekitar 17% lalu lintas. Dalam hal ini, Anda harus menargetkan penggunaan CPU rata-rata 50–60%.

Pemanfaatan memori

Layanan OpenSearch mendukung dua jenis pengumpulan sampah. Yang pertama adalah pengumpulan sampah G1 (G1GC), yang digunakan oleh node Layanan OpenSearch, didukung oleh AWS Graviton 2. Yang kedua adalah Concurrent Mark Sweep (CMS), yang digunakan oleh semua node yang didukung oleh prosesor lain. Dari semua memori yang dialokasikan ke sebuah node, setengah dari memori (hingga 32 GB) ditugaskan ke tumpukan Java, dan sisa memori digunakan oleh tugas sistem operasi lain, cache sistem file, dan sebagainya. Untuk menjaga ketersediaan domain, sebaiknya pertahankan penggunaan maksimal JVM sekitar 80% di CMS dan 95% di G1GC. Apa pun di luar itu akan memengaruhi ketersediaan domain Anda dan membuat klaster Anda tidak sehat. Kami juga merekomendasikan untuk mengaktifkan penyetelan otomatis, yang secara aktif memantau penggunaan memori dan memicu pengumpul sampah.

Pemanfaatan penyimpanan

Layanan OpenSearch menerbitkan beberapa panduan untuk ukuran domain. Kami memberikan rumus empiris sehingga Anda dapat menentukan jumlah penyimpanan yang tepat yang diperlukan untuk kebutuhan Anda. Namun, penting untuk memperhatikan penipisan penyimpanan seiring waktu dan perubahan karakteristik beban kerja. Untuk memastikan domain tidak kehabisan penyimpanan dan dapat terus mengindeks data, Anda harus mengonfigurasi amazoncloudwatch alarm dan pantau ruang penyimpanan gratis Anda.

AWS juga merekomendasikan pemilihan jumlah shard utama sehingga setiap shard berada dalam rentang ukuran yang optimal. Anda dapat menentukan ukuran shard yang optimal melalui pengujian proof-of-concept dengan data dan lalu lintas Anda. Kami menggunakan ukuran shard utama 10–30 GB untuk kasus penggunaan pencarian dan ukuran shard utama 45–50 GB untuk kasus penggunaan analitik log sebagai pedoman. Karena shard adalah pekerja di domain Anda, mereka secara langsung bertanggung jawab atas distribusi beban kerja di seluruh node data. Jika shard Anda terlalu besar, Anda mungkin melihat tekanan di heap Java Anda dari agregasi besar, kinerja kueri yang lebih buruk, dan kinerja yang lebih buruk pada tugas tingkat kluster seperti penyeimbangan ulang shard, snapshot, dan migrasi hot-to-warm. Jika shard Anda terlalu kecil, shard dapat membanjiri ruang heap Java domain, memperburuk kinerja kueri melalui jaringan internal yang berlebihan, dan memperlambat tugas tingkat klaster. Kami juga menyarankan agar jumlah shard per node sebanding dengan heap yang tersedia (setengah dari RAM instans hingga 32 GB)—25 shard per GB heap Java. Ini membuat batas praktis 1,000 pecahan pada node data apa pun di domain Anda.

Kesimpulan

Dalam posting ini, Anda mempelajari berbagai tip dan trik untuk menyiapkan domain dengan ketersediaan tinggi menggunakan Layanan OpenSearch, yang membantu Anda mempertahankan kinerja Layanan OpenSearch dan tersedia dengan menjalankannya di tiga Availability Zone.

Nantikan serangkaian postingan yang berfokus pada berbagai fitur dan fungsi dengan Layanan OpenSearch. Jika Anda memiliki umpan balik tentang posting ini, kirimkan di bagian komentar. Jika Anda memiliki pertanyaan tentang posting ini, mulailah utas baru di Forum Layanan Pencarian Terbuka atau kontak Dukungan AWS.

Tentang penulis

Rohin Bhargava adalah Manajer Produk Senior dengan tim Amazon OpenSearch Service. Semangatnya di AWS adalah membantu pelanggan menemukan perpaduan yang tepat dari layanan AWS untuk mencapai kesuksesan tujuan bisnis mereka.

Prashant Agrawal adalah Sr. Search Specialist Solutions Architect dengan Amazon OpenSearch Service. Dia bekerja sama dengan pelanggan untuk membantu mereka memindahkan beban kerja mereka ke cloud dan membantu pelanggan yang sudah ada menyempurnakan klaster mereka untuk mencapai kinerja yang lebih baik dan menghemat biaya. Sebelum bergabung dengan AWS, dia membantu berbagai pelanggan menggunakan OpenSearch dan Elasticsearch untuk kasus penggunaan analitik pencarian dan log mereka. Saat tidak bekerja, Anda dapat menemukannya bepergian dan menjelajahi tempat-tempat baru. Singkatnya, dia suka melakukan Eat → Travel → Repeat.

Stempel Waktu:

Lebih dari Data Besar AWS