Cara Kami Membuat Infrastruktur Roblox Lebih Efisien dan Tangguh

Seiring dengan berkembangnya Roblox selama lebih dari 16 tahun terakhir, skala dan kompleksitas infrastruktur teknis yang mendukung jutaan pengalaman virtual bersama 3D imersif juga meningkat. Jumlah mesin yang kami dukung meningkat lebih dari tiga kali lipat dalam dua tahun terakhir, dari sekamir 36.000 pada 30 Juni 2021 menjadi hampir 145.000 saat ini. Mendukung pengalaman virtual yang selalu aktif bagi pengguna di seluruh dunia memerlukan lebih dari 1.000 layanan internal. Untuk membantu kami mengendalikan biaya dan latensi jaringan, kami menerapkan dan mengelola mesin ini sebagai bagian dari infrastruktur cloud pribadi hybrid yang dibuat secara dan berjalan di lokasi.

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

Pada bulan Oktober 2021, kami mengalami gangguan layanan di seluruh sistem. Ini dimulai dari hal kecil, dengan masalah pada satu komponen di satu pusat data. Tetapi, masalah ini menyebar dengan cepat saat kami menyelidikinya dan akhirnya mengakibatkan gangguan layanan selama 73 jam. Pada saat itu, kami menginformasikan apa yang terjadi dan pembelajaran awal kami dari masalah tersebut. Sejak itu, kami terus mempelajari masalah tersebut dan berupaya meningkatkan ketahanan infrastruktur kami terhadap tipe kegagalan yang terjadi di semua sistem berskala besar karena berbagai faktor seperti lonjakan lalu lintas yang ekstrem, cuaca, kegagalan hardware, bug software, atau sekadar kesalahan manusia. Ketika kegagalan ini terjadi, bagaimana kami memastikan bahwa masalah pada satu komponen atau sekelompok komponen, tidak akan menyebar ke seluruh sistem? Pertanyaan ini telah menjadi fokus kami selama dua tahun terakhir dan meskipun upaya ini terus dilakukan, apa yang telah kami lakukan sejauh ini telah 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 berbagi pekerjaan yang telah kami lakukan, serta visi jangka panjang kami untuk membangun sistem infrastruktur yang lebih tangguh.

Membangun Penghalang

Dalam sistem infrastruktur skala besar, kegagalan skala kecil terjadi berkali-kali dalam sehari. Jika satu mesin mengalami masalah dan harus dihentikan layanannya, hal ini dapat diatasi karena sebagian besar perusahaan mengelola beberapa layanan back-end mereka. Oleh karena itu, saat satu instance gagal, instance lain akan mengambil alih beban kerjanya. Untuk mengatasi kegagalan yang sering terjadi ini, permintaan biasanya diatur untuk mencoba ulang secara otomatis jika terjadi kesalahan.

Hal ini menjadi tantangan saat suatu sistem atau seseorang melakukan percobaan ulang secara terlalu agresif, yang dapat menjadi jalan 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 ini pada akhirnya akan membebani setiap layanan tersebut dan kemungkinan sistem lainnya, secara global. Gangguan yang kami alami pada tahun 2021 adalah hasil dari sesuatu yang cukup umum terjadi pada sistem skala besar: Kegagalan dimulai dari hal kecil kemudian menyebar ke seluruh sistem, menjadi besar dengan sangat cepat sehingga sulit untuk diselesaikan sebelum semuanya terganggu.

