Meta’nın Hiperscale Altyapısına Genel Bakış ve İçgörüler

• Meta’nın mühendislik kültürü hızlı icra, teknolojiye açıklık, üretim ortamında araştırma ve paylaşılan altyapıyı vurgular
• Geliştirici üretkenliğini artırmak için sürekli dağıtımı benimser ve daha fazla geliştiricinin geleneksel servis kodu yerine sunucusuz fonksiyonlar yazabilmesini sağlar
• Donanım maliyetlerini düşürmek için veri merkezi ölçeğinde donanım-yazılım ortak tasarımından yararlanır ve kaynak tahsisini tek tek kümelerle sınırlamadan dünya genelindeki veri merkezleri arasında otomatik olarak optimize eder
• Meta’nın yapay zeka stratejisi, PyTorch’tan AI hızlandırıcılarına, ağlara ve Llama gibi ML modellerine kadar tüm yığını ortak tasarımla ele alır

# [Mühendislik kültürü]

Hızlı hareket et (Move Fast)

• Meta, çeviklik ve hızlı iterasyonu vurgulayan bir “hızlı hareket et” kültürünü sürdürür
• En güncel kodun mümkün olan en kısa sürede production ortamına alınmasını sağlayan sürekli dağıtımı (Continuous Deployment) güçlü biçimde destekler
• Ürün mühendisleri PHP, Python, Erlang gibi dilleri kullanarak durumsuz sunucusuz fonksiyonlar yazar
• Uzun planlama süreçleri olmadan öncelikler değiştirilebilir ve belirsiz problemler iteratif uygulamayla çözülür
• Bu yaklaşım pazara hızlı tepki ve ürünlerin süratle kullanıma sunulmasını mümkün kılar

Teknolojiye açıklık (Technology Openness)

• İç açıklık: Tüm projelerin kodunu tek bir depoda tutmak için monorepo yaklaşımı kullanılır
  • Kod arama, yeniden kullanım ve ekipler arası iş birliği kolaylaşır
  • Projelerin çoğunda katı kod sahipliği kısıtlamaları yoktur; geliştiriciler özgürce katkı verebilir
• Dış açıklık: Açık kaynak donanım ve yazılım projeleri aktif biçimde paylaşılır
  • Donanım tasarımları Open Compute Project üzerinden kamuya açılır
  • PyTorch, Llama, Presto, RocksDB, Cassandra gibi çeşitli açık kaynak yazılım projeleri yürütülür
  • Altyapı teknolojileri araştırma makaleleri aracılığıyla paylaşılır

Üretimde araştırma (Research in Production)

• Meta, ayrı bir sistem araştırma laboratuvarı olmadan, araştırmayı doğrudan gerçek işletim ortamında yürütür
• Production sistemleri geliştiren ekipler bizzat araştırma makaleleri yazar; böylece gerçek sorunları çözer ve büyük ölçekli işletim ortamında doğrulanmış çözümler sunar
• Bu yaklaşım pratiktir ve başarılı sistem araştırmasının temel ölçütlerini karşılar

Ortak altyapı (Common Infrastructure)

• Ayrı ekiplerin teknoloji yığınını özgürce seçmesi yerine, standardizasyon ve küresel optimizasyon önceliklendirilir
• Donanım:
  • Tüm sunucular paylaşılan sunucu havuzundan tahsis edilir
  • AI dışı bilgi işlem iş yükleri için tek bir sunucu tipi sunulur (temel olarak 1 CPU, 256GB DRAM); böylece sunucu tipi karmaşıklığı azaltılır
• Yazılım:
  • Eskiden Cassandra, HBase, ZippyDB gibi çeşitli anahtar-değer depoları kullanılırken, bugün bunlar ZippyDB altında birleştirilmiştir
  • Yazılım dağıtımı, yapılandırma yönetimi, servis mesh, performans testi gibi alanlar ortak araçlarla birleştirilmiştir
• Yeniden kullanılabilir bileşen tercihi:
  • Tectonic dosya sistemi → ZippyDB (metadata depolama) → Shard Manager (veri sharding yönetimi) → ServiceRouter (shard keşfi ve istek yönlendirme) → Delos (yüksek güvenilirlikli veri deposu) şeklinde bir bileşen yeniden kullanım zinciri kurulmuştur
  • HDFS gibi monolitik sistemler yerine modüler ve yeniden kullanılabilir bileşenler kullanılarak ölçeklenebilirlik en üst düzeye çıkarılır

Kültür vaka çalışması: Threads uygulamasının geliştirilmesi (Culture Case Study: The Threads App)

• Threads uygulamasının geliştirilme örneği, Meta’nın mühendislik kültürünü iyi gösterir
• Teknik çalışma yalnızca 5 ay içinde tamamlanmış, altyapı ekibi ise production dağıtım hazırlığını 2 gün önceden yapılan bildirimle bitirmiştir
• Büyük şirketlerin çoğunda iki gün içinde bir proje planı yazmak bile zordur. Ancak Meta, gerçek zamanlı sorun çözümü için war room kurarak hızlı yanıt vermiştir
• Sonuç olarak uygulama yayına alındıktan 5 gün sonra 100 milyon kullanıcıyı aşmış ve tarihin en hızlı büyüyen uygulaması olmuştur
• Threads, mevcut altyapıyı yeniden kullanarak hızla ölçeklenebilmiştir:
  • Instagram’ın Python backend’i
  • Meta’nın paylaşılan altyapısı (sosyal grafik veritabanı, anahtar-değer deposu, sunucusuz platform, ML platformu, mobil uygulama yapılandırma yönetimi vb.)
