Pemantauan Kehilangan Paket Jaringan & Latensi di Roblox Cloud

Tim Teknik Jaringan Roblox mengelola jaringan besar yang berkembang pesat dengan pusat data dan lokasi titik kehadiran (POP) yang tersebar di seluruh dunia. Pengalaman pengguna yang optimal di platform Roblox bergantung pada kinerja dan keandalan jaringan ini. Sangat penting bagi operator jaringan untuk dapat mendeteksi dan mengatasi masalah di jaringan, serta memiliki visibilitas terhadap kinerja jaringan. Pemantauan jaringan umumnya dilakukan dengan mengumpulkan statistik perangkat, metrik kesalahan, dan syslog secara berkala, serta menyimpannya dalam basis data seri waktu atau log. Data dikumpulkan menggunakan model push atau pull melalui protokol standar seperti SNMP, Netconf, Rest APIs, atau Streaming Telemetry.

Deteksi gangguan jaringan hanya melalui telemetri perangkat memiliki beberapa kelemahan, karena ini merupakan teknik pemantauan pasif. Hal ini bergantung pada kemampuan node jaringan untuk mengidentifikasi dan melaporkan situasi anomali segera setelah terjadi. Perangkat mungkin tidak selalu melaporkan data kembali atau, dalam beberapa kasus, mungkin tidak memiliki semua statistik kesehatannya yang terpapar pada metode pengumpulan telemetri biasa. Selain itu, perangkat jaringan terkadang dapat memberikan data yang salah atau secara diam-diam memblokir lalu lintas. Keterbatasan utama dari telemetri perangkat adalah bahwa hal ini memberikan visibilitas yang sangat sedikit terhadap jangkauan ujung ke ujung, kehilangan paket, dan statistik latensi jaringan.

Cara yang sangat baik untuk memantau jaringan secara aktif adalah dengan secara teratur mengirimkan probe yang disintesis melintasi jaringan mesh seperti yang digambarkan pada gambar di bawah ini.

Saat menangani gangguan produksi, operator jaringan sering ditanya pertanyaan seperti, “Apakah jaringan kehilangan paket?” atau “Apakah ada gangguan jaringan yang sedang berlangsung yang memengaruhi konektivitas layanan?” Untuk menjawab pertanyaan semacam ini tanpa akses ke data historis kehilangan paket dan latensi, mereka perlu menyelidiki sejumlah besar tautan dan node di dalam jaringan.

Merancang sistem pemantauan jaringan mesh yang andal dan skalabel

Agar sistem pemantauan jaringan black box efektif dalam mendeteksi kehilangan paket atau lonjakan latensi, sistem tersebut memerlukan pengujian berkelanjutan di berbagai bagian jaringan. Jaringan pusat data memanfaatkan semua tautan antar node untuk lalu lintas pengguna. Perangkat jaringan produksi menjalankan BGP dan membagi beban lalu lintas melalui jalur-jalur dengan biaya yang sama. Perubahan topologi jaringan biasanya tercermin dalam hitungan detik melalui pembaruan tabel rute dalam kondisi normal. Untuk mendapatkan pengukuran kehilangan paket jaringan yang akurat, probe pengujian harus melintasi sebanyak mungkin jalur yang mencakup semua node dan tautan jaringan. Dengan jaringan besar seperti milik kami, yang mencakup beberapa lokasi di seluruh dunia, tidaklah skalabel untuk melakukan pengujian antara setiap pasangan node atau rak. Solusi yang lebih berkelanjutan yang kami pilih, yang tidak mengorbankan tingkat visibilitas, adalah melakukan pengujian pada mesh N² di antara rak-rak di setiap lokasi serta mesh N² lainnya di antara semua lokasi.

Apa yang kami gunakan untuk menguji jaringan?

