Gambaran Umum dan Wawasan tentang Infrastruktur Hiperskala Meta

• Budaya engineering Meta menekankan eksekusi cepat, keterbukaan teknologi, riset di lingkungan produksi, dan infrastruktur bersama
• Untuk meningkatkan produktivitas developer, Meta mengadopsi deployment berkelanjutan dan memungkinkan lebih banyak developer menulis fungsi serverless alih-alih kode layanan tradisional
• Untuk menekan biaya hardware, Meta memanfaatkan co-design hardware-software pada skala pusat data, serta secara otomatis mengoptimalkan alokasi sumber daya antar pusat data global tanpa membatasinya pada klaster individual
• Strategi AI Meta melakukan co-design atas seluruh stack, dari PyTorch hingga akselerator AI, jaringan, dan model ML seperti Llama

# [Budaya Engineering]

Eksekusi Cepat (Move Fast)

• Meta mempertahankan budaya "eksekusi cepat" yang menekankan kelincahan dan iterasi cepat
• Meta sangat mendukung deployment berkelanjutan (Continuous Deployment) untuk merilis kode terbaru ke produksi secepat mungkin
• Engineer produk menulis fungsi serverless stateless menggunakan bahasa seperti PHP, Python, Erlang
• Prioritas dapat diubah tanpa proses perencanaan yang panjang, dan masalah yang tidak pasti diselesaikan melalui eksekusi berulang
• Pendekatan ini memungkinkan respons pasar yang cepat dan peluncuran produk yang gesit

Keterbukaan Teknologi (Technology Openness)

• Keterbukaan internal: menggunakan pendekatan monorepo untuk menyimpan kode semua proyek dalam satu repositori
  • Memudahkan pencarian kode, penggunaan ulang, dan kolaborasi lintas tim
  • Pada sebagian besar proyek, tidak ada pembatasan kepemilikan kode yang ketat, sehingga developer dapat berkontribusi dengan bebas
• Keterbukaan eksternal: secara aktif membagikan proyek hardware dan software open-source
  • Membuka desain hardware melalui Open Compute Project
  • Mengelola berbagai proyek software open-source seperti PyTorch, Llama, Presto, RocksDB, Cassandra
  • Membagikan teknologi infrastruktur melalui makalah riset

Riset di Produksi (Research in Production)

• Meta melakukan riset langsung di lingkungan operasional nyata tanpa laboratorium sistem khusus
• Tim yang mengembangkan sistem produksi juga menulis makalah riset untuk menyelesaikan masalah nyata dan menyediakan solusi yang tervalidasi di lingkungan operasi berskala besar
• Pendekatan ini praktis dan memenuhi kriteria utama riset sistem yang sukses

Infrastruktur Bersama (Common Infrastructure)

• Alih-alih membiarkan tiap tim bebas memilih stack teknologi, Meta memprioritaskan standardisasi dan optimasi global
• Hardware:
  • Semua server dialokasikan dari pool server bersama
  • Untuk workload komputasi non-AI, Meta menyediakan satu jenis server (pada dasarnya 1 CPU, 256GB DRAM) untuk mengurangi kompleksitas jenis server
• Software:
  • Sebelumnya Meta menggunakan berbagai key-value store seperti Cassandra, HBase, ZippyDB, tetapi kini telah dikonsolidasikan ke ZippyDB
  • Deployment software, manajemen konfigurasi, service mesh, pengujian performa, dan lainnya disatukan dengan tool bersama
• Preferensi pada komponen yang dapat digunakan ulang:
  • Meta membangun rantai penggunaan ulang komponen yang terdiri dari sistem file Tectonic → ZippyDB (penyimpanan metadata) → Shard Manager (manajemen sharding data) → ServiceRouter (penemuan shard dan routing permintaan) → Delos (penyimpanan data berkeandalan tinggi)
  • Alih-alih sistem monolitik seperti HDFS, Meta menggunakan komponen modular yang dapat digunakan ulang untuk memaksimalkan skalabilitas

Studi Kasus Budaya: Pengembangan aplikasi Threads (Culture Case Study: The Threads App)

• Kasus pengembangan aplikasi Threads menunjukkan budaya engineering Meta dengan jelas
• Pekerjaan teknis diselesaikan hanya dalam 5 bulan, dan setelah pemberitahuan awal 2 hari sebelumnya, tim infrastruktur menuntaskan persiapan deployment ke produksi
• Di sebagian besar perusahaan besar, menyusun dokumen rencana proyek dalam dua hari saja pun sulit. Namun Meta membangun war room untuk penyelesaian masalah secara real-time dan merespons dengan cepat
• Hasilnya, menembus 100 juta pengguna hanya dalam 5 hari sejak peluncuran, menjadikannya aplikasi dengan pertumbuhan tercepat dalam sejarah
• Threads dapat melakukan scale-up dengan cepat dengan menggunakan ulang infrastruktur yang sudah ada:
  • Backend Python milik Instagram
  • Infrastruktur bersama Meta (database social graph, key-value store, platform serverless, platform ML, manajemen konfigurasi aplikasi mobile, dll.)
