Monolitikten Mikroservise: 5 Ayda Yaşadıklarımız

Önce dur: mikroservis gerçekten gerekiyor mu?

Bu soruyu bize kimse sormadı; biz de kendimize sormadık. O günlerde mikroservis “modern olan” şeydi. Şimdi sorulsa cevabım şu tabloyla başlar:

Kural şu: mikroservis bir performans aracı değil, bir bağımsızlık aracı. Bağımsız çıkması gereken ekipler yoksa aldığın şey hız değil, ağ üstünden dağıtılmış bir monolit. Bizde son üç satır gerçekten geçerliydi; karar doğruydu. Yapılış şekli değildi.

Neden başladık: bir deploy treni hikâyesi

Sekiz yaşında bir monolit, dört ekip, haftada bir deploy. Sayılar kötüydü ama asıl sorun sayılar değildi:

• Deploy 45 dakika, geri alma 52 dakika. Bu yüzden haftada bir; daha sık çıkmayı kimse göze alamıyordu.
• Haftalık pakette ortalama 60–80 değişiklik. Bir şey bozulunca hangisi olduğunu bulmak saatler alıyordu.
• Ödeme ekibinin acil düzeltmesi, rapor ekibinin yarım kalmış işini bekliyordu. Ya da tersi.
• Test ortamı tek. Bir ekip test ederken diğeri bekliyordu.

Yani problem “sistem yavaş” değil, “dört ekip birbirine kelepçeli” idi.

İlk gün verdiğimiz ikinci karar da buradan çıktı: servisler birbirini çağırmayacak, olay yayınlayacak. Broker olarak Kafka’yı seçtik. HTTP ile çağıran servis, çağırdığının o an ayakta olmasına bağlıdır; olay dinleyen servis değildir. Ekipler deploy’da birbirinden bağımsız olacaksa çalışma zamanında da bağımsız olmalıydı. Karar doğruydu. Bedelini bilmiyorduk.

Adım adım: yanlıştan doğruya

Deneme 1 — katmana göre böldük (bozuk)

web-api  --(bekler)-->  is-kurallari-servisi  --(bekler)-->  veri-erisim-servisi  -->  DB

# "Olayla konusacaklar" demistik.
# Katmanlar olayla konusamaz: is kurali, veri erisiminin CEVABINI beklemek zorunda.

Deneme 2 — alana göre böldük, veritabanını bölmedik (dağıtık monolit)

siparis-servisi  --> yayinla(SiparisDegisti { id: 4711 })
kargo-servisi    --> dinle, sonra:  SELECT * FROM siparis WHERE id = 4711   <- ortak tablo
rapor-servisi    --> dinle, sonra:  SELECT * FROM siparis WHERE id = 4711   <- ortak tablo

Kimse hata yapmamıştı. Müşteri ekibi kendi tablosunu değiştirmişti. Ama o tablo kendinin değildi — dört servisin ortak sözleşmesiydi ve olay tabanlı görünen sistem bunu gizliyordu. Öğrendiğimiz cümle: servis sınırı kodda değil, veride çizilir. Olay, tüketicinin ihtiyacı olan veriyi taşımalı; “git kendin bak” diyen olay, olay değil, tabloya giden bir davetiye.

Deneme 3 — çekirdekten başladık (yarım kaldı)

Deneme 4 — kenardan, kademeli (doğru)

# monolit icinde, bildirim kodu:
if hash(siparisId) % 100 < BILDIRIM_SERVISI_YUZDESI:   # 5 -> 25 -> 100
    pass                       # yeni servis SiparisOlustu olayini dinliyor, o gonderecek
else:
    eskiBildirimGonder()       # monolitteki kod, henuz yerinde

Sıra şuydu ve bir daha olsa yine bu olurdu: en az bağımlı olandan en çok bağımlı olana. Çekirdek en sona kalır, çünkü çekirdek ancak etrafı boşaldığında hareket edebilir.

Birinci bedel: aynı mesaj iki kez gelir

İkinci ayın başında bir Salı sabahı müşteri hizmetlerinden mesaj: “Aynı siparişe iki kargo çıkmış, müşteriye iki kutu gitmiş.” Tek sipariş değil; bir haftada 17 çift kargo. Kampanya tarafında daha sessiz bir şey: 300’den fazla müşteriye puan iki kez yüklenmiş, kimse fark etmemiş — şikâyet eden yok.

Sebep bir hata değil, sözleşmenin kendisi. Kargo servisi olayı aldı, etiketi oluşturdu, veritabanına yazdı ve broker’a “işledim” demeden önce deploy yedi. Broker cevap alamayınca aynı olayı yeniden teslim etti; yeni kopya onu ilk kez görüyormuş gibi işledi. Kullandığımız broker tam olarak vaat ettiği şeyi yapmıştı: en az bir kez teslim. Monolitte bu problem yoktu, çünkü fonksiyon çağrısı “yeniden teslim” edilmez.