Probe pengujian harus meniru lalu lintas langsung yang melewati jaringan produksi. Sebagian besar lalu lintas di jaringan kami adalah TCP, UDP, atau HTTP, dan masing-masing dapat digunakan untuk probe. Salah satu masalah dengan probe TCP adalah tidak cukup ringan untuk diskalakan ke jumlah koneksi yang diperlukan untuk memantau jaringan besar. Masalah lain dengan TCP adalah kontrol aliran bawaan dan transmisi berbasis jendela geser yang mengakibatkan laju transmisi probe yang bervariasi, yang tidak ideal untuk mengukur atau mendeteksi penurunan paket sesaat. ICMP, yang digunakan oleh ping dan traceroute, biasanya dibatasi laju pada server atau node jaringan. Hal ini membatasi laju agregat probe ICMP yang dapat digunakan. Permintaan HTTP berada di lapisan aplikasi yang lebih tinggi dan bergantung pada faktor-faktor di luar jaringan, seperti kinerja server atau aplikasi. HTTP menambahkan faktor variabel tambahan pada hasil yang sulit dipisahkan. Tujuan sistem ini adalah memantau kinerja infrastruktur jaringan dasar yang beroperasi terutama pada lapisan OSI 4 dan di bawahnya. Kami memilih probe UDP karena alasan ini, selain karena UDP merupakan protokol lapisan transportasi utama di jaringan kami.

Dari mana kami melakukan pengujian?

Salah satu cara untuk mencapai tingkat pengujian agregat yang tinggi dan mencakup sejumlah besar jalur jaringan adalah dengan memanfaatkan sebanyak mungkin node komputasi untuk mengirimkan probe. Hal ini memiliki dua keuntungan: membantu mendistribusikan beban pada sistem yang menghasilkan probe, dan memperluas jumlah port jaringan yang mengangkutnya. Namun, hal ini memerlukan agen yang sangat stabil dan seminimal mungkin menggunakan sumber daya sistem tuan rumah. Pada saat yang sama, agen harus mampu mengukur kehilangan paket dan latensi secara akurat pada berbagai jalur tanpa terpengaruh oleh fluktuasi pemanfaatan CPU, memori, atau I/O pada sistem host. Agen harus terus-menerus menjaga keseimbangan yang rumit ini antara menjadi ringan dan berkinerja tinggi.

Bagaimana cara mengukur kehilangan jaringan dan latensi?

Ini mungkin tampak sebagai perhitungan sederhana pada satu aliran probe, namun ada beberapa tantangan yang muncul saat skalabilitas yang tidak langsung terlihat. Untuk menskalakan ke jaringan mesh yang sangat besar, agen perlu menghitung jumlah paket transmisi (Tx) dan penerimaan (Rx) dengan cap waktu secara cepat dan akurat pada banyak aliran secara bersamaan. Penting agar metrik kehilangan jaringan tidak mencakup paket yang hilang di host yang menjalankan agen saat CPU-nya sibuk atau buffer jaringannya meluap. Latensi jaringan perlu dihitung berdasarkan total waktu probe berada di kabel atau node jaringan perantara, sambil mengesampingkan waktu yang dihabiskan menunggu di buffer I/O dan proses agen yang menunggu penjadwalan sistem operasi.

Sistem Ping Mesh Roblox

Kebutuhan akan pemantauan kehilangan jaringan dan latensi black box telah ada sejak pertumbuhan infrastruktur cloud publik dan privat. Solusi siap pakai yang dapat disesuaikan dengan jaringan besar kami terbukti sulit ditemukan. Beberapa operator cloud besar dan penyedia alat jaringan telah merancang solusi mereka sendiri untuk memantau kehilangan jaringan dan latensi. Kami mencoba beberapa alat yang tersedia secara terbuka, tetapi menemui masalah terkait stabilitas dan skalabilitas, serta hanya mendapatkan visibilitas terbatas terhadap kinerja jaringan. Hal ini mendorong kami untuk membangun sistem pemantauan mesh kami sendiri yang telah memberikan deteksi yang lebih baik terhadap kesalahan frekuensi rendah dengan overhead yang rendah. Beberapa keunggulan sistem kami adalah:

