Roblox Kembali Beroperasi

Mulai tanggal 28 Oktober dan sepenuhnya pulih pada tanggal 31 Oktober, Roblox mengalami gangguan selama 73 jam.¹ Lima puluh juta pemain menggunakan Roblox setiap hari dan, untuk menciptakan pengalaman yang diharapkan pemain kami, skala kami melibatkan ratusan layanan online internal. Seperti halnya layanan berskala besar lainnya, kami mengalami gangguan layanan dari waktu ke waktu, tetapi lamanya gangguan ini membuatnya sangat patut diperhatikan. Kami dengan tulus meminta maaf kepada komunitas kami atas gangguan ini.

Kami membagikan detail teknis ini untuk memberikan pemahaman kepada komunitas kami mengenai akar masalah, cara kami mengatasinya, dan langkah-langkah yang kami ambil untuk mencegah masalah serupa terjadi di masa depan. Kami ingin menegaskan kembali bahwa tidak ada kehilangan data pengguna atau akses oleh pihak yang tidak berwenang terhadap informasi apa pun selama insiden ini.

Tim Teknik Roblox dan staf teknis dari HashiCorp bekerja sama untuk mengembalikan layanan Roblox. Kami ingin mengucapkan terima kasih kepada tim HashiCorp, yang telah menyediakan sumber daya luar biasa dan bekerja tanpa lelah bersama kami hingga masalah teratasi.

Ringkasan Gangguan

Gangguan ini unik baik dari segi durasi maupun kompleksitasnya. Tim harus mengatasi sejumlah tantangan secara berurutan untuk memahami akar masalah dan mengaktifkan kembali layanan.

• Gangguan tersebut berlangsung selama 73 jam.
• Penyebab utamanya adalah dua masalah. Mengaktifkan fitur streaming yang relatif baru di Consul di bawah beban baca dan tulis yang sangat tinggi menyebabkan persaingan yang berlebihan dan kinerja yang buruk. Selain itu, kondisi beban khusus kami memicu masalah kinerja patologis di BoltDB. Sistem BoltDB sumber terbuka digunakan di dalam Consul untuk mengelola log penulisan di muka (write-ahead-logs) untuk pemilihan pemimpin dan replikasi data. 
• Satu klaster Consul yang mendukung banyak beban kerja memperparah dampak dari masalah-masalah ini.
• Tantangan dalam mendiagnosis dua masalah yang pada dasarnya tidak terkait ini, yang tersembunyi jauh di dalam implementasi Consul, merupakan penyebab utama dari waktu henti yang berkepanjangan. 
• Sistem pemantauan kritis yang seharusnya memberikan visibilitas lebih baik terhadap penyebab pemadaman bergantung pada sistem yang terpengaruh, seperti Consul. Kombinasi ini sangat menghambat proses triase.
• Kami sangat cermat dan berhati-hati dalam pendekatan kami untuk mengaktifkan kembali Roblox dari kondisi mati total yang berkepanjangan, yang juga memakan waktu yang cukup lama.
• Kami telah mempercepat upaya teknik untuk meningkatkan pemantauan, menghilangkan ketergantungan sirkuler dalam tumpukan observabilitas kami, serta mempercepat proses bootstrapping kami. 
• Kami sedang berupaya untuk pindah ke beberapa zona ketersediaan dan pusat data.
• Kami sedang memperbaiki masalah di Consul yang menjadi akar penyebab kejadian ini.

Pendahuluan: Lingkungan Cluster dan HashiStack

Infrastruktur inti Roblox berjalan di pusat data Roblox. Kami mengimplementasikan dan mengelola perangkat keras kami sendiri, serta sistem komputasi, penyimpanan, dan jaringan di atas perangkat keras tersebut. Skala implementasi kami sangat besar, dengan lebih dari 18.000 server dan 170.000 kontainer.

Untuk menjalankan ribuan server di berbagai lokasi, kami memanfaatkan rangkaian teknologi yang dikenal sebagai “HashiStack.” Nomad, Consul, dan Vault adalah teknologi yang kami gunakan untuk mengelola server dan layanan di seluruh dunia, serta memungkinkan kami mengorkestrasi kontainer yang mendukung layanan Roblox.

Nomad digunakan untuk penjadwalan tugas. Ia menentukan kontainer mana yang akan dijalankan di node mana dan di port mana mereka dapat diakses. Ia juga memvalidasi kesehatan kontainer. Semua data ini diteruskan ke Service Registry, yang merupakan basis data kombinasi IP:Port. Layanan Roblox menggunakan Service Registry untuk menemukan satu sama lain sehingga mereka dapat berkomunikasi. Proses ini disebut “penemuan layanan.” Kami menggunakan Consul untuk penemuan layanan, pemeriksaan kesehatan, penguncian sesi (untuk sistem HA yang dibangun di atasnya), dan sebagai penyimpanan kunci-nilai (KV).