• Keterbukaan internal: mempercepat pengembangan dengan menggunakan ulang sebagian kode Instagram melalui monorepo
• Keterbukaan eksternal: memanfaatkan ActivityPub dengan tujuan interoperabilitas dengan aplikasi lain
• Berbagi pengalaman pengembangan: secara terbuka membagikan pengalaman pengembangan dan deployment cepat

# [Alur Permintaan Pengguna End-to-End (End-to-End User Request Flow)]

• Untuk melihat lebih dalam teknologi infrastruktur Meta, bagian ini menjelaskan seluruh proses bagaimana permintaan pengguna diproses
• Produk Meta didukung oleh infrastruktur layanan bersama, yang mencakup berbagai komponen inti

Routing Permintaan (Request Routing)

• Pemetaan DNS dinamis (Dynamic DNS Mapping)
  • Saat pengguna mengakses facebook.com, server DNS Meta secara dinamis mengembalikan alamat IP dari PoP (Point of Presence) terdekat
  • PoP adalah pusat data edge berskala kecil yang mendistribusikan beban jaringan dari lokasi yang dekat dengan pengguna
  • PoP mempertahankan koneksi TCP jangka panjang dengan pusat data Meta, sehingga mengurangi waktu pembentukan koneksi TCP dan meningkatkan performa jaringan
  • Ratusan PoP tersebar di seluruh dunia, sehingga memberikan latensi jaringan yang rendah bagi sebagian besar pengguna
• Caching konten statis (Static-Content Caching)
  • Konten statis seperti gambar dan video dapat di-cache di PoP lalu disajikan langsung
  • Selain itu, Meta juga mengoperasikan CDN (content delivery network) dan bekerja sama dengan ISP (penyedia layanan internet) untuk membangun situs CDN
  • Jika permintaan pengguna adalah facebook.com/image.jpg, Meta menulis ulangnya menjadi CDN109.meta.com/image.jpg agar konten disajikan dari situs CDN terdekat
  • Jika konten tersebut tidak ada di CDN, permintaan akan diteruskan melalui PoP → load balancer pusat data → sistem storage
• Routing permintaan konten dinamis (Dynamic-Content Request Routing)
  • Permintaan konten dinamis seperti News Feed diteruskan dari PoP ke pusat data
  • Tool traffic engineering memilih pusat data yang optimal dengan mempertimbangkan kapasitas pusat data dan latensi jaringan
  • Trafik dari PoP ke pusat data dikirim melalui WAN privat Meta (wide area network)
  • Trafik antar pusat data jauh lebih besar daripada trafik pengguna-ke-PoP, karena replikasi data dan interaksi antar-microservice

Topologi Infrastruktur (Infrastructure Topology)

• Infrastruktur global Meta terdiri dari berbagai lapisan komponen infrastruktur
• Setiap komponen menjalankan peran tertentu dan dioperasikan pada skala berikut:
  • Region pusat data (Region): Terdapat sekitar 10 region pusat data di seluruh dunia, dan setiap region dapat mengoperasikan hingga 1 juta server
  • PoP (Point of Presence, pusat data edge): Ada lebih dari 100 PoP, dan setiap PoP biasanya mencakup 100 hingga 1.000 server. PoP menangani trafik di lokasi yang dekat dengan pengguna untuk mengurangi latensi
  • Situs CDN: Terdapat lebih dari 1.000 situs CDN, biasanya mencakup 10 server atau lebih, dan beberapa situs besar mengoperasikan lebih dari 100 server. Situs ini melakukan caching konten statis (gambar, video, dan sebagainya) agar dapat disajikan dengan cepat
  • Pusat data (Datacenter): Di setiap region pusat data terdapat beberapa pusat data, dan setiap pusat data dapat mengoperasikan sekitar 100 ribu server atau lebih
  • MSB (main switchboard): Di dalam pusat data terdapat hingga 12 MSB, dan setiap MSB menangani 10 ribu hingga 20 ribu server. MSB berperan dalam distribusi daya dan menjadi domain kegagalan utama di dalam pusat data. Jika MSB gagal, hingga 20 ribu server dapat down
• Jaringan edge:
  • PoP terhubung ke beberapa autonomous system (AS) internet, dan menggunakan BGP (Border Gateway Protocol) untuk memilih rute terbaik
• Jaringan pusat data:
  • Server terhubung menggunakan topologi Clos 3 tingkat
  • Dirancang untuk mencegah kemacetan jaringan dan menyediakan bandwidth maksimum antarseserver
• Jaringan regional:
  • Pusat data dihubungkan melalui fabric aggregator, sehingga dapat berkomunikasi dengan WAN
  • Menggunakan topologi Fat-Tree agar dapat diperluas secara bertahap