• İç açıklık: Monorepo’dan yararlanılarak Instagram kodunun bir kısmı yeniden kullanılmış ve geliştirme hızı artırılmıştır
• Dış açıklık: Diğer uygulamalarla birlikte çalışabilirliği hedeflemek için ActivityPub kullanılır
• Geliştirme deneyiminin paylaşılması: Hızlı geliştirme ve dağıtım deneyimi kamuoyuyla açık biçimde paylaşılmıştır

# [Uçtan uca kullanıcı istek akışı (End-to-End User Request Flow)]

• Meta’nın altyapı teknolojilerine derinlemesine bakmak için bir kullanıcı isteğinin işlenmesindeki tüm süreç açıklanır
• Meta’nın ürünleri, içinde çeşitli temel bileşenlerin bulunduğu paylaşılan servis altyapısı tarafından desteklenir

İstek yönlendirme (Request Routing)

• Dinamik DNS eşlemesi (Dynamic DNS Mapping)
  • Kullanıcı facebook.com adresine girdiğinde Meta’nın DNS sunucusu, dinamik olarak en yakın PoP (Point of Presence) için IP adresini döndürür
  • PoP, küçük ölçekli bir edge veri merkezidir ve kullanıcıya yakın bir konumda ağ yükünü dağıtır
  • PoP, Meta’nın veri merkezleriyle uzun süreli TCP bağlantıları sürdürür; böylece TCP bağlantısı kurma süresi azalır ve ağ performansı iyileşir
  • Dünya genelinde yüzlerce PoP bulunduğundan, kullanıcıların çoğuna düşük ağ gecikmesi sağlanır
• Statik içerik önbellekleme (Static-Content Caching)
  • Görseller, videolar gibi statik içerikler PoP üzerinde önbelleğe alınır ve doğrudan sunulabilir
  • Ayrıca Meta, bir CDN (içerik dağıtım ağı) işletir ve ISP’lerle (internet servis sağlayıcıları) iş birliği yaparak CDN noktaları kurar
  • Kullanıcının isteği facebook.com/image.jpg ise Meta bunu CDN109.meta.com/image.jpg olarak yeniden yazar ve içeriği yakındaki CDN noktasından sunar
  • İlgili içerik CDN’de yoksa istek PoP → veri merkezi load balancer → depolama sistemi yoluyla iletilir
• Dinamik içerik istek yönlendirmesi (Dynamic-Content Request Routing)
  • Haber akışı gibi dinamik içerik istekleri PoP’den veri merkezine iletilir
  • Trafik mühendisliği araçları, veri merkezi kapasitesi ve ağ gecikmesini dikkate alarak en uygun veri merkezini seçer
  • PoP ile veri merkezi arasındaki trafik, Meta’nın özel WAN’ı (geniş alan ağı) üzerinden taşınır
  • Veri merkezleri arasındaki trafik, kullanıcı-PoP trafiğinden çok daha fazladır; bunun nedeni veri replikasyonu ve mikroservisler arası etkileşimdir

Altyapı Topolojisi (Infrastructure Topology)

• Meta’nın küresel altyapısı, çeşitli katmanlardaki altyapı bileşenlerinden oluşur
• Her bileşen belirli bir rol üstlenir ve şu ölçeklerde işletilir:
  • Veri merkezi bölgesi (Region): Dünya genelinde yaklaşık 10 veri merkezi bölgesi bulunur ve her bölge en fazla 1 milyon sunucu çalıştırabilir
  • PoP (Point of Presence, uç veri merkezi): 100’den fazla PoP vardır ve her PoP genellikle 100 ila 1.000 sunucu içerir. Trafiği kullanıcıya yakın konumlarda işleyerek gecikmeyi azaltır
  • CDN sitesi: 1.000’den fazla CDN sitesi vardır; bunlar genellikle 10’dan fazla sunucu içerir ve bazı büyük siteler 100’den fazla sunucu çalıştırır. Statik içeriği (görseller, videolar vb.) cache’leyerek hızlı sunum sağlar
  • Veri merkezi (Datacenter): Her veri merkezi bölgesinde birden fazla veri merkezi bulunur ve her veri merkezi yaklaşık 100.000’den fazla sunucu çalıştırabilir
  • MSB (ana switchboard, Main Switchboard): Bir veri merkezinde en fazla 12 MSB bulunur ve her MSB 10.000 ila 20.000 sunucudan sorumludur. Güç dağıtımı görevini üstlenir ve veri merkezi içindeki temel arıza alanlarından biri olarak işlev görür. Bir MSB arızalanırsa 20.000’e kadar sunucu devre dışı kalabilir
• Uç ağ:
  • PoP’ler birden fazla internet otonom sistemine (AS) bağlanır ve en iyi rotayı seçmek için BGP (Border Gateway Protocol) kullanır
• Veri merkezi ağı:
  • Sunucular 3 katmanlı Clos topolojisi ile birbirine bağlanır
  • Ağ tıkanıklığını önleyecek ve sunucular arası azami bant genişliği sağlayacak şekilde tasarlanmıştır
• Bölgesel ağ:
  • Veri merkezleri fabric aggregator ile bağlanır ve WAN ile iletişim kurabilir
  • Kademeli olarak ölçeklenebilmek için Fat-Tree topolojisi kullanılır

