Monzo 2.800 mikroserviste geçişleri nasıl yürütüyor

• MSA ile 2.800'den fazla hizmet çalıştırıyor ve bundan büyük değer elde ediyorlar
• Ancak bu mimarinin zorlukları da var. Bunlardan biri, tüm hizmetlerde kütüphane değişiklikleri yapmak
• Genellikle en güncel kütüphaneler, tutarlı kütüphane sürümleri ve düşük yükseltme eforu arasından yalnızca ikisini seçmek gerekir

Merkezi geçiş stratejisi

• Monzo, merkezi olarak yürütülen bir geçiş yaklaşımıyla yukarıdaki üç özelliği de yüksek düzeyde sağlayabileceğine inanıyor
• Geçiş sorumluluğunu hizmet sahiplerine bırakmak yerine, tek bir ekibin geçişi yönetmesini tercih ediyor
• Bu sayede yüksek koordinasyon yükünden (yavaş geçişlere yol açar) ve proje durması riskinden (tutarsızlığa yol açar) kaçınabiliyorlar
• Tek bir ekibin geçişi makul süre içinde tamamlayabilmesi için büyük ölçüde şunlara dayanıyorlar:
  • Temel teknoloji seçimleri (ör. yüksek düzeyde tutarlılık, monorepo kullanımı)
  • Otomasyonun geniş çapta kullanımı (ör. toplu hizmet dağıtım araçları, otomatik rollback kontrolleri)

OpenTracing SDK'den OpenTelemetry SDK'ye geçiş

• Monzo yakın zamanda OpenTracing SDK'den OpenTelemetry SDK'ye geçiş projesiyle bu stratejiyi uygulamaya koydu
• Tüm hizmetler izleme verilerini Jaeger'a aktarıyor. Daha önce bunu OpenTracing ve Jaeger Go SDK aracılığıyla yapıyorlardı
• Bu kütüphaneler artık kullanım dışı ve topluluk bunun yerine OpenTelemetry etrafında birleşmiş durumda
• İzleme sistemini iyileştirecek zemini hazırlamak için önce kullanım dışı kütüphaneleri OpenTelemetry SDK ile değiştirmek istediler

Geçiş ilkeleri

• Hizmet sahipleri açısından şeffaf merkezi geçiş. Koordinasyon yükünü en aza indirmek ve geçişin durma riskini azaltmak için tek bir ekip tarafından merkezi olarak yürütülebilecek stratejileri tercih ediyorlar
• Kesinti olmaması. Geçişlerin çoğu bankanın temel işlevleri açısından kritik hizmetleri kapsadığı için kesinti kabul edilemez
• Kademeli roll forward, hızlı rollback. Büyük değişikliklerde, sorun çıkması halinde etki alanını küçültmek için kademeli roll forward yapılabilmeli. Ancak gerekirse her şey hızla rollback edilebilmeli
• Otomasyonda 80/20 kuralı. Büyük ölçekli geçişlerde değişikliklerin büyük kısmı genellikle ortak bir şablona uyar. Bu değişiklikler kolayca otomatikleştirilebilir. Daha sıra dışı kullanım durumlarında otomasyonun getirisi azalır ve bunları vaka bazında çözmek daha verimlidir. Kötü sürprizlerden kaçınmak ve ilerlemeyi izlemeyi kolaylaştırmak için gerekli değişiklikleri önceden bu iki kategoriye ayırmak faydalıdır

Geçiş stratejisi

• Monzo'da sistematik olarak uyguladıkları bir dizi geçiş adımı var

1. Planlama ve hizalanma

• Geçişler önemli riskler taşır. Yalnızca çok sayıda hizmeti etkilemekle kalmaz, geçişi yürüten ekibin geçiş yaptığı hizmetler hakkında çok az ya da hiç bağlamı olmayabilir
• Hizmetlerde tutarlılığı hedefleseler de her zaman istisnalar vardır ve bu sürprizleri mümkün olduğunca erken yakalamak isterler
• Bu nedenle planlama sürecinin şeffaf olması ve tüm mühendislerin katkı sunma fırsatı bulması çok önemlidir
• Bunun için iki süreçleri var:
  • Proposal: Monzo'da bunlardan çok yazılıyor. Esasen her şey sonunda şirket içindeki herkesin görüş bildirebildiği tek bir Slack kanalında paylaşılıyor
  • Mimari inceleme: En büyük değişikliklerde, daha tartışmalı veya riskli belirli alanlara derinlemesine girilen eşzamanlı mimari inceleme toplantıları yapıyorlar. Amaç onay veya imza almak değil; tasarımı anlamlı biçimde ilerletip projeyi hızlandırmak