Pemrosesan Permintaan (Request Processing)

• Pemrosesan online (Online Processing)
  • Permintaan pengguna didistribusikan melalui load balancer ke puluhan ribu fungsi frontend serverless (FrontFaaS)
  • Fungsi frontend dapat memanggil berbagai layanan backend, dan juga dapat memanggil layanan inferensi ML (misalnya rekomendasi iklan, rekomendasi konten News Feed)
  • Saat berjalan, fungsi frontend menambahkan event ke event queue agar fungsi serverless berbasis event (XFaaS) dapat dieksekusi secara asinkron
  • Rasio server untuk fungsi frontend dan fungsi berbasis event dioperasikan sekitar 5:1
• Pemrosesan offline (Offline Processing)
  • Sistem pemrosesan offline mendukung sistem online serta menjalankan analisis data dan pelatihan machine learning
  • Fungsi frontend dan layanan backend menyimpan berbagai data log ke data warehouse
    • Pelatihan ML: memperbarui model machine learning menggunakan data log
    • Pemrosesan stream: memperbarui topik yang paling banyak dibicarakan di dalam situs lalu menyimpannya ke database dan cache
    • Analisis batch: memperbarui sistem rekomendasi teman menggunakan Spark dan Presto
    • Eksekusi fungsi serverless berbasis event: pembaruan data berperan sebagai pemicu event untuk menjalankan fungsi serverless secara otomatis

# [Meningkatkan Produktivitas Developer (Boosting Developer Productivity)]

• Infrastruktur bersama Meta bertujuan untuk memaksimalkan produktivitas developer
• Untuk itu, Meta memanfaatkan continuous deployment dan fungsi serverless secara maksimal

Continuous Deployment (Continuous Deployment)

• Meta dioptimalkan agar dapat mendeploy perubahan kode dan konfigurasi (configuration) dengan cepat
• Fitur baru dan perbaikan bug dapat langsung dideploy sehingga memungkinkan feedback cepat dan perbaikan iteratif
• Perubahan konfigurasi (Configuration Changes)
  • Alat manajemen konfigurasi Meta mendeploy lebih dari 100 ribu perubahan real-time per hari ke production
  • Konfigurasi diperbarui secara otomatis di sekitar lebih dari 10 ribu layanan dan jutaan server
  • Berbagai tugas seperti load balancing, rollout fitur, A/B test, pencegahan overload, dan lainnya dijalankan secara otomatis
  • Perubahan konfigurasi direview seperti perubahan kode lalu di-commit ke repositori kode, dan perubahan tersebut dipropagasikan ke seluruh sistem dalam hitungan detik
• Perubahan kode (Code Changes)
  • Alat deployment Meta mengoperasikan lebih dari 30 ribu pipeline deployment untuk mengelola pembaruan software
  • 97% layanan mengadopsi deployment yang sepenuhnya otomatis sehingga pembaruan dilakukan tanpa intervensi manual:
    • 55% menggunakan continuous deployment (CD) penuh, sehingga perubahan kode otomatis diterapkan ke production
    • 42% dideploy otomatis dengan jadwal tetap (harian atau mingguan)
  • Fungsi frontend serverless (FrontFaaS) berjalan di lebih dari 500 ribu server, dan lebih dari 10 ribu developer melakukan ribuan commit kode setiap hari
  • Bahkan dalam lingkungan sedinamis ini, versi baru dari semua fungsi serverless dideploy ke production setiap 3 jam
• Pembaruan software jaringan dan infrastruktur
  • Private WAN Meta mempertahankan beberapa network plane paralel, sehingga algoritme jaringan baru dapat diuji secara independen
  • Software switch jaringan juga sering diperbarui, dan dengan memanfaatkan fitur "Warm Boot" pada switch, software dapat diperbarui tanpa menghentikan trafik jaringan
  • Karena perubahan kode dan konfigurasi yang sering diperbarui meningkatkan risiko gangguan situs, Meta banyak berinvestasi dalam pengujian, deployment bertahap, dan health check
    • Menjalankan kampanye internal untuk meningkatkan otomatisasi deployment kode dari 12% menjadi 97%
    • Melakukan uji Canary otomatis untuk semua perubahan konfigurasi demi menjamin stabilitas

Fungsi serverless (Serverless Functions)

• Fungsi serverless (atau FaaS, Function-as-a-Service) adalah elemen kunci lain untuk meningkatkan produktivitas pengembang
• Berbeda dari layanan backend tradisional, fungsi serverless tidak menyimpan state dan mengimplementasikan antarmuka fungsi yang sederhana
• Setiap pemanggilan fungsi dijalankan secara independen, dan state dikelola dengan memanfaatkan database eksternal atau sistem cache
• Keunggulan fungsi serverless
  • Pengembang cukup menulis logika produk tanpa mengelola infrastruktur
  • Deployment kode dan penskalaan otomatis (auto-scaling) sesuai perubahan beban dilakukan secara otomatis
  • Mencegah pemborosan hardware, dan pengembang tidak perlu mengalokasikan resource secara berlebihan