İstek İşleme (Request Processing)

• Çevrimiçi işleme (Online Processing)
  • Kullanıcı istekleri, load balancer üzerinden on binlerce sunucusuz frontend fonksiyonuna (FrontFaaS) dağıtılır
  • Frontend fonksiyonları birden fazla backend servisini çağırabilir ve ML çıkarım servislerini de (ör. reklam önerileri, haber akışı içerik önerileri) çağırabilir
  • Çalışma sırasında frontend fonksiyonları, event queue içine olay ekleyerek olay tabanlı sunucusuz fonksiyonların (XFaaS) eşzamansız biçimde çalışmasını sağlar
  • Frontend fonksiyonları ile olay tabanlı fonksiyonların sunucu oranı yaklaşık 5:1 olarak işletilir
• Çevrimdışı işleme (Offline Processing)
  • Çevrimdışı işleme sistemi, çevrimiçi sistemi destekler ve veri analizi ile makine öğrenimi eğitimi gerçekleştirir
  • Frontend fonksiyonları ve backend servisleri, çeşitli log verilerini veri ambarına kaydeder
    • ML eğitimi: Log verileri kullanılarak makine öğrenimi modelleri güncellenir
    • Akış işleme: Sitede en çok tartışılan konular güncellenir ve veritabanı ile cache’e kaydedilir
    • Toplu analiz: Spark ve Presto kullanılarak arkadaş öneri sistemi güncellenir
    • Olay tabanlı sunucusuz fonksiyon çalıştırma: Veri güncellemeleri olay tetikleyicisi görevi görerek sunucusuz fonksiyonları otomatik olarak çalıştırır

# [Geliştirici Üretkenliğini Artırma (Boosting Developer Productivity)]

• Meta’nın paylaşılan altyapısı, geliştirici üretkenliğini en üst düzeye çıkarmayı hedefler
• Bunun için sürekli dağıtım (Continuous Deployment) ve sunucusuz fonksiyonları (Serverless Functions) en uç noktaya kadar kullanıyor

Sürekli Dağıtım (Continuous Deployment)

• Meta, kod ve yapılandırma (Configuration) değişikliklerini hızla dağıtabilmek için optimize edilmiştir
• Yeni özellikler ve hata düzeltmeleri anında dağıtılarak hızlı geri bildirim ve yinelemeli iyileştirme sağlanır
• Yapılandırma değişiklikleri (Configuration Changes)
  • Meta’nın yapılandırma yönetim aracı, her gün 100.000’den fazla gerçek zamanlı değişikliği production’a dağıtır
  • Yapılandırmalar, 10.000’den fazla servis ve milyonlarca sunucuda otomatik olarak güncellenir
  • Load balancing, özellik rollout’u, A/B testleri, aşırı yük önleme gibi çeşitli işlemler otomatik olarak yürütülür
  • Yapılandırma değişiklikleri, kod değişiklikleri gibi incelemeden geçirilip kod deposuna commit edilir ve değişiklikler birkaç saniye içinde tüm sisteme yayılır
• Kod değişiklikleri (Code Changes)
  • Meta’nın dağıtım aracı, 30.000’den fazla dağıtım pipeline’ı işleterek yazılım güncellemelerini yönetir
  • Servislerin %97’si tamamen otomatik dağıtımı benimsemiştir ve manuel müdahale olmadan güncellenir:
    • %55’i tam sürekli dağıtım (CD) kullanır; kod değişiklikleri otomatik olarak production’a yansır
    • %42’si sabit bir takvimle (günlük veya haftalık) otomatik dağıtılır
  • Frontend sunucusuz fonksiyonları (FrontFaaS), 500.000’den fazla sunucuda çalışır ve 10.000’den fazla geliştirici her gün binlerce kod commit’i yapar
  • Bu kadar dinamik bir ortamda bile tüm sunucusuz fonksiyonların yeni sürümleri her 3 saatte bir production’a dağıtılır
• Ağ ve altyapı yazılımı güncellemeleri
  • Meta’nın özel WAN’ı (Private WAN), birden fazla paralel ağ düzlemini koruyarak yeni ağ algoritmalarının bağımsız biçimde test edilmesini sağlar
  • Ağ switch yazılımı da sık güncellenir ve switch’in "Warm Boot" özelliği kullanılarak ağ trafiğini kesmeden yazılım güncellemesi yapılabilir
  • Sık güncellenen kod ve yapılandırma değişiklikleri site arızası riskini artırdığından, Meta testlere, aşamalı dağıtıma ve sağlık kontrollerine yoğun yatırım yapmaktadır
    • Kod dağıtım otomasyonunu %12’den %97’ye çıkaran şirket içi bir kampanya yürüttü
    • Tüm yapılandırma değişiklikleri için otomatik Canary testleri uygulanarak kararlılık sağlanır

Sunucusuz işlevler (Serverless Functions)

• Sunucusuz işlevler (veya FaaS, Function-as-a-Service), geliştirici üretkenliğini artıran bir diğer temel unsur
• Geleneksel backend servislerinden farklı olarak, sunucusuz işlevler durum saklamaz ve basit bir işlev arayüzü uygular
• Her işlev çağrısı bağımsız olarak çalışır ve durumu yönetmek için harici veritabanları veya önbellek sistemlerinden yararlanır
• Sunucusuz işlevlerin avantajları
  • Geliştiricilerin altyapı yönetimi olmadan yalnızca ürün mantığını yazması yeterlidir
  • Kod dağıtımı ve yük değişimlerine göre otomatik ölçeklendirme (Auto-Scaling) otomatik olarak gerçekleştirilir
  • Donanım israfını önler ve geliştiricilerin gereğinden fazla kaynak tahsis etmesine gerek kalmaz