Pada saat gangguan terjadi, kami memiliki satu pusat data yang aktif (dengan komponen di dalamnya bertindak sebagai cadangan). Kami memerlukan kemampuan untuk melakukan failover secara manual ke pusat data baru ketika ada masalah yang menyebabkan pusat data yang ada tidak berfungsi. Prioritas pertama kami adalah memastikan kami memiliki penyebaran cadangan Roblox, jadi kami membuat cadangan tersebut di pusat data baru, yang terletak di wilayah geografis berbeda. Hal ini memberikan perlindungan tambahan untuk skenario terburuk: gangguan yang menyebar ke cukup banyak komponen dalam pusat data sehingga tidak dapat dioperasikan sepenuhnya. Saat ini kami memiliki satu pusat data yang menangani beban kerja (aktif) dan satu lagi siaga, berfungsi sebagai cadangan (pasif). Tujuan jangka panjang kami adalah beralih dari konfigurasi aktif-pasif ke konfigurasi aktif-aktif. Dengan konfigurasi ini, kedua pusat data menangani beban kerja, dengan penyeimbang beban yang mendistribusikan permintaan di antara keduanya berdasarkan latensi, kapasitas, dan kesehatan. Setelah hal ini dilakukan, kami berharap dapat memiliki keandalan yang lebih tinggi untuk seluruh Roblox dan dapat melakukan failover hampir secara instan dibandingkan dalam beberapa jam.

Berpindah ke Infrastruktur Seluler

Prioritas kami berikutnya adalah menciptakan dinding ledakan yang kuat di dalam setiap pusat data untuk mengurangi kemungkinan kegagalan di seluruh pusat data. Sel (beberapa perusahaan menyebutnya cluster) pada dasarnya adalah sekumpulan mesin dan merupakan cara kami membuat dinding ini. Kami mereplikasi layanan baik di dalam maupun di seluruh sel untuk menambah redundansi. Pada akhirnya, kami ingin semua layanan di Roblox berjalan dalam sel sehingga dapat memperoleh manfaat dari dinding ledakan yang kuat dan redundansi. Jika suatu sel tidak lagi berfungsi, sel tersebut dapat dinonaktifkan dengan aman. Replikasi antar sel memungkinkan layanan tetap berjalan saat sel diperbaiki. Dalam beberapa kasus, perbaikan sel mungkin berarti penyediaan ulang sel secara menyeluruh. Di seluruh industri, menghapus dan menyediakan ulang satu mesin atau sekelompok kecil mesin, merupakan hal yang cukup umum, namun melakukan hal ini untuk seluruh sel, yang memiliki rata-rata 1.400 mesin, bukanlah hal yang umum.

Agar hal ini dapat berfungsi, sebagian besar sel ini harus seragam, agar kami dapat dengan cepat dan efisien memindahkan beban kerja dari satu sel ke sel lainnya. Kami telah menetapkan persyaratan tertentu yang harus dipenuhi oleh layanan sebelum dijalankan di sel. Misalnya, layanan harus dimasukkan ke dalam container agar lebih portabel dan mencegah siapa pun membuat perubahan konfigurasi di tingkat OS. Kami telah mengadopsi filosofi infrastruktur sebagai kode untuk sel: Dalam repositori kode sumber, 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 berupaya membantu pemilik layanan memenuhi persyaratan tersebut jika memungkinkan, dan kami telah membuat alat baru untuk memudahkan migrasi layanan ke dalam sel jika sudah siap. Misalnya, alat penyebaran baru kami secara otomatis “stripes” penyebaran layanan di seluruh sel, sehingga pemilik layanan tidak perlu memikirkan strategi replikasi. Tingkat ketepatan ini membuat proses migrasi jauh lebih menantang dan memakan waktu, tetapi manfaat jangka panjangnya adalah sistem yang:

• Jauh lebih mudah untuk membendung kegagalan dan mencegah kegagalan tersebut dari menyebar ke sel lain;
• Engineer infrastruktur kami dapat bekerja dengan lebih efisien dan bergerak lebih cepat; dan
• Engineer yang membangun layanan tingkat produk yang pada akhirnya diterapkan dalam sel tidak perlu mengetahui atau khawatir tentang sel mana yang menjalankan layanan mereka.

Memecahkan Tantangan yang Lebih Besar