• Platform serverless Meta
  • Di Meta, jumlah pengembang yang menulis fungsi serverless lebih banyak 50% dibanding pengembang yang menulis kode layanan tradisional, dari total lebih dari 10.000 pengembang
  • IDE pengembangan serverless Meta mendukung akses mudah ke database social graph dan berbagai sistem backend, serta menyediakan pengujian integrasi berkelanjutan (CI) untuk memungkinkan umpan balik cepat
• Platform serverless Meta: FrontFaaS dan XFaaS
  • FrontFaaS: fungsi serverless frontend berbasis PHP, berjalan di lebih dari 500.000 server
    • Dengan menjaga runtime PHP selalu aktif, sistem dapat langsung memproses permintaan tanpa masalah cold start
    • Saat beban server rendah, sebagian server dilepas melalui auto-scaling dan dimanfaatkan untuk tugas lain
  • XFaaS: fungsi serverless berbasis event yang berjalan secara asinkron
    • Menangani tugas latar belakang yang tidak memerlukan respons langsung
    • Untuk menghindari tugas dengan beban tinggi, eksekusi dapat ditunda, serta diterapkan global load balancing dan throttling berbasis kuota
• Inovasi serverless Meta
  • Sejak akhir 2000-an, menggunakan pendekatan serverless sebagai paradigma pengembangan default
  • Perbedaan dengan platform serverless cloud publik:
    • Cloud publik menggunakan satu virtual machine untuk setiap fungsi demi isolasi yang kuat
    • Sebaliknya, Meta merancang agar banyak fungsi dapat berjalan bersamaan dalam satu proses Linux untuk memaksimalkan efisiensi hardware

# [Pengurangan Biaya Hardware (Reducing Hardware Costs)]

• Infrastruktur bersama Meta tidak hanya meningkatkan produktivitas pengembang, tetapi juga berperan penting dalam mengurangi biaya hardware
• Untuk itu, Meta menggunakan strategi memaksimalkan efisiensi hardware melalui optimasi software

Mengoperasikan semua pusat data global seperti satu komputer (All Global Datacenters as a Computer)

• Di lingkungan cloud lama, pengguna harus mengatur sendiri jumlah replika layanan, wilayah deployment, dan sebagainya
• Pendekatan pengelolaan manual ini menimbulkan masalah seperti pemborosan resource, ketidakseimbangan beban, dan kurangnya migrasi antar pusat data
• Meta mengembangkan pendekatan lama "Datacenter as a Computer" (DaaC), yang mengoperasikan pusat data sebagai satu komputer, menjadi Global-DaaC yang "mengoperasikan pusat data di seluruh dunia seperti satu komputer"
• Karakteristik utama Global-DaaC:
  • Pengguna cukup mengajukan permintaan deployment global, lalu infrastruktur secara otomatis menentukan jumlah replika optimal, wilayah deployment, jenis hardware, dan perutean trafik
  • Lokasi layanan dapat diubah sesuai kebutuhan, dan sistem mampu beradaptasi terhadap perubahan pasokan maupun perubahan beban
  • Berbeda dari cloud publik, Meta mengoperasikan semua aplikasinya sendiri sehingga dapat memindahkan workload dengan lebih fleksibel
• Cara implementasi Global-DaaC
  • Mengotomatiskan alokasi resource di tingkat global, regional, dan server individual:
    • Alat manajemen kapasitas global: menganalisis dependensi antarlayanan dengan memanfaatkan RPC tracing, lalu menentukan distribusi kapasitas optimal melalui mixed-integer programming (MIP)
    • Alat manajemen kapasitas regional: mengalokasikan resource server per pusat data untuk membentuk virtual cluster
    • Alat manajemen container: menempatkan container dalam virtual cluster, dan menyebarkannya ke beberapa pusat data untuk memastikan fault tolerance
    • Teknik manajemen kernel: membagi dan mengisolasi resource memori serta I/O antar-container secara tepat
• Contoh penerapan Global-DaaC
  • Database dan layanan penyimpanan state:
    • Setiap container meng-host beberapa data shard untuk memaksimalkan efisiensi
    • Global Service Placer (GSP) menentukan jumlah replika shard optimal dan wilayah penempatannya
    • Berdasarkan itu, framework sharding mengalokasikan shard ke container dan memigrasikannya secara dinamis
  • Workload machine learning (ML):
    • Tugas inferensi ML mengelola replika model seperti halnya data shard
    • Pelatihan ML mengharuskan data dan GPU ditempatkan di pusat data yang sama
    • Setelah menerima alokasi kapasitas GPU global, scheduler pelatihan ML melakukan replikasi data dan penempatan GPU yang optimal

