Giriş

Selam arkadaşlar! Bugün Apache Flink’in en kritik konularından birine dalacağız: deployment modları ve cluster yöneticileri/kaynak sağlayıcıları (resource providers). Flink kodunu yazdınız, şimdi ne olacak?. Bu yazıda cevabını bulmaya çalışacağız.

Apache Flink, yüksek performanslı akış (stream) ve toplu (batch) veri işleme için harika bir framework. Ama işin püf noktası sadece kod yazmak değil – “bu kod nerede çalışacak?”, “kaynaklarımı nasıl yöneteceğim?”, “iş izolasyonunu nasıl sağlayacağım?” gibi sorulara da cevap bulmak gerekiyor.

Flink’in güzelliği, esnek mimarisi sayesinde bu sorulara birçok farklı kombinasyonla yanıt verebilmesi.

Flink’in Deployment Modları Nedir?

Önce temel kavramları anlayalım. “Deployment modu” dediğimiz şey, Flink işinin bir cluster ile nasıl ilişkilendirildiği, cluster’ın yaşam döngüsünün ne zaman başladığı/biteceği ve kaynak izolasyonunun nasıl sağlandığı gibi konuları kapsar [1].

Flink’in üç ana deployment modu var:

1. Session Cluster / Session Modu

Nasıl çalışır? Bir Flink cluster’ı önceden ayağa kaldırılır ve bu cluster’a birden fazla iş (job) göndeririz. Cluster kendisi sürekli çalışır; işler gelip geçer [1].

Yapısı: Tek bir JobManager var ve birden fazla TaskManager. Her yeni iş, aynı cluster üzerindeki paylaşılan kaynakları kullanır [1].

Avantajları:

• Cluster’ı her iş için yeniden açıp kapatmaya gerek yok, dolayısıyla başlatma maliyeti düşük
• Başlatma gecikmesi (startup latency) minimal – kısa işler için harika
• Hızlı geliştirme ve test döngüleri için ideal

Dezavantajları:

• Kaynak paylaşımı nedeniyle işlerin birbirini etkileme riski var (bir iş bozulursa diğerleri zarar görebilir)
• JobManager’ın yükü artar, çok sayıda işi yönetmek zorunda kalabilir
• Classpath, konfigürasyon ve güvenlik gibi konularda paylaşılan kaynak izolasyonu sorunları olabilir [1]

Kullanım senaryosu: Geliştirme ortamları, birçok küçük iş, interaktif kullanım [3]

2. Per-Job Mode (İş Başına Cluster)

Nasıl çalışır? Her bir Flink işi için ayrı bir cluster (JobManager + TaskManager seti) açılır. İş tamamlandığında bu cluster kapatılır [2].

Özellikler:

• Güçlü kaynak izolasyonu sağlar – bir işin hatası başka işleri etkilemez
• main() metodu genellikle client tarafında çalışır [2]
• Her iş için cluster açmak maliyetli olabilir (kaynak, zaman)

Not: Bu mod, Application Mode ortaya çıkmadan önce yaygındı. Flink 1.11 ile birlikte “Application Mode” tanıtılarak bu modun dezavantajları azaltılmak istendi [2].

3. Application Mode (Uygulama Modu) ⭐

Modern yaklaşım! Bir uygulama (tekil iş veya birden çok işi kapsayan) için özel cluster açılır, uygulamanın main() metodu doğrudan JobManager üzerinde çalışır, ve uygulama tamamlandığında cluster kapanır [2][3].

Mimari özellikler:

• main() metodu cluster üzerinde yürütülür, bu sayede client daha hafif hale gelir [3]
• İzolasyon seviyesi Per-Job moduna yakın, ama main() kodunun cluster tarafında çalışması veri transferi ve paket gönderme yükünü azaltır [2]
• Aynı uygulama içinde birden çok execute() çağrısına izin verir (örneğin, birden çok “alt iş” çalıştırmak) [2]

Avantajları:

• Kaynak izolasyonu + client üzerindeki yükü azaltma dengesi sağlar
• Çok aşamalı uygulamalar için mantıklı
• Production ortamlar için önerilen yaklaşım [3]

Dikkat edilmesi gerekenler:

• registerCachedFile() gibi fonksiyonlar için yolların JobManager tarafından erişilebilir olması gerekir [3]
• Yüksek erişilebilirlik (HA) sadece tek execute() uygulamaları için tam desteklenir [3]

Modların Hızlı Karşılaştırması

Cluster Yöneticileri (Resource Providers)

