AI Pipeline'ında Idempotency Kabusu: Veri Kaybı ve Düzeltme Süreci

Bu yazıda, yakın zamanda AI destekli bir veri işleme pipeline’ında yaşadığım, hem zaman hem de veri kaybına yol açan bir “idempotency” sorununu ve bu sorunun nasıl çözüldüğünü anlatacağım. Belki de bu tür sistemleri kurarken gözden kaçırdığımız ince detaylardan biri olan idempotency’nin, özellikle hata durumlarında ne kadar kritik olabileceğini kendi deneyimlerimle aktarmaya çalışacağım.

Idempotency Nedir ve Neden Önemlidir?

Idempotency, bir operasyonun birden çok kez çalıştırıldığında aynı sonucu vermesi anlamına gelir. Basit bir örnekle açıklamak gerekirse, bir değişkenin değerini 10 artırmak idempoten bir işlem değildir; çünkü her çalıştırmada farklı bir sonuç elde edersiniz. Ancak, bir değişkenin değerini 0’a sabitlemek idempoten bir işlemdir; çünkü kaç kez çalıştırırsanız çalıştırın sonuç hep 0 olacaktır.

Yazılım sistemlerinde, özellikle dağıtık sistemlerde ve mesaj kuyrukları gibi bileşenlerin yer aldığı pipeline’larda idempotency hayati önem taşır. Ağ kesintileri, servis çökmeleri veya tekrarlayan mesajlar gibi beklenmedik durumlar, aynı isteğin birden çok kez işlenmesine neden olabilir. Eğer işlenen operasyon idempoten değilse, bu durum veri tutarsızlığına, çift kayıtlara veya istenmeyen yan etkilere yol açabilir.

Karşılaştığım Sorun: AI Pipeline’ında Beklenmedik Tekrarlar

Yakın zamanda üzerinde çalıştığım bir projede, kullanıcı girdilerini işleyen ve bir dizi AI modelinden geçiren bir pipeline kurmuştum. Bu pipeline, gelen her girdiyi alıp, ön işleme adımlarından geçiriyor, ardından farklı AI modellerine gönderiyor ve sonuçları bir veritabanına kaydediyordu. Sistem, her adımın başarılı olup olmadığını kontrol eden ve bir hata durumunda ilgili adımı yeniden deneyen bir yapıya sahipti.

Sorun, özellikle bir adayın AI modelinden dönüş alamaması ve sistemin bu adımı yeniden denemesi sırasında ortaya çıktı. Ağda kısa süreli bir kararsızlık yaşanmış ve ilk istek modele ulaşmış ancak yanıt geri dönmemişti. Pipeline, yanıt gelmediği için bu adımı “başarısız” olarak işaretleyip yeniden deneme mekanizmasını tetikledi. İkinci denemede model başarıyla yanıt verdi ve sonuç veritabanına kaydedildi. İlk istek ise, sistemin yeniden deneme döngüsünden sonra, arka planda asenkron olarak da olsa nihayet hedefe ulaştı ve aynı veriyi tekrar veritabanına kaydetti.

Neden Idempotency Mekanizması Kurulmamıştı?

Bu tür bir pipeline’da idempotency’nin göz ardı edilmesi benim için de bir hayal kırıklığıydı. Bunun birkaç temel nedeni olduğunu düşünüyorum:

1. Varsayılan Güven: Genellikle, modern servisler ve mesajlaşma sistemleri “at-least-once” veya “exactly-once” (ancak bu daha zordur) gibi teslimat garantileri sunar. Bu garantiler, geliştiricilerin mükerrer işleme senaryolarını kendilerinin ele alması gerektiği gerçeğini bazen ikinci plana atmasına neden olabiliyor.
2. Karmaşıklık: Idempotency mekanizmalarını doğru bir şekilde uygulamak, özellikle dağıtık sistemlerde ek karmaşıklık getirir. Her bir adımı benzersiz bir ID ile etiketlemek, bu ID’leri kontrol etmek ve durumları yönetmek, geliştirme sürecini uzatabilir.
3. Önceliklendirme: Proje başlangıcında, pipeline’ın hızla devreye alınması ve temel işlevselliğin sağlanması daha öncelikliydi. Idempotency gibi “edge case” sorunları, daha sonra ele alınacak konular arasında listelenmişti. Ancak “edge case” dediğimiz bu tür sorunlar, üretim ortamında en sık karşılaşılan problemlerden olabiliyor.

Çözüm Süreci: Idempotency’yi Pipeline’a Entegre Etmek

Sorunu tespit ettikten sonra, çözüm için birkaç farklı yaklaşım değerlendirdim.

1. Kayıt Bazlı Benzersizlik Kontrolü

İlk aklıma gelen yöntem, veritabanı düzeyinde benzersizlik kısıtlamaları (unique constraints) kullanmaktı. Eğer kaydedilecek her veri parçası için benzersiz bir tanımlayıcı (örneğin, bir request_id veya transaction_id) varsa, veritabanı bu benzersizlik kuralını uygulayarak mükerrer kayıtları engelleyebilir.

Ancak bu yaklaşımın bazı sınırlılıkları vardı:

• Tüm Veri Yapıları İçin Uygulanamaz: Pipeline’daki bazı adımlar, doğrudan veritabanına benzersiz bir anahtarla kaydedilmeyen ara verileri işliyordu. Bu adımlar için veritabanı seviyesinde bir kısıtlama koymak mümkün değildi.
• Hata Mesajları: Veritabanı benzersizlik hatası verdiğinde, bu hatayı yakalayıp kullanıcıya veya sisteme anlamlı bir şekilde iletmek gerekiyordu. Bu da ek kodlama anlamına geliyordu.

