Pelajaran yang Dipetik: Menjalankan Presto pada Skala Meta

Presto adalah mesin kueri SQL sumber terbuka gratis. Kami telah menggunakannya di Meta selama sepuluh tahun terakhir, dan belajar banyak dari situ. Menjalankan apa pun pada skala besar—fitur, proses, layanan—memerlukan pemecahan masalah untuk mengatasi tantangan yang tidak terduga. Berikut adalah empat hal yang kami pelajari saat meningkatkan skala Presto ke skala Meta, dan beberapa saran jika Anda tertarik untuk menjalankan kueri Anda sendiri dalam skala besar!

Meningkatkan skala Presto dengan cepat untuk memenuhi permintaan yang terus meningkat: Tantangan apa yang kami hadapi?

Menerapkan rilis baru Presto

Gambar 1: Alur kerja proses untuk mendorong versi baru Presto (Diagram oleh Philip S. Bell)

Meta menjalankan banyak kluster Presto yang mencakup pusat data di seluruh lokasi di seluruh dunia. Versi baru Presto dibuat dan siap untuk diterapkan kira-kira setidaknya sekali, dan terkadang dua kali, setiap bulan. Salah satu tantangan paling awal yang kami hadapi saat jejak Presto di Meta berkembang pesat adalah menerapkan mesin kueri ke kluster volume tinggi sambil memastikan ketersediaan dan keandalan yang konsisten. Hal ini terus berlaku terutama untuk kasus penggunaan interaktif Presto, yaitu saat pengguna meluncurkan kueri dan secara aktif menunggu hasilnya. Kegagalan kueri kurang menjadi perhatian untuk kasus penggunaan "batch" otomatis dengan percobaan ulang otomatis memastikan bahwa kueri pada akhirnya berhasil.

Solusinya sederhana. Semua kluster Presto berada di belakang penyeimbang muatan yang disebut Gateway yang bertanggung jawab (bersama dengan sistem lain di Meta) untuk merutekan kueri Presto ke kluster yang sesuai. Saat kluster Presto perlu diperbarui, kluster tersebut pertama kali ditandai sebagai terkuras dari Gateway, yaitu: Gateway berhenti merutekan kueri baru apa pun ke kluster tersebut. Otomatisasi kemudian menunggu waktu yang telah ditentukan sampai kueri yang sedang berjalan di kluster selesai. Kluster tersebut kemudian diperbarui, dan setelah online, kluster tersebut dapat dilihat oleh Gateway, yang dapat mulai merutekan kueri baru ke kluster tersebut.

Aspek lain untuk menerapkan rilis baru Presto adalah ketersediaan. Kami perlu memastikan bahwa pengguna masih dapat menggunakan Presto saat kluster diperbarui. Sekali lagi, otomatisasi memastikan bahwa setiap pusat data di setiap wilayah fisik selalu memiliki jumlah kluster Presto yang diperlukan. Tentu saja, harus ada keseimbangan antara menghapus terlalu banyak kluster sekaligus (masalah ketersediaan) dan menghapus terlalu sedikit sekaligus (penerapan memakan waktu terlalu lama).

Mengotomatiskan standup dan penonaktifan kluster Presto

Gambar 2: Alur kerja otomatis untuk menambahkan perangkat keras ke kluster (Diagram oleh Philip S. Bell)

Distribusi gudang data di Meta di berbagai wilayah terus berkembang. Ini berarti kluster Presto baru harus berdiri sementara yang sudah ada dinonaktifkan secara teratur. Sebelumnya, ketika kluster Presto hanya sedikit, ini adalah proses manual. Saat skala Meta mulai meningkat, melacak semua perubahan secara manual menjadi makin menantang. Untuk mengatasi masalah ini, kami menerapkan otomatisasi untuk menangani status dan penonaktifan kluster.

Pertama, kami harus melakukan standardisasi konfigurasi kluster kami, yaitu: kami harus membuat konfigurasi dasar untuk kasus penggunaan Presto yang berbeda di Meta. Setiap kluster kemudian akan memiliki jumlah minimal spesifikasi tambahan atau penggantian atas konfigurasi dasar. Setelah itu selesai, kluster baru apa pun dapat muncul dengan membuat konfigurasi secara otomatis dari template dasar. Turnup kluster juga memerlukan integrasi dengan pengait otomatisasi untuk berintegrasi dengan berbagai layanan infrastruktur di seluruh perusahaan seperti Tupperware dan layanan khusus gudang data. Setelah kluster online, beberapa kueri pengujian dikirim ke kluster dan otomatisasi memverifikasi bahwa kueri berhasil dijalankan oleh kluster. Kluster tersebut kemudian didaftarkan ke Gateway dan mulai melayani kueri.

