Bagaimana Kami Membuat Infrastruktur Roblox Lebih Efisien dan Tangguh

Seiring pertumbuhan Roblox selama lebih dari 16 tahun terakhir, skala dan kompleksitas infrastruktur teknis yang mendukung jutaan pengalaman bersama 3D yang imersif juga semakin meningkat. Jumlah mesin yang kami dukung telah meningkat lebih dari tiga kali lipat selama dua tahun terakhir, dari sekitar 36.000 pada 30 Juni 2021 menjadi hampir 145.000 saat ini. Mendukung pengalaman yang selalu aktif ini bagi orang-orang di seluruh dunia membutuhkan lebih dari 1.000 layanan internal. Untuk membantu kami mengendalikan biaya dan latensi jaringan, kami mengimplementasikan dan mengelola mesin-mesin ini sebagai bagian dari infrastruktur cloud pribadi hybrid yang dibangun khusus dan beroperasi terutama di lokasi sendiri.  

Infrastruktur kami saat ini mendukung lebih dari 70 juta pengguna aktif harian di seluruh dunia, termasuk para kreator yang mengandalkan ekonomi Roblox untuk bisnis mereka. Jutaan orang ini mengharapkan tingkat keandalan yang sangat tinggi. Mengingat sifat imersif dari pengalaman kami, toleransi terhadap lag atau latensi sangat rendah, apalagi gangguan layanan. Roblox adalah platform untuk komunikasi dan koneksi, tempat orang-orang berkumpul dalam pengalaman 3D yang imersif. Ketika orang-orang berkomunikasi sebagai avatar mereka di ruang imersif, penundaan atau gangguan sekecil apa pun akan lebih terasa dibandingkan saat berkomunikasi melalui obrolan teks atau panggilan konferensi.

Pada Oktober 2021, kami mengalami gangguan sistem secara luas. Awalnya kecil, dengan masalah pada satu komponen di satu pusat data. Namun, masalah tersebut menyebar dengan cepat saat kami menyelidikinya dan akhirnya mengakibatkan gangguan selama 73 jam. Saat itu, kami membagikan detail tentang apa yang terjadi serta beberapa pelajaran awal dari masalah tersebut. Sejak saat itu, kami telah mempelajari pelajaran tersebut dan bekerja untuk meningkatkan ketahanan infrastruktur kami terhadap jenis kegagalan yang terjadi di semua sistem berskala besar akibat faktor seperti lonjakan lalu lintas ekstrem, cuaca, kegagalan hardware, bug perangkat lunak, atau kesalahan manusia. Ketika kegagalan ini terjadi, bagaimana kami memastikan bahwa masalah pada satu komponen, atau sekelompok komponen, tidak menyebar ke seluruh sistem? Pertanyaan ini telah menjadi fokus kami selama dua tahun terakhir dan meskipun pekerjaan ini masih berlangsung, apa yang telah kami lakukan sejauh ini sudah membuahkan hasil. Misalnya, pada paruh pertama tahun 2023, kami menghemat 125 juta jam interaksi per bulan dibandingkan dengan paruh pertama tahun 2022. Hari ini, kami membagikan pekerjaan yang telah kami lakukan, serta visi jangka panjang kami untuk membangun sistem infrastruktur yang lebih tangguh.

Membangun Sistem Cadangan

Dalam sistem infrastruktur berskala besar, kegagalan skala kecil terjadi berkali-kali dalam sehari. Jika satu mesin mengalami masalah dan harus dihentikan layanannya, hal itu masih dapat ditangani karena sebagian besar perusahaan memiliki beberapa instance layanan back-end. Jadi, ketika satu instance gagal, instance lainnya akan mengambil alih beban kerja. Untuk mengatasi kegagalan yang sering terjadi ini, permintaan umumnya diatur untuk mencoba kembali secara otomatis jika terjadi kesalahan.

Hal ini menjadi tantangan ketika sistem atau pengguna mencoba ulang secara berlebihan, yang dapat menjadi cara bagi kegagalan skala kecil tersebut untuk menyebar ke seluruh infrastruktur ke layanan dan sistem lain. Jika jaringan atau pengguna mencoba ulang secara terus-menerus, hal itu pada akhirnya akan membebani setiap instance layanan tersebut, dan berpotensi sistem lain, secara global. Gangguan pada tahun 2021 yang kami alami merupakan hasil dari sesuatu yang cukup umum terjadi pada sistem berskala besar: Kegagalan dimulai dari skala kecil kemudian menyebar ke seluruh sistem, menjadi besar dengan sangat cepat sehingga sulit untuk diatasi sebelum semuanya mati. 

