- "Up: Portable Microservices Ready for the Cloud"
- Uber’de 4.500 mühendis ve çok sayıda otomatik sistem, her hafta 4.500 stateless mikroservisi 4.000’den fazla kez dağıtıyor
- Bu servisler, dünya genelinde bağımsız çalışan yüzlerce ayrı ekip tarafından geliştiriliyor, dağıtılıyor ve işletiliyor
- Servisler boyut, yapı ve işlev açısından çeşitlilik gösteriyor; bazıları küçük ve iç işler için kullanılırken, bazıları büyük ve geniş ölçekli gerçek zamanlı hesaplamalar için kullanılıyor
Uber’in Stateless servis geçmişi
- 2014’te Uber, Python ile yazılmış bir monolith kullanıyor ve verileri tek bir PostgreSQL DB’de saklıyordu
- Büyüdükçe daha fazla mühendis işe aldı ve microservice mimarisine geçti
- Servis sayısı arttıkça Uber, kodu merkezi olarak büyük ölçekte dağıtmak için µDeploy adlı bir araç geliştirdi
- Tüm stateless servisleri containerize etti ve host yönetimi ile yerleştirmeyi soyutladı
- Altyapı grubunun, iş birimlerine ait mikroservislerden bağımsız olarak host filosunu yönetebilmesini sağladı
- Ancak servis yönetimi ve yerleştirme hâlâ manueldi
- Uber’in altyapısı, Zone gruplarının Region oluşturduğu bir modeli izliyor
- Bir region içindeki zone’lar arası gecikme yeterince düşük olduğu için, aynı region içindeki servisler arasında senkron iletişim verimli
- Her zone, Uber’in sahip olduğu makinelerden oluşan bir cluster ya da bir public cloud sağlayıcısına ait olabilir; ancak belirli bir zone her zaman tek bir sağlayıcıya aittir
- Genel olarak, tüm mikroservislerin aynı region içinde kaldıkları sürece gecikme sorunu olmadan diğer servisleri çağırabilmesi gerekir
- µDeploy, mühendislerin fiziksel yerleşimi hâlâ Availability Zone seviyesinde yönetmesini gerektirdiğinden, iş yüklerinin coğrafi yerleşimi sistem içinde merkezileştirilmemişti
- Yani servis mühendisleri, yalnızca servislerin on-premise zone’larda çalışıp çalışmayacağına değil, hangi belirli zone’da çalışacağına da karar vermek zorundaydı
- On-premise veri merkezleri işletilirken çip kıtlığı ve tedarik zinciri sorunları nedeniyle teslim süreleri uzadı
- 13 Şubat 2023’te Uber, tedarik zinciri sorunlarına maruziyetini azaltmak ve çeşitlenmek için Oracle ve Google ile ortaklık kurdu
- İşi destekleyen yüzlerce farklı servisi geliştiren binlerce Uber mühendisi açısından, "temel altyapıyı soyutlayabilen bir sistem" olmadan bu stratejiyi hayata geçirmek mümkün değildi
Uber’i buluta taşımaya hazırlanmak
- İşletmeyi çalışır durumda tutarken 4.500 stateless servisi buluta taşımak, muazzam düzeyde koordinasyon ve emek gerektiriyordu
- Bunun hataya açık olduğu ve manuel olarak koordine edilen bir çabayla yönetilmesinin neredeyse imkânsız olduğu en baştan belliydi
- Stateless mikroservislerin bakımını ve yönetimini büyük ölçekte yapmak için, servislerin insan müdahalesi olmadan merkezi bir dağıtım sistemi tarafından otomatik olarak yönetilebilecek şekilde dönüştürülmesi gerekiyordu
- Stateless’ı aşarak Portability’ye
- Region ve Zone modeline dayanarak "taşınabilirlik (Portability)" kavramını geliştirdiler
- Taşınabilirlik, bir servisin bir region içindeki tüm zone’larda çalışabilmesi ve insan müdahalesi olmadan altyapı platformu tarafından otomatik olarak yeni zone’lara taşınabilmesi anlamına geliyor
- Buna public cloud sağlayıcıları arasında taşınma olduğu gibi, on-premise zone’ların içine ve dışına taşınma da dahil
- Bazı servisler zone yapılandırmasına ve zone kaynak tercihlerine bağlı olduğundan, genelde taşınabilir değildi
- Buluta otomatik geçiş yapabilmek için tüm servislerin taşınabilir hâle getirilmesi gerekiyordu
Uber’i Portable hâle getirmek
- 2021 ve 2022 boyunca, tüm servislerin taşınabilir olduğundan emin olmak için şirket genelinde bir program yürüttüler
- Pek çok durumda, yalnızca kod incelemesinde string sabitleri ve dosya adı kullanımına bakmak bile taşınabilirlik ihlallerini tespit etmeye yetiyordu
- Basit vakalar için, belirli bir fiziksel konumda çalışacak şekilde hardcode edilmiş görünen kodu işaretleyen linter kuralları yazdılar
- Bir servisin gerçekten taşınabilir olup olmadığını test etmek için, servisi gerçekten insan müdahalesi olmadan farklı zone’lar arasında taşımak gerekiyordu
- Servis sahiplerinin servislerinin ilk taşınmasını başlatabilmesi için bir test araç seti oluşturuldu
- Güvenli ve kademeli kod rollout’u için mevcut araçlar temel alındığından, servis sahipleri istedikleri zaman dağıtımı orijinal zone’a geri alabiliyor ve sorun bulunursa düzeltebiliyordu
- Taşıma başarıyla tamamlandığında, servis ileride otomatik taşınacak şekilde işaretleniyordu
- Sonraki birkaç yıl boyunca bu süreç Uber’deki tüm servisler için tekrarlandı ve sonunda tüm servisler tamamen tamamlandı
- Çalışma tamamlandıktan sonra, servis mühendislerinin müdahalesi olmadan zone topolojisini değiştirmek mümkün oldu
- Servislerin zaman içinde de taşınabilir kalmasını sağlamak için, birkaç haftada bir tüm servisleri zone’lar arasında sürekli taşıyarak bu taşıma kabiliyetini düzenli olarak test ediyorlar
- Bu sayede regresyonları kolayca tespit edebiliyorlar ve mühendisler zamanla servislerin belirli bir zone yerleşimine bağlı olmadığını varsaymaya alıştı
Up: Multi-Cloud Multi-Tenant Federation Control Plane
- Şu ilk sistem hedeflerini belirlediler
- Mühendislerin altyapı sistemiyle etkileşime geçebileceği tek bir giriş noktası (Single Point of Entry) sunmak
- Sisteme doğrudan dağıtılan servisler için best practice’leri yönetip uygulayarak kod rollout’u sırasında yüksek güvenlik seviyesi sağlamak
- Servis yerleşimini availability zone düzeyinde otomatikleştirmek; yeni availability zone’lar kullanılabilir olduğunda dağıtımları bu yeni zone’lara kaydırarak, genel olarak Uber’in yüksek erişilebilirliğini desteklemek için yerleşimi merkezi olarak koordine etmek
- Zahmetli altyapı seviyesi migration’ları otomatikleştirerek servis mühendislerinin migration sürecine dahil olmasını gereksiz kılmak
- Yüksek seviye mimari
- Experience Layer:
- Mühendislerin sistemle etkileşime geçtiği çeşitli yolları uygular
- UI, Continuous Delivery ve sistemi sağlıklı durumda tutan robotlar gibi bileşenleri içerir
- İş yüklerini daha az kullanılan cluster ve zone’lara sürekli taşıyan Balancer
- Her iş yükü için kapasite tahsisini sürekli optimize eden Auto Scaler
- Platform Layer:
- Experience katmanının servislerle etkileşime geçmek için kullandığı soyutlamaları uygular
- Servis operasyonlarının kavramsal modelini oluşturan servis ve servis ortamı soyutlamalarını ve servis seviyesi API’yi içerir
- Platform katmanında servis kısıtları, gerçek servis yerleşiminin istenen özelliklerini tanımlayan yüksek seviyeli hedef durum olarak ifade edilir
- Buna, çalıştırılacak makinelerin performansına ve region bazında servisler için toplam hesaplama kapasitesine ilişkin kısıtlar dahil olabilir
- Federation Layer:
- Compute cluster’larıyla entegrasyonu uygular
- Üst katmanların kullandığı region ve zone soyutlamalarını hayata geçirmek için tüm cluster’ları işlevlerine ve fiziksel yerleşimlerine göre düzenler
- Platformdan gelen yüksek seviyeli servis hedef durumunu alır ve bunu zone ile cluster yerleşimine dönüştürür; bu dönüşüm, hedef durum kısıtlarına ve cluster’ların gerçek durumuna göre yapılır; buna mevcut kullanılabilir kapasite ile cluster ve yardımcı kısıtları karşılayabilen cluster’lar dahildir
- Bu dönüşümün sonucu zaman içinde değişebilir ve daha sonra farklı zone ve cluster yerleşimleri daha tercih edilir hâle gelebilir
- Balancer’ın her çağrısı ve experience katmanında başlatılan diğer işlemler nedeniyle bu yerleşim yeniden hesaplanıp değiştirilebilir
- Sistemin güvenli kalmasını ve servislerin sağlıklı durumda olmasını sağlamak için değişiklik yönetimi bileşeni, servis sağlığını izleyen tüm sistemlerle entegrasyon üzerinden global durumu küçük ve kademeli adımlarla değiştiren bir rollout akışı uygular
- Rollout süreci, sistem genelinde canarying ve sağlık sinyali izlemeyi içerir; sorun bulunursa sistem, servisi değişiklik başlamadan önceki yapılandırma ve yerleşime hızla rollback eder
- Regions
- Region’lar gerçek cluster instance’larını içerir
- Peloton ve Kubernetes® cluster’larını kapsar
- Bunlar Up’ın kendisinin dışındadır ancak gerçek kapasite yerleşiminin hedefidir ve fiziksel host’lar üzerindeki container yerleşimini yönetir
Etki
- Up üzerindeki çalışmaya 2018’de başladılar, 2019 başında çalışan bir prototip sundular ve 2020 ortasında platformu resmen kullanıma aldılar
- O zamandan beri Uber’in tüm iş kollarında 4.000’den fazla servisi eski dağıtım platformundan Up’a taşıdılar
- Bu migration’ın büyük bölümü otomatikleştirildiği için ekip en ileri kullanım senaryolarına odaklanabildi ve diğer ekiplerin geçişlerini de destekleyebildi
- Bu dönemde, platformun kararlılığı en yüksek öncelik olarak ele alındı ve her gün milyonlarca kullanıcının Uber sistemlerini kullandığı bir ortamda iş güvenilir biçimde işletildi
- Yaklaşık 2.000.000 compute core’un yeni platforma taşındığı bu toplam migration yaklaşık 2 yıla yayıldı ve 2022’de başarıyla tamamlandı
- Bu migration sayesinde auto scaling ve verimlilik çalışmalarıyla işletmeye onlarca milyon dolarlık ek kapasite geri kazandırıldı
- Manuel servis güncellemeleri, yeni zone’ların kurulup doldurulması ve Uber’in karmaşık altyapı ortamında gezinmeyi öğrenmek için harcanan on binlerce saatlik mühendislik zamanından tasarruf edilerek ciddi parasal maliyetler azaltıldı
Sırada ne var
- µDeploy’den Up’a migration tamamlandıktan sonra ekip artık, tüm servis filosuna merkezi ve otomatik bir şekilde uygulanabilecek çözümler ve bu yeteneklerin etrafında şekillenen kullanıcı deneyimi oluşturmaya odaklanabiliyor
- Bulut migration’ı
- Uber, filosunun önemli bir bölümünü buluta taşıyor
- Büyük ölçekli otomasyon ve Up’ın sunduğu soyutlama katmanı sayesinde servis ekipleri, bu geçiş için gerekli altyapı ayrıntılarından büyük ölçüde ayrıştırılabiliyor
- Otomatik Continuous Delivery
- Amaç, kod production’a dağıtılmadan önce çeşitli kontroller ve testler yapan otomatik pipeline’lar kullanarak production’a kadar olan kod dağıtımını tamamen otomatikleştirmek
- Ekibin 2023’te odaklanmayı planladığı özel alanlardan biri, servisleri "güncel" tutarak production’da çalışan tüm kodun en güncel güvenlik ve kütüphane güncellemelerine sahip olmasını sağlamak
- Dağıtım güvenliği (Safety)
- Mevcut veriler, gözlemlenen olayların önemli bir kısmının kod ve yapılandırma değişiklikleriyle ilişkili olduğunu gösteriyor
- Production öncesi testleri çalıştırmak ya da kademeli rollout politikaları ayarlamak gibi servis yaşam döngüsünün manuel yönlerini otomatikleştirerek, gerçekten production’a ulaşan hata oranını ciddi biçimde azaltmayı hedefliyorlar
- Platform
- Uber’in tüm stateless servis filosunu tek bir şemsiye platform altında toplamak, altyapı platform ürünleri arasındaki bağımlılıkları ve etkileşimleri daha net modellemeyi mümkün kılıyor
- Bu, yalnızca kod içinde birleşik bir model sunmakla kalmıyor, aynı zamanda mühendislik organizasyonunun geri kalanına da tamamen entegre bir kullanıcı deneyimi sağlıyor
- Tüm altyapıyı tek bir yerden gözlemleyip işletmek ekibin bir sonraki büyük hedefi
Sonuç
- Up platformunu kurma çabası, artık tüm stateless servislerin aynı best practice’ler ve otomasyonla kademeli biçimde dağıtılıyor olması açısından önemli bir kültürel değişimi temsil ediyor
- Rollout politikalarını değiştirmek ya da geniş ölçekli kütüphane rollout’ları için otomasyon kurmak gibi, eskiden aylar süren işler artık merkezi şekilde yapılabiliyor
- Uber mühendislerinin altyapı kaygıları olmadan yalnızca koda odaklanabilmesi vizyonunu gerçekleştirmek için, Up paydaşları ve servis sahipleriyle çalışmayı sürdürmeyi umuyorlar
Henüz yorum yok.