Ko-desain perangkat keras-perangkat lunak (Hardware and Software Co-Design)

• Menerapkan ko-desain perangkat keras-perangkat lunak (Co-Design) pada level server tunggal adalah hal yang umum, tetapi Meta memperluasnya ke skala global untuk mengatasi keterbatasan perangkat keras berbiaya rendah melalui optimasi perangkat lunak
• Toleransi gangguan berbiaya rendah (Low-Cost Fault Tolerance)
  • Public cloud menyediakan perangkat keras dengan ketersediaan tinggi, tetapi Meta mengadopsi pendekatan mengatasi gangguan melalui perangkat lunak sehingga dapat memanfaatkan perangkat keras yang lebih murah
  • Perbedaan utama:
    • Rak server (Rack) di public cloud menggunakan dual power supply dan dual switch ToR (Top-of-Rack), sedangkan Meta menggunakan daya tunggal dan switch ToR tunggal
    • Virtual machine (VM) di public cloud menggunakan block storage yang terhubung ke jaringan sehingga mendukung live migration, sedangkan container di Meta menggunakan SSD lokal berbiaya rendah
  • Strategi penanganan gangguan berbasis perangkat lunak:
    • Alat alokasi resource: menyebarkan container layanan dan shard data ke domain kegagalan lain di dalam data center
    • Protokol kolaboratif: memungkinkan aplikasi ikut campur dalam pengelolaan lifecycle container, sehingga replika shard data tidak berhenti secara bersamaan
    • Menjamin daya tahan lintas banyak data center: dirancang agar layanan tetap berjalan meskipun satu wilayah penuh mengalami gangguan, dan keandalannya diverifikasi melalui pengujian produksi secara berkala
• Pengurangan biaya proxy routing (Eliminating Routing Proxy Costs)
  • Service mesh konvensional menggunakan sidecar proxy (Sidecar Proxy) untuk merutekan permintaan RPC, tetapi Meta menangani 99% permintaan RPC dengan routing langsung client-server
  • Pendekatan ini dapat menghemat sekitar 100 ribu server proxy
  • Namun, ada tantangan untuk mengompilasi dan mendistribusikan library routing ke lebih dari 10 ribu layanan, tetapi Meta mengatasinya melalui alat deployment perangkat lunak dan manajemen konfigurasi
• Penyimpanan bertingkat dan pemanfaatan SSD lokal (Tiered Storage and Local SSDs)
  • Storage dibedakan berdasarkan frekuensi akses data dan kebutuhan latensi untuk memaksimalkan efisiensi biaya:
    • Hot Data: disimpan di memori dan SSD (contoh: database grafik sosial)
    • Warm Data: disimpan di distributed file system berbasis HDD (contoh: video, gambar, data log)
    • Cold Data: disimpan di server HDD berkapasitas besar (contoh: video resolusi tinggi lama)
      • Dipertahankan dalam mode hemat daya untuk menekan biaya
  • Pemanfaatan SSD lokal:
    • Sebagian workload memberikan kinerja lebih baik di SSD lokal dibanding shared remote storage
    • Namun, ada risiko utilisasi SSD menjadi rendah akibat distribusi beban yang tidak seimbang
    • Meta menggunakan framework sharding umum untuk mengatasi ketidakseimbangan dan memaksimalkan efisiensi SSD

Desain perangkat keras internal (In-House Hardware Design)

• Meta mendesain sendiri data center, server, network switch, dan chip AI demi efisiensi biaya dan daya
• Karena daya adalah resource paling terbatas di data center, Meta mengoperasikan alat otomatisasi untuk mengoptimalkan penggunaan daya
• Penghematan biaya dan daya melalui ko-desain perangkat keras-perangkat lunak:
  • Optimasi penggunaan SRAM pada chip AI
  • Menghilangkan unit pendingin kompresi di data center
• Meta juga mengembangkan sendiri network switch dan perangkat lunaknya sehingga pembaruan berkala dimungkinkan, dan membagikan sebagian besar desain perangkat kerasnya sebagai open source melalui Open Compute Project

# [Merancang sistem yang dapat diskalakan (Designing Scalable Systems)]

• Dalam infrastruktur hiperskala, perancangan sistem yang dapat diskalakan merupakan elemen inti
• Sistem terdistribusi (BGP, BitTorrent, DHT, dan sebagainya) yang dirancang untuk lingkungan internet memiliki skalabilitas tinggi, tetapi di lingkungan data center, controller terpusat dapat memberikan skalabilitas dan efisiensi yang lebih tinggi

Penghapusan controller terdesentralisasi (Deprecating Decentralized Controllers)

• Meta memilih arah beralih dari controller terdesentralisasi yang ada ke controller terpusat
• Sebagai pengecualian, network switch tetap mempertahankan BGP, tetapi dirancang agar controller terpusat dapat mengatur ulang rute ketika terjadi kemacetan trafik atau gangguan link
• Controller terpusat memungkinkan load balancing yang lebih baik dan respons gangguan yang lebih cepat, sehingga lebih cocok untuk lingkungan data center