Consul diimplementasikan sebagai kluster mesin dengan dua peran. “Voters” (5 mesin) secara otoritatif menyimpan status kluster; “Non-voters” (5 mesin tambahan) adalah replika read-only yang membantu dalam penskalaan permintaan baca. Pada setiap saat, salah satu dari voters dipilih oleh kluster sebagai pemimpin. Pemimpin bertanggung jawab untuk mereplikasi data ke voters lainnya dan menentukan apakah data yang ditulis telah sepenuhnya dikonfirmasi.  Consul menggunakan algoritma bernama Raft untuk pemilihan pemimpin dan mendistribusikan status di seluruh kluster dengan cara yang memastikan setiap node di kluster menyetujui pembaruan. Tidak jarang pemimpin berganti melalui pemilihan pemimpin beberapa kali sepanjang hari.

Berikut ini adalah tangkapan layar terbaru dari dasbor Consul di Roblox setelah insiden tersebut. Banyak metrik operasional utama yang dirujuk dalam posting blog ini ditampilkan pada tingkat normal. Waktu penerapan KV, misalnya, dianggap normal jika kurang dari 300 ms dan saat ini berada di angka 30,6 ms. Pemimpin Consul telah melakukan kontak dengan server lain dalam kluster dalam 32 ms terakhir, yang merupakan waktu yang sangat baru.

Dalam beberapa bulan menjelang insiden Oktober, Roblox melakukan upgrade dari Consul 1.9 ke Consul 1.10 untuk memanfaatkan fitur streaming baru. Fitur streaming ini dirancang untuk secara signifikan mengurangi penggunaan CPU dan bandwidth jaringan yang diperlukan untuk mendistribusikan pembaruan di seluruh kluster berskala besar seperti yang ada di Roblox.

Deteksi Awal (28/10 13:37)

Pada sore hari tanggal 28 Oktober, kinerja Vault menurun dan satu server Consul mengalami beban CPU yang tinggi. Insinyur Roblox mulai menyelidiki. Pada saat itu, para pemain belum terkena dampaknya.

Triage Awal (28/10 13:37 – 29/10 02:00)

Penyelidikan awal menunjukkan bahwa klaster Consul yang menjadi andalan Vault dan banyak layanan lainnya sedang tidak sehat.  Secara spesifik, metrik kluster Consul menunjukkan latensi penulisan yang meningkat pada penyimpanan KV dasar tempat Consul menyimpan data. Latensi persentil ke-50 pada operasi ini biasanya di bawah 300 ms, tetapi kini mencapai 2 detik. Masalah hardware bukanlah hal yang tidak biasa pada skala Roblox, dan Consul dapat bertahan dari kegagalan hardware. Namun, jika hardware hanya lambat daripada gagal, hal itu dapat memengaruhi kinerja Consul secara keseluruhan. Dalam kasus ini, tim menduga penurunan kinerja perangkat keras sebagai akar masalah dan memulai proses penggantian salah satu node kluster Consul. Ini adalah upaya pertama kami dalam mendiagnosis insiden tersebut. Sekitar waktu itu, staf dari HashiCorp bergabung dengan insinyur Roblox untuk membantu dalam diagnosis dan perbaikan. Semua referensi terhadap “tim” dan “tim teknik” mulai saat ini merujuk pada staf Roblox dan HashiCorp.

Bahkan dengan perangkat keras baru, kinerja klaster Consul tetap terganggu. Pada pukul 16:35, jumlah pemain online turun menjadi 50% dari biasanya.

Penurunan ini bertepatan dengan penurunan signifikan dalam kesehatan sistem, yang pada akhirnya mengakibatkan pemadaman sistem total. Mengapa? Ketika layanan Roblox ingin berkomunikasi dengan layanan lain, layanan tersebut mengandalkan Consul untuk mendapatkan informasi terkini mengenai lokasi layanan yang ingin dihubungi. Namun, jika Consul tidak sehat, server akan kesulitan untuk terhubung. Selain itu, Nomad dan Vault bergantung pada Consul, sehingga ketika Consul tidak sehat, sistem tidak dapat menjadwalkan kontainer baru atau mengambil rahasia produksi yang digunakan untuk otentikasi. Singkatnya, sistem gagal karena Consul merupakan titik kegagalan tunggal, dan Consul tidak sehat.

Pada titik ini, tim mengembangkan teori baru tentang apa yang salah: peningkatan lalu lintas. Mungkin Consul lambat karena sistem kami mencapai titik kritis, dan server tempat Consul berjalan tidak lagi mampu menangani beban? Ini adalah upaya kedua kami dalam mendiagnosis akar penyebab insiden tersebut.

Mengingat tingkat keparahan insiden tersebut, tim memutuskan untuk mengganti semua node di kluster Consul dengan mesin baru yang lebih bertenaga. Mesin-mesin baru ini memiliki 128 inti (peningkatan 2x) dan disk SSD NVMe yang lebih baru dan lebih cepat. Pada pukul 19:00, tim telah memigrasikan sebagian besar kluster ke mesin baru, namun kluster tersebut masih belum sehat. Cluster melaporkan bahwa sebagian besar node tidak mampu mengikuti kecepatan penulisan, dan latensi persentil ke-50 pada penulisan KV masih sekitar 2 detik, bukan 300 ms atau kurang seperti biasanya.

