Dağıtık sis­tem­lerde idem­po­tency

Deneyimli backend ekiplerini deneyimsiz olanlardan ayıran bir cümle vardır: “Bu mesaj iki kez gelebilir.” Dağıtık sistemleri yeterince uzun süre işleten kişi, mükerrer mesajların yok olmasını dilemeyi bırakır ve onlar için inşa etmeye başlar. Çünkü mükerrer mesaj ortadan kaldırılacak bir bug değildir; mesajların, cevapları her an yutabilen bir ağ üzerinden yolculuk etmesinin kaçınılmaz bir sonucudur.

Buna verilebilecek tek güvenilir cevabın adı idempotency'dir (eş etkililik): Bir işlem, birden çok kez yürütülmesi tek bir yürütmeyle aynı durumu üretiyorsa idempotent'tir. Bir hesaptan para çekme işlemi idempotent ise, iki kez iletilen bir “Öde” komutu ikinci bir çekim yapmaz. Bu metin mükerrer mesajların neden kaçınılmaz olarak oluştuğunu, “exactly-once” kavramının neden bir yanılsama olduğunu ve idempotency key'ler, HTTP semantiği, outbox ve inbox ile mükerrer iletime ve tekrarlanan yürütmeye dayanabilen sistemlerin nasıl inşa edildiğini açıklıyor; framework'ten, kuyruktan ve buluttan bağımsız olarak. Araçlar stack'e göre değişir; ilke değişmez.

Mükerrer mesajlar neden oluşur

Tüm mükerrer mesajların kökeninde tek ve çözülemez bir problem yatar: Bir gönderici bir istek gönderip cevap alamadığında, ne olduğunu bilemez. Onun için üç durum aynı görünür: İstek hiç ulaşmadı; ulaştı ve işlendi ama cevap kayboldu; hâlâ yolda. Gönderici yalnızca şunu görür: cevap yok. Birinci durumu düzelten tek eylem yeniden denemektir ve bu da ikinci durumda mükerrer bir işlem üretir.

Şema: Sunucu ilk isteğin yeni mi yoksa bir tekrar mı olduğunu ayırt edemez ve idempotency olmadan parayı iki kez çeker.

Bu durum her yerde ortaya çıkar: Client'taki bir timeout bir tekrarı tetikler. Bir load balancer, kısa bir kesintiden sonra bir isteği yeniden iletir. Bir kuyruk, consumer mesajı onaylayamadan çöktüğü için mesajı ikinci kez teslim eder. Ağdaki anlık bir aksaklık bir paketi tekrarlar. Bu durumların hiçbiri yazılımdaki bir hata değildir; dağıtık bir sistemin olağan işleyişidir. Mükerrer mesajlar tepki verilen bir istisna değil, onlar için inşa edilen kuraldır.

Exactly-once ve at-least-once

Mesajların iletimi için akla gelebilecek üç garanti vardır ve bunları anlamak tüm tasarımı belirler.

At-most-once en fazla bir kez iletir: mükerrer yok, ama kayıp mümkün; yalnızca kaybolan bir olayın önemsiz olduğu yerde kullanışlıdır. At-least-once en az bir kez iletir: kayıp yok, ama mükerrer mümkün; her ciddi kuyruğun ve her yeniden deneme mekanizmasının dürüst olağan durumu. Exactly-once iletim ise genel durumda imkânsızdır, çünkü bir ağ üzerinden iletmek ile onaylamak atomik olarak birleştirilemez: “İşlendi” ile “onaylandı” arasında her zaman bir şey çökebilir.

Bu yüzden sistemlerin “exactly-once” dediği şey neredeyse hiçbir zaman exactly-once iletim değil, at-least-once iletim artı idempotent işlemedir; ikisi birlikte “effectively-once” sonucunu verir: Mesaj belki birden çok kez ulaşır, ama etkisi tam olarak bir kez gerçekleşir. Ulaşılabilecek tek durum da, gerekli olan tek durum da budur.