• Meta’nın sunucusuz platformu
  • Meta’daki 10 binden fazla geliştirici arasında, sunucusuz işlev yazan geliştiricilerin sayısı geleneksel servis kodu yazanlardan %50 daha fazladır
  • Meta’nın sunucusuz geliştirme ortamı (IDE), sosyal grafik veritabanına ve çeşitli backend sistemlerine kolay erişim sağlar; ayrıca hızlı geri bildirim için sürekli entegrasyon testleri (CI) sunar
• Meta’nın sunucusuz platformu: FrontFaaS ve XFaaS
  • FrontFaaS: PHP tabanlı frontend sunucusuz işlevleri, 500 binden fazla sunucuda çalışır
    • PHP runtime’ını sürekli hazır tutarak cold start sorunu olmadan istekleri anında işleyebilir
    • Sunucu yükü düşük olduğunda otomatik ölçeklendirme ile bazı sunucuları devreden çıkarıp başka işlerde kullanır
  • XFaaS: Asenkron çalışan, olay tabanlı sunucusuz işlevler
    • Anında yanıt gerektirmeyen arka plan işlerini işler
    • Yüksek maliyetli işleri önlemek için yürütmeyi geciktirme, global load balancing ve kota tabanlı throttling uygular
• Meta’nın sunucusuz alandaki yenilikleri
  • 2000’lerin sonlarından beri sunucusuz yaklaşımı varsayılan geliştirme paradigması olarak kullanıyor
  • Public cloud’daki sunucusuz platformlardan farkı:
    • Public cloud, güçlü izolasyon için her işlev başına bir sanal makine kullanır
    • Buna karşılık Meta, tek bir Linux sürecinde birden fazla işlevin eşzamanlı çalışabilmesini sağlayacak şekilde tasarlayarak donanım verimliliğini en üst düzeye çıkarır

# [Donanım maliyetlerini azaltma (Reducing Hardware Costs)]

• Meta’nın paylaşımlı altyapısı yalnızca geliştirici üretkenliğini artırmakla kalmaz, donanım maliyetlerinin azaltılmasında da önemli rol oynar
• Bunun için yazılım optimizasyonunu kullanarak donanım verimliliğini en üst düzeye çıkarma stratejisi uygulanır

Tüm global veri merkezlerini tek bir bilgisayar gibi işletmek (All Global Datacenters as a Computer)

• Mevcut cloud ortamlarında kullanıcıların servis kopyası (replica) sayısını, dağıtım bölgelerini ve benzer ayarları doğrudan belirlemesi gerekiyordu
• Bu tür manuel yönetim, kaynak israfı, yük dengesizliği ve veri merkezleri arasında yetersiz taşıma gibi sorunlara yol açıyordu
• Meta, “veri merkezini tek bir bilgisayar olarak işletme” yaklaşımı (DaaC, Datacenter as a Computer) üzerine inşa ederek, “dünya genelindeki veri merkezlerini tek bir bilgisayar gibi işletme” anlamına gelen Global-DaaC’i hayata geçirdi
• Global-DaaC’in temel özellikleri:
  • Kullanıcı yalnızca global dağıtım talebinde bulunduğunda, altyapı en uygun kopya sayısını, dağıtım bölgelerini, donanım türünü ve trafik yönlendirmesini otomatik olarak belirler
  • Gerektiğinde servislerin konumunu değiştirir ve arz ile yük değişimlerine uyum sağlayabilir
  • Public cloud’dan farklı olarak Meta tüm uygulamaları kendisi işlettiği için workload’ları çok daha esnek biçimde taşıyabilir
• Global-DaaC’in uygulama yöntemi
  • Kaynak tahsisini global, bölgesel ve tekil sunucu seviyelerinde otomatikleştirir:
    • Global kapasite yönetim aracı: RPC tracing kullanarak servisler arası bağımlılıkları analiz eder ve mixed-integer programming (MIP) ile en uygun kapasite dağılımını belirler
    • Bölgesel kapasite yönetim aracı: veri merkezi bazında sunucu kaynakları tahsis ederek sanal kümeler (Virtual Cluster) oluşturur
    • Konteyner yönetim aracı: sanal kümelerde konteynerleri yerleştirir ve birden fazla veri merkezine dağıtarak hata toleransı (Fault Tolerance) sağlar
    • Kernel yönetim teknikleri: konteynerler arasında bellek ve I/O kaynaklarını uygun şekilde paylaşır ve izole eder
• Global-DaaC’in kullanım örnekleri
  • Veritabanları ve durum saklayan servisler:
    • Her konteyner, verimliliği en üst düzeye çıkarmak için birden fazla veri shard’ını barındırır
    • Global Service Placer (GSP), en uygun shard kopya sayısını ve yerleşim bölgelerini belirler
    • Sharding framework’ü buna dayanarak shard’ları konteynerlere atar ve dinamik olarak taşır
  • Makine öğrenimi (ML) iş yükleri:
    • ML inference işleri, model kopyalarını veri shard’ları gibi yönetir
    • ML training için veri ile GPU’nun aynı veri merkezinde konumlandırılması gerekir
    • Global GPU kapasite tahsisi alındıktan sonra, ML eğitim planlayıcısı en uygun veri kopyalama ve GPU yerleşimini gerçekleştirir

