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!
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).
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.
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:
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:
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.
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:
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.
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.
Gambar 5: Penskalaan arsitektur presto (Diagram oleh Philip S. Bell)
Beberapa aspek penting yang perlu diingat saat meningkatkan skala Presto adalah:
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.