Exactly-once iletimin neden mümkün olmadığının nedeni, daha önceki kaybolan onayın (lost ACK) aynısıdır, yalnızca bir seviye yukarıda: Broker'ın mesajı iletmesi ve aynı, bölünemez anda consumer'ın onayını alması gerekirdi; ama ikisinin arasında onayı yutabilecek bir ağ vardır. Ne kadar akıllıca kurgulanırsa kurgulansın, broker'ın consumer'ın mesajı alıp almadığını bilmediği bir pencere kalır. Yalnızca seçim yapabilir: şüphe durumunda yeniden iletmek (at-least-once) ya da şüphe durumunda iletmemek (at-most-once). Bu pencere olmadan “tam olarak bir kez” diye bir şey yoktur; yalnızca şüphenin hangi tarafında yanılmak istediğinizi seçebilirsiniz.

Önerimiz: At-least-once için tasarlayın ve işlemeyi idempotent hâle getirin; “exactly-once iletim” vaatlerine şüpheyle yaklaşın. Bedeli, durum değiştiren her işlemenin altyapıya güvenmek yerine tekilleştirme (dedup) mantığı taşıması gerekmesidir. Kaybı hiçbir sonuç doğurmayan verilerde farklı karar veriyoruz; örneğin kritik olmayan telemetri. Orada at-most-once yeterlidir ve idempotency'ye hiç gerek kalmaz.

Idempotency key'ler

Kendi başına idempotent olmayan bir işlemi idempotent hâle getirmenin en genel yolu idempotency key'dir: Göndericinin her mantıksal işlem için ürettiği ve istekle birlikte gönderdiği benzersiz bir anahtar. Sunucu, anahtarları sonuçlarla eşleyen bir depo tutar. Bir anahtar ilk kez geldiğinde işlem yürütülür ve sonuç bu anahtar altında saklanır. Aynı anahtar tekrar geldiğinde sunucu işlemi yeniden yürütmeden saklanan sonucu döndürür.

Şema: Aynı anahtar ikinci seferde aynı sonucu döndürür; etkiyi ikinci kez tetiklemeden.

Doğruluğu üç ayrıntı belirler. Anahtar teknik isteği değil, mantıksal işlemi tanımlamalıdır; bir ödemede HTTP çağrısını değil, ödeme sürecini. Deponun “tamamlandı, sonuç X” durumunun yanında bir “işleniyor” durumuna da ihtiyacı vardır; aksi hâlde aynı anda gelen iki mükerrer istek, biri saklanmadan önce işlemi ikisi birden yürütür. Saklama süresi de en büyük tekrar penceresi kadar uzun olmalıdır; aksi hâlde anahtar, son tekrar gelmeden önce süresi dolarak silinir.

Önerimiz: Durum ya da para değiştiren komutlara, gönderici tarafından üretilen bir idempotency key ve “işleniyor” durumunu da bilen bir depo ekleyin. Bedeli, kendi tutarlılığı ve temizlik yükümlülüğü olan ek bir depo ile anahtarın sistem sınırları ötesinde koordinasyonudur. Doğası gereği idempotent olan işlemlerde farklı karar veriyoruz (birazdan değineceğiz); orada key gereksiz bir mekanizmadır.

HTTP idempotency'si

HTTP protokolü kendi içinde zaten bir idempotency anlayışı taşır ve bunu doğru kullanmak kendi mekanizmanızı kurma ihtiyacını azaltır.

GET, PUT ve DELETE spesifikasyona göre idempotent'tir: Bir durumu belirleyen bir PUT istendiği kadar gönderilebilir, sonuç aynı kalır; bir DELETE ikinci seferde artık hiçbir şey silmez. POST ve PATCH ise idempotent değildir: Bir kaynak oluşturan ya da bir ödemeyi tetikleyen bir POST, ikinci seferde ikincisini oluşturur. Idempotency key'e ihtiyaç duyanlar tam olarak bunlardır.