Pada saat gangguan terjadi, kami memiliki satu pusat data aktif (dengan komponen di dalamnya yang berfungsi sebagai cadangan). Kami membutuhkan kemampuan untuk beralih secara manual ke pusat data baru ketika masalah menyebabkan pusat data yang ada mengalami gangguan. Prioritas utama kami adalah memastikan kami memiliki deployment cadangan Roblox, jadi kami membangun cadangan tersebut di pusat data baru, yang berlokasi di wilayah geografis yang berbeda. Hal ini memberikan perlindungan tambahan untuk skenario terburuk: gangguan yang menyebar ke cukup banyak komponen di dalam pusat data sehingga pusat data tersebut menjadi tidak berfungsi sama sekali. Kini kami memiliki satu pusat data yang menangani beban kerja (aktif) dan satu pusat data cadangan (pasif). Tujuan jangka panjang kami adalah beralih dari konfigurasi aktif-pasif ini ke konfigurasi aktif-aktif, di mana kedua pusat data menangani beban kerja, dengan penyeimbang beban yang mendistribusikan permintaan di antara keduanya berdasarkan latensi, kapasitas, dan kesehatan. Setelah ini diterapkan, kami berharap dapat memiliki keandalan yang lebih tinggi untuk seluruh Roblox dan mampu melakukan failover hampir secara instan, bukan dalam hitungan jam.

Beralih ke Infrastruktur Seluler

Prioritas kami selanjutnya adalah membuat dinding pelindung yang kokoh di dalam setiap pusat data untuk mengurangi kemungkinan kegagalan seluruh pusat data. Sel (beberapa perusahaan menyebutnya klaster) pada dasarnya adalah sekumpulan mesin dan merupakan cara kami membuat dinding pelindung ini. Kami mereplikasi layanan baik di dalam maupun di seluruh sel untuk menambah redundansi. Pada akhirnya, kami ingin semua layanan di Roblox berjalan di dalam sel sehingga dapat memanfaatkan dinding pelindung yang kokoh dan redundansi. Jika sebuah sel tidak lagi berfungsi, sel tersebut dapat dinonaktifkan dengan aman. Replikasi antar sel memungkinkan layanan tetap berjalan sementara sel tersebut diperbaiki. Dalam beberapa kasus, perbaikan sel mungkin berarti melakukan reprovisioning ulang sel secara keseluruhan. Di industri ini, menghapus dan melakukan reprovisioning pada satu mesin atau sekelompok kecil mesin cukup umum, tetapi melakukannya untuk seluruh sel yang berisi ~1.400 mesin tidaklah umum. 

Agar hal ini berfungsi, sel-sel ini harus seragam, sehingga kami dapat memindahkan beban kerja dari satu sel ke sel lain dengan cepat dan efisien. Kami telah menetapkan persyaratan tertentu yang harus dipenuhi layanan sebelum dijalankan di dalam sel. Misalnya, layanan harus dikontainerisasi, yang membuatnya jauh lebih portabel dan mencegah siapa pun melakukan perubahan konfigurasi di tingkat sistem operasi. Kami telah mengadopsi filosofi infrastruktur sebagai kode untuk sel: Di repositori kode sumber kami, kami menyertakan definisi segala sesuatu yang ada di dalam sel sehingga kami dapat membangunnya kembali dengan cepat dari awal menggunakan alat otomatis. 

Tidak semua layanan saat ini memenuhi persyaratan ini, jadi kami telah bekerja untuk membantu pemilik layanan memenuhinya sejauh mungkin, dan kami telah membangun alat baru untuk memudahkan migrasi layanan ke dalam sel saat sudah siap. Misalnya, alat penyebaran baru kami secara otomatis “membagi” penyebaran layanan ke berbagai sel, sehingga pemilik layanan tidak perlu memikirkan strategi replikasi. Tingkat ketelitian ini membuat proses migrasi jauh lebih menantang dan memakan waktu, tetapi hasil jangka panjangnya adalah sistem di mana: 

• Jauh lebih mudah untuk mengendalikan kegagalan dan mencegahnya menyebar ke sel-sel lain; 
• Insinyur infrastruktur kami dapat bekerja lebih efisien dan bergerak lebih cepat; dan 
• Insinyur yang membangun layanan tingkat produk yang pada akhirnya diterapkan di sel-sel tidak perlu tahu atau khawatir tentang sel mana yang menjalankan layanan mereka.

Mengatasi Tantangan yang Lebih Besar

