Hatchet – Açık kaynak dağıtık iş kuyruğu

Dağıtık, hata toleranslı iş kuyruğu

• Hatchet, yönetmesi zor mevcut kuyruk veya pub/sub sistemlerinin yerine geçerek, hatalardan kurtulabilen ve eşzamanlılık, adalet, hız sınırlama gibi sorunları çözebilen dayanıklı iş yükleri tasarlamayı sağlar.
• Kendi iş kuyruğunuzu veya pub/sub sisteminizi yönetmek yerine, Hatchet ile çok az yapılandırma ya da altyapıyla fonksiyonları bir dizi worker arasında dağıtabilirsiniz.

Hatchet'in avantajları

• Ultra düşük gecikmeli ve yüksek verimli zamanlama
  • Hatchet, ortalama 25ms başlatma süresine sahip düşük gecikmeli bir kuyruk üzerine kuruludur; bu da gerçek zamanlı etkileşim yeteneği ile görev açısından kritik işler için gereken güvenilirliği dengeli biçimde sunar.
• Eşzamanlılık, adalet, hız sınırlama
  • FIFO, LIFO, Round Robin ve Priority Queues gibi stratejiler Hatchet'in yerleşik stratejileriyle uygulanarak, minimum yapılandırmayla yaygın ölçekleme sorunlarının etrafından dolaşılır.
• Tasarım gereği dayanıklılık
  • Özel yeniden deneme politikaları ve entegre hata işleme sayesinde Hatchet, geçici hatalardan sonra işleri hızla kurtarmayı garanti eder.

Geliştirilmiş görünürlük ve kontrol

• Gözlemlenebilirlik
  • Tüm çalıştırmalar tamamen aranabilir durumdadır ve sorunlar hızlıca tespit edilebilir.
• (Pratik) dayanıklı yürütme
  • Olayları yeniden oynatabilir ve workflow'un belirli bir adımından yürütmeyi manuel olarak yeniden başlatabilirsiniz.
• Cron
  • Fonksiyon çalıştırmalarını tekrarlı olarak zamanlayabilirsiniz.
• Tek seferlik zamanlama
  • Fonksiyon çalıştırmalarını belirli bir saat ve tarihte zamanlayabilirsiniz.
• Ani yük artışı koruması
  • Trafikteki ani sıçramaları yumuşatır ve sistemin kaldırabileceği kadar işi çalıştırır.
• Artımlı streaming
  • Arka plan worker'larının ilerleme durumuna göre güncellemelere abone olabilirsiniz.

Örnek kullanım senaryoları

• Üretken yapay zeka için adalet
  • Yoğun kullanıcıların sistemi ezmesini önlemek için Hatchet ile istekleri worker'lara adil biçimde dağıtabilirsiniz.
• Belge indeksleme için toplu işleme
  • Hatchet, belge, görsel ve diğer verilerin büyük ölçekli batch işlenmesini yönetebilir ve hata durumunda işi yarıda kaldığı yerden sürdürebilir.
• Çok modlu sistemler için workflow orkestrasyonu
  • Hatchet, çok modlu girdi ve çıktıları koordine edebilir ve tam DAG tarzı yürütmeleri yönetebilir.
• Olay tabanlı işleme için doğruluk
  • Dış olaylara veya sistem içi olaylara tepki verebilir ve olayları otomatik olarak yeniden oynatabilir.

Hızlı başlangıç

• Hatchet; Python, Typescript ve Go için açık kaynak SDK'ları destekler.
• Başlamak için Hatchet belgelerine bakabilir veya hızlı başlangıç deposunu inceleyebilirsiniz.

SDK deposu

• Hatchet varsayılan olarak bir Go SDK sunar.
• Typescript SDK da kullanılabilir.
• SDK ile ilgili bir sorun yaşarsanız ilgili depoda issue açabilirsiniz.

Hatchet'in yönetilen bir bulut sürümü var mı?