Contoh perubahan sistem terdistribusi yang ada menjadi terpusat

• Private WAN
  • Sebelumnya menggunakan RSVP-TE (penetapan rute terdistribusi), tetapi kemudian beralih ke sistem berbasis controller terpusat
  • Secara otomatis menghitung jalur trafik optimal dan menetapkan jalur cadangan terlebih dahulu saat terjadi gangguan untuk pemulihan cepat
• Key-value store
  • Berubah dari pendekatan lama yang menggunakan multi-hop routing berbasis DHT (distributed hash table) menjadi framework sharding berbasis controller terpusat
  • Controller terpusat secara dinamis menyesuaikan relokasi shard untuk mengoptimalkan keseimbangan beban
• Distribusi data berukuran besar
  • Sebelumnya menggunakan BitTorrent (unduhan P2P terdistribusi), tetapi beralih ke sistem distribusi terpusat milik Meta bernama Owl
  • Jalur unduhan data ditentukan secara terpusat sehingga memberikan kecepatan unduh yang jauh lebih tinggi
• Distribusi metadata berukuran kecil
  • Pada awalnya menggunakan struktur pohon terdistribusi 3 tingkat (berbasis Java), tetapi diubah ke struktur pohon berbasis P2P karena masalah skalabilitas
  • Namun, karena kinerja beberapa node yang tidak stabil menurunkan kinerja keseluruhan, akhirnya kembali ke arsitektur server proxy terpusat berbasis C++ berperforma tinggi

Studi kasus: service mesh yang dapat diskalakan (Scalable Service Mesh)

Meta mengoperasikan service mesh internal bernama ServiceRouter,
dan melalui sistem ini membuktikan efektivitas arsitektur terpusat yang dapat diskalakan.

• Masalah pada arsitektur service mesh konvensional
  • Service mesh pada umumnya merutekan permintaan RPC melalui sidecar proxy L7 di setiap proses layanan
  • Namun, dalam lingkungan hiperskala, tidak efisien jika controller terpusat harus mengelola langsung jutaan sidecar proxy
  • Meta mengganti pendekatan sidecar proxy dengan struktur di mana layanan itu sendiri menangani routing
• Arsitektur ServiceRouter milik Meta
  • Metadata routing dibuat di controller terpusat, tetapi masing-masing router L7 menyusun sendiri routing table-nya
  • Menggunakan database berbasis Paxos (RIB, Routing Information Base) untuk menjamin skalabilitas
    • Men-shard controller untuk mendistribusikan beban, dan beberapa controller dapat menghitung routing table untuk layanan tertentu secara paralel
  • Distribution layer menggunakan ribuan replika RIB untuk menangani permintaan baca dari jutaan router L7
  • Pada akhirnya, setiap router L7 dapat dikonfigurasi secara mandiri tanpa intervensi langsung dari controller terpusat
• Cara ServiceRouter mencapai skalabilitas
  1. Mengadopsi controller stateless: controller tidak mengelola router tertentu secara langsung, melainkan hanya mempertahankan informasi routing global
  2. Sharding controller: beberapa controller beroperasi secara independen, dan dapat memproses informasi routing untuk layanan yang berbeda secara paralel
  3. Menghapus fungsi yang tidak esensial: fungsi pengelolaan router L7 individual dihapus dari controller, dan setiap router dirancang untuk mengelola dirinya sendiri
• Hasil dan pelajaran
  • Arsitektur yang menggabungkan controller terpusat dan data plane terdistribusi memberikan skalabilitas optimal
  • Biaya operasional dan performa dioptimalkan dengan menghilangkan sidecar proxy yang tidak perlu
  • Melalui sharding yang strategis dan desain stateless, jutaan routing layanan dapat dikelola secara efektif

# [Arah Masa Depan (Future Directions)]

• Infrastruktur hiperskala Meta sangat kompleks, tetapi dokumen ini menyajikan ringkasan insight teknis yang utama
• Terakhir, dibagikan prospek mengenai tren masa depan infrastruktur hiperskala

AI (kecerdasan buatan)

• Workload AI kini telah menjadi workload yang mengambil porsi terbesar di data center
• Sebelum 2030, lebih dari separuh konsumsi daya data center diperkirakan akan digunakan untuk workload AI
• AI sangat mungkin mengubah struktur infrastruktur yang ada secara mendasar karena jaringan berperforma tinggi dan konsumsi sumber daya yang besar
• Infrastruktur hiperskala di masa lalu berkembang dengan pendekatan scale-out (Scaling-Out) (penempatan massal server berbiaya rendah), namun
  cluster AI di masa depan kemungkinan besar akan beralih ke pendekatan scale-up (Scaling-Up) (arsitektur superkomputer)
  • Contoh: memanfaatkan jaringan Ethernet berbasis RDMA (Remote Direct Memory Access) yang dioptimalkan untuk pelatihan machine learning (ML) skala besar