Serupa dengan cara pintu kebakaran digunakan untuk menampung api, sel bertindak sebagai dinding ledakan yang kuat dalam infrastruktur kami untuk membantu mengatasi masalah apa pun yang memicu kegagalan dalam satu sel. Pada akhirnya, semua layanan yang membentuk Roblox akan diterapkan secara berlebihan di dalam dan di seluruh sel. Setelah pekerjaan ini selesai, masalah masih dapat menyebar cukup luas sehingga seluruh sel tidak dapat dioperasikan, namun akan sangat sulit bagi suatu masalah untuk menyebar ke luar sel tersebut. Dan jika kami berhasil membuat sel dapat dipertukarkan, pemulihan akan jauh lebih cepat arena kami dapat melakukan failover ke sel lain dan mencegah masalah tersebut berdampak pada pengguna akhir.

Hal yang menjadi rumit adalah memisahkan sel ini untuk mengurangi peluang menyebarkan kesalahan, sekaligus menjaga kinerja dan fungsionalitas. Dalam sistem infrastruktur yang kompleks, layanan perlu berkomunikasi satu sama lain untuk berbagi pertanyaan, informasi, beban kerja, dll. Saat kami mereplikasi layanan ini ke dalam sel, kami perlu memikirkan cara mengelola komunikasi silang. Idealnya, kami mengalihkan lalu lintas dari satu sel tidak sehat ke sel sehat lainnya. Tetapi, bagaimana kami mengelola “kueri kematian”—yang menyebabkan sel menjadi tidak sehat? Jika kami mengalihkan kueri tersebut ke sel lain, hal ini dapat menyebabkan sel tersebut menjadi tidak sehat seperti yang ingin kami hindari. Kami perlu menemukan mekanisme untuk mengalihkan lalu lintas “baik” dari sel yang tidak sehat sambil mendeteksi dan menghentikan lalu lintas yang menyebabkan sel menjadi tidak sehat.

Dalam jangka pendek, kami telah menyebarkan salinan layanan komputasi ke setiap sel komputasi sehingga sebagian besar permintaan ke pusat data dapat dilayani oleh satu sel. Kami juga melakukan penyeimbangan beban lalu lintas di seluruh sel. Melihat lebih jauh, kami telah mulai membangun proses penemuan layanan generasi berikutnya yang akan dimanfaatkan oleh mesh layanan, yang kami harap akan selesai pada tahun 2024. Hal ini akan memungkinkan kami menerapkan kebijakan canggih yang hanya memungkinkan komunikasi lintas sel ketika itu tidak akan berdampak negatif pada sel failover. Pada tahun 2024 juga akan ada metode untuk mengarahkan permintaan dependen ke versi layanan di sel yang sama, yang akan meminimalkan lalu lintas lintas sel dan dengan demikian mengurangi risiko kegagalan propagasi lintas sel.

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

Memigrasikan Infrastruktur yang Selalu Aktif

Roblox adalah platform global yang mendukung pengguna di seluruh dunia, jadi kami tidak dapat memindahkan layanan di luar jam sibuk atau “waktu henti”, yang semakin mempersulit proses migrasi semua mesin kami ke dalam sel dan layanan kami untuk berjalan di sel tersebut. Kami memiliki jutaan pengalaman virtual selalu aktif yang perlu 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 tidak digunakan dan tersedia untuk memigrasikan beban kerja ini.

Namun, kami memiliki sejumlah kecil mesin tambahan yang dibeli untuk mengantisipasi pertumbuhan di masa depan. Untuk memulai, kami membuat sel baru menggunakan mesin tersebut, lalu memigrasikan beban kerja ke mesin tersebut. Kami menghargai efisiensi dan keandalan. Oleh karena itu, daripada membeli lebih banyak mesin setelah kehabisan mesin “cadangan”, kami membangun lebih banyak sel dengan menghapus dan menyediakan ulang mesin yang telah kami migrasikan. Kemudian, kami memigrasikan beban kerja ke mesin yang telah disediakan ulang tersebut, dan memulai prosesnya dari awal lagi. Proses ini rumit—saat mesin diganti dan dilepaskan untuk dimasukkan ke dalam sel, mesin tidak dilepaskan dengan cara yang ideal dan teratur. Secara fisik mereka terfragmentasi di seluruh ruang data, sehingga kami harus menyediakannya sedikit demi sedikit, yang memerlukan proses defragmentasi tingkat perangkat keras untuk menjaga lokasi perangkat keras tetap selaras dengan domain kegagalan fisik berskala besar.