Önemli bir çekince var: Metoda göre idempotent olmak, uygulamada idempotent olmak anlamına gelmez. Dahili olarak belirlemek yerine ekleme yapan bir PUT, metoduna rağmen idempotent değildir. HTTP semantiği otomatik işleyen bir şey değil, yerine getirilmesi gereken bir vaattir.

Önerimiz: Semantiğin izin verdiği yerde idempotent metotları seçin (tercihen eklemek yerine belirlemek) ve idempotent olmayan işlemlerde bir idempotency key isteyin. Bedeli, işlemleri rahatça artırmak (increment) yerine bazen daha zahmetli biçimde “belirlemek” olarak ifade etmek zorunda kalmanızdır. İş anlamı zorunlu olarak idempotent olmadığında farklı karar veriyoruz; örneğin “bir log'a bir kayıt ekle”. O durumda sorumluluğu metot değil, key taşır.

Kuyruk işleme

Mesaj kuyrukları neredeyse her zaman at-least-once iletir. Nedeni yine kaybolan onaydır: Bir consumer bir mesajı işler, ama onaylamadan önce çöker; dolayısıyla kuyruk mesajı yeniden iletir. Süresi dolan görünürlük pencereleri ve rebalancing de yeniden iletime yol açar. Sonuç kaçınılmazdır: Bir consumer asla tek seferlik iletime güvenemez; idempotent olmak zorundadır.

Consumer'daki idempotency birkaç kaynaktan gelebilir:

Ayrıca etki ile onayın sırası da merkezidir: Bir mesaj ancak etkisi kalıcı olarak kaydedildikten sonra onaylanır. Önce onaylayıp sonra yazan, aradaki bir çökmede mesajı kaybeder.

Önerimiz: Her consumer'ı at-least-once olarak ele alın ve etkisini yukarıdaki kaynaklardan biriyle güvence altına alın; onayı ancak kalıcı commit'ten sonra verin. Bedeli, her consumer için bir dedup mekanizması ve etki ile onayı doğru sıralama özenidir. Doğal olarak idempotent olan handler'larda farklı karar veriyoruz; örneğin yalnızca bir değeri mesajdaki duruma göre belirleyen bir handler. Orada ek bir dedup katmanına gerek yoktur.

Ödemeler

Hiçbir alan, eksik idempotency'nin maliyetini ödemeler kadar acımasızca göstermez. Çift çekim sessiz bir veri hatası değil; müşteride görünür bir zarar, bir destek vakası ve bir güven kırılmasıdır. Kaybolan onay tam da burada en tehlikelidir: “Öde” komutu, iki kez yürütülmesine en az izin verilebilecek ve en sık tekrarlanan işlemdir.

Güvence tüm zincir boyunca uzanır. Client her ödeme süreci için (her tıklama için değil) bir idempotency key üretir. Kendi servisiniz bu anahtara göre tekilleştirme yapar; böylece tekrarlanan bir istek ikinci bir ödemeyi tetiklemez. Ödeme sağlayıcısının kendisi de bir idempotency key kabul eder ve kendi tarafında tekilleştirme yapar. Her aşama bir sonrakinin anahtara uyacağına güvenir; hiçbir aşama “iki kez olmaz herhâlde” düşüncesine güvenmez.

Önerimiz: Her ödeme süreci için bir idempotency key'i tüm zincir boyunca taşıyın (client, kendi servisiniz, sağlayıcı) ve “Öde” komutunu kesin olarak idempotent hâle getirin. Bedeli, sistem sınırları ötesinde koordinasyon ve teknik isteğe değil, temiz biçimde ödeme sürecine bağlanması gereken bir anahtardır. Burada asla farklı karar vermiyoruz: Para söz konusu olduğunda idempotency'den vazgeçtiğimiz bir karşı durum yoktur.

Yeniden denemeler

Yeniden denemeler, at-least-once'ı gerçeğe dönüştüren mekanizmadır ve aynı zamanda mükerrer mesajların ana kaynağıdır. Retry olmadan her geçici hatada mesaj kaybedersiniz; retry ile mükerrer mesaj üretirsiniz. Bu bir çelişki değil, retry'ların ve idempotency'nin neden birbirine ait olduğunun nedenidir: Yalnızca idempotent olanı güvenle tekrarlayabilirsiniz. İdempotent olmayan bir işlemi tekrarlamak, tam da çift çekimin ortaya çıktığı yoldur.