Penonaktifan kluster mengikuti proses kebalikannya. Kluster dicabut pendaftarannya dari Gateway dan setiap kueri yang berjalan diizinkan untuk diselesaikan. Proses Presto dimatikan dan konfigurasi kluster dihapus.

Otomatisasi ini diintegrasikan ke dalam perangkat keras berdiri dan alur kerja penonaktifan untuk gudang data. Hasil akhirnya adalah seluruh proses, mulai dari perangkat keras baru yang muncul di pusat data, hingga kluster Presto yang online dan melayani kueri, lalu dimatikan saat perangkat keras dinonaktifkan, sepenuhnya otomatis. Penerapan ini telah menghemat jam kerja yang berharga, mengurangi waktu idle perangkat keras, dan meminimalkan kesalahan manusia.

Debugging otomatis dan remediasi

Gambar 3: Deteksi host yang buruk (Diagram oleh Philip S. Bell)

Mengingat penerapan Presto yang luas di Meta, sangat penting bagi kami untuk memiliki fitur dan otomatisasi di tempat yang memudahkan petugas oncall (narakontak untuk Presto).

Selama bertahun-tahun, kami telah membuat beberapa "penganalisis" yang membantu petugas oncall men-debug secara efisien dan menilai akar penyebab masalah yang muncul. Sistem pemantauan mengaktifkan peringatan saat ada pelanggaran SLA yang dihadapi pelanggan. Para penganalisis kemudian dipicu. Penganalisis mendapatkan informasi dari berbagai sistem pemantauan (Penyimpanan Data Operasional atau ODS), peristiwa yang diterbitkan ke Scuba, dan bahkan catatan tingkat host. Logika khusus di penganalisis kemudian mengikat semua informasi ini bersama-sama untuk menyimpulkan kemungkinan penyebab utama. Ini sangat berguna bagi petugas oncall dengan memberikan analisis akar penyebab kepada mereka dan memungkinkan mereka untuk melompat langsung ke opsi mitigasi potensial. Dalam beberapa kasus, kami telah sepenuhnya mengotomatiskan proses debug dan remediasi sehingga petugas oncall bahkan tidak perlu terlibat. Beberapa contoh dijelaskan di bawah ini:

Deteksi host buruk

Saat menjalankan Presto dalam skala besar pada sejumlah besar mesin, kami melihat bahwa host "buruk" tertentu dapat menyebabkan kegagalan kueri yang berlebihan. Setelah penyelidikan kami, kami mengidentifikasi beberapa akar penyebab yang menyebabkan host menjadi "buruk", termasuk:

• Masalah level perangkat keras yang belum ditangkap oleh sistem pemantauan seluruh armada karena kurangnya cakupan
• Bug JVM yang tidak jelas yang terkadang menyebabkan kegagalan kueri yang terus-menerus

Untuk mengatasi masalah ini, kami sekarang memantau kegagalan kueri di kluster Presto. Secara khusus, kami mengatribusikan setiap kegagalan kueri ke host yang menyebabkannya, jika memungkinkan. Kami juga menyiapkan peringatan yang terpicu ketika jumlah kegagalan kueri yang sangat tinggi diatribusikan ke host tertentu. Otomasi kemudian masuk untuk menguras host dari armada Presto dan dengan demikian membendung kegagalan.

Melakukan debug masalah antrean

Setiap kluster Presto mendukung kueri antrean setelah mencapai konkurensi maksimalnya untuk menjalankan kueri berdasarkan kasus penggunaan, konfigurasi perangkat keras, dan ukuran kueri. Di Meta, ada mekanisme perutean yang canggih sehingga kueri Presto dikirim ke kluster "benar" yang dapat mengeksekusi kueri sambil memanfaatkan sumber daya sebaik-baiknya. Beberapa sistem di luar Presto terlibat dalam membuat keputusan perutean dan mempertimbangkan banyak faktor:

• Status antrean saat ini di kluster Presto
• Distribusi perangkat keras di berbagai pusat data
• Lokalitas data tabel yang digunakan kueri

Mengingat kerumitan ini, akan sangat sulit bagi petugas oncall untuk mengetahui akar penyebab masalah antrean yang dihadapi dalam produksi. Ini adalah contoh lain saat penganalisis tampil ke depan dengan menarik informasi dari berbagai sumber dan menyajikan kesimpulan.

Kekokohan penyeimbang muatan

Gambar 4: Kekokohan penyeimbang muatan (Diagram oleh Philip S. Bell)