• Evet, beta sürecinde ürünü geliştirmeye ve şekillendirmeye yardımcı olan bazı şirketlere bulut sürümü sunuluyor.

Hatchet'in self-hosted sürümü var mı?

• Evet, self-hosting için açık kaynak Docker container yönergelerini belgelerde bulabilirsiniz.

Bu, alternatiflerle nasıl karşılaştırılıyor? (Celery, BullMQ)

• Neden bir tane daha yönetilen kuyruk yaptınız?
  • Özellikle DAG tarzı yürütmelere dayanan tam işlemsel kuyruklamanın avantajlarını elde etmek istediklerini ve Postgres'in kuyruklama kullanım senaryolarının çoğunun yerini alabileceğine güçlü biçimde inandıklarını belirtiyorlar.
  • Birçok kuyruk Redis tabanlıdır ve dikkat edilmezse OOM nedeniyle veri kaybı yaşanabilir; PG kullanıldığında ise bu sorunlardan kaçınılabilir.

Sorunlar

• Keşfettiğiniz hataları Github issue'ları üzerinden bildirebilirsiniz.
• Proje erken aşamada olduğu için, karmaşık özellik taleplerinden önce Discord üzerinden iletişime geçmeniz önerilir.

Katkıda bulunmak isterseniz

• Katkı belgelerine göz atın ve Discord'daki #contributing kanalında üzerinde çalışmak istediğiniz konuyu paylaşın; bu, proje yönünü şekillendirmeye ve iş birliğini kolaylaştırmaya yardımcı olur.

GN⁺'ın görüşü

• Hatchet, dağıtık sistemlerde iş kuyruğu yönetiminin karmaşıklığını azaltan, yüksek erişilebilirlik ve hata toleransı sunan bir çözüm olarak; özellikle büyük ölçekli veri işleme ve gerçek zamanlı servisler için faydalı görünüyor.
• Bu teknolojinin, bugün piyasada kullanılan diğer kuyruk sistemleriyle karşılaştırıldığında Postgres kullanımı sayesinde elde ettiği kararlılık ve ölçeklenebilirlik dikkat çekici bir avantaj olarak öne çıkıyor.
• Hatchet'i devreye alırken dikkate alınması gereken noktalar arasında mevcut altyapıyla uyumluluk, veri migrasyonu ve ekibin teknik yetkinliği bulunuyor.
• Hatchet'in sunduğu gelişmiş görünürlük ve kontrol özellikleri, sistem performansını izlemeyi ve sorun gidermeyi kolaylaştırarak geliştiricilerin ve operasyon ekiplerinin yükünü azaltabilir.
• Hatchet hâlâ beta aşamasında olduğundan, kararlılık ve işlevsellik açısından yeterince doğrulanması ve büyük ölçekli sistemlere uygulanmadan önce kapsamlı şekilde test edilmesi gerekiyor.

[GN⁺]

Hacker News görüşleri

