Terjemahan
Harga NickSaat ini saya sedang mengerjakan proyek logging besar yang awalnya dilaksanakan menggunakan AWS Elasticsearch. Setelah bekerja dengan cluster backbone skala besar Elasticsearch selama beberapa tahun, saya benar-benar kagum dengan kualitas implementasi AWS dan tidak dapat memahami mengapa mereka tidak memperbaikinya atau setidaknya memperbaikinya.
Ringkasan
Elasticsearch menyimpan data dalam berbagai indeks yang Anda buat secara eksplisit atau yang dapat dibuat secara otomatis setelah data dikirim. Entri dalam setiap indeks dibagi menjadi sejumlah pecahan tertentu, yang kemudian diseimbangkan antara node dalam cluster Anda (serata mungkin jika jumlah pecahan Anda tidak dibagi secara merata dengan jumlah node). Ada dua jenis pecahan utama di ElasticSearch: pecahan dasar dan pecahan replika. Pecahan replika memberikan toleransi kesalahan jika terjadi kegagalan simpul, dan pengguna dapat mengatur jumlah pecahan replika secara terpisah untuk setiap indeks.
Karya Elasticsearch standar
Elasticsearch - Ini elastis. Kadang-kadang bisa sangat rumit, tetapi, secara umum, Anda dapat menambahkan node ke cluster atau menghapusnya. Dan jika dalam kasus menghapus node ada jumlah replika yang sesuai, Elasticsearch akan mendistribusikan pecahan dan bahkan menyeimbangkan beban pada node dalam cluster. Ini biasanya berhasil.
Pemenuhan permintaan yang mahal kadang-kadang dapat menyebabkan jatuhnya node dan sejenisnya, tetapi sejumlah besar pengaturan membantu untuk mempertahankan pekerjaan. Dengan jumlah pecahan replika yang cukup, jika simpul jatuh, ini tidak mempengaruhi pekerjaan secara keseluruhan.
Standard Elasticsearch juga memiliki sejumlah add-on yang tersedia, termasuk X-Pack, fitur audit, ACL granular, pemantauan, dan peringatan. Sebagian besar X-Pack baru-baru ini menjadi gratis, mungkin sebagai tanggapan terhadap kebijakan lisensi Splunk yang baru.
Pekerjaan Pencarian Elastik Amazon
Seperti biasa, Amazon mengambil kode sumber terbuka untuk bagian dari Elasticsearch, membuat persimpangan yang sulit dan mulai menjualnya sebagai layanannya sendiri, secara bertahap memperkenalkan versi fungsinya sendiri yang selama bertahun-tahun telah tersedia dengan satu atau lain cara dalam versi utama Elasticsearch.
Produk Amazon tidak memiliki banyak hal, seperti: RBAC dan audit, yang sangat bermasalah bagi kami, karena kami menerima log dari tim yang berbeda dan ingin memisahkan mereka satu sama lain. Saat ini, setiap pengguna yang memiliki akses ke Elasticsearch memiliki semua hak akses dan dapat secara tidak sengaja menghapus data orang lain, mengubah cara mereka direplikasi pada node dan sepenuhnya berhenti menerima data dengan menambahkan templat pengindeksan yang salah.
Ini membuat frustrasi, tapi ini bukan masalah terbesar dengan layanan. Pecahan Penyeimbang - konsep sentral dari Elasticsearch - tidak berfungsi dalam implementasi AWS, yang meniadakan hampir semua hal baik di Elasticsearch.
Biasanya, ketika data ditambahkan ke node, satu dapat mengisi lebih dari yang lain. Ini diharapkan karena tidak ada jaminan bahwa catatan yang dimuat akan berukuran sama atau bahwa jumlah pecahan akan selalu didistribusikan secara merata di semua node cluster. Ini tidak kritis, karena Elasticsearch dapat menyeimbangkan kembali pecahan antar node, dan jika satu node benar-benar penuh, maka node lain akan dengan senang hati mulai menerima data alih-alih diisi.
Ini tidak didukung di Amazon. Beberapa node dapat mengisi (jauh) lebih cepat daripada yang lain.
Selain itu,
di Amazon, jika satu simpul di gugus Elasticsearch Anda tidak memiliki cukup ruang kosong, seluruh gugus berhenti menerima data , ia akan berhenti sepenuhnya. Solusi Amazon adalah membiarkan pengguna melewati mimpi buruk dengan mengubah secara berkala jumlah pecahan dalam templat pengindeksan mereka, dan kemudian mengindeks ulang data yang dibuat sebelumnya ke dalam indeks baru, menghapus indeks sebelumnya dan, jika perlu, membalikkan pengindeksan data ke dalam struktur sebelumnya. Ini sepenuhnya berlebihan, dan mensyaratkan, di samping biaya komputasi yang besar, salinan yang belum diproses dari data yang diunduh disimpan dengan catatan yang dianalisis, karena salinan yang tidak diproses akan diperlukan untuk pengindeksan ulang. Dan, tentu saja, ini menggandakan jumlah memori yang dibutuhkan untuk pekerjaan "normal" pada AWS.
"Ups! Saya tidak cukup sering mengindeks ulang seluruh kluster, dan simpulnya penuh! Apa yang harus dilakukan? "
Anda memiliki dua opsi. Pertama, hapus data sebanyak yang diperlukan untuk menghidupkan kembali kluster, dan kemudian mulai mengindeks kembali dengan harapan bahwa tidak ada yang akan berantakan. Apakah Anda memiliki cadangan dari apa yang ingin Anda hapus?
Opsi kedua adalah menambahkan lebih banyak node ke cluster atau mengubah ukuran yang sudah ada ke ukuran instance yang lebih besar.
Tapi tunggu, bagaimana cara menambahkan node atau membuat perubahan jika pecahan tidak dapat diseimbangkan kembali?
Solusi Amazon adalah penyebaran biru-hijau. Mereka memutar seluruh cluster baru, menyalin seluruh konten dari cluster sebelumnya ke yang baru, dan kemudian beralih dan hancurkan cluster lama.
Mengubah ukuran tugas seperti itu bisa memakan waktu berhari-hari, untuk kelompok besar, seperti yang dapat Anda bayangkan, menduplikasi beberapa triliun catatan bisa memakan waktu. Ini juga menciptakan beban gila pada cluster yang ada (mungkin sudah melebihi kapasitas) dan benar-benar dapat menyebabkan cluster gagal. Saya melakukan beberapa operasi serupa di lebih dari 30 cluster di AWS dan hanya sekali saya mengamati penyelesaian yang sukses dalam mode otomatis.
Jadi, Anda mencoba mengubah ukuran cluster Anda, dan tugas tidak selesai. Apa sekarang?
Interaksi Amazon
Tugas Anda mengubah ukuran cluster terganggu (untuk layanan yang Anda pilih untuk tidak berurusan dengan artikel seperti itu), sehingga Anda membuka tiket ke dukungan teknis AWS dengan prioritas tertinggi. Tentu saja, mereka akan mengeluh tentang jumlah atau ukuran beling Anda dan akan menambahkan tautan ke "praktik terbaik" yang telah Anda baca 500 kali. Dan kemudian Anda menunggu untuk diperbaiki. Dan tunggu Dan tunggu Terakhir kali saya mencoba mengubah ukuran cluster, dan itu diblokir, yang menyebabkan kegagalan fungsi yang serius, butuh TUJUH HARI untuk mengembalikan semuanya secara online. Mereka memulihkan cluster itu sendiri dalam beberapa hari, tetapi ketika semuanya berhenti, jelas bahwa node yang menjalankan Kibana telah kehilangan kontak dengan cluster utama. Dukungan AWS menghabiskan empat hari lagi untuk mencoba memperbaiki sesuatu sambil bertanya-tanya apakah Kibana bekerja. Mereka bahkan tidak tahu apakah mereka telah memperbaiki masalah, dan saya harus memeriksa apakah mereka telah memulihkan komunikasi antara sistem mereka sendiri. Sejak itu saya berhenti melakukan apa pun selain menghapus data jika node penuh.
Biaya organisasi kami di AWS sangat besar. Ini memberi kami kesempatan untuk bertemu secara berkala dengan para ahli mereka di berbagai bidang, mendiskusikan strategi implementasi dan menangani berbagai masalah teknis. Kami membuat janji dengan perwakilan Elasticsearch, di mana saya menghabiskan sebagian besar pertemuan menjelaskan dasar-dasar Elasticsearch dan menjelaskan ... keanehan ... dari produk mereka. Pakar sangat terkejut bahwa semuanya runtuh ketika node penuh. Jika pakar yang dikirim tidak mengetahui dasar-dasar produknya, tidak mengherankan bahwa tim pendukung memerlukan tujuh hari untuk melanjutkan kluster produksi.
Pikiran akhirnya
Dalam proyek logging, yang saya masukkan ke dalamnya, ada sebagian kesalahan arsitektur dan keputusan desain yang lemah yang sedang kami kerjakan. Dan tentu saja, saya berharap AWS Elasticsearch berbeda dari produk aslinya. Namun, dalam AWS Elasticsearch, banyak fungsi mendasar dinonaktifkan atau hilang sehingga memperburuk hampir semua masalah yang kita temui.
Untuk cluster yang mudah digunakan dan kecil, AWS Elasticsearch bekerja cukup baik, tetapi untuk cluster berukuran petabyte, itu adalah mimpi buruk yang tak ada habisnya.
Saya sangat ingin tahu mengapa implementasi Elasticsearch Amazon tidak dapat menyeimbangkan pecahan; ini adalah fungsi Elasticsearch yang cukup mendasar. Bahkan dengan keterbatasan dibandingkan dengan Elasticsearch utama, itu pasti akan menjadi produk yang dapat diterima untuk kelompok besar jika hanya berfungsi dengan baik. Saya tidak bisa mengerti mengapa Amazon menawarkan sesuatu yang sangat rusak, dan mengapa mereka belum memperbaiki situasi dalam lebih dari dua tahun.
Seperti yang disarankan orang lain, dan tampaknya masuk akal, perilaku ini adalah tanda implementasi AWS, yang dirancang sebagai cluster multi-tenant raksasa, berusaha memberikan isolasi agar terlihat seperti cluster yang berdiri sendiri untuk pengguna akhir. Bahkan dengan opsi seperti data terenkripsi saja dan transfer data terenkripsi, ini tampaknya masuk akal. Atau mungkin alat dan konfigurasi mereka hanyalah warisan dari arsitektur yang jauh sebelumnya.
Dan, seperti yang dikatakan teman saya, cukup lucu bahwa mereka masih menyebutnya "Fleksibel" ketika Anda tidak dapat menambah atau menghapus node dari cluster Anda tanpa memutar yang baru dan mentransfer semua data Anda.
Catatan kaki: ketika saya menulis teks ini, saya menemukan posting dua tahun lalu dengan banyak klaim serupa:
read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f