Maestro: Netflix’in İş Akışı Orkestratörü

 (netflixtechblog.com)
4 puan yazan GN⁺ 2024-07-24 | 1 yorum | WhatsApp'ta paylaş
  • Netflix, büyük ölçekli Data/ML iş akışları için yatay ölçeklenebilir orkestratör Maestro’yu açık kaynak olarak yayımladı; şirket içinde ise yüz binlerce iş akışı minimum kesintiyle taşınmış ve çalıştırılıyor
  • DAG odaklı orkestratörlerin aksine döngüsüz ve döngüsel iş akışlarını birlikte ele alıyor; foreach döngüleri, alt iş akışları ve koşullu dallanmaları motor düzeyinde desenler olarak sunuyor
  • Son bir yılda çalıştırılan iş sayısı %87,5 arttı; şu anda günlük ortalama binlerce iş akışı örneği ve yaklaşık 500 bin iş çalıştırıyor, yoğun günlerde ise yaklaşık 2 milyon işi tamamlıyor
  • JSON tabanlı tanımlara çalıştırma stratejileri, parametreler, SEL ifadeleri, sinyaller, breakpoints, timeline, yeniden deneme politikaları ve rollup’ları birleştirerek operasyonel kontrol ve hata ayıklamayı destekliyor
  • Netflix gibi veri tablolarının tek bir veri ambarında toplandığı ortamlarda iş akışlarını birden fazla kümeye bölmek koordinasyon maliyetini ve kullanıcı deneyimi kaybını artırdığı için, tüm akışın tek bir orkestratör tarafından yönetildiği yapı önem taşıyor

Maestro’nun yayımlanması ve Netflix içindeki operasyon ölçeği

  • Netflix, Maestro GitHub repository üzerinden Maestro kaynak kodunu yayımladı
  • Maestro, veri pipeline’ları ve makine öğrenimi modeli eğitim pipeline’ları gibi büyük ölçekli Data/ML iş akışlarını yöneten yatay ölçeklenebilir bir iş akışı orkestratörüdür
  • İş akışının başlangıcından bitişine kadar tüm yaşam döngüsünü yönetir; yeniden deneme, kuyruğa alma ve işlerin compute engine’lere dağıtımını ele alır
  • Kullanıcılar iş mantığını Docker imajları, notebook’lar, bash script’leri, SQL, Python gibi çeşitli biçimlerde paketleyebilir
  • Netflix, daha önce tanıttıktan sonra yüz binlerce iş akışını Maestro’ya taşıdı ve geçiş sürecinde kullanıcı kesintisini en aza indirdi
  • Güncel operasyon ölçeği:
    • Son 1 yılda çalıştırılan iş sayısı %87,5 arttı
    • Günlük ortalama binlerce iş akışı örneği çalıştırılıyor
    • Günlük ortalama yaklaşık 500 bin iş çalıştırılıyor
    • Yoğun günlerde yaklaşık 2 milyon iş tamamlanıyor

Tek orkestratörle ölçeklenebilirlik ve çeşitlilik desteği

  • Maestro, Netflix içinde binlerce son kullanıcıya, uygulamaya ve servise Workflow-as-a-Service sağlayan tam yönetilen bir orkestratördür
  • ETL pipeline’larını, ML iş akışlarını, AB test pipeline’larını ve birden fazla depolama sistemi arasında veri taşıma pipeline’larını destekler
  • Yatay ölçekli mimarisi, hem çok sayıda iş akışını hem de tek bir iş akışı içindeki çok sayıda işi işlemek üzere tasarlanmıştır
  • Netflix’in iş akışları birbirine sıkı biçimde bağlı olduğundan, bunları küçük gruplara ayırıp birden fazla kümede yönetmek ek koordinasyon mekanizmaları gerektirir ve kullanıcı deneyimini düşürür
  • Veri tabloları tek bir veri ambarında bulunduğu için, bunlara erişen tüm iş akışlarını tek bir orkestratörün işlemesi gerektiği değerlendirilmiştir