Güvenli yeniden denemeler basit bir try again'den fazlasını gerektirir. Tüm client'lar aynı anda yeniden saldırıp bir retry fırtınası başlatmasın diye rastgelelik payı içeren üstel geri çekilmeye (exponential backoff) ihtiyaç duyarlar. Kalıcı olarak bozuk bir süreç sonsuza kadar dönmesin diye bir üst sınıra ihtiyaç duyarlar. Tekrarlanabilir hataları (timeout, ağ hatası, geçici aşırı yük) tekrarlanamayanlardan ayırt etmeleri gerekir, çünkü reddedilmiş bir girdi tekrarla geçerli hâle gelmez. Ve vazgeçilenleri sessizce kaybetmek yerine onlar için bir uç noktaya, bir dead-letter alanına ihtiyaç duyarlar.

Önerimiz: Yalnızca idempotent işlemleri; backoff, rastgelelik payı, üst sınır ve bir dead-letter yoluyla tekrarlayın. Bedeli, ek mantık ve başarısız mesajların bekleyip izlenmesi gereken bir yerdir. İdempotent hâle getirilemeyen ve tekrarı zarar verecek bir işlemde farklı karar veriyoruz; o durumda otomatik olarak tekrarlanmaz, hata bir insana ya da bilinçli olarak inşa edilmiş bir telafi adımına iletilir.

Outbox pattern

Veritabanı ile mesaj broker'ı arasındaki sınırda özellikle sinsi bir problem ortaya çıkar: dual-write problemi. Bir süreç hem bir durumu değiştirmeli hem de bir olay yayınlamalıdır; ama veritabanı ve broker üzerinde ortak bir transaction yoktur. Önce veritabanına yazıp sonra yayınlarsanız, aradaki bir çökmede olay kaybolur. Önce yayınlayıp sonra yazarsanız, yazma başarısız olduğunda olay bir yalandır.

Outbox pattern bunu, iki yazma işlemini tek bir transaction'a taşıyarak çözer. Olay doğrudan yayınlanmaz; durum değişikliğiyle aynı veritabanı transaction'ı içinde bir outbox tablosuna yazılır. Atomik olarak, yani ya ikisi birden ya da hiçbiri. Ayrı bir relay süreci outbox'ı okur, olayları broker'a yayınlar ve ardından gönderildi olarak işaretler.

Şema: Durum ve olay atomik olarak yazılır; relay at-least-once iletir, consumer tekilleştirme yapar.

Relay, yayınlama ile işaretleme arasında çökebileceği için iletim yine at-least-once'tır; olay broker'a iki kez ulaşabilir. Alıcılar idempotent olduğu sürece bu sorun değildir. Outbox, hiçbir olayın kaybolmayacağını ve gerçekte yaşanmamış hiçbir olayın gönderilmeyeceğini garanti eder; mükerrer olanları diğer taraf yakalar.

Önerimiz: Durumun ve olayın birlikte yazıldığı her durumu, doğrudan yayınlamak yerine aynı transaction içindeki bir outbox üzerinden çözün. Bedeli, ek bir tablo, bir relay süreci ve onun ürettiği mükerrer mesajlardır. Sistemden hiçbir olay çıkmadığında farklı karar veriyoruz: Durum değişikliği ve etki aynı veritabanındaysa dual-write yoktur ve outbox'a da gerek yoktur.

Inbox pattern

Outbox gönderici tarafını güvence altına alır; inbox ise alıcı tarafını güvence altına alır ve onun aynadaki yansımasıdır. Bir mükerrer mesajı güvenilir biçimde tanımak için consumer, işlenen her mesajın ID'sini bir inbox tablosunda saklar; üstelik etkiyle aynı transaction içinde. Bir ID'yi zaten kayıtlı bulursa mesajı atlar.