Donanım-yazılım ortak tasarımı (Hardware and Software Co-Design)

• Donanım-yazılım ortak tasarımını (Co-Design) tek sunucu düzeyinde uygulamak yaygındır; ancak Meta bunu küresel ölçekte genişleterek düşük maliyetli donanımın sınırlarını yazılım optimizasyonuyla aşar
• Düşük maliyetli hata toleransı (Low-Cost Fault Tolerance)
  • Public cloud yüksek erişilebilirliğe sahip donanım sunar; ancak Meta, arızaları yazılım üzerinden aşma yaklaşımını benimseyerek daha ucuz donanım kullanır
  • Temel farklar:
    • Public cloud'daki sunucu rack'leri dual güç kaynağı ve dual ToR (Top-of-Rack) switch kullanırken, Meta tek güç kaynağı ve tek ToR switch kullanır
    • Public cloud'daki sanal makineler (VM), canlı taşıma için ağa bağlı blok depolama kullanabilirken, Meta'nın container'ları düşük maliyetli yerel SSD kullanır
  • Yazılım tabanlı arıza giderme stratejileri:
    • Kaynak tahsis araçları: Servislerin container'larını ve veri shard'larını veri merkezi içindeki farklı arıza alanlarına dağıtır
    • İşbirlikçi protokoller: Uygulamaların container yaşam döngüsü yönetimine müdahil olmasını sağlayarak, veri shard kopyalarının aynı anda kesintiye uğramamasını korur
    • Çoklu veri merkezi dayanıklılığı güvencesi: Bir bölgenin tamamı devre dışı kalsa bile hizmetin sürmesini sağlayacak şekilde tasarlanmıştır; güvenilirliği doğrulamak için düzenli olarak gerçek ortam testleri yapılır
• Yönlendirme proxy maliyetlerini azaltma (Eliminating Routing Proxy Costs)
  • Geleneksel service mesh, RPC isteklerini yönlendirmek için sidecar proxy kullanır; ancak Meta, RPC isteklerinin %99'unu doğrudan istemci-sunucu yönlendirmesiyle işler
  • Bu yöntemle yaklaşık 100 bin proxy sunucusundan tasarruf edilebilir
  • Ancak yönlendirme kütüphanesinin 10 binden fazla servise derlenip dağıtılması gerektiği gibi bir zorluk vardır; Meta bunu yazılım dağıtım ve yapılandırma yönetim araçlarıyla çözer
• Katmanlı depolama ve yerel SSD kullanımı (Tiered Storage and Local SSDs)
  • Veri erişim sıklığına ve gecikme gereksinimlerine göre depolamayı ayırarak maliyet verimliliğini en üst düzeye çıkarır:
    • Hot data: Bellek ve SSD'de saklanır (ör. sosyal grafik veritabanı)
    • Warm data: HDD tabanlı dağıtık dosya sisteminde saklanır (ör. video, görsel ve log verileri)
    • Cold data: Büyük kapasiteli HDD sunucularında saklanır (ör. eski yüksek çözünürlüklü videolar)
      • Düşük güç modunda tutularak maliyet azaltılır
  • Yerel SSD kullanımı:
    • Bazı workload'larda paylaşımlı uzak depolamadan (remote storage) daha iyi performans sağlar
    • Ancak dengesiz yük dağılımı nedeniyle SSD kullanım oranının düşmesi riski vardır
    • Meta'nın ortak sharding framework'ü kullanılarak dengesizlik sorunu çözülür ve SSD verimliliği en üst düzeye çıkarılır

Şirket içi donanım tasarımı (In-House Hardware Design)

• Meta, maliyet ve güç verimliliği için veri merkezlerini, sunucuları, ağ switch'lerini ve AI çiplerini kendi tasarlar
• Güç, veri merkezindeki en kısıtlı kaynaktır; bu nedenle güç kullanımını optimize eden otomasyon araçları işletir
• Donanım-yazılım ortak tasarımıyla maliyet ve güç tüketimini azaltır:
  • AI çiplerinde SRAM kullanımının optimize edilmesi
  • Veri merkezlerinde sıkıştırmalı soğutma ekipmanlarının kaldırılması
• Ağ switch'lerini ve yazılımları da kendi geliştirir; bu sayede düzenli güncellemeler yapılabilir ve donanım tasarımlarının büyük bölümünü Open Compute Project üzerinden açık kaynak olarak paylaşır

# [Ölçeklenebilir sistemler tasarlamak (Designing Scalable Systems)]

• Hiperscale altyapıda ölçeklenebilir sistem tasarımı kilit unsurdur
• İnternet ortamı için tasarlanmış dağıtık sistemler (BGP, BitTorrent, DHT vb.) yüksek ölçeklenebilirlik sunar; ancak veri merkezi ortamında merkezi denetleyiciler daha yüksek ölçeklenebilirlik ve verimlilik sağlayabilir

Dağıtık denetleyicilerin kaldırılması (Deprecating Decentralized Controllers)

