Stripe'ın Grafik Arama ve Durum Makineleriyle Otomatik Düzeltme Sistemi
Stripe'ın Grafik Arama ve Durum Makineleriyle Otomatik Düzeltme Sistemi
Gece yarısı, bir mühendis için korkunç bir sahne: bir MongoDB shard’ı, 2025 yılında 1.9 trilyon dolarlık ödeme işlemi yapan küresel veritabanı flotunun bir parçası, bozulmuş bir duruma girmiş. İki düğüm kapalı, üçüncüsü ise yanlış yapılandırılmış bir oy sayısına bağlı olarak bir dizin oluşturma işlemini engelliyor. Bu shard’ın sağlığına kavuşması için mühendisin 15 dakika boyunca dikkatli bir şekilde sırayla yapması gereken manuel işlemler, ardından her bir işlemi tetikleyip izlemesi için 3 saate kadar sürebilirdi. Bu tip senaryolar, Stripe’ın 40’tan fazla farklı shard düzeniyle çalışan, hem maliyet optimize edilmiş hem de afet kurtarma tasarımı olan küresel MongoDB altyapısında yılda yüzlerce kez yaşanıyordu.
Durum Makineleriyle Otomatik Düzeltme: Yeni Bir Yaklaşım
Stripe’ın ilk otomatik düzeltme sistemi (V1), tek adımlı, hard-coded bir durum makinesi olarak çalışıyordu. Her bir sorunu çözmek için özel bir eklenti (örneğin "oyları düzelt", "önceliği düzelt", "kapalı düğümü yeniden başlat") vardı. Bu eklentiler, önceliklerine göre ve bir doğrulama döngüsünde belirli bir sırayla çalışıyordu. Basit durumlar için (örneğin tek bir düğüm kapalıysa) sistem iyi çalışıyordu. Ancak bazı temel sınırlamalar vardı:
- Sorunlar arasında gizli bağımlılıklar vardı. Örneğin "oyları düzelt" ve "önceliği düzelt" eklentilerinin hiç düğümün kapalı olmaması gerektiği, ancak "düğüm kapalı" eklentisinden daha yüksek öncelikte olduğu için döngüsel bağımlılıklar oluşuyordu. Bu durumlar genellikle manuel müdahale ile çözülüyor.
- Çoklu hata durumlarında kör noktalar ortaya çıkıyordu. Birden fazla kapalı düğümle birlikte oy veya öncelik yapılandırması hataları birleştiğinde, sırayla tek bir sorunu çözen yaklaşım geçersiz bir sıralama bulamıyordu. Sistem tüm seçenekleri tüketip işlemi iptal edip, bir operatöre siren çalıyordu.
- Yapılandırmaya bağlı sıkı bağlanma her yerde vardı. Her eklenti, özel bir yapılandırmaya göre güvenlik denetimleri içeriyordu. Bu yüzden yeni bir yapılandırmayı V1 düzeltme platformuna entegre etmek için her eklenti ve iş akışının mantığı gözden geçirilmesi gerekiyordu. Bu süreç her yeni yapılandırmaya yaklaşık bir hafta sürüyordu.
- İşlem iptalleri, shard’ları yarım kalmış durumlara bırakıyordu. İptal edilmiş bir işlem, V1’in önceden tahmin ettiği bir durum olmayan bir duruma getiriyordu. Bu orphan durumlar genellikle manuel temizlik gerektiriyordu.
Bu sınırlamalar, 6 ay içinde 124 kez operatöre siren çalmasına ve 32 kez de başka sağlık sorunlarıyla birlikte tek düğüm kapalı durumlarına neden oldu. Kritik işlemler olan dizin oluşturma ve planlı bakım süreçleri ortalama bir saatlik blokajla karşı karşıya kalıyordu.
Altyapıyı Graf Olarak Görmek: Durum Makinesi ve Graf Arama
Bu kritik sorunların çözümü için, Stripe ekibi soruyu değiştirdi: "Şu anda hangi sorunun en önemli olduğunu sorgulamak yerine, şu anki durumu sağlıklı duruma getiren ve güvenlik invariantlarını asla ihlal etmeyen bir dizi operasyon nedir?" Bu şekilde yaklaşım, bir graf arama problemi olarak görüldü.
MongoDB’de küme topolojisi, düğümlere atanan rollerle kontrol edilir: oy hakkı lider seçimlerine ve quorum yazılara katılmaya olanak tanır, öncelik düzeyleri bir düğümün birincil olma niteliğini kontrol eder ve gizli durum, bir düğümün istemci okuma yolundan çıkmasını sağlar. Bu per-düğüm özelliklerini, shard seviyesindeki oplog boyutları, bölgesel dağılım ve quorum durumu gibi verilerle birlikte bir shard’ın durumunu bir grafın düğümü olarak temsil ederiz.
Grafiğin kenarları, temel altyapı operasyonlarını temsil eder: bir oy veya önceliğin eklenmesi, düğümün gizlenmesi veya gizlenmesinin kaldırılması, düğümün yeniden oluşturulması veya oplog boyutunun değiştirilmesi gibi adımlar. Bu, shard’ın sağlıklı duruma dönüşmesi için gerekli olan adımların bir parçasıdır.
En Kısa Yolu Bulmak: Genişlik Öncelikli Arama ve Dijkstra Algoritması
Başlangıç durumu, shard’ın mevcut gerçekliğidir. Hedef durum ise, sağlıklı yapılandırmanın kaynak kaynağıdır (SOT). Geçersiz durumlar, güvenlik invariantlarını ihlal eder: örneğin, düğüm sayısı çift olursa, yazılara erişim riski artar; veya bir düğüm, öncelik=1 ve oy=0 gibi geçersiz bir durumda kalırsa.
Durum uzayı tanımlandıktan sonra, başlangıç durumundan hedef duruma giden en kısa işlem sırasını bulmak için genişlik öncelikli arama (BFS) kullanılır. Algoritma her adımda sonraki durumları üretir, geçersiz olanları atar ve ilk olarak hedefe ulaşan yolu döndürür. BFS, seviye bazında gezinerek çalıştığı için, ilk bulunan çözümün en az sayıda işlemi kullanarak bir çözüm olduğunu garanti eder.
Örneğin, sağlıklı bir shard’da üç şey birden bozulursa: bir veri düğümü kapalı, yedek düğüm kapalı ve bir veri düğümü oy ve önceliği kaybeder. V1 sistemi tamamen donmuş kalır: "oyları düzelt" eklentisi kapalı düğüm olmamasını gerektirirken, "düğüm yeniden başlat" eklentisi oyların düzgün olması gerektiğini söyler. Ancak durum makinesi, tüm geçerli sıralamaları keşfeder:
- Başlangıç Durumu → [Yedek düğümü yeniden başlat] → [Oy+önceliği düzelt] → [Veri düğümünü yeniden başlat] → Sağlıklı Durum
- Başlangıç Durumu → [Oy+önceliği düzelt] → [Veri düğümünü yeniden başlat] → [Yedek düğümü yeniden başlat] → Sağlıklı Durum
Bu yaklaşım, sistemin her durumda geçerli bir düzeltme yolunu bulmasına olanak sağlar.
Sonuç: Daha Akıllı, Daha Esnek ve Daha Güvenilir
Grafik arama ve durum makineleriyle yapılan bu dönüşüm, Stripe’ın küresel veritabanı flotunda otomatik düzeltmeyi tamamen yeniden tanımlamasına yol açtı. Artık her yeni yapılandırmaya özel bir eklenti yazmak gerekmiyor. Sistem, her durumda geçerli bir düzeltme yolu bulabiliyor ve her bir sorunun çözümü için en az işlemle bir yol üretiyor.
Bu değişikliklerle, Stripe, siren çalma sayısında %30 azalma (yılda yaklaşık 200 siren azalması) ve yılda 12 gün daha az shard’ın bozuk durumda kalması gibi önemli kazanımlar elde etti. Ayrıca, yeni shard düzenleri için ekstra çalışma gerekmiyor. Sistem, her durumda geçerli bir düzeltme yolu bulabildiği için, karmaşık ve değişen küresel altyapılarla daha iyi başa çıkıyor.
Bir altyapı, yalnızca bir sistem olarak değil, aynı zamanda bir graf olarak değerlendirildiğinde, otomatik düzeltme sistemi, sadece bir otomasyon değil, aynı zamanda bir akıl yürütme motoru haline geliyor. Ve bu, küresel ölçekli sistemlerde güvenilirliği ve esnekliği aynı anda artıran bir devrimdir.