Upaya Kembali ke Layanan #1 (29/10 02:00 – 04:00)

Dua upaya pertama untuk mengembalikan kluster Consul ke kondisi sehat tidak berhasil. Kami masih melihat latensi penulisan KV yang tinggi serta gejala baru yang tidak dapat dijelaskan: pemimpin Consul secara teratur tidak sinkron dengan pemilih lainnya. 

Tim memutuskan untuk mematikan seluruh kluster Consul dan mereset statusnya menggunakan snapshot dari beberapa jam sebelumnya – awal terjadinya gangguan. Kami menyadari bahwa hal ini berpotensi menyebabkan kehilangan data konfigurasi sistem dalam jumlah kecil (bukan kehilangan data pengguna). Mengingat tingkat keparahan gangguan dan keyakinan kami bahwa data konfigurasi sistem ini dapat dipulihkan secara manual jika diperlukan, kami merasa hal ini dapat diterima. 

Kami mengharapkan bahwa memulihkan dari snapshot yang diambil saat sistem dalam keadaan sehat akan membawa kluster ke keadaan sehat, tetapi kami memiliki satu kekhawatiran tambahan. Meskipun Roblox tidak memiliki lalu lintas yang dihasilkan pengguna yang mengalir melalui sistem pada saat itu, layanan internal Roblox masih aktif dan secara rutin menghubungi Consul untuk mengetahui lokasi dependensinya serta memperbarui informasi kesehatannya. Pembacaan dan penulisan ini menghasilkan beban yang signifikan pada kluster. Kami khawatir beban ini mungkin langsung mendorong kluster kembali ke keadaan tidak sehat meskipun reset kluster berhasil. Untuk mengatasi kekhawatiran ini, kami mengonfigurasi iptables di kluster untuk memblokir akses. Hal ini akan memungkinkan kami mengaktifkan kembali kluster secara terkendali dan membantu kami memahami apakah beban yang kami berikan pada Consul secara independen dari lalu lintas pengguna merupakan bagian dari masalah.

Reset berjalan lancar, dan awalnya metrik terlihat baik. Ketika kami menghapus pemblokiran iptables, beban penemuan layanan dan pemeriksaan kesehatan dari layanan internal kembali seperti yang diharapkan. Namun, kinerja Consul mulai menurun lagi, dan akhirnya kami kembali ke titik awal: persentil ke-50 pada operasi penulisan KV kembali menjadi 2 detik. Layanan yang bergantung pada Consul mulai menandai diri mereka sebagai “tidak sehat,” dan akhirnya, sistem kembali ke keadaan bermasalah yang kini sudah familiar. Saat itu pukul 04:00. Jelas ada sesuatu tentang beban pada Consul yang menyebabkan masalah, dan setelah lebih dari 14 jam insiden berlangsung, kami masih belum tahu apa penyebabnya.

Upaya Pemulihan Layanan #2 (29/10 04:00 – 30/10 02:00)

Kami telah mengesampingkan kegagalan perangkat keras. Perangkat keras yang lebih cepat tidak membantu dan, seperti yang kami ketahui kemudian, berpotensi merusak stabilitas. Mereset status internal Consul juga tidak membantu. Tidak ada lalu lintas pengguna yang masuk, namun Consul tetap lambat. Kami telah memanfaatkan iptables untuk membiarkan lalu lintas kembali masuk ke kluster secara bertahap. Apakah kluster hanya didorong kembali ke keadaan tidak sehat oleh volume ribuan kontainer yang mencoba terhubung kembali? Ini adalah upaya ketiga kami dalam mendiagnosis akar penyebab insiden tersebut.

Tim teknik memutuskan untuk mengurangi penggunaan Consul dan kemudian memperkenalkannya kembali secara hati-hati dan sistematis. Untuk memastikan kami memiliki titik awal yang bersih, kami juga memblokir sisa lalu lintas eksternal. Kami menyusun daftar lengkap layanan yang menggunakan Consul dan menerapkan perubahan konfigurasi untuk menonaktifkan semua penggunaan yang tidak esensial. Proses ini memakan waktu berjam-jam karena beragamnya sistem dan jenis perubahan konfigurasi yang ditargetkan. Layanan Roblox yang biasanya memiliki ratusan instance berjalan dikurangi menjadi hanya beberapa instance. Frekuensi pemeriksaan kesehatan dikurangi dari 60 detik menjadi 10 menit untuk memberi ruang bernapas tambahan bagi kluster. Pada pukul 16:00 tanggal 29 Oktober, lebih dari 24 jam setelah dimulainya gangguan, tim memulai upaya kedua untuk mengaktifkan kembali Roblox. Sekali lagi, fase awal upaya restart ini terlihat baik, tetapi pada pukul 02:00 tanggal 30 Oktober, Consul kembali berada dalam keadaan tidak sehat, kali ini dengan beban yang jauh lebih ringan dari layanan Roblox yang bergantung padanya.