Deployment modları ne kadar önemliyse, bu modların cluster yöneticileri ile nasıl entegre edildiği de o kadar kritik. Çünkü gerçek kaynak yönetimi (CPU, bellek, container başlatma, ölçekleme) bu yöneticilerin kontrolünde.

Flink şu kaynak sağlayıcıları ile çalışır:

1. Standalone 🔧

Tanım: Kaynak yöneticisi olmayan, Flink’in kendi süreçleriyle yönetilen mod. JobManager ve TaskManager’lar doğrudan JVM süreçleri olarak başlatılır [4].

Avantajları:

• Basit ve direkt kontrol
• Kolay yapılandırma
• Küçük ölçekli ve on-premise ortamlar için uygun [4]

Dezavantajları:

• Dinamik kaynak yönetimi yok – ölçekleme manuel yapılır
• Bir süreç çökerse yeniden başlatma kullanıcıya kalmış [4]

Modlarla uyumu:

• Session Mode: Standalone ile en sık kullanılan mod [4]
• Application Mode: standalone-job.sh gibi betiklerle kullanılabilir [4]
• Per-Job Mode: Genellikle desteklenmez [5]

Pratik örnek: Lokal geliştirme ortamlarında start-cluster.sh ve stop-cluster.sh betikleri ile Session cluster başlatmak çok yaygın [4].

2. YARN (Yet Another Resource Negotiator) 🐘

Kimler için? Hadoop ekosisteminde kaynak yönetimi sağlayan popüler çerçeve. Flink, YARN üzerine entegre edilerek JobManager ve TaskManager’lar YARN container’ları içinde çalışabilir [6].

Desteklenen modlar:

• Session Mode (YARN Session): yarn-session.sh ile YARN uygulaması başlatılır, bu cluster’a job’lar gönderilir [6]
• Application Mode: flink run-application -t yarn-application komutuyla uygulama modunda cluster açılır [6]
• Per-Job Mode: Eski yaklaşım, artık Application Mode tercih edilir [2]

Davranış detayları:

• JobManager, YARN üzerinde Application Master (AM) gibi davranır
• TaskManager container’ları dinamik olarak eklenip çıkarılabilir
• YARN konfigürasyonları (örneğin HADOOP_CLASSPATH) doğru ayarlanmalı [6]

Avantajlar:

• Zaten bir Hadoop/YARN altyapısı varsa entegrasyon maliyeti düşük
• Dinamik kaynak yönetimi mevcut

Dezavantajlar:

• YARN dışı ortamlarda ek karmaşıklık getirir

3. Kubernetes ☸️

Modern yaklaşım! Kubernetes, konteyner orkestrasyon sistemi olarak birçok dağıtık sistemin tercihi haline geldi ve Flink de native entegrasyon sağlıyor [7].

Native Kubernetes Modu: Flink, Kubernetes API ile doğrudan konuşabilir; TaskManager’lar gerektiğinde açılıp kapatılabilir [7].

Flink Kubernetes Operator: Cluster yaşam döngüsünü deklaratif olarak yönetmek için operator kullanılır. Hem standalone hem native modda destek sağlar [7].

Mod uyumu:

• Session Mode: kubernetes-session.sh gibi betiklerle session cluster açılır [7]
• Application Mode: Uygulama JAR’ları Docker imajına gömülür, main() metodu imaj içinde çalışır [7]
• Per-Job Mode: Kullanılabilir, ancak Application Mode genellikle tercih edilir [8]

Dikkat edilmesi gerekenler:

• TaskManager sayısı başlangıçta genellikle sabit belirtilir
• Kubernetes’te HA ve konfigürasyonlar ortama özgü ayarlanmalı
• usrlib klasörü gibi bileşenleri Docker imajına dahil etmek yaygın [7]

Neden popüler? Bulut-yerel (cloud-native) mimarilerde Application Mode + operator kombinasyonu güçlü bir seçenek sunar [7][8].

4. Cloud (Yönetilen Servisler) ☁️

Bulut sağlayıcıları ve özel Flink servisleri, altyapıyı soyutlayarak daha yüksek seviye deneyim sunar.

4.1 Amazon Web Services (AWS) 🟠

Amazon Managed Service for Apache Flink

• Eski adıyla Amazon Kinesis Data Analytics for Apache Flink
• 2023’te yeniden isimlendirildi [12]
• Tam yönetimli (fully managed), serverless stream işleme servisi [12][17]
• Java, Scala, Python ve SQL desteği [17]
• Studio Notebooks: Apache Zeppelin tabanlı interaktif geliştirme ortamı [12]
• Application Mode yaklaşımını benimsiyor [20]