İş akışı tanım modeli

  • Maestro’nun iş akışı tanımı JSON formatında yazılır
  • Kullanıcının sağladığı alanlar ile Maestro tarafından yönetilen alanlar birleştirilerek orkestrasyon tanımı oluşturulur; örnek Maestro repository wiki’de yer alır
  • İş akışı tanımı genel olarak iki bölüme ayrılır
    • properties: yazar/sahip bilgileri ve çalıştırma ayarlarını içerir
    • versioned workflow: iş akışı metadata’sı ve grafik tanımını içerir
  • properties, iş akışı sürümü değişse bile yazar/sahip bilgileri, çalıştırma stratejisi ve eşzamanlılık ayarları gibi temel özellikleri korur
  • Sahiplik değiştiğinde yeni bir iş akışı sürümü oluşturmadan yeni sahip mevcut iş akışının sahipliğini devralabilir
  • versioned workflow; benzersiz tanımlayıcı, ad, açıklama, etiketler, timeout ayarları ve önceliklendirme için low·medium·high criticality seviyelerini içerir
  • İş akışındaki değişiklikler yeni bir sürüm oluşturur; varsayılan olarak aktif sürüm veya en yeni sürüm kullanılır
  • İş akışı, kullanıcının tanımladığı grafiğin düğümleri olan step’lerden oluşur
    • step; bir işi, subworkflow step üzerinden başka bir iş akışını veya foreach step üzerinden bir döngüyü temsil edebilir
    • step’te benzersiz tanımlayıcı, step türü, etiketler, giriş/çıkış parametreleri, bağımlılıklar, yeniden deneme politikası, hata modu ve step çıktıları bulunur
    • Hata türüne göre yapılandırılabilen yeniden deneme politikalarını destekler

Çalıştırma sırasını kontrol eden Run Strategy

  • Maestro, yeni bir iş akışı örneğinin çalıştırılıp çalıştırılmayacağına önceden tanımlanmış run strategy ile karar verir

  • Sequential Run Strategy

    • Varsayılan stratejidir; FIFO sırasıyla aynı anda bir tane çalıştırır
    • Önceki çalıştırmanın başarılı olup olmamasından bağımsız olarak, örnek başarı veya başarısızlık gibi bir son duruma ulaştığında kuyruktaki sonraki örneği başlatır

  • Strict Sequential Run Strategy

    • Tetiklenme sırasına göre çalıştırır, ancak önceki örnek geçmişinde blocking error varsa çalıştırmayı engeller
    • Başarısız örnek manuel olarak yeniden başlatılana veya unblock edilene kadar yeni örnek kuyrukta kalır
    • Zaman hassasiyeti düşük ama iş açısından kritik önemi yüksek iş akışları için yararlıdır

  • First-only Run Strategy

    • Çalışmakta olan iş akışı tamamlanmadan yeni örnekleri kuyrukta tutmaz
    • Hâlihazırda çalışan bir örnek varsa kuyruğa yeni giren örneği kaldırarak kuyruğa almayı fiilen kapatır
    • Yeni örnekler biriktirmediği için idempotency sorunlarından kaçınmaya yardımcı olur

  • Last-only Run Strategy

    • Her zaman en son tetiklenen örneğin çalıştırılmasını sağlar
    • Mevcut çalışan bir örnek varsa onu durdurur ve yeni tetiklenen örneği çalıştırır
    • Her seferinde tüm tablonun en güncel snapshot’ını işleyen iş akışları gibi yalnızca en güncel veriye ihtiyaç duyulan durumlarda yararlıdır

  • Parallel with Concurrency Limit Run Strategy

    • Önceden tanımlanmış eşzamanlılık sınırı içinde birden fazla örneği paralel çalıştırır
    • Çok miktarda veriyi sınırlı süre içinde işlemek için çalıştırmayı fan-out edip dağıtabilir
    • Eski verilerin backfill edilmesi yaygın bir kullanım örneğidir

Parametreler ve SEL ifadeleri

  • Maestro’da parametreler; çalıştırma mantığını kontrol etmek, iş akışı ile step’ler arasında durum paylaşmak ve upstream ile downstream step’ler arasında durum paylaşmak için kullanılır
  • Maestro, kod enjeksiyonu içeren dinamik parametreleri destekleyerek karmaşık parametreli iş akışlarının tanımlanmasını sağlar
  • Kod enjeksiyonu güvenlik ve kararlılık riskleri yaratabilir
    • Kullanıcı sonsuz döngü yazarak bir diziye sürekli öğe eklerse sunucu OOM nedeniyle durabilir
    • Enjekte edilen kodu iş mantığının içine taşımak kullanıcının yükünü artırır ve iş akışı tanımı ile iş mantığını güçlü biçimde birbirine bağlar
  • Netflix bunu azaltmak için kendi ifade dili olan SEL(Simple, Secure, and Safe Expression Language)’i geliştirdi
  • SEL, Java Language Specifications’ın gramer ve sözdizimini izler ancak Maestro kullanım senaryolarına uyarlanmış bir alt kümeyi destekler
  • SEL; Maestro parametre türlerinin veri tiplerini, hata üretmeyi, tarih-saat işlemeyi ve önceden tanımlanmış yardımcı metotları destekler
  • Kararlılık için döngü yineleme sınırı, dizi boyutu kontrolü ve nesne bellek boyutu sınırı gibi runtime kontrolleri içerir
  • SEL dokümantasyonu Maestro GitHub documentation’da bulunur