2. Application-Level Idempotency Key (Uygulama Seviyesi Idempotency Anahtarı)

Daha sağlam bir çözüm, her isteğe benzersiz bir “idempotency key” atamak ve bu anahtarı işlemin her adımında takip etmekti. Bu anahtar, bir UUID (Universally Unique Identifier) veya istemci tarafından oluşturulan özel bir ID olabilir.

İşleyiş şu şekilde olmalıydı:

1. İstek Oluşturma: Pipeline’a giren her ana veri için benzersiz bir idempotency_key oluşturulur. Bu key, istekle birlikte pipeline’a iletilir.
2. Durum Takibi: Her işlem adımı başladığında, sistem bu idempotency_key’i ve işlemin hangi adımda olduğunu bir cache (örneğin Redis) veya özel bir veritabanı tablosunda saklar.
3. Tekrarlanan İstek Kontrolü: Eğer aynı idempotency_key ile başka bir istek gelirse, sistem öncelikle bu key’in daha önce işlenip işlenmediğini kontrol eder.
   • Eğer istek daha önce işlenmiş ve başarılı olmuşsa, işlem tekrar çalıştırılmaz ve önceki başarılı sonuç döndürülür.
   • Eğer istek daha önce işlenmiş ancak başarısız olmuşsa ve yeniden deneme mekanizması tetiklenmişse, bu durum yönetilir (belki hata loglanır veya farklı bir strateji izlenir).
4. Başarılı İşlem: İşlem başarıyla tamamlandığında, idempotency_key’in durumu “başarılı” olarak güncellenir.

Bu yaklaşım, pipeline’ın herhangi bir noktasında mükerrer işlemeyi engellemek için kullanılabilir.

Uygulama Detayları ve Karşılaşılan Zorluklar

Bu “application-level idempotency key” yaklaşımını uygulamaya karar verdim. İşte sürecin bazı detayları ve karşılaştığım zorluklar:

• Anahtar Üretimi: Benzersiz idempotency_key’leri üretmek için Python’da uuid.uuid4() fonksiyonunu kullandım. Bu, yüksek olasılıkla benzersiz anahtarlar üretiyor.
• Durum Saklama: Durumları saklamak için önceleri Redis’i düşünmüştüm. Ancak pipeline’ın farklı servisler arasında çalıştığını ve her servisin kendi Redis bağlantısını yönetmesinin karmaşık olacağını fark ettim. Bu nedenle, her adımda merkezi bir veri deposuna (bu durumda PostgreSQL’deki yeni bir tablo) yazmaya karar verdim. Tablo yapısı şöyleydi:

CREATE TABLE idempotency_log (
    idempotency_key UUID PRIMARY KEY,
    operation_name VARCHAR(255) NOT NULL,
    status VARCHAR(50) NOT NULL CHECK (status IN ('PROCESSING', 'COMPLETED', 'FAILED')),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

• Pipeline Adımlarının Güncellenmesi: Pipeline’daki her bir işlem adımı, bu tabloyu kullanacak şekilde güncellendi. Bir adım başladığında, önce idempotency_log tablosuna bir kayıt atılıyor ve status ‘PROCESSING’ olarak ayarlanıyordu. İşlem tamamlandığında ise status ‘COMPLETED’ olarak güncelleniyor veya bir hata durumunda ‘FAILED’ olarak işaretleniyordu.
• Hata Durumları: En zorlayıcı kısım, hata durumlarını yönetmekti. Eğer bir adım ‘FAILED’ olarak işaretlenirse ve sistem yeniden deneme yaparsa, idempotency_log tablosundaki ilgili kaydın status’ünü tekrar ‘PROCESSING’ yapmamız gerekiyordu. Ancak bu, bir önceki denemenin neden başarısız olduğunu da bilmemizi gerektiriyordu. Bu nedenle, status yerine, her denemenin bir sürümünü tutmak daha mantıklı olabilirdi.

• Performans Etkisi: Her adımda veritabanı sorguları yapmak, pipeline’ın genel performansını bir miktar etkiledi. Özellikle yoğun trafik altında, bu ek sorguların gecikmeye yol açmaması için veritabanı indekslerinin doğru ayarlanması ve sorguların optimize edilmesi gerekiyordu. idempotency_key üzerinde bir indeks oluşturmak bu konuda kritikti.

CREATE INDEX idx_idempotency_key ON idempotency_log (idempotency_key);

Sonuç ve Çıkarılan Dersler

Bu deneyim, “kurumsal danışman” tonunda yazmak yerine, kendi yaşadığım problemleri ve çözümleri doğrudan anlatmanın önemini bir kez daha gösterdi. AI pipeline’larında idempotency, sadece bir “nice-to-have” özelliği değil, ciddi veri kaybı veya tutarsızlığına yol açabilecek kritik bir gerekliliktir.

Bu sorunu çözmek için harcadığım zaman ve çaba, ilk başta idempotency’yi göz ardı etmenin ne kadar maliyetli olabileceğini gösterdi. Yaklaşık 8 saatlik bir kesinti ve 100’den fazla mükerrer kayıt, bu konuya daha fazla önem vermem gerektiğini öğretti.

Bu tür sorunlarla karşılaşan başka geliştiriciler için bu deneyimin faydalı olmasını umuyorum. Unutmamak gerekir ki, sistem ne kadar karmaşık olursa olsun, temel prensiplere dikkat etmek, uzun vadede büyük problemleri önlemenin anahtarıdır.