Özellikler:

• Otomatik ölçekleme ve yüksek erişilebilirlik
• CloudWatch ile entegre izleme [15]
• Kinesis Data Streams, MSK (Kafka), S3 gibi AWS servisleri ile kolay entegrasyon [15]
• Checkpoint ve savepoint yönetimi otomatik [15]

Dikkat: Amazon Kinesis Data Analytics for SQL Applications hizmeti 27 Ocak 2026’da sonlandırılacak – kullanıcıların Managed Service for Apache Flink’e geçmesi öneriliyor [13][18].

4.2 Microsoft Azure 🔵

Durum Güncellemesi (Önemli!):

• Azure HDInsight on AKS hizmeti 31 Ocak 2025’te sonlandırıldı [22][23]
• Microsoft, kullanıcıları Microsoft Fabric veya eşdeğer Azure ürünlerine geçmeye yönlendiriyor [22]
• Hizmet public preview aşamasındayken sonlandırıldı

Geçmiş özellikler (artık mevcut değil):

• Apache Flink, Spark ve Trino workload’larını destekliyordu [25]
• Azure Kubernetes Service (AKS) altyapısı üzerine kuruluydu [25]
• Application Mode cluster desteği vardı [29]
• Azure Data Factory ve Airflow ile entegrasyon sağlıyordu [26]

Alternatifler:

• Confluent Cloud on Azure: Azure Marketplace’te mevcut, Kafka ve Flink entegrasyonu sunuyor [7]
• Microsoft Fabric: Azure’un yeni nesil veri platformu
• Self-managed Flink on AKS: Kullanıcılar kendi AKS cluster’larında Flink deploy edebilir

4.3 Google Cloud Platform (GCP) 🟢

Google Cloud, Flink için birden fazla seçenek sunuyor:

BigQuery Engine for Apache Flink (Yeni! 🆕)

• Ekim 2024’te duyuruldu [32]
• Tam serverless, yönetilen Flink servisi
• BigQuery ile derin entegrasyon [32]
• AWS, Azure ve Google Cloud’da kullanılabilir
• AI/ML yetenekleri ile entegre (Vertex AI, Gemini) [32]
• Google Managed Service for Apache Kafka ile birlikte kullanılabilir [32]

Google Cloud Dataproc

• Apache Flink’i opsiyonel component olarak destekler [33]
• YARN üzerinde çalışır
• Session Mode desteği var [33]
• Compute Engine VM’leri üzerinde çalışır [33]

Google Cloud Dataflow

• Apache Beam tabanlı [36]
• Flink’ten farklı bir yaklaşım – Beam pipeline’larını çalıştırır
• Serverless, otomatik ölçeklenen altyapı [36]
• Flink runner desteği var (Beam pipeline’larını Flink üzerinde çalıştırabilir) [33]

Karşılaştırma: BigQuery Engine for Apache Flink, native Flink uygulamaları için; Dataflow ise Apache Beam tabanlı pipeline’lar için tercih edilir [32][36].

4.4 Confluent Cloud 🟣

Confluent Cloud for Apache Flink

• Tam serverless, yönetilen Flink servisi [2][3]
• Kafka ile derin entegrasyon – Kafka topic’leri otomatik olarak Flink table’ları olarak görünür [3]
• AWS, Azure ve Google Cloud’un üçünde de mevcut [3]
• Flink SQL, Table API (Java/Python) desteği [3]

Özellikler:

• Scale-to-zero: Kullanılmadığında kaynak serbest bırakılır, maliyetten tasarruf [3]
• Compute pools: Bölgesel servis, otomatik ölçeklenir [3]
• Entegre güvenlik, izleme ve yönetişim [2]
• AI özellikleri: Flink Native Inference, vector arama, ML fonksiyonları [10][11]

Confluent Platform for Apache Flink:

• On-premise ve private cloud için [2]
• Kubernetes üzerinde otomatik deployment [2]

Yeni özellikler (2025 Q1):

• Tableflow: Kafka topic’lerini Iceberg/Delta Lake table’larına dönüştürme [5]
• AI enhancements: Real-time embedding generation, anomaly detection [10][11]
• Instant SQL validation, time-series visualization [5]

Neden öne çıkıyor? Confluent, Kafka’nın yaratıcıları tarafından kuruldu ve Kafka + Flink’i unified platform olarak sunan tek bulut servisi [2][8].

4.5 Ververica Platform