Çıkış parametreleri ve parametreli iş akışları

  • Maestro, callable step execution aracılığıyla kullanıcı çalıştırma sonuçlarını çıkış parametreleri olarak sisteme geri verebilir
  • Çıkış verileri Maestro REST API üzerinden iletilir; step runtime’ı Maestro veritabanına doğrudan erişmez
  • Statik iş akışları basittir, ancak küçük farkları yansıtmak için aynı iş akışını birden çok kez kopyalamak gerekebilir; parametreler olmadan iş akışı ve işler durum paylaşamaz
  • Tamamen dinamik iş akışlarının yönetimi ve desteklenmesi zordur; hata ayıklama, sorun giderme ve yeniden kullanım da güçleşir
  • Parametreli iş akışları, kullanıcı tanımlı parametrelere dayanarak runtime’da step bazında başlatılır; böylece çalıştırma anı kontrolünde esneklik ile yönetilebilirliği birlikte sunar
  • Maestro’nun parametre desteği, backfill veri pipeline’ları gibi karmaşık parametreli iş akışlarının oluşturulmasını mümkün kılar

Motor Düzeyinde İş Akışı Çalıştırma Kalıpları

  • Maestro, yaygın veri akışı ve iş akışı kalıplarını doğrudan motor içinde destekler
  • Motorun doğrudan desteği, kalıp optimizasyonunu ve tutarlı bir uygulama biçimini mümkün kılar

  • Foreach

    • foreach kalıbı başlangıçta iş akışı tanımı içinde özel bir step olarak modellenmiştir
    • foreach döngüsünün her yinelemesi dahili olarak ayrı bir iş akışı instance’ı olarak işlenir
    • foreach tanım bloğu içindeki step’lerin çalıştırılması, yani sub-graph yürütmesi, ayrı bir iş akışı instance’ına devredilir
    • foreach step’i, her yinelemeden sorumlu iş akışı instance’ının durumunu izler ve toplar
    • Farklı parametrelerle aynı işi yineleme bazında çalıştıran veri backfill’lerinde veya makine öğrenimi modeli tuning’inde sık kullanılır
    • Kullanıcıların yüz binlerce yinelemeyi doğrudan iş akışı tanımına yazması gerekmez; foreach kapsamı değiştiğinde yeni bir iş akışı oluşturma ihtiyacı da azalır

  • Conditional Branch

    • Koşullu dallanma, upstream step’in belirli bir koşulu sağlandığında sonraki step’lerin çalıştırılmasını sağlar
    • Koşullar SEL ifadeleriyle tanımlanır ve runtime’da değerlendirilir
    • Bir denetim kontrol step’i başarısız olduğunda kurtarma işini yaptıktan sonra işi yeniden çalıştıran bir akış kurulabilir

  • Subworkflow

    • subworkflow, tek bir iş akışı step’inin başka bir iş akışını çalıştırmasını sağlayarak ortak işlevlerin birden fazla iş akışında paylaşılmasına imkân verir
    • İş akışı grafiği “workflow as a function” biçiminde oluşturulabilir
    • Netflix’te, birden fazla ekibin sağladığı subworkflow’ları birleştirerek yüzlerce tablonun verisini işleyen, yüzlerce subworkflow’dan oluşan karmaşık iş akışları da gözlemlenmiştir
    • foreach, koşullu dallanma ve subworkflow birlikte birleştirilebilir
    • Bir subworkflow kümesi döngüyle işlenebilir
    • İç içe foreach döngüleri çalıştırılabilir
    • Koşullu dallanma ve subworkflow birlikte kullanılarak hataları ele alan ve işleri otomatik yeniden deneyen otomatik kurtarma iş akışları oluşturulabilir