onSiparisOlustu(olay):
    etiket = kargo.olustur(olay.siparisId)
    db.kaydet(etiket)
    ack()   # <- buraya gelemeden olurse
            #    olay yeniden gelir,
            #    etiket ikinci kez cikar

onSiparisOlustu(olay):
    BEGIN
      INSERT INTO islenen_olaylar (olay_id)
        VALUES (olay.id)   -- UNIQUE:
                           -- ikinci gelis burada patlar
      etiket = kargo.olustur(olay.siparisId,
                             header "Idempotency-Key: " + olay.id)   -- dis sistem: ayni anahtar,
                                                                    -- ayni etiket, yeni etiket yok
      db.kaydet(etiket)
    COMMIT
    ack()

    # unique ihlali -> zaten islenmis, sessizce ack, gec

Anahtar üç şey. Olayın kimliğini üretici koyuyor, tüketici üretmiyor. “Gördüm” kaydı, işin veritabanı tarafıyla aynı işlemde; ayrı işlemde olursa aradaki çökme yine iki etiket üretir. Ve en geç fark ettiğimiz üçüncüsü: dış sistem çağrısı transaction’ın içinde durur ama ona dahil değildir.

İlk dedup’tan sonra çift kargo haftada 17’den 2’ye indi; sıfıra inmedi. Kalan ikisi şuydu: INSERT geçti, kargo firmasının API’si etiketi kesti, COMMIT’ten önce süreç öldü. Veritabanı geri alındı — dedup kaydı da onunla birlikte — ama kargo firması geri almadı. Olay tekrar geldi, API bir daha çağrıldı, ikinci etiket. Çözüm dış sistemin de idempotent olması: kargo API’sine olay kimliğini idempotency anahtarı olarak geçtik; aynı anahtarla gelen ikinci istek aynı etiketi döndürüyor, yenisini kesmiyor. Dış sistem bunu desteklemiyorsa iş ikiye bölünür: önce “istek gönderiliyor” kaydını commit et, sonra çağır, sonra sonucu yaz — güvenli yeniden deneme ancak öyle mümkün. Ayrıntısı mesaj teslim garantileri yazısında; buradaki ders sıralamayla ilgili: bu, ilk olay tüketicisiyle birlikte kurulmalıydı, on yedi çift kargodan sonra değil.

Tekrar yalnızca tüketici tarafından gelmiyor. Siparişi yazıp olayı yayınlarken süreç ölürse olay hiç gitmez; bunu outbox ile çözdük — ve outbox relay’i de yeniden dener, o da aynı olayı iki kez yayınlayabilir. Yani tekrar iki uçtan da gelebiliyor ve tek savunma tüketicide. Kural basit, bedeli her servise bir tablo: olay tüketen her servis, aynı olayı iki kez alınca aynı sonucu üretmeli. Tercih değil, olaya geçişin giriş şartı.

İkinci bedel: sıra

Dedup’ı kurduktan iki hafta sonra yeni bir şikâyet: “İptal ettiğim sipariş kapıma geldi.” Log şunu gösteriyordu:

Sebep: olayları yayınlarken partition anahtarı vermiyorduk; broker dağıtıyordu. Aynı siparişin iki olayı iki farklı partition’a düştü ve iki tüketici kopyası onları kendi hızında işledi. Kafka sırayı yalnızca aynı partition içinde garanti eder; bunu biliyorduk, ama “bize olmaz” diyorduk. İki olay arasındaki 170 milisaniye yetti.

yayinla(topic="siparis", key=siparisId, olay)   # ayni siparisin butun olaylari ayni partition

Bir de sırayı bozmadan çözülemeyen bir durum kaldı: iptal olayı gerçekten önce gelirse “bilinmeyen sipariş” diye atmak yerine iptali kaydedip beklemek. Sonra SiparisOlustu gelince önce iptal var mı diye bakmak. Sıra artık garanti olsa da bu koruma duruyor; tüketici ucuz, çift kargo pahalı.

Üçüncü bedel: “sipariş verdim ama listede yok”

Bu en çok destek bileti üreten madde oldu. Sipariş yazılıyor, olay yayınlanıyor, “Siparişlerim” sayfası ayrı bir okuma modelinden besleniyor ve o model olayı 1–3 saniye sonra işliyor. Müşteri “Sipariş ver”e basıp hemen listeye gidiyor: boş. Yeniden sipariş veriyor. Haftada 12 çift sipariş, hepsi bu yoldan.