Belirleyici nokta ortak transaction'dır. Dedup kaydı ve etki atomik olarak birlikte kaydedildiği için, etkinin gerçekleştiği ama ID'nin saklanmadığı (ya da tersi) bir durum oluşmaz. Doğru bir tekilleştirmeyi görünüşteki bir tekilleştirmeden ayıran tam olarak budur: ID ayrı bir transaction'da kontrol edilip etki başka bir transaction'da gerçekleştirilirse, aradaki bir çökme ikisini birbirinden koparabilir ve ya bir mükerrer mesaj araya sızar ya da bir mesaj kaybolur.

Outbox ve inbox birlikte kesintisiz bir zincir oluşturur: Gönderici hiçbir şey kaybetmez (outbox), alıcı tam olarak bir kez etki eder (inbox) ve arada iletim pekâlâ mükerrer olabilir. Bu, tüm mesaj yolu boyunca “effectively-once”tır.

Önerimiz: Consumer'da, kaydı etkiyle aynı transaction içinde yazılan bir inbox tablosu üzerinden tekilleştirme yapın. Bedeli, temizlik yükümlülüğü olan bir tablo daha ve dedup ile etkiyi kapsayan bir transaction'dır. Etkinin kendisi zaten idempotent olduğunda farklı karar veriyoruz: bir benzersizlik kısıtı ya da koşullu bir güncelleme. O durumda tekilleştirmeyi veritabanı üstlenir ve ayrı bir inbox gereksiz bir tekrar olurdu.

Sık yapılan hatalar

Idempotency'nin başarısız olduğu tekrar eden örüntüler:

• At-least-once'ı varsaymak yerine, var olmayan “exactly-once” iletime güvenmek.
• Tek seferlik iletimi varsayan ve hiçbir tekilleştirme taşımayan consumer'lar.
• İdempotent olmayan işlemleri otomatik olarak tekrarlamak; çift çekime giden doğrudan yol.
• Dedup kontrolünü ve etkiyi ayrı transaction'larda yürütmek; böylece aradaki bir çökme ikisini birbirinden koparır.
• Bir idempotency key'i süresiz (sınırsız depolama) ya da çok kısa süreyle (pencere tekrardan küçük) saklamak.
• Çakışmalara ya da boşluklara izin veren, benzersiz olmayan bir anahtar seçmek: bir zaman damgası, tahmin edilmiş bir ID.
• Etki kalıcı olarak kaydedilmeden onay vermek; mesaj bir çökmede kaybolur.
• Outbox olmadan durumu ve olayı ayrı ayrı yazmak; kaybolan ya da uydurulmuş olaylar.
• “İşleniyor” durumunu unutmak; böylece aynı anda gelen iki mükerrer mesajın ikisi de işlenir.
• Doğruluk için at-least-once'ın garanti etmediği mesaj sırasına güvenmek.

Karar kontrol listesi

Durum değiştiren her işlemeden önce sorulacak sorular. Bunlar yargı değil, teşhis sorularıdır.

• Bu işlem durumu ya da parayı değiştiriyor mu? Evet ise idempotent olmalıdır; para söz konusuysa istisnasız.
• Doğası gereği mi idempotent, yoksa anahtara ya da tekilleştirmeye mi ihtiyaç duyuyor? Doğal idempotency en ucuz olanıdır.
• Her mantıksal işlem için gönderici tarafından üretilen benzersiz bir anahtar var mı? Her teknik istek için değil.
• Dedup ve etki aynı transaction içinde mi kaydediliyor? Ayrı ise gerçek bir tekilleştirme değildir.
• Onayı ancak etkinin kalıcı commit'inden sonra mı veriyoruz? Aksi hâlde kayıp tehlikesi vardır.
• Anahtarın saklama süresi en büyük tekrar penceresini kapsıyor mu? Aksi hâlde süresi çok erken dolar.
• Yalnızca ardışık değil, eşzamanlı mükerrer mesajları da ele alıyor muyuz? Bunun için bir “işleniyor” durumu gerekir.
• Veritabanı/broker sınırını aşıyor muyuz? Evet ise: outbox ve inbox.
• Yeniden denemeler backoff, rastgelelik payı ve dead-letter yoluyla sınırlandırılmış mı? Aksi hâlde fırtına ve sessiz kayıp tehlikesi vardır.