Pada titik ini, jelas bahwa penggunaan Consul secara keseluruhan bukanlah satu-satunya faktor yang berkontribusi terhadap penurunan kinerja yang pertama kali kami perhatikan pada tanggal 28. Mengingat hal ini, tim kembali mengubah strategi. Alih-alih melihat Consul dari perspektif layanan Roblox yang bergantung padanya, tim mulai meneliti bagian dalam Consul untuk mencari petunjuk.

Penelitian Terkait Kontensi (30/10 02:00 – 30/10 12:00)

Selama 10 jam berikutnya, tim teknik menyelidiki lebih dalam log debug dan metrik tingkat sistem operasi. Data ini menunjukkan bahwa penulisan KV Consul terblokir dalam waktu yang lama. Dengan kata lain, “kontensi.” Penyebab kontensi tersebut tidak langsung jelas, tetapi salah satu teori adalah bahwa peralihan dari server 64 Core ke 128 Core pada awal gangguan mungkin memperburuk masalah. Setelah menganalisis data htop dan data debugging kinerja yang ditampilkan pada tangkapan layar di bawah ini, tim menyimpulkan bahwa sebaiknya kembali menggunakan server dengan 64 inti CPU, serupa dengan yang digunakan sebelum gangguan. Tim mulai mempersiapkan perangkat keras: Consul diinstal, konfigurasi sistem operasi diperiksa tiga kali, dan mesin-mesin disiapkan untuk layanan dengan detail yang sedetail mungkin. Tim kemudian mengalihkan kluster Consul kembali ke server dengan 64 inti CPU, tetapi perubahan ini tidak membantu. Ini adalah upaya keempat kami dalam mendiagnosis akar penyebab insiden tersebut.

Penyebab Utama Ditemukan (30/10 12:00 – 30/10 20:00)

Beberapa bulan yang lalu, kami mengaktifkan fitur streaming Consul baru pada sebagian layanan kami. Fitur ini, yang dirancang untuk mengurangi penggunaan CPU dan bandwidth jaringan kluster Consul, berfungsi sesuai harapan, sehingga selama beberapa bulan berikutnya kami secara bertahap mengaktifkan fitur ini pada lebih banyak layanan backend kami. Pada tanggal 27 Oktober pukul 14:00, satu hari sebelum gangguan, kami mengaktifkan fitur ini pada layanan backend yang bertanggung jawab atas pengalihan lalu lintas. Sebagai bagian dari implementasi ini, untuk mempersiapkan lonjakan lalu lintas yang biasanya terjadi di akhir tahun, kami juga meningkatkan jumlah node yang mendukung pengalihan lalu lintas sebesar 50%. Sistem telah beroperasi dengan baik menggunakan streaming pada tingkat ini selama sehari sebelum insiden terjadi, sehingga awalnya tidak jelas mengapa kinerjanya berubah. Namun, melalui analisis laporan kinerja dan grafik flame dari server Consul, kami menemukan bukti bahwa jalur kode streaming bertanggung jawab atas persaingan yang menyebabkan penggunaan CPU tinggi. Kami menonaktifkan fitur streaming untuk semua sistem Consul, termasuk node pengalihan lalu lintas. Perubahan konfigurasi selesai diterapkan pada pukul 15:51, saat itu persentil ke-50 untuk penulisan Consul KV turun menjadi 300ms. Kami akhirnya menemukan solusi.

Mengapa streaming menjadi masalah? HashiCorp menjelaskan bahwa, meskipun streaming secara keseluruhan lebih efisien, implementasinya menggunakan lebih sedikit elemen kontrol koncurrency (saluran Go) dibandingkan dengan long polling. Di bawah beban yang sangat tinggi – khususnya, beban baca dan tulis yang sangat tinggi – desain streaming memperparah tingkat persaingan pada satu saluran Go, yang menyebabkan pemblokiran selama penulisan, sehingga menjadi jauh kurang efisien. Perilaku ini juga menjelaskan efek dari server dengan jumlah core yang lebih tinggi: server-server tersebut memiliki arsitektur dual socket dengan model memori NUMA. Konflik tambahan pada sumber daya bersama pun semakin parah di bawah arsitektur ini. Dengan menonaktifkan streaming, kami secara dramatis meningkatkan kesehatan kluster Consul.