Step Runtime ve Parametre Birleştirme

  • Maestro, çalışma anındaki işi açıklamak için step runtime kullanır
  • step runtime arayüzü iki tür bilgi tanımlar
    • step instance’ının çalışma davranışını kontrol eden temel API kümesi
    • step runtime durumu ile çalışma sonucunu izleyen basit veri yapısı
  • Maestro, foreach step runtime ve subworkflow step runtime gibi implementasyonlar sağlar
  • Her implementasyon start, execute ve terminate davranışları için kendi mantığını tanımlar
  • Runtime durumu, step’in bir sonraki durum geçişini belirlemek ve başarısızlık ya da sonlandırma olup olmadığını değerlendirmek için kullanılır
  • Çalışma sonucu, step artifact’lerini ve step çalıştırma geçmişi timeline’ını içerir; sonraki step’ler bunlara erişebilir

  • Step Parameter Merging

    • Maestro, step davranışını dinamik olarak kontrol etmek için runtime parameter ve tag enjeksiyonunu destekler
    • step parameter map başlangıçta boştur ve şu sırayla birleştirilir
    • Default General Parameters: workflow_instance_id, step_instance_uuid, step_attempt_id, step_id gibi tüm step’lerin temel parametreleridir; Maestro içinde ayrılmış değerler olarak kullanılır ve kullanıcı tarafından geçirilemez
    • Injected Parameters: step runtime tarafından dinamik olarak üretilen parametrelerdir; step türüne özgü schema’ya göre değişebilir
    • Default Typed Parameters: Belirli bir step türüyle ilgili varsayılan parametrelerdir; foreach step’in loop_params, loop_index değerleri buna örnektir
    • Workflow and Step Info Parameters: workflow_id gibi step ve iş akışıyla ilgili kimlik bilgileri
    • Undefined New Parameters: İş akışı instance’ı başlatılırken veya yeniden başlatılırken kullanıcının yeni belirttiği step parametreleri
    • Step Definition Parameters: Tanım anında kullanıcının yazdığı step parametreleri
    • Run and Restart Parameters: Başlatma veya yeniden başlatma sırasında kullanıcının mevcut tanım parametrelerinin üzerine yazmak için sağladığı değerlerdir; en son birleştirilir

Step Dependencies ve Signal

  • Maestro iş akışı grafiğindeki step’ler, yürütme bağımlılıklarını step dependency ile ifade edebilir
  • step dependency, step’in çalışması için gereken veriyle ilgili koşulları belirtir
  • Koşullar genellikle signal temelinde tanımlanır
  • signal, parametre değerleri gibi bilgileri taşıyan bir mesajdır; step çıktısı olarak ya da SNS·Kafka gibi dış sistemler üzerinden yayımlanabilir
  • signal hem trigger kalıbında hem de publisher-subscriber biçimindeki signal dependency kalıbında kullanılır
  • Tek bir step, çıktı signal’ı yayımlayarak o signal’a bağımlı birden fazla step’in çalışmasının önünü açabilir
  • signal definition, eşlenmiş parametre listesini içerir; Maestro yalnızca bazı alanlarla signal matching yapabilir
  • Maestro, signal parametre değerleri için <, > gibi signal operators destekler
  • Netflix, signal kavramı üzerine çeşitli soyutlamalar inşa etmiştir
    • Bir ETL iş akışı tabloyu güncelleyip signal gönderdiğinde, bu veriye bağımlı downstream iş akışı step’i çalıştırılabilir
    • signal lineage, geçmiş signal instance’larını ve bu signal’ı yayımlayan ya da tüketen iş akışı step’lerini keşfetmeyi sağlar
    • signal trigger, tek bir signal’a veya join edilmiş signal kümesine abone olan iş akışları için exactly-once execution’ı garanti eder
  • Yalnızca belirtilen signal koşulları karşılandığında iş akışı veya step çalıştırıldığı için kaynak tasarrufu sağlanabilir

Hata Ayıklama ve Çalıştırma Görünürlüğü

  • Breakpoint

    • Maestro, iş akışı step’lerine breakpoint koyabilir
    • İş akışı instance’ı breakpoint koyulmuş step’e ulaştığında, ilgili step paused durumuna geçer
    • Kullanıcı manuel olarak devam ettirene kadar iş akışı grafiğinin ilerlemesi durur
    • Aynı iş akışı step’inin birden fazla instance’ı breakpoint’te durmuşsa, birini devam ettirmek yalnızca o instance’ı etkiler; diğerleri paused durumda kalır
    • Breakpoint silindiğinde durmuş olan tüm step instance’ları devam eder
    • İlk iş akışı geliştirme sırasında step çalışmasını ve çıktı verilerini kontrol etmek için kullanışlıdır
    • foreach kalıbında tek bir step’e breakpoint koyulursa tüm yinelemeler o step’te durur ve hata ayıklama yapılabilir
    • Çalışma sırasında insan müdahalesi veya çalışma sırasında step durum değişikliği desteği için de kullanılabilir

  • Timeline

    • Maestro, step çalıştırma timeline’ını içerir ve durum makinesi değişiklikleri ile bunların nedenleri gibi önemli olayları kaydeder
    • Örnek olaylar arasında Created, Evaluating params gibi geçişler bulunur
    • Uygulanan step runtime, son kullanıcıya çalıştırma bilgilerini göstermek için timeline olayları ekleyebilir
    • Timeline örneği sample-step-instance-failed.json içinde yer alır