Sıkça Sorulan Sorular

Modern broker'larda exactly-once yok mu? Broker'ların bu adla andığı şey çoğu zaman kendi sınırları içinde effectively-once'tır: broker'da tekilleştirme artı transactional onay. Bir mesaj broker'ın dışında bir etkiyi (örneğin bir para çekimini) tetiklediği anda yeniden at-least-once geçerli olur ve idempotency sizin sorumluluğunuzdadır. Garanti broker'ın sınırında biter.

Bir benzersizlik kısıtı yetmez mi? Çoğu zaman yeter; benzersizlik kısıtı bir idempotency biçimidir: İkinci ekleme denemesi başarısız olur. Önemli olan, anahtarın mantıksal işlemi temsil etmesi ve çakışma durumunun temiz biçimde ele alınmasıdır; yani “zaten mevcut” durumunun hata olarak değil, mevcut sonuçla birlikte başarı olarak değerlendirilmesi.

Idempotency key'leri ne kadar süre saklamalıyız? En az, bir tekrarın gelebileceği en büyük pencere kadar; retry'lar, yeniden iletimler ve manuel tekrarlar dâhil. Sonrasında anahtarın süresi dolabilir. Süre çok kısa olursa geç gelen bir tekrar yeni bir istek gibi ele alınır; sınırsız olursa depo sonsuza kadar büyür.

İki mükerrer mesaj aynı anda gelirse ne olur? O durumda yalnızca sonuçları saklayan bir depo yetmez, çünkü biri saklanmadan önce ikisi birden başlar. Bir “işleniyor” durumuna ya da anahtar üzerinde bir kilide ihtiyaç vardır: İlk mükerrer mesaj anahtarı tutar, ikincisi bekler ya da reddedilir. Idempotency'yi eşzamanlılık altında da doğru kılan ancak budur.

Her işlemin idempotency'ye ihtiyacı var mı? Hayır. Salt okuma işlemlerinin buna ihtiyacı yoktur ve doğal olarak idempotent olan işlemler (bir değer belirlemek, ID ile silmek) bunu zaten kendi içlerinde taşır. Emek, kendiliğinden idempotent olmayan, durum ve para değiştiren işlemler içindir. Diğer her şey karşılığı olmayan bir mekanizma olurdu.

Outbox mu, broker transaction'ı mı? Outbox her yerde, özel broker yetenekleri gerektirmeden çalışır, çünkü yalnızca bir veritabanı transaction'ına ihtiyaç duyar. Broker veritabanıyla gerçek bir transactional bağlantı sunuyorsa bu da değerlendirilebilir; ama outbox taşınabilir, framework'ten ve buluttan bağımsız standart yoldur.

İleri okuma

• Idempotency: Kavramın kısa tanımı.
• Kuyruk mu, senkron işleme mi ve Asenkron işlemeyi devreye almak: Kuyrukların ne zaman anlamlı olduğu ve nasıl devreye alındığı.
• Müşterileri bozmadan API sürümlendirme: Idempotency key'ler, sağlam bir API sözleşmesinin parçasıdır.
• Kesintisiz veritabanı migrasyonları: Aynı tekrarlanabilirlik disiplininin backfill'lere uygulanmış hâli.

Temelinde Batunet Engineering Method yatar: hata durumu için tasarlamak, küçük ve geri alınabilir adımlarla inşa etmek, ilk günden gözlemlenebilirlik.

Mesajların iki kez iletilmesine izin verilmeyen dağıtık bir sistem, inşa edilemeyecek bir sistemdir. Dürüst hedef mükerrer mesajları önlemek değil, onları kimsenin fark etmeyeceği kadar sonuçsuz hâle getirmektir.