Sebagian dari tim teknik infrastruktur kami berfokus pada migrasi beban kerja yang ada dari lingkungan lama, atau lingkungan “pra-sel”, ke dalam sel. Pekerjaan ini akan terus berlanjut hingga kami berhasil memigrasikan ribuan layanan infrastruktur berbeda dan ribuan layanan back-end ke dalam sel yang baru dibangun. Kami memperkirakan proses ini akan berlangsung hingga tahun depan dan mungkin hingga tahun 2025, karena beberapa faktor yang rumit. Pertama, kami perlu membangun alat yang kuat. Misalnya, kami memerlukan alat untuk secara otomatis menyeimbangkan kembali sejumlah besar layanan ketika kami menerapkan sel baru—tanpa berdampak pada pengguna kami. Kami juga melihat layanan yang dibangun dengan asumsi tentang infrastruktur kami. Kami perlu merevisi layanan ini sehingga tidak bergantung pada hal yang dapat berubah di masa depan seiring dengan perpindahan kami ke dalam sel. Kami juga telah mengimplementasi cara untuk mencari pola desain yang diketahui yang tidak akan berfungsi dengan baik dengan arsitektur seluler, serta proses pengujian metodis untuk setiap layanan yang dimigrasi. Proses ini membantu kami mencegah masalah apa pun yang dihadapi pengguna yang disebabkan oleh ketidakcocokan layanan dengan sel.

Saat ini, hampir 30.000 mesin dikelola oleh sel. Ini hanya sebagian kecil dari total armada kami, tetapi sejauh ini transisinya sangat mulus tanpa dampak negatif terhadap pemain. Tujuan utama kami adalah agar sistem kami mencapai 99,99 persen waktu aktif pengguna setiap bulannya, yang berarti kami tidak akan mengganggu lebih dari 0,01 persen jam interaksi. Di seluruh industri, waktu henti tidak dapat sepenuhnya dihilangkan, namun tujuan kami adalah mengurangi waktu henti Roblox hingga tingkat yang hampir tidak terasa.

Mempersiapkan Masa Depan Seiring dengan Peningkatan Skala Kami

Meskipun upaya awal kami terbukti berhasil, upaya kami dalam bidang 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. eiring berjalannya waktu, platform ini akan semakin tangguh terhadap permasalahan, dan permasalahan apa pun yang terjadi akan semakin tidak terasa dan mengganggu pengguna 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 dan berhasil memigrasikan lebih dari 70 persen lalu lintas layanan back-end kami ke sel ini.
• Tetapkan persyaratan dan praktik terbaik yang harus kami ikuti untuk menjaga keseragaman semua sel saat kami terus memigrasikan seluruh infrastruktur kami.
• Memulai proses berkelanjutan untuk membangun “dinding ledakan” yang lebih kuat antar sel.

Ketika sel ini menjadi lebih dapat dipertukarkan, komunikasi silang antar sel akan berkurang. Hal ini membuka beberapa peluang yang sangat menarik bagi kami dalam hal meningkatkan otomatisasi seputar pemantauan, pemecahan masalah, dan bahkan pengalihan 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, sebagian besar seputar akses data, yang perlu kami perbaiki seiring upaya kami untuk menjadi aktif-aktif sepenuhnya. Secara keseluruhan, eksperimen ini cukup berhasil sehingga dapat dijalankan untuk lalu lintas dari sejumlah pengguna kami yang terbatas.

Kami bersemangat untuk terus mendorong upaya ini guna meningkatkan efisiensi dan ketahanan platform. Pekerjaan pada sel dan infrastruktur aktif-aktif ini, bersama dengan upaya kami yang lain, akan memungkinkan kami untuk tumbuh menjadi perusahaan utilitas yang andal dan berkinerja tinggi bagi jutaan pengguna dan terus berkembang seiring upaya kami menghubungkan satu miliar orang secara real-time.