Meskipun ada terobosan, kami belum sepenuhnya keluar dari masalah. Kami melihat Consul sesekali memilih pemimpin kluster baru, yang merupakan hal normal, tetapi kami juga melihat beberapa pemimpin menunjukkan masalah latensi yang sama seperti sebelum kami menonaktifkan streaming, yang tidak normal. Tanpa petunjuk jelas mengenai akar penyebab masalah pemimpin yang lambat, dan dengan bukti bahwa kluster tetap sehat selama server tertentu tidak terpilih sebagai pemimpin, tim mengambil keputusan pragmatis untuk mengatasi masalah tersebut dengan mencegah pemimpin bermasalah tetap terpilih. Hal ini memungkinkan tim untuk fokus mengembalikan layanan Roblox yang bergantung pada Consul ke kondisi sehat.

Namun, apa yang sebenarnya terjadi dengan pemimpin yang lambat? Kami tidak menemukan jawabannya selama insiden tersebut, tetapi para insinyur HashiCorp menentukan penyebab utamanya beberapa hari setelah gangguan tersebut. Consul menggunakan perpustakaan persisten open-source populer bernama BoltDB untuk menyimpan log Raft. Perpustakaan ini tidak digunakan untuk menyimpan keadaan saat ini di dalam Consul, melainkan sebagai log berputar dari operasi yang sedang diterapkan. Untuk mencegah BoltDB tumbuh tanpa batas, Consul secara rutin melakukan snapshot. Operasi snapshot ini menulis keadaan saat ini dari Consul ke disk, lalu menghapus entri log tertua dari BoltDB. 

Namun, karena desain BoltDB, meskipun entri log tertua dihapus, ruang yang digunakan BoltDB di disk tidak pernah menyusut. Sebaliknya, semua halaman (segmen 4 KB dalam file) yang digunakan untuk menyimpan data yang dihapus justru ditandai sebagai “kosong” dan digunakan kembali untuk penulisan berikutnya. BoltDB melacak halaman-halaman kosong ini dalam struktur yang disebut “freelist.” Biasanya, latensi penulisan tidak terpengaruh secara signifikan oleh waktu yang dibutuhkan untuk memperbarui freelist, tetapi beban kerja Roblox mengungkap masalah kinerja patologis di BoltDB yang membuat pemeliharaan freelist menjadi sangat mahal. 

Memulihkan Layanan Caching (30/10 20:00 – 31/10 05:00)

Sudah 54 jam sejak dimulainya gangguan. Dengan streaming dinonaktifkan dan proses yang diterapkan untuk mencegah pemimpin yang lambat tetap terpilih, Consul kini stabil secara konsisten. Tim siap untuk fokus pada pemulihan layanan.

Roblox menggunakan pola layanan mikro yang umum untuk backend-nya. Di bagian bawah "tumpukan" mikroservis terdapat database dan cache. Database-database ini tidak terpengaruh oleh gangguan, tetapi sistem caching, yang secara rutin menangani 1 miliar permintaan per detik di seluruh lapisan selama operasi sistem normal, berada dalam kondisi tidak sehat. Karena cache kami menyimpan data sementara yang dapat dengan mudah diisi ulang dari database yang mendasarinya, cara termudah untuk mengembalikan sistem caching ke kondisi sehat adalah dengan melakukan redeploy.

Proses penyebaran ulang cache mengalami serangkaian masalah: 

1. Kemungkinan karena reset snapshot cluster Consul yang telah dilakukan sebelumnya, data penjadwalan internal yang disimpan sistem cache di Consul KV menjadi tidak akurat. 
2. Deploy cache berukuran kecil memakan waktu lebih lama dari yang diharapkan, sedangkan deploy cache berukuran besar tidak selesai. Ternyata ada node yang tidak sehat yang dianggap sepenuhnya aktif oleh penjadwal tugas, bukan sebagai node yang tidak sehat. Hal ini menyebabkan penjadwal tugas mencoba menjadwalkan tugas cache secara agresif pada node tersebut, yang gagal karena node tersebut tidak sehat. 
3. Alat deployment otomatis sistem cache dirancang untuk mendukung penyesuaian bertahap pada deployment skala besar yang sudah menangani lalu lintas dalam skala besar, bukan upaya berulang untuk membangun kluster besar dari awal. 

Tim bekerja sepanjang malam untuk mengidentifikasi dan mengatasi masalah ini, memastikan sistem cache diimplementasikan dengan benar, dan memverifikasi keakuratan. Pada pukul 05:00 tanggal 31 Oktober, 61 jam sejak dimulainya gangguan, kami memiliki kluster Consul yang sehat dan sistem cache yang sehat. Kami siap untuk mengaktifkan sisa layanan Roblox.

Kembalinya Para Pemain (31/10 05:00 – 31/10 16:00)

Fase pemulihan layanan secara resmi dimulai pada pukul 05:00 tanggal 31. Sama seperti sistem cache, sebagian besar layanan yang berjalan telah dimatikan selama gangguan awal atau fase pemecahan masalah. Tim perlu memulai ulang layanan-layanan ini pada tingkat kapasitas yang tepat dan memverifikasi bahwa mereka berfungsi dengan benar. Proses ini berjalan lancar, dan pada pukul 10:00, kami siap membuka layanan untuk para pemain.