Mirip dengan cara pintu api digunakan untuk menahan api, sel bertindak sebagai dinding pelindung yang kokoh di dalam infrastruktur kami untuk membantu menahan masalah apa pun yang memicu kegagalan di dalam satu sel. Akhirnya, semua layanan yang membentuk Roblox akan diimplementasikan secara berlebihan di dalam dan di antara sel-sel. Setelah pekerjaan ini selesai, masalah masih dapat menyebar cukup luas untuk membuat satu sel tidak berfungsi, tetapi akan sangat sulit bagi masalah tersebut untuk menyebar melampaui sel tersebut. Dan jika kami berhasil membuat sel-sel dapat dipertukarkan, pemulihan akan jauh lebih cepat karena kami dapat beralih ke sel lain dan mencegah masalah tersebut memengaruhi pengguna akhir. 

Yang menjadi rumit di sini adalah memisahkan sel-sel ini cukup jauh untuk mengurangi peluang penyebaran kesalahan, sambil tetap menjaga kinerja dan fungsionalitas sistem. Dalam sistem infrastruktur yang kompleks, layanan perlu berkomunikasi satu sama lain untuk berbagi kueri, informasi, beban kerja, dan sebagainya. Saat kami mereplikasi layanan-layanan ini ke dalam sel-sel, kami perlu mempertimbangkan dengan cermat cara mengelola komunikasi antar-sel. Dalam dunia ideal, kami mengalihkan lalu lintas dari satu sel yang tidak sehat ke sel-sel lain yang sehat. Namun, bagaimana kita mengelola “kueri maut”—yang menyebabkan suatu sel menjadi tidak sehat? Jika kita mengalihkan kueri tersebut ke sel lain, hal itu dapat menyebabkan sel tersebut menjadi tidak sehat, persis seperti yang ingin kita hindari. Kita perlu menemukan mekanisme untuk mengalihkan lalu lintas “baik” dari sel yang tidak sehat sambil mendeteksi dan memblokir lalu lintas yang menyebabkan sel menjadi tidak sehat. 

Dalam jangka pendek, kami telah mendistribusikan salinan layanan komputasi ke setiap sel komputasi sehingga sebagian besar permintaan ke pusat data dapat dilayani oleh satu sel. Kami juga melakukan pembagian beban lalu lintas antar sel. Menuju masa depan, kami telah mulai membangun proses penemuan layanan generasi berikutnya yang akan dimanfaatkan oleh jaringan layanan (service mesh), yang kami harapkan selesai pada 2024. Hal ini akan memungkinkan kami menerapkan kebijakan canggih yang hanya mengizinkan komunikasi antar-sel jika tidak berdampak negatif pada sel cadangan. Pada tahun 2024 juga akan hadir metode untuk mengarahkan permintaan yang bergantung ke versi layanan di sel yang sama, yang akan meminimalkan lalu lintas antar-sel dan dengan demikian mengurangi risiko penyebaran kegagalan antar-sel.

Pada puncaknya, lebih dari 70 persen lalu lintas layanan back-end kami dilayani dari sel-sel, dan kami telah belajar banyak tentang cara membuat sel, tetapi kami mengantisipasi penelitian dan pengujian lebih lanjut seiring kami terus memigrasikan layanan kami hingga tahun 2024 dan seterusnya. Seiring kemajuan kami, dinding penghalang ini akan semakin kuat.

Migrasi infrastruktur yang selalu aktif

Roblox adalah platform global yang mendukung pengguna di seluruh dunia, sehingga kami tidak dapat memindahkan layanan selama jam-jam sepi atau "waktu henti", yang semakin memperumit proses migrasi semua mesin kami ke dalam sel-sel dan layanan kami untuk berjalan di sel-sel tersebut. Kami memiliki jutaan pengalaman yang selalu aktif yang harus terus didukung, bahkan saat kami memindahkan mesin yang menjalankannya dan layanan yang mendukungnya. Saat kami memulai proses ini, kami tidak memiliki puluhan ribu mesin yang menganggur dan tersedia untuk memigrasi beban kerja ini. 

Namun, kami memiliki sejumlah kecil mesin tambahan yang dibeli untuk mengantisipasi pertumbuhan di masa depan. Sebagai langkah awal, kami membangun sel-sel baru menggunakan mesin-mesin tersebut, lalu memigrasikan beban kerja ke sana. Kami mengutamakan efisiensi dan keandalan, jadi daripada membeli lebih banyak mesin saat kehabisan "mesin cadangan", kami membangun sel-sel baru dengan menghapus dan mengonfigurasi ulang mesin-mesin yang telah dipindahkan. Kami kemudian memindahkan beban kerja ke mesin-mesin yang telah dikonfigurasi ulang tersebut, dan memulai proses ini dari awal lagi. Proses ini kompleks—seiring mesin diganti dan tersedia untuk dibangun menjadi sel, mereka tidak tersedia secara ideal dan teratur. Mereka tersebar secara fisik di seluruh ruang data, memaksa kami untuk mengonfigurasinya secara bertahap, yang memerlukan proses defragmentasi tingkat hardware untuk menjaga lokasi hardware selaras dengan domain kegagalan fisik berskala besar. 