• Meta, mevcut dağıtık denetleyicilerden merkezi denetleyicilere geçiş yönünde karar aldı
• İstisna olarak ağ switch'leri BGP'yi korur; ancak trafik sıkışıklığı veya bağlantı arızası durumunda merkezi denetleyici rotaları yeniden ayarlayabilecek şekilde tasarlanmıştır
• Merkezi denetleyiciler daha iyi yük dengeleme ve daha hızlı arıza müdahalesi sağlar; bu nedenle veri merkezi ortamına daha uygundur

Mevcut dağıtık sistemlerin merkezi yapıya dönüştürüldüğü örnekler

• Private WAN
  • Önceden RSVP-TE (dağıtık yol kurma) kullanılırken, merkezi denetleyici tabanlı sisteme geçildi
  • En uygun trafik rotaları otomatik olarak hesaplanır ve arıza anında yedek rotalar önceden ayarlanarak hızlı kurtarma sağlanır
• Anahtar-değer deposu (Key-Value Store)
  • Önceden DHT (dağıtık hash tablosu) tabanlı çok atlamalı yönlendirme kullanan yapıdan, merkezi denetleyici tabanlı bir sharding framework'üne geçildi
  • Merkezi denetleyici, shard yeniden yerleştirmelerini dinamik olarak ayarlayarak yük dengesini optimize eder
• Büyük ölçekli veri dağıtımı
  • Önceden BitTorrent (dağıtık P2P indirme) kullanılırken, Meta'nın Owl adlı merkezi dağıtım sistemine geçildi
  • Veri indirme yolları merkezden belirlenerek çok daha yüksek indirme hızı sağlanır
• Küçük ölçekli metadata dağıtımı
  • İlk başta 3 katmanlı dağıtık ağaç yapısı (Java tabanlı) kullanıldı, ancak ölçeklenebilirlik sorunları nedeniyle P2P tabanlı ağaç yapısına geçildi
  • Ancak bazı düğümlerin kararsız performansı genel performansı düşürdüğü için, sonunda yüksek performanslı C++ tabanlı merkezi proxy sunucu mimarisine geri dönüldü

Vaka çalışması: ölçeklenebilir service mesh (Scalable Service Mesh)

Meta, ServiceRouter adlı kendi service mesh'ini işletiyor ve
bu sistem aracılığıyla ölçeklenebilir merkezi mimarinin etkisini kanıtlıyor.

• Mevcut service mesh mimarisinin sorunları
  • Yaygın service mesh mimarilerinde her servis süreci, RPC isteklerini L7 sidecar proxy üzerinden yönlendirir
  • Ancak hiperscale ortamda merkezi denetleyicinin milyonlarca sidecar proxy'yi doğrudan yönetmesi verimsizdir
  • Meta, sidecar proxy yaklaşımı yerine yönlendirmeyi doğrudan servisin üstlendiği bir yapıya geçti
• Meta'nın ServiceRouter mimarisi
  • Yönlendirme metadata'sı merkezi denetleyici tarafından üretilir, ancak her L7 router yönlendirme tablosunu kendisi oluşturur
  • Paxos tabanlı veritabanı (RIB, Routing Information Base) kullanılarak ölçeklenebilirlik sağlanır
    • Denetleyiciler sharding ile bölünerek yük dağıtılır ve belirli bir servise ait yönlendirme tabloları birden fazla denetleyici tarafından paralel hesaplanabilir
  • Dağıtım katmanı (Distribution Layer), binlerce RIB kopyasını kullanarak milyonlarca L7 router'dan gelen okuma isteklerini işler
  • Sonuç olarak her L7 router, merkezi denetleyicinin doğrudan müdahalesi olmadan bağımsız biçimde yapılandırılabilir
• ServiceRouter'ın ölçeklenebilirliği nasıl sağladığı
  1. Durumsuz (stateless) denetleyiciler benimsenmesi: Denetleyici belirli bir router'ı doğrudan yönetmez, yalnızca küresel yönlendirme bilgisini tutar
  2. Denetleyici sharding'i: Birden fazla denetleyici birbirinden bağımsız çalışır ve farklı servislerin yönlendirme bilgilerini paralel olarak işleyebilir
  3. Zorunlu olmayan özelliklerin kaldırılması: Tek tek L7 router yönetimi denetleyiciden çıkarılmış, her router'ın kendini yönetmesi sağlanmıştır
• Sonuçlar ve çıkarımlar
  • Merkezi denetleyici ile dağıtık data plane'i birleştiren mimari en iyi ölçeklenebilirliği sağlar
  • Gereksiz sidecar proxy'lerin kaldırılmasıyla operasyonel maliyet ve performans optimize edilir
  • Stratejik sharding ve durumsuz tasarım sayesinde milyonlarca servis yönlendirmesi etkili biçimde yönetilebilir

# [Gelecek Yönelimleri (Future Directions)]

• Meta’nın hiperscale altyapısı son derece karmaşık, ancak bu belgede temel teknik içgörüler özetlenerek sunuluyor
• Son olarak, hiperscale altyapının gelecekteki trendlerine dair öngörüler paylaşılıyor

AI (yapay zeka)