Dengan cache yang kosong dan sistem yang masih kami ragukan, kami tidak ingin terjadi lonjakan lalu lintas yang berpotensi membuat sistem kembali ke kondisi tidak stabil. Untuk menghindari lonjakan tersebut, kami menggunakan pengalihan DNS untuk mengelola jumlah pemain yang dapat mengakses Roblox. Hal ini memungkinkan kami untuk membiarkan persentase tertentu pemain yang dipilih secara acak masuk, sementara yang lain terus diarahkan ke halaman pemeliharaan statis kami. Setiap kali kami meningkatkan persentase tersebut, kami memeriksa beban database, kinerja cache, dan stabilitas sistem secara keseluruhan. Pekerjaan berlanjut sepanjang hari, dengan meningkatkan akses secara bertahap sekitar 10% setiap kali. Kami senang melihat beberapa pemain paling setia kami memahami skema pengalihan DNS kami dan mulai berbagi informasi ini di Twitter agar mereka bisa mendapatkan akses “lebih awal” saat kami mengaktifkan kembali layanan. Pada pukul 16:45 hari Minggu, 73 jam setelah dimulainya gangguan, 100% pemain diberi akses dan Roblox beroperasi penuh.

Analisis Lebih Lanjut dan Perubahan Akibat Gangguan

Meskipun pemain diizinkan kembali ke Roblox pada 31 Oktober, Roblox dan HashiCorp terus menyempurnakan pemahaman mereka tentang gangguan tersebut sepanjang minggu berikutnya. Masalah persaingan spesifik dalam protokol streaming baru diidentifikasi dan diisolasi. Meskipun HashiCorp telah melakukan pengujian kinerja streaming pada skala yang serupa dengan penggunaan Roblox, mereka belum pernah mengamati perilaku spesifik ini sebelumnya karena hal tersebut muncul akibat kombinasi antara jumlah aliran yang besar dan tingkat pergantian yang tinggi. Tim teknik HashiCorp sedang membuat tolok ukur laboratorium baru untuk mereproduksi masalah kontensi spesifik tersebut dan melakukan uji skala tambahan. HashiCorp juga berupaya meningkatkan desain sistem streaming untuk menghindari kontensi di bawah beban ekstrem dan memastikan kinerja yang stabil dalam kondisi tersebut. 

Analisis lebih lanjut terhadap masalah slow leader juga mengungkap penyebab utama penulisan data Raft selama dua detik dan masalah konsistensi cluster. Para insinyur mengamati grafik flame seperti yang ada di bawah ini untuk mendapatkan pemahaman yang lebih baik tentang cara kerja BoltDB.

Hasil perintah di atas memberi tahu kita beberapa hal:

• Penyimpanan log sebesar 4,2 GB ini hanya menyimpan 489 MB data aktual (termasuk semua bagian internal indeks). 3,8 GB adalah ruang "kosong".
• Daftar halaman kosong (freelist) berukuran 7,8 MB karena berisi hampir satu juta ID halaman kosong.

Artinya, untuk setiap penambahan log (setiap penulisan Raft setelah beberapa pengelompokan), daftar bebas baru sebesar 7,8 MB juga ditulis ke disk meskipun data mentah aktual yang ditambahkan hanya sebesar 16 kB atau kurang. 

Tekanan balik pada operasi ini juga menyebabkan buffer TCP penuh dan berkontribusi pada waktu penulisan 2-3 detik pada pemimpin yang tidak sehat. Gambar di bawah ini menunjukkan penelitian tentang TCP Zero Windows selama insiden tersebut.

HashiCorp dan Roblox telah mengembangkan dan menerapkan proses menggunakan alat BoltDB yang ada untuk "mengompres" basis data, yang berhasil mengatasi masalah kinerja.

Peningkatan Terkini dan Langkah ke Depan

Sudah 2,5 bulan sejak kejadian gangguan tersebut. Apa yang telah kami lakukan? Kami memanfaatkan waktu ini untuk belajar sebanyak mungkin dari gangguan tersebut, menyesuaikan prioritas teknik berdasarkan apa yang kami pelajari, dan memperkuat sistem kami secara agresif. Salah satu nilai Roblox adalah Menghormati Komunitas, dan meskipun kami bisa saja menerbitkan postingan lebih cepat untuk menjelaskan apa yang terjadi, kami merasa berkewajiban kepada Anda, komunitas kami, untuk membuat kemajuan signifikan dalam meningkatkan keandalan sistem kami sebelum mempublikasikannya. 

Daftar lengkap peningkatan keandalan yang telah diselesaikan dan sedang berlangsung terlalu panjang dan terlalu rinci untuk dituliskan di sini, tetapi berikut adalah poin-poin utamanya:

Peningkatan Telemetri

Terdapat ketergantungan siklik antara sistem telemetri kami dan Consul, yang berarti ketika Consul tidak sehat, kami kekurangan data telemetri yang akan memudahkan kami untuk mengidentifikasi masalah. Kami telah menghilangkan ketergantungan siklik ini. Sistem telemetri kami kini tidak lagi bergantung pada sistem yang seharusnya mereka pantau.

