Slack Bermigrasi ke Arsitektur Seluler

• Selama 1,5 tahun terakhir, Slack beralih dari struktur tunggal ke struktur berbasis sel (Cellular Architecture) untuk meningkatkan redundansi dan membatasi dampak kegagalan situs
• Perubahan ini didorong oleh kebutuhan untuk meningkatkan ketahanan layanan Slack setelah insiden gangguan jaringan pada Juni 2021 yang menyebabkan penurunan layanan bagi pelanggan Slack
• Arsitektur seluler membuat setiap layanan beroperasi sebagai satu layanan virtual per Availability Zone (AZ), sehingga kegagalan di satu AZ tidak memengaruhi AZ lainnya
• Struktur ini juga mencakup kemampuan untuk mengalirkan keluar trafik (drain) dari AZ yang bermasalah, sehingga AZ tersebut dapat diisolasi secara efektif dari bagian sistem lainnya
• Mekanisme drain dirancang agar cepat, bebas kesalahan, bertahap, dan independen dari sumber daya AZ yang sedang dikosongkan
• Transisi ke arsitektur seluler mencakup strategi yang disebut siloing, yang membuat layanan hanya menerima dan mengirim trafik di dalam AZ-nya sendiri. Ini membantu membatasi semua kegagalan dalam satu AZ saja
• Implementasi mekanisme pemindahan trafik berfokus pada sistem yang merutekan kueri pengguna ke layanan inti
• Arsitektur baru ini memanfaatkan fitur Envoy berupa weighted clusters dan penetapan bobot dinamis melalui RTDS untuk mendukung pengosongan AZ
• Transisi ini mengubah cara Slack beroperasi dan membangun layanannya, serta menyediakan alat baru yang kuat untuk pengelolaan trafik dan mitigasi kegagalan
• Melalui posting blog berikutnya, mereka akan membahas lebih dalam detail implementasi teknis serta bagaimana struktur baru ini memengaruhi operasi Slack

[GN⁺]

Opini Hacker News

• Migrasi Slack ke arsitektur seluler menarik perhatian karena pendekatan operasi dan pemantauan mereka yang unik.
• Strategi perusahaan adalah menangani permintaan dalam satu Availability Zone (AZ) AWS, menyederhanakan operasi, dan mempermudah pemantauan.
• Pendekatan ini memungkinkan insiden pada satu klaster dideteksi dan dimitigasi dengan mudah dengan membandingkan metrik antar-klaster.
• Namun, strategi ini menyebabkan redundansi pada komputasi, cache, dan lainnya, karena sebagian besar layanan harus berjalan di beberapa klaster.
• Beberapa pengguna mempertanyakan efisiensi sistem permintaan API Slack, yang dapat melakukan fan-out ratusan RPC ke backend layanan.
• Ada perdebatan tentang perbedaan antara menggunakan afinitas Availability Zone AWS dan sekadar menyingkirkan AZ yang down di titik perutean tingkat atas.
• Muncul kekhawatiran tentang redundansi menjalankan semuanya di AWS USE1, karena masalah terkait USE1 dapat memengaruhi banyak layanan.
• Pertanyaan diajukan tentang bagaimana data pengguna ditangani dalam arsitektur ini, terutama saat terjadi kegagalan beberapa AZ.
• Beberapa pengguna mengenang arsitektur serupa yang pernah mereka kerjakan di masa lalu, misalnya sistem operasi terdistribusi bernama Metal Cell.
• Ada diskusi tentang kemungkinan pekerjaan yang memakan banyak sumber daya terus berjalan tanpa batas di AZ yang terisolasi, meskipun tidak ada permintaan pengguna baru yang datang.
• Para pengguna penasaran bahasa pemrograman apa yang saat ini digunakan Slack, dan bertanya apakah masih Hack/PHP.
• Beberapa pengguna mengungkapkan kekecewaan terhadap performa Slack, dan membandingkannya secara tidak menguntungkan dengan aplikasi chat lain seperti Discord.