• Kami memilih Go untuk mengimplementasikan semua komponen sistem kami, dan hal ini membantu mencapai tingkat kinerja yang tinggi sambil menggunakan sumber daya sistem yang minimal.
• Agen kami sangat stabil dan dapat berjalan di berbagai host produksi, termasuk yang menjalankan layanan kritis di platform Roblox seperti server lalu lintas, caching, dan aplikasi.
• Agen ini dioptimalkan untuk mengelompokkan operasi I/O paket menggunakan fungsi wrapper Go di atas panggilan sistem Linux sendmmsg() dan recvmmsg(), yang memungkinkannya mengirimkan probe dengan laju tinggi dan beban rendah. Setiap agen dalam deployment kami secara bersamaan mengirimkan probe ke hingga 100 host lain, dengan laju 100 paket per detik (PPS). Agen mengirimkan burst paket setiap detik ke setiap tujuan.
• Probe membawa nilai bidang type-of-service (TOS) yang berbeda di header IP ke setiap tujuan dan dicatat secara terpisah untuk kehilangan paket dan latensi di jaringan. Setiap burst paket mencakup campuran nilai TOS yang beragam ke setiap tujuan lainnya. Hal ini membantu memantau kinerja jaringan untuk kelas kualitas layanan (QoS) yang berbeda.
• Agen dapat mendeteksi penurunan jaringan serendah 1 dari 6.000 paket per menit pada setiap jalur probe. Kehilangan paket di inti atau tepi jaringan yang berlangsung kurang dari 1 detik dapat terdeteksi, seperti yang terjadi selama BGP flap.
• Grafik kehilangan paket probe menyerupai grafik tingkat kesalahan antarmuka perangkat jaringan ketika kesalahan tersebut menjadi penyebab kehilangan paket. Kami telah berhasil menemukan bug black-holing lalu lintas di jaringan yang sulit dideteksi.
• Agen menggunakan cap waktu pembacaan kernel NIC untuk mencapai akurasi tinggi dalam pengukuran latensi jaringan. Latensi round trip intra-site yang konsisten sebesar 50–100 mikrodetik dapat diukur dengan mengesampingkan latensi penjadwalan sistem operasi host dan penyimpangan jam jaringan.
• Penggunaan CPU dan jejak memori yang rendah. Agen menggunakan kurang dari 25% dari satu inti pada tingkat transmisi dan penerimaan puncak (masing-masing 5 kpps). Sebagian besar agen yang diimplementasikan hanya menggunakan sekitar 5% dari satu inti. Hanya diperlukan 10MB memori heap untuk mengelola buffer dan penghitung paket transmisi (Tx) dan penerimaan (Rx) agen. Saat jaringan berkembang, kami dapat melakukan skalabilitas vertikal atau horizontal dengan menyesuaikan batas atau menambahkan agen tambahan.
• Agen ini jarang terpengaruh ketika sistem host sedang mengalami beban berat. Kami telah memperoleh hasil yang akurat bahkan ketika beban CPU host mendekati 99% pada beberapa kesempatan.
• Data telemetri dikumpulkan dari setiap agen untuk memantau kondisinya. Agen dapat mengidentifikasi situasi bermasalah seperti saat sistem host reboot, saat proses agen dimulai ulang, atau saat paket terlewat akibat buffer soket meluap.

Agen-agen ini diimplementasikan menggunakan Chef pada berbagai kluster server untuk memastikan jumlah node yang tinggi berpartisipasi dalam pemantauan jaringan. Biner agen dijalankan dan dikelola dengan systemd di Linux sehingga otomatis dimulai ulang setelah reboot host atau pembaruan agen. Penjadwal mesh secara dinamis mendeteksi dan menyesuaikan aliran sesuai kebutuhan saat salah satu agen mati atau agen baru muncul. Aplikasi penjadwal kami secara berkala memeriksa inventaris perangkat dan sistem penemuan layanan untuk mendeteksi agen baru serta status kesehatan server sebelum mengalokasikan target untuk pengujian Intra-Pod, Intra-Site, dan Inter-Site. Sebuah bus pesan digunakan untuk mengkomunikasikan daftar host target ke setiap agen yang mengirimkan probe pengujian. Aliran individu yang berasal atau berakhir di rak tertentu didistribusikan di antara semua agen yang tersedia di dalam rak tersebut. Hal ini membantu kami menguji sejumlah besar jalur dengan biaya yang sama di dalam jaringan kami, seperti yang ditunjukkan pada gambar di bawah ini.

Kami memulai dengan 150 agen pada implementasi pertama kami, dan kini telah berhasil memperluasnya hingga 10 kali lipat. Jaringan mesh ini mencakup backbone kami yang menghubungkan 25 situs yang tersebar di seluruh dunia. Di salah satu situs pusat data utama kami, kami memiliki jaringan intra-situs yang mencakup lebih dari 200 rak dengan sekitar 33.000 aliran yang teragregasi menjadi laju pengukuran 1,65 Mpps. Setiap rak menerima 5–10 kpps pengukuran dari rak lain. Aplikasi penjadwal menghitung dan mendistribusikan secara merata lebih dari 35.000 target ke seluruh agen kami di berbagai situs.