Kami telah memperluas sistem telemetri kami untuk memberikan visibilitas yang lebih baik terhadap kinerja Consul dan BoltDB. Kami kini menerima peringatan yang sangat spesifik jika ada tanda-tanda bahwa sistem mendekati kondisi yang menyebabkan gangguan ini. Kami juga telah memperluas sistem telemetri kami untuk memberikan visibilitas yang lebih baik terhadap pola lalu lintas antara layanan Roblox dan Consul. Visibilitas tambahan ini terhadap perilaku dan kinerja sistem kami di berbagai tingkatan telah membantu kami selama proses pembaruan sistem dan sesi debugging.

Perluasan ke Beberapa Zona Ketersediaan dan Pusat Data

Menjalankan semua layanan backend Roblox pada satu klaster Consul membuat kami rentan terhadap gangguan seperti ini. Kami telah membangun server dan jaringan untuk pusat data tambahan yang secara geografis terpisah, yang akan menampung layanan backend kami. Kami sedang berupaya untuk berpindah ke beberapa zona ketersediaan di dalam pusat data ini; kami telah melakukan modifikasi besar pada peta jalan teknik dan rencana penempatan staf kami guna mempercepat upaya ini.

Peningkatan dan Sharding Consul

Roblox masih tumbuh dengan cepat, jadi meskipun menggunakan beberapa kluster Consul, kami ingin mengurangi beban yang ditempatkan pada Consul. Kami telah meninjau cara layanan kami menggunakan penyimpanan KV dan pemeriksaan kesehatan Consul, serta memisahkan beberapa layanan kritis ke dalam kluster khusus mereka sendiri, sehingga mengurangi beban pada kluster Consul pusat ke tingkat yang lebih aman.

Beberapa layanan inti Roblox menggunakan penyimpanan KV Consul secara langsung sebagai tempat yang nyaman untuk menyimpan data, meskipun kami memiliki sistem penyimpanan lain yang mungkin lebih sesuai. Kami sedang dalam proses memigrasikan data ini ke sistem penyimpanan yang lebih sesuai. Setelah selesai, hal ini juga akan mengurangi beban pada Consul.

Kami menemukan sejumlah besar data KV yang sudah usang. Menghapus data usang ini meningkatkan kinerja Consul.

Kami bekerja sama erat dengan HashiCorp untuk menerapkan versi baru Consul yang menggantikan BoltDB dengan penerusnya yang disebut bbolt, yang tidak memiliki masalah yang sama terkait pertumbuhan daftar bebas yang tak terbatas. Kami sengaja menunda upaya ini hingga tahun baru untuk menghindari proses upgrade yang rumit selama puncak lalu lintas akhir tahun. Upgrade ini sedang diuji saat ini dan akan selesai pada kuartal pertama.

Peningkatan pada Prosedur Bootstrapping dan Manajemen Konfigurasi

Upaya pemulihan layanan terhambat oleh sejumlah faktor, termasuk penyebaran dan pemanasan cache yang dibutuhkan oleh layanan Roblox. Kami sedang mengembangkan alat dan proses baru untuk membuat proses ini lebih otomatis dan kurang rentan terhadap kesalahan. Secara khusus, kami telah merancang ulang mekanisme penyebaran cache kami untuk memastikan kami dapat dengan cepat mengaktifkan sistem cache dari awal. Implementasi ini sedang berlangsung.

Kami bekerja sama dengan HashiCorp untuk mengidentifikasi beberapa peningkatan Nomad yang akan memudahkan kami menjalankan pekerjaan besar setelah periode tidak tersedia yang lama. Peningkatan ini akan diterapkan sebagai bagian dari pembaruan Nomad berikutnya, yang dijadwalkan pada akhir bulan ini.

Kami telah mengembangkan dan menerapkan mekanisme untuk perubahan konfigurasi mesin yang lebih cepat.

Pengenalan Kembali Streaming

Awalnya, kami menerapkan streaming untuk menurunkan penggunaan CPU dan bandwidth jaringan dari klaster Consul. Setelah implementasi baru diuji pada skala kami dengan beban kerja kami, kami berencana untuk memperkenalkannya kembali ke sistem kami secara hati-hati.

Catatan tentang Cloud Publik

Setelah kejadian gangguan seperti ini, wajar jika muncul pertanyaan apakah Roblox akan mempertimbangkan untuk pindah ke cloud publik dan membiarkan pihak ketiga mengelola layanan komputasi, penyimpanan, dan jaringan dasar kami.