• Meta sedang menjalankan co-design full-stack yang mencakup PyTorch → model ML → chip AI → jaringan → data center → server → storage → daya dan pendinginan

Perangkat Keras Khusus Domain (Domain-Specific Hardware)

• Pada tahun 2000-an, hardware semakin terstandarisasi, tetapi
  ke depan diperkirakan akan ada peningkatan berbagai hardware khusus untuk pelatihan/inferensi AI, virtualisasi, encoding video, enkripsi, kompresi, memori berlapis, dan lainnya
• Perusahaan hiperskala dapat merancang dan mendistribusikan hardware kustom secara ekonomis melalui produksi massal
• Namun, peningkatan keragaman hardware ini akan memperbesar kompleksitas software stack dan menimbulkan tantangan dalam mengelola lingkungan yang heterogen

Data Center Edge (Edge Datacenters)

• Seiring meningkatnya aplikasi metaverse dan Internet of Things (IoT), ekspansi data center edge diperkirakan akan terjadi
• Cloud gaming menjalankan rendering grafis bukan di perangkat pengguna, melainkan di server GPU pada data center edge, dan
  latensi jaringan rendah di bawah 25 ms menjadi hal yang wajib
• Karena meningkatnya aplikasi yang membutuhkan respons real-time, jumlah dan skala data center edge sangat mungkin bertambah besar
• Untuk mengoperasikannya secara efektif, perlu perluasan Global-DaaC (konsep mengoperasikan data center di seluruh dunia seperti satu komputer) agar developer dapat dioptimalkan tanpa perlu memikirkan pengelolaan infrastruktur yang kompleks

Peningkatan Produktivitas Developer (Developer Productivity)

• Selama 20 tahun terakhir, alat otomasi telah sangat meningkatkan produktivitas administrator sistem sehingga rasio jumlah server yang ditangani per administrator meningkat tajam
• Namun, pengembangan software masih padat karya dan peningkatan produktivitasnya relatif lambat
• Ke depan, produktivitas developer diperkirakan meningkat tajam karena dua faktor:
  1. Kemajuan alat pembuatan kode dan debugging berbasis AI
  2. Munculnya paradigma pemrograman serverless yang sepenuhnya terintegrasi dan khusus domain
• FrontFaaS milik Meta adalah contoh dari pendekatan pemrograman serverless semacam ini, dan
  di masa depan diperkirakan akan muncul paradigma pemrograman baru yang dioptimalkan untuk industri tertentu (misalnya keuangan, kesehatan, dan lain-lain)

Kesimpulan

• Inovasi infrastruktur yang berpusat pada AI akan berkembang cepat selama 10 tahun ke depan
• Perusahaan hiperskala perlu berkontribusi agar seluruh komunitas dapat berkembang lebih cepat dengan membagikan insight mereka

[secret3056]

PoP itu BGP4 atau TCP anycast, dan sepertinya memang tidak ada cara bagi pengguna individu untuk memakainya, ya..?(menangis)

[pribess]

Saya kurang paham apa tepatnya yang dimaksud dengan pernyataan bahwa PoP adalah BGP4 atau TCP anycast, tetapi jika yang dimaksud adalah apakah mereka mengoperasikan AS sendiri, maka ya.
Biasanya, layanan multi-region pada umumnya lebih sering menggunakan anycast DNS yang dipadukan dengan penyeimbangan berbasis geolokasi.
Ya, untuk saat ini belum ada. Jika Anda membutuhkan PoP multi-region, Anda bisa menggunakan provider lain.

[GN⁺]

Komentar Hacker News

• Setelah Threads dikembangkan, tim infrastruktur hanya diberi pemberitahuan dua hari untuk bersiap menuju peluncuran. Sebagian besar organisasi besar membutuhkan waktu lebih dari dua hari hanya untuk menyusun rencana proyek yang melibatkan puluhan tim yang saling bergantung. Namun di Meta, mereka dengan cepat membangun war room di berbagai lokasi terdistribusi agar tim infrastruktur dan produk bisa menyelesaikan masalah secara real-time. Aplikasi ini mencapai 100 juta pengguna hanya dalam 5 hari setelah peluncuran dan menjadi aplikasi dengan pertumbuhan tercepat dalam sejarah

• Mengesankan bahwa mereka tetap mampu meluncurkan produk dengan cepat. Dibutuhkan banyak usaha agar birokrasi tidak meningkat, dan agar tim legal atau departemen lain tidak membuat gerbang persetujuan. Atau dibutuhkan kemampuan untuk menyelesaikan pekerjaan dengan cepat lewat war room