• Ververica, Apache Flink’in yaratıcılarından biri olan Ververica (eski adıyla data Artisans) tarafından geliştiriliyor
• Tam yönetilen Flink platformu
• Community edition mevcut
• Kubernetes operator ile deployment [37]

Deployment Modları x Cluster Yöneticileri Kombinasyonları

Şimdi geldik işin eğlenceli kısmına – hangi deployment modu hangi cluster yöneticisi ile nasıl çalışır?

Gerçek Dünya Örnekleri

Örnek 1: Kubernetes + Application Mode

Senaryo: Mikroservis mimarisinde real-time veri işleme

# 1. Uygulama JAR'ını Docker imajına gömme
FROM flink:1.18
COPY my-flink-app.jar /opt/flink/usrlib/

# 2. Kubernetes manifest ile deploy
kubectl apply -f flink-application-deployment.yaml

# 3. JobManager pod'unda main() çalışır
# 4. İş bitince pod'lar otomatik kapanır

Avantajlar:

• Her uygulama izole
• Kubernetes’in otomatik restart özellikleri
• Ölçeklenebilir [7]

Örnek 2: YARN + Session Mode

Senaryo: Mevcut Hadoop cluster’ında çoklu job çalıştırma

# 1. YARN session başlat
yarn-session.sh --detached -tm 2048 -s 4

# 2. Job'ları gönder
flink run -t yarn-session examples/WordCount.jar
flink run -t yarn-session examples/PageRank.jar

# 3. Session'ı durdur
echo "stop" | yarn-session.sh -id application_xxx

Avantajlar:

• YARN’ın kaynak yönetimi
• Mevcut altyapıyı kullanma [6]

Örnek 3: Confluent Cloud – Serverless

Senaryo: Kafka topic’lerini real-time işleme

-- Kafka topic otomatik olarak table olarak görünür
CREATE TABLE pageviews_enriched AS
SELECT 
  p.user_id,
  p.page_id,
  u.name,
  u.country,
  p.timestamp
FROM pageviews p
JOIN users u ON p.user_id = u.user_id;

-- Compute pool otomatik scale eder
-- İş bitince kaynak serbest bırakılır

Avantajlar:

• Altyapı yönetimi yok
• Otomatik ölçekleme
• Kafka ile native entegrasyon [3]

En İyi Pratikler ve İpuçları 💡

1. Kaynak İzolasyonu

• Kritik production işler için: Application Mode kullanın
• Geliştirme için: Session Mode yeterli
• Bir job’un çökmesi diğerlerini etkilememeli [2][3]

2. Başlatma Süresi

• Her job için cluster açmak zaman alır
• Kısa işler için Session Mode tercih edilebilir
• Uzun süreli işler için Application Mode [3]

3. Main() Metodu Konumu

• Application Mode’da main() cluster üzerinde çalışır
• Dosya yolları ve registerCachedFile gibi fonksiyonlar için erişilebilirlik önemli [3]

4. Yüksek Erişilebilirlik (HA)

• JobManager için yedek yapılar kurun
• Checkpoint ve savepoint stratejisi belirleyin
• Kubernetes veya cloud servisleri HA’yı kolaylaştırır [15][30]

5. Otomatik Ölçekleme

• Kubernetes ve YARN dinamik kaynak yönetimi destekler
• Standalone modda bu özellik yok [4]
• Cloud servisleri en iyi ölçekleme yeteneklerini sunar [3][12]

6. Maliyet Optimizasyonu

• Geliştirme: Standalone veya Session Mode
• Production: Cloud servisleri (scale-to-zero ile) veya Kubernetes (spot instance’lar ile)
• Confluent Cloud ve AWS Managed Flink pay-as-you-go model sunar [3][12]

7. Topluluk Önerileri

• Flink topluluğu Application Mode’u ileriye dönük tercih edilen mod olarak görüyor [2]
• Per-Job mod zamanla geride kalıyor [2]

Hangi Kombinasyonu Seçmeliyim?

İşte karar ağacınız:

🔹 Eğer…

• Yeni bir proje başlıyorsanız → Kubernetes + Application Mode veya Cloud Servisi
• Mevcut Hadoop altyapınız varsa → YARN + Application Mode
• Kafka kullanıyorsanız → Confluent Cloud
• AWS ekosistemindeyseniz → AWS Managed Service for Apache Flink
• GCP kullanıyorsanız → BigQuery Engine for Apache Flink
• Geliştirme/test yapıyorsanız → Standalone + Session Mode
• Maksimum izolasyon istiyorsanız → Application Mode (herhangi bir yönetici ile)
• Altyapı yönetimi istemiyorsanız → Cloud Servisleri (AWS/GCP/Confluent)