Salah satu nilai Roblox adalah "Take The Long View", dan nilai ini sangat memengaruhi pengambilan keputusan kami. Kami membangun dan mengelola infrastruktur dasar kami sendiri di lokasi (on-prem) karena, pada skala saat ini, dan yang lebih penting, skala yang kami ketahui akan kami capai seiring pertumbuhan platform kami, kami percaya ini adalah cara terbaik untuk mendukung bisnis dan komunitas kami. Secara spesifik, dengan membangun dan mengelola pusat data kami sendiri untuk layanan backend dan jaringan tepi, kami berhasil mengendalikan biaya secara signifikan dibandingkan dengan cloud publik. Penghematan ini secara langsung memengaruhi jumlah yang dapat kami bayarkan kepada kreator di platform. Selain itu, memiliki perangkat keras sendiri dan membangun infrastruktur tepi kami sendiri memungkinkan kami meminimalkan variasi kinerja serta mengelola latensi pemain kami di seluruh dunia dengan cermat. Kinerja yang konsisten dan latensi rendah sangat penting bagi pengalaman para pemain kami, yang tidak selalu berlokasi di dekat pusat data penyedia cloud publik.

Perlu dicatat bahwa kami tidak terikat secara ideologis pada pendekatan tertentu: kami menggunakan cloud publik untuk kasus penggunaan di mana hal itu paling masuk akal bagi para pemain dan pengembang kami. Sebagai contoh, kami menggunakan cloud publik untuk kapasitas burst, sebagian besar alur kerja DevOps kami, dan sebagian besar analisis internal kami. Secara umum, kami menemukan bahwa cloud publik merupakan alat yang baik untuk aplikasi yang tidak kritis terhadap kinerja dan latensi, serta yang berjalan pada skala terbatas. Namun, untuk beban kerja yang paling kritis terhadap kinerja dan latensi, kami telah memilih untuk membangun dan mengelola infrastruktur kami sendiri di lokasi (on-prem). Kami membuat pilihan ini dengan menyadari bahwa hal itu membutuhkan waktu, uang, dan talenta, tetapi juga menyadari bahwa hal itu akan memungkinkan kami untuk membangun platform yang lebih baik. Hal ini sejalan dengan nilai "Take The Long View" kami.

Stabilitas Sistem Sejak Gangguan

Roblox biasanya mengalami lonjakan lalu lintas pada akhir Desember. Kami masih memiliki banyak pekerjaan yang harus dilakukan terkait keandalan, tetapi kami dengan senang hati melaporkan bahwa Roblox tidak mengalami satu pun insiden produksi yang signifikan selama lonjakan pada bulan Desember, dan bahwa kinerja serta stabilitas Consul dan Nomad selama lonjakan ini sangat baik. Tampaknya peningkatan keandalan yang kami lakukan secara langsung sudah membuahkan hasil, dan seiring dengan selesainya proyek jangka panjang kami, kami mengharapkan hasil yang lebih baik lagi.

Catatan Penutup

Kami ingin mengucapkan terima kasih kepada komunitas Roblox global atas pengertian dan dukungannya. Salah satu nilai Roblox kami adalah "Take Responsibility", dan kami sepenuhnya bertanggung jawab atas apa yang terjadi di sini. Kami ingin sekali lagi mengucapkan terima kasih yang tulus kepada tim di HashiCorp. Insinyur mereka langsung turun tangan untuk membantu kami sejak awal gangguan yang belum pernah terjadi sebelumnya ini dan tidak pernah meninggalkan kami. Bahkan sekarang, dua bulan setelah gangguan tersebut, insinyur Roblox dan HashiCorp terus berkolaborasi erat untuk memastikan kami melakukan segala upaya bersama agar gangguan serupa tidak pernah terjadi lagi.

Terakhir, kami ingin mengucapkan terima kasih kepada rekan-rekan Roblox kami yang telah membuktikan mengapa tempat ini adalah tempat yang luar biasa untuk bekerja. Di Roblox, kami percaya pada kesopanan dan rasa hormat. Mudah untuk bersikap sopan dan menghormati saat segala sesuatunya berjalan lancar, tetapi ujian sesungguhnya adalah bagaimana kita memperlakukan satu sama lain saat keadaan menjadi sulit. Pada suatu titik selama gangguan selama 73 jam, dengan waktu terus berjalan dan tekanan meningkat, tidak mengherankan jika ada yang kehilangan ketenangan, mengatakan hal yang tidak sopan, atau bertanya-tanya siapa yang harus disalahkan atas semua ini. Namun, itulah yang tidak terjadi. Kami saling mendukung dan bekerja sama sebagai satu tim tanpa henti hingga layanan kembali normal. Tentu saja, kami tidak bangga dengan gangguan ini dan dampaknya terhadap komunitas kami, tetapi kami bangga dengan cara kami bersatu sebagai tim untuk menghidupkan kembali Roblox, serta cara kami memperlakukan satu sama lain dengan kesopanan dan rasa hormat di setiap langkahnya.

Kami telah belajar banyak dari pengalaman ini, dan kami lebih berkomitmen dari sebelumnya untuk menjadikan Roblox platform yang lebih kuat dan andal ke depannya.

Terima kasih sekali lagi.