Cara Kami Membuat Infrastruktur Roblox Lebih Efisien dan Tangguh - Blog Roblox

Diterbitkan Ulang Oleh Plato

Followers: 0

Seiring berkembangnya Roblox selama 16+ tahun terakhir, skala dan kompleksitas infrastruktur teknis yang mendukung jutaan pengalaman bersama 3D yang mendalam juga meningkat. Jumlah mesin yang kami dukung meningkat lebih dari tiga kali lipat dalam 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 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 hibrid yang dibuat khusus dan terutama dijalankan di lokasi.

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

Pada bulan Oktober 2021, kami mengalami pemadaman seluruh sistem. Ini dimulai dari hal kecil, dengan masalah pada satu komponen di satu pusat data. Namun penyakit ini menyebar dengan cepat saat kami menyelidikinya dan akhirnya mengakibatkan pemadaman listrik selama 73 jam. Saat itu, kami berbagi keduanya detail tentang apa yang terjadi dan beberapa pembelajaran awal kami dari masalah ini. Sejak itu, kami telah mempelajari pembelajaran tersebut dan berupaya meningkatkan ketahanan infrastruktur kami terhadap jenis kegagalan yang terjadi di semua sistem berskala besar karena faktor-faktor seperti lonjakan lalu lintas ekstrem, cuaca, kegagalan perangkat keras, bug perangkat lunak, atau sekadar manusia melakukan kesalahan. Ketika kegagalan ini terjadi, bagaimana kita 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 sementara 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 keterlibatan per bulan dibandingkan 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 ditangani karena sebagian besar perusahaan mengelola beberapa layanan back-end mereka. Jadi ketika 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 mendapatkan kesalahan.

Hal ini menjadi tantangan ketika sebuah sistem atau seseorang melakukan percobaan ulang secara terlalu agresif, yang dapat menjadi jalan bagi kegagalan berskala kecil 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. Pemadaman kami 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 menjadi buruk.

Pada saat pemadaman 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 sudah ada tidak berfungsi. Prioritas pertama kami adalah memastikan kami memiliki penerapan 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: pemadaman listrik yang menyebar ke cukup banyak komponen dalam pusat data sehingga tidak dapat dioperasikan sepenuhnya. Kami sekarang memiliki satu pusat data yang menangani beban kerja (aktif) dan satu lagi siaga, berfungsi sebagai cadangan (pasif). Sasaran jangka panjang kami adalah beralih dari konfigurasi aktif-pasif ke konfigurasi aktif-aktif, yang mana kedua pusat data menangani beban kerja, dengan penyeimbang beban yang mendistribusikan permintaan di antara keduanya berdasarkan latensi, kapasitas, dan kesehatan. Setelah hal ini diterapkan, kami berharap dapat memiliki keandalan yang lebih tinggi untuk seluruh Roblox dan dapat melakukan failover hampir secara instan dibandingkan dalam beberapa jam.

Pindah ke Infrastruktur Seluler

Prioritas kami berikutnya adalah menciptakan dinding ledakan yang kuat di dalam setiap pusat data untuk mengurangi kemungkinan kegagalan seluruh pusat data. Sel (beberapa perusahaan menyebutnya cluster) pada dasarnya adalah sekumpulan mesin dan merupakan cara kita 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 memprovisi ulang satu mesin, atau sekelompok kecil mesin, merupakan hal yang cukup umum, namun melakukan hal ini untuk seluruh sel, yang berisi ~1,400 mesin, bukanlah hal yang umum.

Agar hal ini dapat berfungsi, sebagian besar sel-sel ini harus seragam, sehingga kita 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, yang membuatnya 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 sel jika sudah siap. Misalnya, alat penerapan baru kami secara otomatis “menggariskan” penerapan layanan di seluruh sel, sehingga pemilik layanan tidak perlu memikirkan strategi replikasi. Tingkat ketelitian ini membuat proses migrasi jauh lebih menantang dan memakan waktu, namun manfaat jangka panjangnya adalah sistem yang:

Jauh lebih mudah untuk membendung kegagalan dan mencegahnya menyebar ke sel lain;
Insinyur infrastruktur kami bisa lebih efisien dan bergerak lebih cepat; Dan
Para insinyur 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

Mirip dengan cara pintu kebakaran digunakan untuk menampung api, sel bertindak sebagai dinding ledakan yang kuat dalam infrastruktur kita 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 kita berhasil membuat sel-sel dapat dipertukarkan, pemulihan akan jauh lebih cepat karena kami dapat melakukan failover ke sel lain dan mencegah masalah tersebut berdampak pada pengguna akhir.

Hal yang menjadi rumit adalah memisahkan sel-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 kita mereplikasi layanan ini ke dalam sel, kita perlu memikirkan cara mengelola komunikasi silang. Idealnya, kita mengalihkan lalu lintas dari satu sel tidak sehat ke sel sehat lainnya. Tapi bagaimana kita mengelola “pertanyaan tentang kematian”—pertanyaan itu menyebabkan sel menjadi tidak sehat? Jika kita mengalihkan kueri tersebut ke sel lain, hal ini dapat menyebabkan sel tersebut menjadi tidak sehat seperti yang ingin kita hindari. Kita perlu menemukan mekanisme untuk mengalihkan lalu lintas “baik” dari sel-sel yang tidak sehat sambil mendeteksi dan mematikan 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 jaringan 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, namun kami mengantisipasi lebih banyak penelitian dan pengujian seiring kami terus memigrasikan layanan kami hingga tahun 2024 dan di luar. Seiring kemajuan kita, 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 berjalan di sel tersebut . Kami memiliki jutaan pengalaman 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, jadi daripada keluar dan membeli lebih banyak mesin setelah kehabisan mesin “cadangan”, kami membangun lebih banyak sel dengan menghapus dan menyediakan ulang mesin yang telah kami migrasikan. Kami kemudian memigrasikan beban kerja ke mesin yang telah diprovisi 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. Mereka secara fisik 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 skala 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 hal ini akan berlangsung hingga tahun depan dan mungkin hingga tahun 2025, karena beberapa faktor yang rumit. Pertama, pekerjaan ini membutuhkan perkakas yang kuat untuk dibangun. Misalnya, kita memerlukan alat untuk secara otomatis menyeimbangkan kembali sejumlah besar layanan ketika kita menerapkan sel baru—tanpa berdampak pada pengguna kita. Kami juga melihat layanan yang dibangun dengan asumsi tentang infrastruktur kami. Kita perlu merevisi layanan-layanan ini sehingga tidak bergantung pada hal-hal yang dapat berubah di masa depan seiring dengan perpindahan kita ke dalam sel. Kami juga telah menerapkan 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. Sasaran 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 keterlibatan. Di seluruh industri, waktu henti tidak dapat sepenuhnya dihilangkan, namun tujuan kami adalah mengurangi waktu henti Roblox hingga tingkat yang hampir tidak terlihat.

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. Seiring berjalannya waktu, platform ini akan semakin tangguh terhadap permasalahan, dan permasalahan apa pun yang terjadi akan semakin tidak terlihat dan mengganggu pengguna platform kami.

Singkatnya, hingga saat ini, kami memiliki:

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-sel ini menjadi lebih dapat dipertukarkan, crosstalk 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 orang dan terus berkembang seiring kami berupaya menghubungkan satu miliar orang secara nyata. waktu.