Sebagian tim insinyur infrastruktur kami fokus pada migrasi beban kerja yang ada dari lingkungan warisan, atau “pra-sel”, ke dalam sel. Pekerjaan ini akan berlanjut hingga kami memigrasikan ribuan layanan infrastruktur dan ribuan layanan back-end ke dalam sel yang baru dibangun. Kami memperkirakan ini akan memakan waktu sepanjang tahun depan dan mungkin hingga 2025, karena beberapa faktor yang mempersulit. Pertama, pekerjaan ini memerlukan alat yang tangguh untuk dikembangkan. Misalnya, kami membutuhkan alat untuk secara otomatis menyeimbangkan kembali sejumlah besar layanan saat kami mengimplementasikan sel baru—tanpa mengganggu pengguna kami. Kami juga menemukan layanan yang dibangun dengan asumsi tertentu tentang infrastruktur kami. Kami perlu merevisi layanan-layanan ini agar tidak bergantung pada hal-hal yang dapat berubah di masa depan seiring kami beralih ke sel. Kami juga telah menerapkan cara untuk mendeteksi pola desain yang diketahui tidak akan berfungsi dengan baik dalam arsitektur seluler, serta proses pengujian sistematis untuk setiap layanan yang dipindahkan. Proses-proses ini membantu kami mencegah masalah yang berdampak pada pengguna akibat ketidakcocokan layanan dengan sel.

Saat ini, hampir 30.000 mesin dikelola oleh sel. Ini hanya sebagian kecil dari total armada kami, tetapi transisi sejauh ini berjalan sangat lancar tanpa dampak negatif bagi pemain. Tujuan akhir kami adalah agar sistem kami mencapai waktu operasional pengguna sebesar 99,99 persen setiap bulan, yang berarti kami tidak akan mengganggu lebih dari 0,01 persen jam interaksi. Di seluruh industri, waktu henti tidak dapat sepenuhnya dihilangkan, tetapi tujuan kami adalah mengurangi waktu henti Roblox hingga tingkat yang hampir tidak terasa.

Mempersiapkan masa depan seiring pertumbuhan

Meskipun upaya awal kami terbukti berhasil, pekerjaan kami pada sel masih jauh dari selesai. Seiring dengan terus berkembangnya Roblox, kami akan terus berupaya meningkatkan efisiensi dan ketahanan sistem kami melalui teknologi ini dan teknologi lainnya. Seiring berjalannya waktu, platform ini akan menjadi semakin tangguh terhadap masalah, dan masalah apa pun yang terjadi seharusnya menjadi semakin tidak terlihat dan tidak mengganggu pengguna di platform kami.

Singkatnya, hingga saat ini, kami telah: 

• Membangun pusat data kedua dan berhasil mencapai status aktif/pasif. 
• Membuat sel di pusat data aktif dan pasif kami serta berhasil memigrasi lebih dari 70 persen lalu lintas layanan back-end kami ke sel-sel ini.
• Menetapkan persyaratan dan praktik terbaik yang perlu kami ikuti untuk menjaga keseragaman semua sel saat kami terus memigrasi sisa infrastruktur kami. 
• Memulai proses berkelanjutan untuk membangun “dinding pelindung” yang lebih kuat di antara sel-sel. 

Seiring sel-sel ini menjadi lebih dapat dipertukarkan, akan ada lebih sedikit interferensi antar sel. Hal ini membuka peluang yang sangat menarik bagi kami dalam hal meningkatkan otomatisasi seputar pemantauan, pemecahan masalah, dan bahkan pemindahan beban kerja secara otomatis. 

Pada bulan September, kami juga mulai menjalankan eksperimen aktif/aktif di seluruh pusat data kami. Ini adalah mekanisme lain yang kami uji untuk meningkatkan keandalan dan meminimalkan waktu failover. Eksperimen ini membantu mengidentifikasi sejumlah pola desain sistem, terutama seputar akses data, yang perlu kami perbaiki saat kami berupaya menjadi sepenuhnya aktif-aktif. Secara keseluruhan, eksperimen ini cukup berhasil sehingga kami membiarkannya tetap berjalan untuk lalu lintas dari sejumlah pengguna kami yang terbatas.