2. Eski kütüphaneyi sarmalama

• Yeni kütüphaneyi kurup hizmet kodunu onu çağıracak şekilde güncellemek yerine önce eski kütüphaneyi sarmalamaya karar verdiler

  1. Temel kütüphaneye yapılan çağrıları yakalayıp dinamik yapılandırmaya göre hangi implementasyonun kullanılacağına karar verebilirler. Bu sayede tüm hizmetleri yeniden dağıtmaya gerek kalmadan kolayca roll forward ve rollback yapabilirler
  2. Yeni kütüphanede ciddi ölçüde farklı türler/fonksiyonlar vardı. Tüm çağrı noktalarını güncellemek ciddi efor gerektiriyordu ve bazı durumlarda yeni API'nin faydası sınırlıydı. Eski kütüphaneyi sarmalayarak bu gibi durumlarda eski kütüphaneye benzer bir arayüz koruyup çağrı noktalarını daha kolay güncelleyebildiler

• Kütüphane sarmalamanın başka faydaları da var:

  • Kendi telemetri kütüphaneleriyle enstrümantasyon yapabiliyorlar
  • Daha görüş sahibi bir arayüz sunabiliyorlar

3. Çağrı noktalarını güncelleme

• Bu kütüphanenin kullanımı ortak bir desene uyuyordu:

  • Kod tabanı genelinde birçok kez referans verilen az sayıda fonksiyon/tür vardı
  • Bunun ardından yalnızca birkaç yerde referans verilen fonksiyon/türlerden oluşan uzun bir kuyruk geliyordu

• Bu iki durumu farklı şekilde ele aldılar:

  • Birçok yerde referans verilen az sayıdaki fonksiyon/tür için mümkün olduğunca otomasyon kullandılar. Bu kütüphanede otomatik refactoring için ağırlıklı olarak gopls ve gorename kullandılar
  • Yalnızca birkaç yerde referans verilen uzun kuyruktaki fonksiyon/türleri ele almak için manuel, vaka bazlı bir yaklaşım benimsediler. Bazı durumlarda bunları elle taşıdılar. Diğer durumlarda ise aynı işin daha standart API'lerle yapılabildiğini fark edip ona geçtiler. Bu da artık özel durum olarak ele alınmalarına gerek bırakmadı ve wrapper kütüphanesinin API'sini küçük ve görüş sahibi tutma gibi ek bir fayda sağladı

• Eski kütüphaneyi sarmalamanın yanı sıra, eski kütüphaneye yeni bağımlılıkların eklenmesini de engellediler. Bunu semgrep kullanarak CI kontrolü ekleyip yaptılar

4. Yeni kütüphaneyi sarmalama

• Eski kütüphane sarıldıktan sonra wrapper kütüphanesinin arkasına yeni kütüphaneyi eklemeye başlayabildiler
• Başlangıçta yeni implementasyon yapılandırma üzerinden devre dışıydı. Bu, davranış değişikliğinin henüz beklenmediği ve master branch'e değişiklikleri kademeli olarak birleştirmeye devam edebildikleri anlamına geliyordu

5. Toplu hizmet dağıtımı

• Yeni implementasyonu etkinleştirmeye başlamadan önce çalışan tüm hizmetlerin yeni implementasyonu destekleyebildiğinden emin olmaları gerekiyordu
• Başka tür kütüphane değişikliklerinde yeni işlevi içeren hizmetlerin yalnızca bir alt kümesi aynı anda dağıtılabilir. Ancak izleme kütüphanesinde, bir hizmet yeni kütüphaneyi kullanacak şekilde taşındıysa, onun (geçiş sürecinde) çağırabileceği tüm hizmetlerin de yeni işlevi desteklemesi gerekir
• Çok sayıda hizmet dağıtımını yönetmek için, tüm hizmetlere kütüphane değişikliklerini asenkron toplu işler olarak itebilen bir toplu dağıtım aracı geliştirdiler
• Olası hatalı dağıtımların etkisini azaltmak için:
  • Otomatik rollback kontrolleri kullanıyorlar
  • Önce en az kritik hizmetleri dağıtıyorlar. Tüm hizmetleri bir "tier" etiketiyle işaretlediler ve toplu dağıtım aracı bunu en düşük riskli dağıtımlara öncelik vermek için kullanıyor