Sonuç

Apache Flink’in gücü, hem esnek deployment modları hem de çok sayıda kaynak sağlayıcıyla çalışabilmesinden geliyor.

Öğrendiklerimiz:

• Deployment modları: İşin cluster ile nasıl ilişkilendiğini belirler
• Cluster yöneticileri: Kaynakları sağlama ve ölçekleme görevlerini üstlenir
• Modern yaklaşım: Application Mode + Kubernetes veya Cloud Servisleri
• Bulut servisleri: AWS, GCP ve Confluent Cloud güçlü yönetilen çözümler sunuyor
• Azure: HDInsight on AKS sonlandırıldı, alternatif çözümler değerlendirilmeli

Bir projede en iyi kararı verirken:

• ✅ İşin süresi
• ✅ Kaynak izolasyonu gereksinimi
• ✅ Altyapı yetenekleri
• ✅ Operasyonel karmaşıklık
• ✅ Maliyet
• ✅ Mevcut ekosistem (Kafka, Hadoop, vb.)

kriterlerini göz önünde bulundurmalısınız.

Umarım bu yazı Flink deployment dünyasında size yol gösterici olmuştur. Sorularınız varsa yorum bırakmayı unutmayın! Happy streaming! 🚀

Kaynaklar

[1] Apache Flink Documentation – Deployment Overview. https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/overview/

[2] Flink Blog – Application Deployment in Flink: Current State and the new Application Mode (2020). https://flink.apache.org/2020/07/14/application-deployment-in-flink-current-state-and-the-new-application-mode/

[3] Apache Flink 1.11 Documentation – Clusters & Deployment. https://nightlies.apache.org/flink/flink-docs-release-1.11/ops/deployment/

[4] Apache Flink Documentation – Standalone Overview. https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/resource-providers/standalone/overview/

[5] Confluent Blog – Q1 2025 Cloud Launch: Tableflow, Freight clusters, and Flink AI enhancements. https://www.confluent.io/blog/2025-q1-confluent-cloud-launch/

[6] Apache Flink Documentation – YARN Deployment. https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/resource-providers/yarn/

[7] Apache Flink Documentation – Native Kubernetes. https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/resource-providers/native_kubernetes/

[8] Ververica Blog – An Overview of Apache Flink’s Deployment Modes. https://www.ververica.com/blog/an-overview-of-apache-flinks-deployment-modes

[9] Alibaba Cloud – Principles and Practices of Flink on YARN and Kubernetes. https://www.alibabacloud.com/blog/principles-and-practices-of-flink-on-yarn-and-kubernetes-flink-advanced-tutorials_596625

[10] Confluent Press Release – New Confluent Cloud for Apache Flink Capabilities Simplify Real-Time AI Development (March 2025). https://finance.yahoo.com/news/confluent-cloud-apache-flink-capabilities-043000821.html

[11] Confluent Blog – Introducing Real-Time Embeddings: Any Model, Any Vector Database (January 2025). https://www.confluent.io/blog/latest-confluent-for-apache-flink/

[12] AWS Blog – Announcing Amazon Managed Service for Apache Flink (August 2023). https://aws.amazon.com/blogs/aws/announcing-amazon-managed-service-for-apache-flink-renamed-from-amazon-kinesis-data-analytics/

[13] AWS Blog – Migrate from Amazon Kinesis Data Analytics for SQL to Amazon Managed Service for Apache Flink (October 2024). https://aws.amazon.com/blogs/big-data/migrate-from-amazon-kinesis-data-analytics-for-sql-to-amazon-managed-service-for-apache-flink-and-amazon-managed-service-for-apache-flink-studio/

[15] AWS Documentation – Managed Service for Apache Flink: How it works. https://docs.aws.amazon.com/managed-flink/latest/java/how-it-works.html

[17] AWS Documentation – Welcome – Amazon Managed Service for Apache Flink. https://docs.aws.amazon.com/managed-flink/latest/apiv2/Welcome.html

[18] AWS Documentation – Amazon Kinesis Data Analytics for SQL Applications discontinuation. https://docs.aws.amazon.com/kinesisanalytics/latest/dev/discontinuation.html

[20] AWS Documentation – What is Amazon Managed Service for Apache Flink? https://docs.aws.amazon.com/managed-flink/latest/java/

Kapak Görseli: Photo by Joerg Breuer on Unsplash