Aynı ailenin ikinci üyesi daha kötüydü. “Her şey olay” deyince ödeme sonucunu da olayla bekliyorduk: sipariş ekranı OdemeTamamlandi gelene kadar bir dönen simge gösteriyor ve her saniye sunucuya soruyordu. Ödeme onayının ekranda görünmesi p95’te 6 saniye; monolitte 80 milisaniyeydi. Bu sürede müşteri sekmeyi kapatıyor, para çekilmiş, sipariş “bekliyor”da kalıyordu.

POST /siparis
  -> siparisi yaz
  -> yayinla(SiparisOlustu)
  -> 202 Accepted

# ekran: OdemeTamamlandi gelene kadar
# her saniye GET /siparis/4711/durum

POST /siparis
  -> stok.kontrol()      # HTTP, 300 ms zaman asimi
  -> odeme.al()          # HTTP, devre kesici
  -> siparisi yaz + outbox(SiparisOlustu)
  -> 201 { siparisId, durum: "alindi" }

# kargo, bildirim, puan, rapor, okuma modeli:
# olayi dinler, kendi hizinda

Ölçü şu oldu: cevabı olmadan isteğe devam edilemeyen adım senkron; gerisi olay. Stok ve ödeme bu testi geçiyor, geri kalan yedi şey geçmiyor. İki senkron çağrıya zaman aşımı ve devre kesici kondu; ödeme servisi yavaşlarsa sipariş ekranı 300 ms’de “şu an alamıyoruz” diyor, 6 saniye dönmüyor.

“Listede yok” problemi için de iki küçük şey: sipariş sonrası ekran listeye değil sipariş detayına gidiyor ve detay, okuma modelinden değil doğrudan sipariş servisinden okunuyor (kendi yazdığını görmek). Listede gecikme hâlâ 1–3 saniye; ama artık kimse o sürede ikinci sipariş vermiyor.

Dördüncü bedel: bir işlemin dört servise dağılması

Monolitte sipariş oluşturma tek bir veritabanı işlemiydi: stok düş, sipariş yaz, kampanya kullan, ödeme kaydet — hepsi ya olur ya olmaz. Olaya dağıldığında bu garanti sessizce kayboldu; mutlu yolda her şey çalıştığı için kimse fark etmedi.

İlk üç hafta bunu elle düzeltiyorduk — haftada 20-30 kayıt. Sonra telafi olaylarına geçtik: OdemeBasarisiz yayınlanınca stok servisi StokIadeEt, kampanya servisi kuponu serbest bırakıyor. Her ileri adımın bir geri adımı var ve her servis kendi telafisini dinliyor. Bu saga yazısının konusu; burada önemli olan şu: bu maliyeti geçişten önce kimse hesaplamamıştı. Monolitte bedava olan bir garanti, olay tabanlı sistemde tasarlanması gereken bir özellik.

Görünmezlik: hata ayıklama 10 dakikadan 3 saate

HTTP zincirinde en azından bir stack trace olur. Olayda hiçbir şey yok: kargo etiketi yanlış çıkmış, hangi olay üretmiş, o olayı hangi olay tetiklemiş? Üçüncü ayda aynı iş ortalama üç saat alıyordu; altı servisin logunda aynı saniyeye bakıp müşterinin siparişini elle eşleştiriyorduk.

Correlation ID ve dağıtık izlemeyi o yazıda anlattım; olay tabanlı sistemde bir adım daha var. Tek kimlik yetmiyor, üç tane gerekiyor ve üçü de olayın başlığında taşınıyor:

event_id        bu olayin kendi kimligi            (dedup bunu kullanir)
correlation_id  is akisinin kimligi; ilk istekte dogar, zincir boyunca DEGISMEZ
causation_id    bu olayi tetikleyen olayin event_id'si

SiparisOlustu         event_id=E1   correlation_id=C1   causation_id=-
OdemeTamamlandi       event_id=E2   correlation_id=C1   causation_id=E1
KargoEtiketiKesildi   event_id=E3   correlation_id=C1   causation_id=E2

Tüketici, ürettiği olaya correlation kimliğini olduğu gibi kopyalıyor, causation alanına tükettiği olayın kimliğini yazıyor. Correlation ile “bu müşterinin isteği hangi olayları doğurdu” sorusuna tek sorguyla cevap alıyorsun; causation ile zinciri geriye doğru yürüyüp yanlış etiketin hangi olaydan çıktığını buluyorsun. Biz üçüncü ayda ekledik; aradaki üç ay boyunca “görmediğimiz için olmadığını sandığımız” hataları da ekleyince, bu gecikmenin faturası en pahalılardan biriydi.