6. Yapılandırma ile rollout kontrolü

• Toplu dağıtım aracının sorunu nispeten yavaş olması. Gerçekten kaçınmak istedikleri şey, tüm hizmetleri dağıttıktan sonra yeni kütüphanede sorun olduğunu fark etmek ve hızlı rollback yapamamaktır
• Bu yüzden yeni implementasyonu açık şekilde dağıtmak yerine, onu yapılandırma sistemi üzerinden etkinleştirebilecekleri özelliği dağıttılar
• Normal dağıtıma kıyasla burada yapılandırma sistemi kullanmanın avantajı hızdır. Tüm hizmetler yapılandırmayı her 60 saniyede bir yenilediği için gerekirse hızla rollback yapılabilir
• Ayrıca yeni implementasyonun ne zaman kullanılacağı konusunda çok daha fazla kontrol sağlar. Örneğin yalnızca belirli bir kullanıcı kümesi veya isteklerin rastgele bir yüzdesi için etkinleştirilebilir
• Bu durumda yalnızca ekibin sahip olduğu API endpoint'leri için rollout yapmayı seçtiler ve bunu kademeli artan olasılıkla etkinleştirdiler

7. Temizlik

• Yeni implementasyona tamamen geçildiğinde, wrapper kütüphanesinden eski implementasyonu kaldırma işini tatmin edici bir son adım olarak yapıyorlar

Geçiş süper gücü

• Bu tür merkezi geçişler, Monzo'nun yaptığı temel teknoloji seçimleri ve yatırım yapmayı sürdürdüğü araçlar sayesinde mümkün oldu
• Tutarlı teknoloji: Tüm hizmetler Go ile yazılmıştı ve eski kütüphanenin aynı sürümünü kullanıyordu. Bu, değişikliklerin otomasyonunu çok daha kolay hale getiriyor. Örneğin dil başına bir araç yerine tek bir refactoring aracı yeterli oluyor
• Monorepo: Tüm hizmet kodunun tek bir monorepo içinde olması, büyük ölçekli refactoring işlemlerinin tek bir commit içinde çok daha kolay yapılmasını sağlıyor. Ayrıca belirli bir kütüphanenin kullanımını CI kontrolleriyle küresel olarak dayatmaya imkân vererek tutarlılığı korumaya yardımcı oluyor
• Toplu dağıtım: Dağıtılabilir bileşen sayısı çok olduğunda, kütüphane değişikliklerini yaymak için otomatik bir dağıtım süreci gerekiyor
• Hafif ve esnek yapılandırma hizmeti: Dağıtım süreci güvenli ama yavaş (dağıtım başına birkaç dakika). Yeni özellikleri çok sayıda hizmette hızlı ve anlık olarak açıp kapatmak için daha hafif ve esnek bir sürece ihtiyaç var

Sonuç

• Geçmişte geçişleri dağıtmaya çalıştılar ancak bu kaçınılmaz olarak tamamlanmamış geçişlere ve yüksek koordinasyon eforuna yol açtı
• Monzo'nun merkezi geçişi güçlü biçimde tercih etmesinin nedeni bu. Tek bir ekip nispeten yüksek maliyet üstleniyor ama genel olarak daha az efor harcanıyor ve tutarlılığı koruma olasılığı ciddi biçimde artıyor
• Bu yaklaşım olumlu bir döngü yaratıyor:
  • Geçişi yürüten ekip, geçişi otomatikleştirecek araçlara yatırım yapmak için güçlü bir motivasyona sahip oluyor
  • Aynı zamanda teknik tutarlılığı da koruyorlar (bu da araç geliştirmeyi kolaylaştırıyor)
  • Ancak otomasyon düzeyi konusunda hâlâ pragmatikler; 80/20 kuralını uyguluyorlar
• Monzo'nun yatırım yapmayı sürdürdüğü araçlara ek olarak, bu yaklaşım yalnızca başlangıçta yaptıkları bazı temel teknoloji seçimleri sayesinde mümkün oldu
  • Özellikle daha görüş sahibi ve sınırlı bir teknoloji seti kullanmaları sayesinde