• Saat masih di FB, saya merasakan sendiri betapa kuatnya infrastrukturnya. Para engineer produk membangun proyek berskala besar hanya dalam hitungan hari. Saya pernah bekerja sebagai tech lead di beberapa tim, dan beberapa tim yang disebut di sini termasuk tim HBase dan ZippyDB

• Keren melihat ZippyDB disebut secara publik untuk pertama kalinya. Sangat keren juga bahwa peningkatan efisiensi developer ikut disebut. Setiap hari ada 10.000 service yang di-push atau semua commit dilakukan

• Setelah meninggalkan FB, saya tidak bisa menemukan hal serupa. Jadi sebagai startup, saya sedang membangun infrastruktur yang saya butuhkan. Batteries Included

• Saya menyayangkan banyaknya sinisme dan reaksi negatif di komentar-komentar ini. Banyak orang membenci Meta, tetapi artikel aslinya bagi saya terasa menakjubkan. Saya tidak tahu betapa luas dan rumitnya infrastruktur yang menopang dunia digital modern. Membaca artikel ini dan melihat skalanya sungguh mengejutkan

• Perusahaannya mungkin buruk dalam banyak hal, tetapi semua yang ada di artikel itu terasa menakjubkan bagi saya

• Saya bukan engineer seperti kalian, jadi mungkin artikel ini adalah kabar lama bagi kalian, tetapi saya tidak bisa tidak berkata "wow"

• Kalau artikel ini ditunjukkan kepada para penulis fiksi ilmiah masa lalu, saya rasa mereka juga akan takjub

• Menakjubkan. Semua teknologi luar biasa dan mengesankan ini, serta para engineer terbaik di dunia, dipakai hanya untuk menaruh lebih banyak iklan di depan mata orang. Hah

• Menarik bahwa frontend web PHP dijelaskan sebagai arsitektur "serverless" atau "function as a service". Sepertinya ini soal sudut pandang. Ini adalah service dengan satu codebase yang memiliki banyak endpoint yang dideploy. Dari sudut pandang maintainer endpoint, ini mungkin "serverless", tetapi seperti semua abstraksi, ada kebocoran

• Di lingkungan data center, saya lebih menyukai controller terpusat karena kesederhanaannya dan kemampuan mengambil keputusan berkualitas tinggi. Dalam banyak kasus, pendekatan hibrida yang menggabungkan control plane terpusat dan data plane terdistribusi adalah yang paling optimal

• Pendekatan ini tampak sebagai salah satu desain paling optimal untuk software networking (service mesh) dan storage (operasi database) di organisasi dengan jumlah server yang sangat besar. Menarik bahwa jaringan IP juga mengikuti model yang sama alih-alih terutama bergantung pada BGP

• Saya memperkirakan mereka menggunakan caching lokal untuk mengurangi beban pada router L7 dan memperbaiki latensi kueri database. Klien dapat menginvalidasi cache dan melakukan lookup kembali ke service mesh setelah timeout yang wajar

• Gabungan function serverless yang dikembangkan cepat dan continuous deployment, ditambah siapa pun bisa mengedit seluruh codebase, terdengar seperti mimpi buruk distopia. Jumlah logging yang dibutuhkan untuk debugging dan mencari bug pasti sangat ekstrem

• Menggunakan Erlang untuk menulis function serverless terasa seperti menghindari semua keuntungan besar yang bisa diberikan BEAM

• Para engineer produk terutama menulis kode dalam PHP, Python, dan Erlang sebagai function serverless stateless. Ini memberi keuntungan dalam kesederhanaan, produktivitas, dan kecepatan iterasi

• Untuk meningkatkan produktivitas developer, Meta mengadopsi continuous deployment secara universal, dan memungkinkan lebih banyak developer menulis function serverless dibanding kode service tradisional

• Untuk beban kerja komputasi non-AI, mereka hanya menyediakan satu tipe server, dilengkapi satu CPU dan jumlah DRAM yang sama (sebelumnya 64GB, sekarang 256GB). Saya penasaran apakah ini umum di seluruh industri, atau hanya umum di Meta

• Saat gambar tidak di-cache di CDN109, ketika pengguna memintanya, CDN109 akan meneruskan permintaan itu ke PoP terdekat. PoP lalu meneruskan permintaan itu ke load balancer di region data center, dan load balancer mengambil gambar dari sistem storage

• Saat meminta gambar 1MB, bukankah mengirim gambar 1MB dengan latensi 100ms di koneksi lambat tetap lebih cepat daripada melewati beberapa round-trip dan latensi yang terus bertambah?

• Jika diasumsikan permintaan melewati sistem Meta, pada akhirnya tetap menuju data center yang sama, dan diasumsikan tidak ada teknologi FTL

• Perbandingan eksplisit dengan hyperscaler sangat menarik. Saya penasaran apakah mereka sedang bersiap meluncurkan public cloud sendiri. Saya berharap ada seseorang dari Meta yang mau berkomentar