Yeniden Deneme, Aggregated View, Rollup

  • Retry Policies

    • Maestro, başarısızlıkla son duruma ulaşan step’ler için yeniden deneme politikalarını destekler
    • Kullanıcılar yeniden deneme sayısını, denemeler arasındaki gecikmeyi, sabit aralıklı yeniden denemeyi ve exponential backoff stratejisini ayarlayabilir
    • Yeniden denemeler iki türe ayrılır
    • platform retry: kullanıcı mantığından bağımsız platform düzeyi hatalara yanıt
    • user retry: kullanıcı tanımlı koşullara göre yeniden deneme
    • Her tür ayrı bir yeniden deneme politikasına sahip olabilir
    • Otomatik yeniden deneme, kullanıcı müdahalesi olmadan çözülebilecek geçici hataları ele almak için yararlıdır
    • İdempotent olmayan step’lerde yeniden denemeden kaçınmak için yeniden deneme sayısı 0 olarak ayarlanabilir

  • Aggregated View

    • Tek bir workflow instance birden fazla run’a sahip olabileceğinden, kullanıcının tüm step’lerin toplulaştırılmış durumunu görebilmesi gerekir
    • aggregated view, temel aggregated view ile mevcut run’ın step durumları birleştirilerek hesaplanır
    • Örneğin ilk çalıştırmada step1 ve step2 başarılı, step3 başarısız, step4 ve step5 henüz başlamamışsa, yeniden başlatma step3’ten başlar; step1 ve step2 ise önceki başarılı durumları nedeniyle atlanabilir
    • Tüm step’ler başarılı olduğunda aggregated view, tüm step’lerin run durumunu gösterir

  • Rollup

    • rollup, workflow instance için üst düzey bir özet sağlar; her step’in durumunu ve durum başına step sayısını gösterir
    • Mevcut instance ile subworkflow ve foreach gibi iç içe non-inline workflow’ların step’lerini açarak toplulaştırır
    • Başarılı bir workflow üç step’e sahipse ve bunlardan biri beş step’lik bir subworkflow ise, rollup başarılı step sayısını 7 olarak gösterir
    • Rollup’ta yalnızca leaf step’ler toplulaştırılır; diğer step’ler belirli bir workflow’u işaret eden pointer’lar olarak ele alınır
    • Başarılı olmayan step’lerin referansları da korunur; böylece iç içe workflow içindeki sorunlu step’e gidilebilir
    • aggregated rollup, mevcut run’ın runtime data’sı ile base rollup birleştirilerek hesaplanır
    • subworkflow step’inin rollup’ı, subworkflow instance’ın rollup’ını olduğu gibi yansıtır
    • foreach step’inin rollup’ı, önceki çalıştırmadan yeniden başlatılacak iterasyonlar hariç base rollup ile mevcut çalıştırmadaki iterasyonların rollup’larını birleştirir
    • Bu süreç nedeniyle rollup modeli eventually consistent’tır; iç içe foreach ve subworkflow birden fazla seviyeye yayıldığında hesaplama karmaşık ve özyinelemeli olabilir

Olay Yayınlama ve Harici Entegrasyon

  • Workflow tanımı, workflow instance veya step instance değiştiğinde Maestro olaylar üretir ve bunları dahili işleme sonrasında harici sistemlere yayınlar
  • Maestro olayları dahili olaylar ve harici olaylar olarak ayrılır
    • internal event: workflow, workflow instance ve step instance yaşam döngüsündeki dahili değişiklikleri izler ve dahili kuyruğa yayınlanır
    • external event: aşağı akış servislerinin tüketmesi için Maestro durum değişikliği bilgilerini içerir ve SNS, Kafka gibi harici kuyruklara gönderilir
  • Maestro event processor, dahili kuyruğa abone olarak internal event’leri alır; olay türüne göre işledikten sonra gerekirse external event’e dönüştürür
  • Son aşamadaki notification publisher harici olayları yayınlayarak aşağı akış servislerinin bunları tüketebilmesini sağlar
  • Aşağı akış servisleri çoğunlukla olay tabanlıdır ve Maestro event’leri, Maestro’daki çeşitli değişiklikleri algılamak için gereken mesajları içerir
  • Değişiklik türleri genel olarak iki kategoriye ayrılır
    • workflow change: workflow tanımı veya properties değişiklikleri gibi workflow düzeyi işlemler
    • instance status change: workflow instance veya step instance durum geçişi

Nasıl Başlanır

  • Maestro koduna github.com/Netflix/maestro adresinden ulaşılabilir
  • Sorular, görüşler ve yorumlar Maestro deposundaki GitHub issue üzerinden bırakılabilir
  • Netflix, Maestro’nun sunduğu ölçeklenebilirlik ve kullanılabilirliğin Netflix dışındaki workflow geliştirmeyi de hızlandırmasını umuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-24