Pengumpulan dan visualisasi data

Kami menjalankan aplikasi pengumpul terpisah yang secara berkala memeriksa semua agen Ping Mesh untuk hasil kehilangan paket dan latensi. Data ini secara otomatis disaring untuk mengesampingkan hasil yang tidak valid berdasarkan status kesehatan yang disimpan secara lokal di pengumpul. Misalnya, kami mengesampingkan hasil dari agen yang berjalan di server yang tidak merespons pemeriksaan kesehatan atau server yang baru saja di-reboot. Pengumpul kami dapat secara sinkron memeriksa dan menyaring hasil dari lebih dari 1.500 node, lalu memasukkan data ke basis data seri waktu dalam waktu 2 detik.

Baik hasil agregat maupun per aliran ditampilkan menggunakan dasbor Grafana. Grid peta panas (heatmap) dapat sulit digunakan dengan set data yang besar, terutama untuk situs pusat data kami yang besar. Kami menggunakan kueri Prometheus topk() untuk menampilkan jalur dengan tingkat kehilangan paket individu tertinggi di antara ribuan hasil, yang umumnya hanya beberapa saja. Hasil-hasil tersebut diperiksa secara menyeluruh berdasarkan statistik kesehatan agen dan sistem host yang sering dipantau oleh pengumpul. Hal ini memberi kami tingkat keyakinan yang tinggi terhadap setiap hasil individu terlepas dari seberapa besar variasi kehilangan paket tersebut. Hasil-hasil individu tersebut, jika dilihat secara bersamaan, dapat memberi kami petunjuk di mana kesalahan jaringan terjadi. Beberapa contoh kehilangan paket yang terdeteksi oleh sistem pemantauan mesh kami ditampilkan di bawah ini.

Ringkasan dan langkah selanjutnya

Sistem Ping Mesh kami telah menjadi alat yang ampuh bagi tim Teknik Jaringan untuk memantau kehilangan paket dan latensi ujung ke ujung. Data ini dapat digunakan untuk langsung menjawab pertanyaan, “Apakah jaringan kehilangan paket?” Berdasarkan pengalaman kami, insiden jaringan besar yang berdampak pada pelanggan biasanya terdeteksi dan diberi peringatan oleh sistem pemantauan telemetri perangkat. Masalah yang berdampak rendah namun berpotensi menimbulkan masalah terkait penumpukan jaringan atau lalu lintas yang terisolasi yang terperangkap (black-holing) terungkap melalui sistem ini.

Sistem kami juga dapat memberikan wawasan tentang keandalan keseluruhan Jaringan Cloud Roblox. Di salah satu situs pusat data utama kami, kami memiliki lebih dari 100 juta probe per menit yang memantau kesehatan jaringan, dan kami jarang mencapai jumlah kehilangan paket lebih dari 50 per menit. Hal ini menunjukkan tingkat keandalan sekitar 6 9’s (99,9999%) dari jaringan pusat data kami. Seringkali, tidak ada kehilangan paket yang terdeteksi di antara 100 juta paket tersebut. Ketika terjadi kehilangan paket dalam jumlah signifikan, sistem ini memberikan wawasan mengenai lokasi dan durasi terjadinya kehilangan paket. Mesin pemulihan otomatis (auto-remediation engine) memperbaiki jaringan secara mandiri dan mencegah lalu lintas pengguna mengalami kehilangan paket lebih lanjut dengan mengalihkannya melalui jalur berbeda di jaringan. Tim Jaringan di Roblox telah membangun jaringan cloud yang sangat andal.

Di masa depan, kami berencana menggunakan mesin analitik untuk mengkorelasikan data dari telemetri perangkat, syslog, dan kumpulan data lainnya. Kemudian, kami berencana membandingkannya dengan data Ping Mesh untuk membantu mengidentifikasi lokasi terjadinya gangguan jaringan. Seiring dengan perluasan dan evolusi jaringan cloud Roblox, kami berencana meningkatkan mekanisme pemantauan kami untuk mencakup IPv6 dan jumbo frames, sambil menambahkan lebih banyak agen untuk meningkatkan cakupan antar-lokasi.