Kimsenin hesaplamadığı bedel: operasyon

Bir monolitin bir pipeline’ı, bir panosu, bir nöbet defteri vardır. On dört servisin on dört tane — artı kuyruklar:

Kuyruğun kendi hastalıkları da geldi. Bozuk bir olay (şeması eski bir üreticiden) kargo tüketicisini 40 dakika kilitledi: aynı mesajı tekrar tekrar deniyor, arkadaki 2.000 olay bekliyor. Zehirli mesaj kuyruğu (DLQ) o gün kuruldu — kuyruk hastalıkları yazısında hepsi var; buradaki not, hepsinin ilk üç ayda birer birer başımıza geldiği.

Alarm sayısı ilk üç ayda neredeyse üçe katlandı; sistem daha kırılgan olduğu için değil, daha çok parçası olduğu için. Bunu ancak bir platform ekibiyle geri çektik: ortak pipeline şablonu, ortak log/izleme paketi, tek komutla yeni servis iskeleti — içinde dedup tablosu, outbox ve lag alarmı hazır. O ekip planda yoktu, dördüncü ayda mecburiyetten kuruldu. Bugün olsa ilk haftada kurulurdu.

Bir de insan tarafı var: on dört servis, dört ekip. Her ekip üç dört servisin sahibi. Bu Conway’in kendini hatırlatma biçimi — servis sınırlarını ekip sınırlarına göre çizmeyince, ekip sınırları kendini servis sınırlarına uydurmaya başlıyor.

Geri birleştirdiklerimiz

Bunu yazmak biraz zor ama en faydalı ders bu. Beşinci ayda iki servisi geri birleştirdik:

• Sepet ve fiyatlandırma. Sepet her değişince SepetDegisti, fiyatlandırma cevap olarak FiyatHesaplandi, sepet onu bekliyor — iki servis arasında olay ping-pongu ve kullanıcı yeni fiyatı 1-2 saniye sonra görüyor. Birbirinden bağımsız hiç değişmemişlerdi: dört ayda 40 deploy, 38’i aynı gün. Tek servis oldu; fiyat anında, hiçbir şey kaybedilmedi.
• Kargo ve teslimat takibi. Aynı ekip, aynı veri, aynı gün değişen iki servis. Ayrılma gerekçesi “ileride ayrı ekipler olur” idi. Olmadı.

Kural sonradan netleşti: iki servis deploy geçmişinde tek servis gibi davranıyorsa, muhtemelen tek servis olmalıdır. Bunu ölçmek kolay — deploy geçmişine bak. Ayrı çıkma özgürlüğü kullanılmıyorsa ayrılığın bedeli boşuna ödeniyor.

Sahadan: 5 ay sonra sayılar

Tablonun orta sütunu, çoğu yazıda olmayan sütun. İkinci ayda her şey daha kötüydü: daha yavaş, daha çok alarm, daha uzun hata ayıklama, tutarsız veri, çift kargo. O dönemde “geri dönelim” diyen vardı ve haksız değildi. Geçiş, ortasında bırakılırsa iki dünyanın da kötüsünü veriyor; sonuna kadar götürülünce ilk sütunun asıl problemini — ekiplerin birbirine kelepçeli olmasını — çözüyor. Son sütundaki tek gerçek kazanç ikinci ve dördüncü satır; geri kalanı, ikinci ayda kaybettiklerimizi geri almak.

Bugün yeniden başlasam

Kontrol listesi

Sonuç

Beş ayın sonunda doğru kararı yanlış sırayla vermiş olduğumuzu gördük. Karar iki parçaydı ve ikisi de doğruydu: dört ekibin tek deploy trenine kelepçeli olması sürdürülemezdi, ve servisler birbirini çağırmak yerine olayla konuşmalıydı. Sıra yanlıştı: katman, sonra ortak veritabanı, sonra çekirdek — üç deneme, yaklaşık on hafta. Ve olayın üç bedelini — tam bir kez çalışma, sıralama, anlık tutarlılık — tasarlayarak değil, çift kargo, iptal edilmiş siparişin kapıya gelmesi ve boş sipariş listesiyle öğrendik.

Akılda kalacak sıra şu: önce sınırı monolitin içinde çiz, sonra veriyi böl, sonra kenardan başlayıp ağ ekle; olay tüketen ilk servisle birlikte dedup, partition anahtarı ve kimlik gelsin; hangi adımın olay olmayacağına baştan karar ver. Mikroservis, kuyruktan konuşan kod parçaları değil; birbirini beklemeden çıkabilen ekipler demek. Ekipler beklemeye devam ediyorsa ne servis sayısının ne de kuyruğun önemi var.