• AI iş yükleri artık veri merkezlerindeki en büyük paya sahip iş yükleri haline geldi
• 2030’dan önce veri merkezi elektrik tüketiminin yarısından fazlasının AI iş yükleri için kullanılmasının beklendiği belirtiliyor
• AI, yüksek performanslı ağlar ve yüksek kaynak tüketimi nedeniyle mevcut altyapı yapısını kökten değiştirme potansiyeline sahip
• Geçmişte hiperscale altyapı scale-out (Scaling-Out) yaklaşımıyla (düşük maliyetli sunucuların büyük ölçekte konuşlandırılması) gelişti, ancak
  gelecekteki AI kümelerinin scale-up (Scaling-Up) yaklaşımına (süper bilgisayar mimarisi) yönelmesi muhtemel
  • Örnek: RDMA (Remote Direct Memory Access) tabanlı Ethernet ağı kullanılarak büyük ölçekli makine öğrenimi (ML) eğitimi için optimizasyon
• Meta, PyTorch → ML modeli → AI çipi → ağ → veri merkezi → sunucu → depolama → güç ve soğutmaya kadar uzanan tam yığın ortak tasarımını (co-design) yürütüyor

Alana Özel Donanım (Domain-Specific Hardware)

• 2000’lerde donanım giderek daha standart hale gelmişti, ancak
  önümüzdeki dönemde AI eğitim/çıkarım, sanallaştırma, video kodlama, şifreleme, sıkıştırma, katmanlı bellek gibi çeşitli özel donanımların artması bekleniyor
• Hiperscale şirketleri, kitlesel üretim sayesinde özelleştirilmiş donanımı ekonomik biçimde tasarlayıp dağıtabilir
• Ancak donanım çeşitliliğindeki bu artış, yazılım yığınının karmaşıklığını artıracak ve heterojen ortamları yönetme konusunda yeni zorluklar doğuracak

Uç Veri Merkezleri (Edge Datacenters)

• Metaverse ve Nesnelerin İnterneti (IoT) uygulamalarındaki artış nedeniyle uç veri merkezlerinin genişlemesi bekleniyor
• Cloud Gaming, grafik işleme sürecini kullanıcının cihazında değil, uç veri merkezlerindeki GPU sunucularında gerçekleştiriyor ve
  25 ms’nin altında düşük ağ gecikmesi zorunlu
• Gerçek zamanlı yanıt vermenin kritik olduğu uygulamaların artmasıyla birlikte uç veri merkezlerinin sayısının ve ölçeğinin büyük ölçüde artması olası
• Bunun etkin biçimde işletilebilmesi için Global-DaaC kavramının (dünya çapındaki veri merkezlerini tek bir bilgisayar gibi işletme yaklaşımı) genişletilerek, geliştiricilerin karmaşık altyapı yönetimiyle uğraşmak zorunda kalmayacağı şekilde optimize edilmesi gerekiyor

Geliştirici Verimliliğinin Artırılması (Developer Productivity)

• Son 20 yılda otomasyon araçları, sistem yöneticilerinin verimliliğini büyük ölçüde artırarak bir yöneticinin sorumlu olduğu sunucu sayısında keskin bir artış sağladı
• Ancak yazılım geliştirme hâlâ emek yoğun bir alan ve verimlilik artışı görece yavaş ilerliyor
• Gelecekte iki faktör nedeniyle geliştirici verimliliğinin hızla artması bekleniyor:
  1. AI tabanlı kod üretimi ve hata ayıklama araçlarının gelişimi
  2. Alana özel, tamamen entegre serverless programlama paradigmalarının ortaya çıkışı
• Meta’nın FrontFaaS yaklaşımı, bu tür serverless programlamaya bir örnek ve
  ileride belirli sektörlere (ör. finans, sağlık vb.) optimize edilmiş yeni programlama paradigmalarının ortaya çıkması bekleniyor

Sonuç

• AI merkezli altyapı yenilikleri önümüzdeki 10 yılda hızla ilerleyecek
• Hiperscale şirketleri, kendi içgörülerini paylaşarak topluluğun tamamının daha hızlı ilerlemesine katkıda bulunmalı

[secret3056]

Şu PoP, BGP4 ya da TCP anycast sanırım; bunu bireysel olarak kullanmanın bir yolu yoktur herhalde..? hıçkırık

[pribess]

PoP'un BGP4 ya da TCP anycast olduğu şeklindeki ifadenin tam olarak ne anlama geldiğinden emin değilim, ancak soru kendi AS'nizi işletip işletmediğinizse evet, öyle.
Genelde tipik multi-region servisler, anycast DNS ile birlikte daha çok geolocation tabanlı dengeleme kullanır.
Evet, şu an için yok. Multi-region PoP'a ihtiyacınız varsa başka bir sağlayıcı kullanabilirsiniz.

[GN⁺]

Hacker News görüşleri

• Threads geliştirildikten sonra, altyapı ekibine lansmana hazırlanmak için yalnızca iki gün önceden haber verilmiş. Çoğu büyük kuruluş, onlarca karşılıklı bağımlı ekibi içeren bir proje planı yazmaya bile iki günden fazla zaman harcar. Ancak Meta’da farklı sahalara hızla savaş odaları kurulmuş ve altyapı ile ürün ekiplerinin sorunları gerçek zamanlı çözmesi sağlanmış. Uygulama, lansmandan sadece 5 gün sonra 100 milyon kullanıcıya ulaşarak tarihin en hızlı büyüyen uygulaması olmuş

• Ürünleri hızlı çıkarabilme yeteneğini korumaları etkileyici. Bürokrasinin artmamasını sağlamak ve hukuk ekibi ya da diğer departmanların onay kapıları oluşturmamasını engellemek için büyük çaba gerekiyor. Ya da savaş odaları aracılığıyla işleri hızla tamamlama becerisine ihtiyaç var

