Flink SQL Benimseme Hikayesi

Flink SQL'e geçişin arka planı

• Azar Matching Dev Team'in yönettiği Flink tabanlı uygulamalar arasında 96 CPU kullanan ağır bir legacy uygulama vardı
• Bu uygulama birden fazla özelliği monolitik yapıda uyguladığı için bakımı zordu
• Altyapı çalışması kapsamında çalışan node'lar değiştirildiğinde uygulamanın düzgün çalışmaması sorunu ortaya çıktı
• Yüksek operasyonel yorgunluğu göze alarak bakımını sürdürmekle başka bir yöntemle değiştirmek arasında karar verilmesi gerekiyordu

Değerlendirilebilecek seçenekler

• Mevcut uygulamanın kritik işlevleri zaten yeni bir Flink uygulamasında hayata geçirilmişti
• Koşullu event yayımı ve mantık yürütme kısmını nasıl değiştirebileceği değerlendirildi
  1. Tek bir Flink App olarak uygulamak
     • Artı: Operasyonu kolaydır
     • Eksi: Uygulamanın büyüme ihtimali yüksektir ve bir bölüm başarısız olursa diğer işlevler de kolayca etkilenebilir
  2. Birden fazla Flink App olarak uygulamak
     • Artı: Bağımsız şekilde yönetilebilir
     • Eksi: Uygulama sayısı arttıkça yük de artar
  3. Flink SQL kullanmak
     • Artı: Mantık sorgularla tanımlanabilir, yalnızca tek bir cluster yönetilir
     • Eksi: Karmaşık mantıkları ifade etmek zordur ve cluster yönetimine alışkın değilseniz zor olabilir

Flink SQL'in seçilme nedenleri ve alternatif teknolojilerle karşılaştırma

• Flink SQL'i devreye almadan önce ksqlDB ve Spark Structured Streaming incelendi
• Flink SQL'in seçilme nedenleri:
  1. High Availability
     • Checkpoint ve Savepoint sayesinde uygulama durumu güvenli biçimde kaydedilip geri yüklenebilir
     • JobManager, HA modunda yapılandırılabilir
  2. Gelişmiş streaming özellikleri desteği
     • SQL söz dizimiyle çeşitli streaming işleme özellikleri desteklenir
     • Window, join, event time işleme ve watermark gibi özellikler desteklenir
  3. UDF ve Custom Connector ile genişletilebilirlik
     • Kullanıcı tanımlı fonksiyonlar ile çeşitli veri kaynaklarına ve sink'lere bağlanmak mümkündür

vs ksqlDB

• Confluent platformuna dahildir, ancak stateful streaming işlemede HA davranışı verimsizdir

vs Spark Structured Streaming

• Spark SQL engine tabanlıdır; UDF ve Custom Sink yazılabilir
• Micro-batch birimleriyle çalıştığı için gerçek zamanlı işleme açısından dezavantajlı olabilir

Cluster ortamının kurulumu ve sorgu dağıtım yöntemi

Local'de basitçe test etmek

• Flink Cluster'ı local'de ayağa kaldırıp SQL sorgusu gönderme yöntemi tanıtılıyor

Üretim ortamındaki cluster mimarisi

• Kubernetes üzerinde Flink SQL Cluster yapılandırıldı
• Application mode ile Session mode karşılaştırıldı

GitOps yaklaşımıyla sorgu dağıtımı

• GitHub Actions kullanılarak sorgu dağıtımı ve job durdurma işlemleri gerçekleştirildi

Başlıca operation örnekleri ve troubleshooting deneyimleri

JobManager veya TaskManager fail olduğunda

• JobManager, HA ayarı sayesinde fail olsa bile işi sürdürmeye devam edebilir
• TaskManager fail olduğunda işler yeniden dağıtılarak devam eder

Sorgu fail olduğunda

• Anormal veri girişi veya yetersiz hesaplama kaynağı durumunda ortaya çıkabilir
• JSON format hatalarını yok sayma ve varsayılan değer atama ayarları yapılabilir

Cluster yeniden başlatıldığında bazı job'lar fail olduğunda

• timeout ve retry ayarlarının düzeltilmesi gerekir

Sorgudaki tek bir koşulu değiştirip yeniden dağıtmak istendiğinde

• Yalnızca basit değişikliklerde savepoint kullanılarak state geri yüklenebilir

Başlıca izleme noktaları

• numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used gibi metrikler kontrol edilmeli

Kapanış

• Flink SQL'e geçişle birlikte üretkenlik ve operasyonel verimlilik arttı
• Kararlılığı yüksek ve GitOps Controller pattern'ini hayata geçirme planı var

[flgkselql98]

Flink gibi dağıtık sistemlerde HA’yi korumak için 2~3 rack bulundurmak gerekir; ancak Kubernetes entegrasyonuyla bunun sağlandığı anlaşılıyor. Yine de sonuçta kube slave node tarafındaki kaynakları da düşünmek gerekecek; acaba sadece Flink çalıştıran node’lardan oluşan bir yapı mı kurdular diye düşündürüyor (Flink yükü sırasında slave node’ların düşmesi gibi bir sorun olabilir).
Bu açıdan bakınca Kubernetes kullanmanın bir avantajı var mı?

Ayrıca Flink’te window function kullanıldığında, o aralıktaki veri bellekte tutulurken SQL join ifadesi çalışıyor; bu trade-off açısından bakıldığında Flink gerçekten iyi bir tercih mi diye düşünüyorum. Zaman geçtikçe büyüyen SQL + job öldüğünde ortaya çıkacak büyük sorunlar...

Ben de en üst seviyedeki data source tarafında join gereken durumlarda Flink kullanmadan, bunu application level’a indirip hangi yöntemle işleyebileceğimizi düşünüyorum.