Seperti disebutkan di atas, kluster Presto kami berada di belakang penyeimbang muatan yang merutekan setiap kueri Presto di Meta. Pada awalnya, ketika Presto belum meningkatkan tingkat penggunaan internal yang dimilikinya saat ini, Gateway masih sangat sederhana. Namun, karena penggunaan Presto meningkat di Meta, kami mengalami masalah skalabilitas pada beberapa kesempatan. Salah satunya adalah Gateway gagal di bawah muatan berat, yang dapat menyebabkan Presto tidak tersedia untuk semua pengguna. Akar penyebab beberapa masalah stabilitas adalah salah satu layanan yang secara tidak sengaja membombardir Gateway dengan jutaan kueri dalam waktu singkat, mengakibatkan proses Gateway crash dan tidak dapat merutekan kueri apa pun.

Untuk mencegah skenario seperti itu, kami mulai membuat Gateway lebih kokoh dan toleran terhadap traffic gaya DDoS yang tidak diinginkan. Kami menerapkan fitur pelambatan, yang menolak kueri saat di bawah muatan berat. Pelambatan dapat diaktifkan berdasarkan jumlah kueri per detik di berbagai dimensi seperti per pengguna, per sumber, per IP, dan juga di level global untuk semua kueri. Penyempurnaan lain yang kami terapkan adalah penskalaan otomatis. Bersandar pada layanan seluruh Meta yang mendukung penskalaan naik dan turunnya pekerjaan, jumlah instance Gateway sekarang dinamis. Ini berarti bahwa di bawah muatan berat, skala Gateway sekarang dapat ditingkatkan untuk menangani traffic tambahan dan tidak dimaksimalkan pada CPU/memori, sehingga mencegah skenario crash yang dijelaskan di atas. Hal ini, bersama dengan fitur pelambatan, memastikan bahwa Gateway kokoh dan dapat menahan pola traffic yang merugikan dan tidak dapat diprediksi.

Saran apa yang akan kami berikan kepada tim yang meningkatkan Data Lakehouse mereka sendiri menggunakan Presto?

Gambar 5: Penskalaan arsitektur presto (Diagram oleh Philip S. Bell)

Beberapa aspek penting yang perlu diingat saat meningkatkan skala Presto adalah:

1. Menetapkan SLA yang mudah dipahami dan terdefinisi dengan baik yang akan dilihat pelanggan. Menentukan SLA di seputar metrik penting seperti waktu antrean dan tingkat kegagalan kueri dengan cara yang melacak titik kesulitan pelanggan menjadi sangat penting saat skala Presto ditingkatkan. Ketika ada sejumlah besar pengguna, kurangnya SLA yang tepat dapat sangat menghambat upaya mitigasi masalah produksi karena kebingungan dalam menentukan dampak suatu insiden.
2. Pemantauan dan debugging otomatis. Saat skala Presto ditingkatkan dan jumlah kluster bertambah, pemantauan dan debugging otomatis menjadi penting.
   • Memiliki pemantauan menyeluruh dapat membantu mengidentifikasi masalah produksi sebelum radius ledakannya menjadi terlalu besar. Mengetahui masalah lebih awal akan memastikan kami meminimalkan dampak pengguna sebisa mungkin.
   • Investigasi manual dalam menghadapi masalah produksi yang berdampak pada pelanggan tidak dapat diskalakan. Sangatlah penting untuk memiliki debugging otomatis sehingga akar penyebabnya dapat ditentukan dengan cepat.
3. Penyeimbangan muatan yang baik. Seiring pertumbuhan armada Presto, penting untuk memiliki solusi penyeimbangan muatan yang baik di depan kluster Presto. Dalam skala besar, inefisiensi kecil dalam penyeimbangan muatan dapat menimbulkan dampak negatif yang sangat besar karena banyaknya volume beban kerja.
4. Pengelolaan konfigurasi. Pengelolaan konfigurasi armada besar kluster Presto dapat menyusahkan jika tidak direncanakan dengan baik. Jika memungkinkan, konfigurasi harus dibuat bisa "hot reload" (memperbarui kode tanpa kehilangan status aplikasi) sehingga instance Presto tidak harus dimulai ulang atau diperbarui dengan cara yang mengganggu yang akan mengakibatkan kegagalan kueri dan ketidakpuasan pelanggan.

Artikel ini ditulis berkat kolaborasi dengan Neerad Somanchi, Production Engineer di Meta, dan Philip Bell, Developer Advocate di Meta.

Untuk mempelajari selengkapnya tentang Presto, kunjungi prestodb.io, tonton penjelasan cepat tentang Presto oleh Philip Bell di YouTube, atau ikuti Presto di Twitter, Facebook, dan LinkedIn.

Untuk mempelajari selengkapnya tentang Meta Open Source, kunjungi situs sumber terbuka kami, silakan berlangganan saluran YouTube kami, atau ikuti kami di Twitter, dan Facebook, dan LinkedIn.