• FB’deyken altyapının ne kadar güçlü olduğunu bizzat deneyimledim. Ürün mühendisleri birkaç gün içinde büyük ölçekli projeler inşa ediyordu. Birden fazla ekipte teknik lider olarak çalıştım; burada adı geçen ekiplerden bazıları HBase ve ZippyDB ekipleri

• ZippyDB’nin ilk kez kamuya açık şekilde anılmasını görmek harika. Geliştirici verimliliğindeki artışın da anılması çok güzel. Her gün 10.000 servis deploy ediliyor ya da tüm commit’ler yapılıyor

• FB’den ayrıldıktan sonra buna benzer bir şey bulamadım. Bu yüzden startup’ımda ihtiyaç duyduğum altyapıyı kendim kuruyorum. Batteries Included

• Bu yorumlardaki yoğun alaycılık ve olumsuz tepki üzücü. Birçok insan Meta’dan hoşlanmıyor ama asıl makale bana göre hayranlık uyandırıcı. Modern dijital dünyayı ayakta tutan altyapının ne kadar geniş ve karmaşık olduğunu bilmiyordum. Bu makaleyi okuyup ölçeği görmek şaşırtıcı

• Şirket birçok açıdan kötü olabilir ama makalede anlatılan her şey bana göre hayranlık verici

• Ben sizin gibi bir mühendis değilim, bu yüzden bu makale sizin için eski haber olabilir ama ben yine de "vay be" demekten kendimi alamadım

• Bu makaleyi geçmişteki bilim kurgu yazarlarına gösterseniz, onların da hayran kalacağını düşünüyorum

• Hayranlık verici. Bütün bu şaşırtıcı ve etkileyici teknoloji ile dünyanın en iyi mühendisleri, sırf insanların gözüne daha fazla reklam sokmak için kullanılıyor. İç çekiş

• PHP web frontend’ini "serverless" ya da "function as a service" mimarisi olarak tanımlamaları ilginç. Sanırım bu biraz bakış açısı meselesi. Bu, çok sayıda endpoint’in deploy edildiği tek bir codebase’e sahip bir servis. Endpoint bakımcısının bakış açısından "serverless" olabilir ama tüm soyutlamalarda olduğu gibi burada da sızıntılar var

• Datacenter ortamlarında, sadelik ve yüksek kaliteli karar alma yeteneği nedeniyle merkezi denetleyicileri tercih ederim. Birçok durumda, merkezi bir control plane ile dağıtık bir data plane’i birleştiren hibrit yaklaşım en optimal olanı

• Bu yaklaşım, çok büyük sayıda sunucuya sahip organizasyonlarda yazılım tabanlı ağ oluşturma (service mesh) ve depolama (veritabanı işletimi) için en optimal tasarımlardan biri gibi görünüyor. IP ağlarının BGP’ye esas olarak dayanmadan aynı modeli izlemesi şaşırtıcı

• Yerel caching kullanılarak L7 router’ların yükünün azaltılması ve veritabanı sorgularının gecikmesinin iyileştirilmesi beklenir. İstemciler cache’i geçersiz kılıp makul bir timeout’tan sonra service mesh’e yeniden sorgu gönderebilir

• Hızla geliştirilen serverless fonksiyonların sürekli deployment ile birleşmesi ve herkesin tüm codebase üzerinde düzenleme yapabilmesi, distopik bir kâbus gibi geliyor. Hata ayıklama ve bug bulma için gereken logging miktarı aşırı düzeyde olurdu

• Serverless fonksiyon yazmak için Erlang kullanmak, BEAM’in sağlayabileceği büyük avantajların neredeyse tamamından kaçınmak gibi görünüyor

• Ürün mühendisleri kodlarını çoğunlukla PHP, Python ve Erlang ile stateless serverless fonksiyonlar olarak yazıyor. Bunun sadelik, üretkenlik ve iterasyon hızı açısından avantajları var

• Geliştirici üretkenliğini artırmak için Meta, sürekli deployment’ı evrensel olarak benimsemiş ve daha fazla geliştiricinin geleneksel servis kodu yerine serverless fonksiyon yazabilmesini sağlamış

• AI dışı bilgi işlem iş yükleri için yalnızca tek bir sunucu tipi sundukları ve bunun bir CPU ile aynı miktarda DRAM’e sahip olduğu söyleniyor (eskiden 64GB, şimdi 256GB). Bunun sektör genelinde mi yaygın olduğunu yoksa yalnızca Meta’ya mı özgü olduğunu merak ediyorum

• Bir görüntü CDN109’da cache’lenmemişse, kullanıcı talep ettiğinde CDN109 isteği yakındaki PoP’a iletir. PoP isteği veri merkezi bölgesindeki load balancer’a yollar ve load balancer görüntüyü depolama sisteminden alır

• 1MB’lık bir görüntü istenirken, yavaş bir bağlantıda 100ms gecikmeyle 1MB görüntüyü sunmak, birden çok round trip ve artan gecikmeler yaşamaktan daha hızlı olmaz mı?

• Bunun Meta’nın sistemleri üzerinden istendiğini, sonunda aynı veri merkezine gidildiğini ve FTL teknolojisi olmadığını varsayarsak

• Hyperscaler’larla yapılan açık karşılaştırma özellikle ilginç. Acaba bu, kendi public cloud’larını piyasaya sürmeye hazırlık mı? Meta’dan birinin bu konuda görüş bildirmesini isterdim