• Bir kullanıcı, Postgres tabanlı bir iş kuyruğu, farklı dillerde çalışan worker'lar ve yeterli yerleşik gözlemlenebilirlik özelliklerine sahip bir ürün aradığını 3 yıldır söylüyor. Bu kullanıcı her 6 ayda bir pazarı kontrol edip alternatifleri değerlendirmiş ama hep hayal kırıklığına uğramış. Ancak RabbitMQ gibi ek bağımlılıklardan kaçınmak istediği için Postgres tabanlı kuyrukları tercih ettiğini belirtiyor. Şu anda graphile-worker kullanıyor ama hâlâ karşılanmayan ihtiyaçları olduğunu söylüyor.
• Başka bir kullanıcı, bu ürünün Y Combinator tarafından desteklendiğine dikkat çekerek, şirketin "open core" modelini mi izleyeceğini yoksa başka gelir elde etme yolları mı arayacağını merak ediyor.
• Bir başka kullanıcı, pub/sub sistemlerinin push subscription özelliğini sevdiğini belirtiyor; örneğin GCP pub/sub'da olayları kuyruktan çekmek yerine bir HTTP endpoint'ine push eden aboneler kullanılabildiğini açıklıyor. Bu yaklaşımın, Cloud Run veya Lambda gibi runtime'larla HTTP isteklerine göre ölçeklenebilme ve sıfıra kadar ölçeklenebilme avantajı sunduğunu söylüyor. Worker'ların otomatik ölçeklendirmesini ayarlamanın daha karmaşık olabileceğini, RabbitMQ'da kuyruk derinliği metriğine göre KEDA autoscaling kurulabileceğini ama bunun ek karmaşıklık getirdiğini ekliyor. Kullanıcı, HTTP bağlantısını açık tutan bir daemon'un işleri push edebileceği bir modeli destekleme planı olup olmadığını soruyor.
• Bir kullanıcı, neden tüm fonksiyonların context'i argüman olarak aldığının açıklanmasını istiyor. Bunun, fonksiyon yazarken çok fazla boilerplate kod yazmayı gerektirdiğini hissettiğini söylüyor.
• Başka bir kullanıcı, dağıtık bir DAG işleme sistemi uygularken bu fikrin o zaman aklına gelmiş olmasını isterdiğini ve denemek istediğini söylüyor.
• Bir kullanıcı, bulut tarafından sunulan hizmetin fiyatlandırmasının açık olup olmadığını ve self-hosting seçeneği için bir Kubernetes operator yapma planı bulunup bulunmadığını soruyor. Ayrıca MIT lisansı kullanılmasının, Amazon'un gelecekte bir Amazon Hatchet hizmeti çıkarabilmesine yol açabileceği yönünde endişe dile getiriyor.
• Bir başka kullanıcı, DAG tabanlı bir job runner için bir iş kuyruğu yazdığını ve PostgreSQL, SQLite, bellek içi vb. seçeneklerle iş grafiğinin; retry, timeout, serileştirilmiş kaynaklar gibi unsurlar dikkate alınmadan çalıştırılabilmesini istediğini söylüyor. Bu kullanıcı bu yaklaşımla ilgileniyor.
• Bir kullanıcı, istemcinin (web tarayıcısı) bir işin ilerleme durumunu tamamlanana kadar dinleyebileceği bir iş kuyruğuna ihtiyaç duyduğunu söylüyor. Deno Queue'nun sadeliğini ve erişilebilirliğini seviyor ama istemci tarafında iş durumuna abone olma yöntemini kendisinin uygulaması gerektiğini belirtiyor. Bunun Postgres tabanlı olarak mümkün olup olmadığını merak ediyor ve dokümantasyon bağlantısından bunun mümkün olduğunu doğruladığını söylüyor.
• Başka bir kullanıcı, önceki iş yerinde sınırsız sayıda işi zamanlamak zorunda kaldıkları bir sorun yaşadığını anlatıyor. Örneğin bir hasta 6 ay sonrasına randevu aldığında, bu süre boyunca randevuyu hatırlatan bir dizi bildirimin zamanlanması gerektiğini söylüyor. Başta veritabanı kuyruğuna kayıt ekleyip birkaç saniyede bir polling yapan bir yaklaşımla başladığını, ancak polling'den kaynaklanan IO maliyetinin ideal olmadığını ve dağıtık bir sistem kullanmadan bunu çözmek istediğini belirtiyor. Redis'e geçmiş ama birden fazla dispatcher'ı yönetmenin karmaşıklığı, OOM sorunları ve işleri anlık kuyruğa taşımak için yardımcı işler çalıştırma gereği gibi problemler yaşamış. PG'ye geçip SKIP LOCKED gibi yöntemleri kullanmayı düşünmüş ama iş değiştirmiş. Hatchet'ın bu tür bir kullanım senaryosuna uygun olup olmadığını soruyor.
• Son olarak bir kullanıcı, Hatchet'ın Temporal/Cadence/Conductor ile kıyaslandığında nasıl konumlandığını ve Hatchet'ın da durable execution desteği sunup sunmadığını soruyor.