Hacker News yorumları

  • Eskiden bu tür şirket teknik bloglarına ve şirket içi özel sistemlere hayranlık duyardım, ama artık duymuyorum. Çünkü kod borçtur
    cron/Celery/Airflow gibi şeyleri yeniden yapmak yerine, bakım ve iyileştirme geçmişi uzun olan yerleşik açık kaynak kullanmak isterim. Sonuçta birilerinin bakım yapması, bug düzeltmesi ve özellik eklemesi gerekiyor. Tabii terfi ve maaş/RSU artışı da geliyorsa durum farklı
    Şirkete para kazandıran çekirdek iş olmayan kodun, dikkati dağıtan ve kaynak tüketen bir şey olduğunu fark etmek gerekiyor

    • Sanırım bu blog yazısı da tam bu yüzden çıktı. Bu yazılımı açık kaynak yaparak artık her şeyi tamamen içeride bakımını yapmak zorunda kalmamayı hedefliyorlar
      Mevcut yerleşik açık kaynakların çözemediği bir ihtiyaç olduğu için bunu yaptılar; şimdi de onu yeniden yerleşik açık kaynağa dönüştürüp kullanmaya devam ederken bakım yükünü paylaşmaya çalışıyorlar. Böyle araçlar en başta nasıl ortaya çıksın, birilerinin yapması gerek
    • “Kod borçtur” bakışı fazla uç ve dünyadaki her şeyi MBA usulü min-max etmeye çalışan düşünceyle güçlü biçimde bağlantılı
      Yeni sistemler kurmaktan ve yeni fikirleri zorlamaktan korkmayan insanların olması iyi. Şirket açısından da sıradan ve riskten kaçınan çözümlerin sınırı var. En kârlı şirketler teknik açıdan epey cesur olabiliyor
      Kod borç değil, şirketin çarklarını döndüren şeydir
    • Yerleşik açık kaynakların kendisi de çoğu zaman büyük şirketlerin iç araçlarını açmasının sonucu. Özellikle burada adı geçen Airflow buna iyi bir örnek, bu alanda Temporal da öyle. Birilerinin yeni bir şey yapacak kadar “aptal” olması gerekiyor
    • “Bakım ve iyileştirme geçmişi uzun” sözü çok büyük bir önkabule dayanıyor
      Kişinin topluluğa katkı yapma planı da var mı merak ediyorum. Yapmak mı almak mı tartışması her zaman önemli ama “almak” tarafında bakım ve güvenilirlik maliyetinin tam olarak sıfır olduğunu varsaymak safça geliyor
    • “Şirketin çekirdek işi olmayan şey” koşulu önemli. Performansın kritik olduğu alanlarda çalışan yetkin bir ekip için, dış kodun düşük kaliteli/düşük kontrollü borca dönüştüğü kırılma noktası o kadar da uzakta değil

  • Mühendislerin bir iş akışı çözümünden memnun kalması için daha kaç yineleme gerekeceğini merak ediyorum. Netflix’in Maestro’dan önce de Metaflow gibi çeşitli çözümleri vardı, Uber de birkaç çözüm yaptı, Amazon’un içinde de en az bir düzine iş akışı motoru vardı
    Farklı şirketlerde birçok kişinin iş akışı motoru yapmak istemesi ilginç. Bu, birini ya da Netflix’i küçümsemek için söylenmiş değil; sadece rahatça konuşulabilecek bir gözlem gibi geliyor

    • Sorun, iş akışı orkestrasyonunun çok geniş bir problem alanı olması. Şirketler birbirinden farklı birçok sorunu çözmek zorunda kalıyor; bu yüzden her çözüm ilgili özelliklerle dolu dev bir ürüne dönüşüyor ve büyüdükçe güçlü felsefesi olan büyük bir monolite kayma eğilimi gösteriyor. Bu yüzden neredeyse kimse memnun kalmıyor
      Aslında beş temel ilgi alanı var: kaynak zamanlama, bağımlılık çözümü, iş ve iş akışı oluşturmak için API/DSL, cron benzeri zamanlanmış çalıştırma ve ETL ya da ML/AI iş akışlarında alan bilgisini açığa çıkaran alan farkındalığı
      Bunların hepsini temizce yapan tek bir çözüm yok. Bu yüzden şirketler mevcut hazır ürünlerin eksiklerini kapatmak için ya kendileri yapıyor ya da etrafından dolaşıyor; herkesin memnuniyetsiz kalması döngüsü de sürüyor
      Bunun bir startup’ın “çözüm” olarak ortaya koyabileceği bir sorun olduğunu sanmıyorum. İyi tak-çıkar modül bileşenlerinden oluşan bir açık kaynak ekosistemi ile çözülmeli
    • Metaflow, Maestro’nun üzerinde çalışıyor; ikisinden biri diğerinin yerine geçmiyor
      https://netflixtechblog.com/orchestrating-data-ml-workflows-... içinde “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.” deniyor
      Bu yazının orkestrasyon bölümünde (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) Metaflow’un Maestro, Airflow, Argo Workflows ve Step Functions ile nasıl örtüştüğü ayrıntılı biçimde anlatılıyor
    • Kendi iş akışı motorumuzu yaptık ama o kadar çok bug vardı ve yeterince esnek değildi ki, alakasız bir projeyi neredeyse bozuyorduk
      İş akışı motorlarının bir ölçüde tasarım kokusu olabileceğini düşünmeye başladım. Bir kez yeniden kullanılabilir bir şey yapınca onu sayısız iş akışında kullanabilirmişsin gibi çekici görünüyor, ama iş akışlarının ortak noktası iki veya daha fazla asenkron adım gerektirmesi dışında neredeyse yok
      Veriler farklı, API’ler farklı, devam edebilmek için kullanıcıdan ya da başka sistemlerden alınması gereken geri bildirimler farklı
    • Muhtemelen çeşitli işleri ele alırken aynı zamanda anlaşılması ve işletilmesi kolay bir iş akışı motoru/orkestratörü hâlâ bulunamadığı içindir
      Belirli bir kullanım durumuna optimize edilmiş özel bir iş akışı motoru yapmak gerçekten kolay. Hâlâ bir yakınsama yaşanmamasının nedeni, böyle bir aracın henüz ortaya çıkmamış olması olabilir
      Son dönemde alanlarını hızla ele geçiren araçlara bakınca, Terraform IaC için, Kubernetes ise dağıtık hesaplamanın zor sorunları için çözüm sundu. İkisi de çok karmaşık ama zor sorunları çözüyor. Buna karşılık genel amaçlı iş akışı motorları anlaması karmaşık, işletmesi zor ve deneyimi de belirsiz; bu yüzden birçok kişi hiç denemiyor bile
    • İsimlendirme, önbellek geçersizleştirme ve bir de iş akışı motorları mı? :)
      https://github.com/meirwah/awesome-workflow-engines

  • https://windmill.dev sitesinin kurucusuyum; Windmill’in Maestro ile pek çok benzerliği var
    Maestro açıklamasındaki “büyük ölçekli workflow’ları, veri pipeline’larını ve ML model eğitim pipeline’larını yöneten genel amaçlı, yatay ölçeklenebilir bir workflow orkestratörü” ifadesi, Windmill ile değiştirildiğinde de tamamen doğru olur. Onların rollup dediği şey, bizim openflow state dediğimiz şey
    Temel farklar şu: Windmill Java yerine Rust ile yazıldı ve Maestro durum saklama için CockroachDB kullanırken biz hem durum hem de kuyruk için PostgreSQL kullanıyoruz. Yine de neden CockroachDB kullandıklarını anlıyorum. Windmill de çok büyük müşteri instance’larında yatay ölçekleme için kendi sharding algoritmasını geliştirmek zorunda kaldı
    Maestro Apache 2.0, Windmill ise daha az kullanıcı dostu AGPL lisansına sahip. Netflix desteğiyle fonları fiilen sınırsız, ama biz gelir elde etsek de çok daha küçük bir şirketiz
    Maestro’nun Kubernetes ya da docker-compose tabanlı self-hosting belgeleri yeterince kapsamlı görünmüyor; ayrıca bir şeyler oluşturmak için bir UI yok gibi, ya da en azından belgelerde henüz iyi görünmüyor. Yine de genel olarak açık kaynak olarak yayınlanmış olması oldukça hoş ve izlemeye devam edip mümkün olan en kısa sürede benchmark etmeyi planlıyorum

    • Windmill’i değerlendirecekseniz önce şuna bakmalısınız: https://www.windmill.dev/docs/advanced/local_development
      Neden Windmill ile “senkronize” olmak gerektiğini, neden Windmill’in içinde bir IDE bulunduğunu ve neden bu kadar karmaşık olduğunu anlamıyorum. Sanki iyi bir ürün yapmak ya da product-market fit bulmaktan önce vendor lock-in hedeflenerek yola çıkılmış gibi görünüyor
    • Karşılaştırma güzel ama Maestro Apache lisanslı olsa bile CockroachDB’ye bağımlıysa, CockroachDB’nin kendisi açık kaynak olmadığından bu çok da iyi değil
      Açık kaynak olmayan bir bağımlılıktansa AGPL codebase bana daha iyi geliyor. Elbette zamanla birileri alternatif veritabanı desteği ekleyebilir

  • Burada tam olarak ne olduğuna biraz şaşırdım. Bu proje Netflix/conductor [0] kullanıyor gibi görünüyor. Ama o depoya gidince arşivlendiğine ve Netflix’in dahili, açık kaynak olmayan bir sürümü ile adı anılmayan bir topluluk fork’u tarafından değiştirildiğine dair bir mesaj var. Muhtemelen Orkes Conductor [1] kastediliyor
    Ama bu, Orkes Conductor’u değil, sonlandırılmış Netflix sürümünü, yani com.netflix.conductor:conductor-core:2.31.5 [2] kullanıyor gibi görünüyor. Üstelik bu da eski bir sürüm
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • ActiveBatch kullanan biri var mı merak ediyorum. Bana göre kurumsal olmayan kullanıcılar için eşdeğer bir ürün olmasını en çok istediğim yazılım bu
    Başka “rakipleri” defalarca denemeye çalıştım ama ActiveBatch’te sıradan bir MS SQL DB bağlayıp Windows GUI ile yürütme ajanını kurduğunuzda, birkaç tıklamayla sağlam bir GUI tabanlı otomasyon ortamı elde ediyorsunuz. Kod yazmak zorunda değilsiniz, ama isterseniz istediğiniz dilde kod da yazabiliyorsunuz
    Airflow güçlü olabilir ama karmaşıklık bariyerinin arkasına saklandığı için, gerçek yetenekleri ne olursa olsun çoğu insan bunları göremiyor. Diğer “açık kaynak” rakipler için de aynı şey geçerli
    Neden kimsenin sağlam bir DB tabanlı, önce GUI yaklaşımını benimseyen sistem yapamadığını anlamıyorum. Çevrimiçi servisleri de denedim ama kıyas bile kabul etmiyorlar. Daha basit ücretli ürünlerin başarısız olmasının nedeni, eklenti yeteneklerini sürdürmenin maliyeti olabilir
    ActiveBatch’in aptalca bir kurumsal satış modelinin arkasına sıkışmış olması gerçekten üzücü. Bu harika yazılımın daha geniş bir topluluğa yayılmasını engelliyor. Gizli bir sır gibi

  • Tavsiyem şu olurdu: Netflix’in açık kaynak olarak yayımladığı araçlara bağımlı kalmamak daha iyi. Duyurduktan sonra desteği kestikleri uzun bir geçmişleri var
    Birileri bu blog yazısı ve kod yayını sayesinde terfi değerlendirme tablosunda bir kutucuğu işaretlemiş olabilir, ama böyle çözümler üzerine iş kurmamak gerekir

  • Temporal gibi daha yerleşik bir seçenek varken neden bunun değerlendirilmesi gerektiğini anlamıyorum. Maestro Java ile yazılmış; Temporal ise Go ile yazılmış gibi görünüyor

    • Temporal’in Go kodu biraz tuhaf. Eskiden Java kullandıklarını sanıyordum, sonra Go’ya geçmişler ve o Go kodu fazlasıyla Java benzeri görünüyor
      Ya da belki de ben Fx’i yeterince iyi bilmiyorumdur
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Temporal’de tekrar tekrar karşılaştığım sorun, dokümantasyonun çok yetersiz olması. İşin kalbine kurulan bir şey ama çeşitli katmanları ve oldukça anlaşılmaz belgeleri aşıp gerçekte neler olup bittiğini anlamak gerçekten çok zor
      Maestro’nun ise hiç dokümantasyonu yok gibi görünüyor. Öyleyse varsayılan kazanan Temporal olur
    • Netflix de Temporal kullanıyor: https://temporal.io/in-use/netflix
    • Bana kalırsa Maestro, Temporal’e alternatif değil de Airflow’a alternatif. Temporal bir iş akışı orkestratörü değil. İç yapılarında örtüşen kısımlar var ama farklı kullanım senaryoları için farklı şekilde tasarlanmışlar
    • Temporal’in bazı çekirdek bölümlerini Rust ile yeniden yazmadılar mı?

  • Gerçekten çok iyi görünen bir proje. Üstlendiğim neredeyse tüm ML + veri mühendisliği karması projelerde bunun neredeyse aynısını, muhtemelen daha kötü bir sürümünü yapmayı düşünüp durmuştum
    Bunu bizzat test etmeyi dört gözle bekliyorum

  • Bu alanda orchestra geliştiren biri olarak görüşümü yazayım: bunu açık kaynak yapmak ve herkese açık biçimde geliştirmek kesinlikle harika. Ama bu da kendi söylediği gibi bir orkestratör ve Airflow başta olmak üzere daha önce çıkmış pek çok seçenek zaten var
    Bu yüzden, ticari ortamda kimsenin kullanmayacağı bir seçeneği daha eklemek dışında, bu alana gerçekten ne kattığını görmek zor
    Küstah tanıtım: https://getorchestra.io

  • Bunun eskiden arşivlenmiş Conductor’dan anlamlı biçimde farklı olup olmadığını merak ediyorum. Koda göz gezdirince epey benzerlik görüyorum; iş akışı tanım dili olarak JSON kullanması da aynı