Teknoloji

Kafka yük altında ve değişiklik sırasında öngörülebilir çalışsın

Kafka kestirmelere uzun süre göz yumar, sonra bir yoğunlukta, bir rebalance sırasında ya da bir yükseltmede bozulur. Partition’ları, anahtarları, istemcileri, şemaları ve kümenin kendisini inceler, risk sırasına göre düzeltiriz.

Görüşme talep edin Olay Güdümlü Mimari hizmetine bakın

Süre: 4 ila 12 hafta
Model: İncele, düzelt, devret
Çıktı: Sağlıklı küme, şema kuralları ve işletim kılavuzları

Bu hizmete ihtiyaç duyduğunuzun işaretleri

Her biri, erken yapılıp bir daha gözden geçirilmemiş bir tercihe işaret eder.

Her yoğunlukta consumer lag tırmanıyor; partition başına bir consumer’a ulaşıldıktan sonra yeni consumer eklemek işe yaramıyor.
Consumer group’lar saatte birkaç kez rebalance oluyor ve işleme her seferinde duruyor.
Birkaç anahtar trafiğin çoğunu taşıdığı için bir partition diğerlerinden çok daha yoğun.
Bir producer’da yeniden adlandırılan bir alan aşağı akıştaki consumer’ları bozdu, çünkü şema uyumluluğu kontrol edilmiyor.
Dağıtımlardan ve rebalance’lardan sonra mükerrer mesajlar görülüyor ve exactly-once’ın sizin kurulumunuzda neyi kapsadığından kimse emin değil.
Partition sayıları ilk gün belirlendi; şimdi artırmak, her anahtarın hangi partition’a düştüğünü değiştirir.
Küme hâlâ ZooKeeper ile ve birkaç sürüm geriden çalışıyor; yükseltmeyi kimse üstlenmek istemiyor.

Bariz çözümler neden ters teper

Kafka ile başlamak kolaydır. Varsayılan ayarlar, ilk gün seçilen bir partition sayısı ve ilk producer’ı yazan kişinin seçtiği anahtarlar bir sistemi uzun süre taşır. Sorunlar sonra ortaya çıkar: en yüksek yükte, bir dağıtım sırasında ya da ikinci bir ekip aynı topic’leri okumaya başladığında.

Bariz çözümler çoğu zaman durumu kötüleştirir. Partition eklemek bir anahtarın hangi partition’a düştüğünü değiştirir; yolda olan anahtarlar için sıralama bozulur. Bir consumer group’a partition sayısından fazla consumer eklemek hiçbir şey kazandırmaz. Transaction’lar Kafka içinde exactly-once işleme sağlar, ama veritabanına yazan bir consumer aynı mesajı yine iki kez uygulayabilir. Yönetilen bir servis broker işletimini üstlenir, tasarım kararlarını değil.

Bu hizmet Kafka’nın kendisiyle ilgilidir: küme, istemciler, şemalar ve araçlar. Hangi akışların olaya dönüşeceğine ve servislerin nasıl tutarlı kalacağına karar vermek Olay Güdümlü Mimari hizmetinin konusudur; ekipler çoğu zaman önce onu yapar, sonra platformun bu yükü taşıması için bu hizmeti kullanır.

Kapsama girenler ve girmeyenler

Dahildir

Topic, partition, anahtar, saklama (retention) ve compaction tasarımı
Producer ayarları: idempotence, onaylar (acks), batching ve tekrar denemeler
Consumer group davranışı, rebalance ve lag alarmları
Schema registry ve topic başına uyumluluk kuralları
Transactional outbox ve change data capture, örneğin Kafka Connect üzerinde Debezium ile
Küme sağlığı, güvenlik ve yükseltmeler; ZooKeeper’dan KRaft’a geçiş dahil
Yönetilen ya da kendi barındırdığınız küme: Amazon MSK, Confluent Cloud, Azure Event Hubs’ın Kafka uç noktası ya da kendi broker’larınız

Dahil değildir

Hangi iş akışlarının olaya dönüşeceğine karar vermek
Stream processing ve analitik uygulamaları geliştirmek
Ölçülmüş bir gerekçe olmadan çalışan bir RabbitMQ kurulumunu değiştirmek
Devirden sonra kümenin günlük işletimi

İş nasıl ilerler

Hafta 1 ila 2Platformu haritalayın. Küme metriklerine, topic yapılandırmasına, istemci ayarlarına ve şemalara salt okunur erişimle her topic’i producer’ları, consumer’ları, anahtarları ve sahibiyle eşleştiririz. Lag, rebalance’lar ve partition dengesizliği gerçek yoğunluklarda ölçülür.
Hafta 3Riskleri sıralayın. Bulgular önce neyin bozulacağına göre sıralanır: acks=1 ya da düşük bir min.insync.replicas gibi veri kaybettirebilecek ayarlar, hatalı sıralama varsayımları, eksik şema kontrolleri ve kapasite sınırları.
Hafta 4 ve sonrasıGeri alınabilir adımlarla düzeltin. İstemci, topic, şema ve connector değişiklikleri dağıtım hattınızdan tek tek geçer; lag ve hata oranları öncesi ve sonrasıyla karşılaştırılır. Bir aşama için verilen yazma yetkisi aşama bitince kaldırılır.
Süreç boyuncaArızayı prova edin. Bir broker’ın kaybı, bir consumer çökmesi, bir poison message ve bir yeniden oynatma ekibinizle birlikte denenir; böylece kılavuzlar gerçekte ne olduğunu anlatır.
Son haftaDevredin. Tüm çıktılar, bunları sahiplenecek mühendislerle birlikte tek tek geçilir.

Elinize ne geçiyor

Yapılandırma ve her diyagramın kaynak dosyaları dahil tüm çıktılar size aittir.

Topic kataloğu

Her topic; anahtarları, partition’ları, saklama süresi, şeması, producer’ları, consumer’ları ve sahibiyle.

Kod olarak yapılandırma

Topic’ler, erişim kuralları ve connector’lar deponuzda tanımlıdır; değişiklikler pull request ile yapılır.

Şema kontrolleri

Registry kurulumu, her subject için bir uyumluluk kuralı ve kırıcı değişiklikleri merge edilmeden durduran bir pipeline kontrolü.

Lag ve sağlık panoları

Her consumer group için mesaj ve süre cinsinden lag, rebalance’lar, eksik replikalı partition’lar ve broker diski; alarmlarıyla birlikte.

İşletim kılavuzları

Broker arızası, topic’i yeniden oynatma, consumer offset sıfırlama, poison message’lar, partition değişiklikleri ve küme yükseltmeleri.

Karar kayıtları

Yönetilen ya da kendi barındırdığınız küme, partition’lama ve teslim semantiği; her biri alternatifleri ve ödünleşimleriyle.

Hangi durumda doğru hizmet değil

Hacmi mütevazı olan ve RabbitMQ ya da yönetilen bir kuyruğun zaten iyi taşıdığı sistemler. Kafka, karşılığını vermesi gereken bir işletim yükü getirir.
Asıl sorunu broker değil, servisler arası tutarlılık olan ekipler. Bu iş Dağıtık Sistem Tasarımı ile başlar.
Kafka’yı günün her saati işletecek birini arayan kurumlar. Biz düzeltir, belgeler ve devrederiz.

Sık sorulanlar

RabbitMQ’dan Kafka’ya geçmeli miyiz?

Yalnızca Kafka’nın farklı yaptığı şeylere ihtiyacınız varsa: yeniden oynatılabilir bir olay geçmişi, aynı akışın birçok bağımsız consumer’ı ya da mevcut broker’ınızın kaldıramadığı bir hacim. RabbitMQ işini görüyorsa geçiş, maliyet ve yeni arıza biçimleri ekler. Önce ölçeriz; cevap hayırsa bunu açıkça söyleriz.

Yönetilen Kafka mı, kendi kümemiz mi?

Amazon MSK, Confluent Cloud ve Azure Event Hubs’ın Kafka uç noktası broker işletiminin çoğunu üstlenir; ama desteklenen özellikler, sürümler, sınırlar ve maliyetin trafikle nasıl büyüdüğü bakımından birbirinden ayrılır. Kendi kümenizi işletmek, örneğin Kubernetes üzerinde Strimzi ile, tam kontrol ve tam sorumluluk demektir. Seçenekleri iş yükünüze ve ekibinize göre karşılaştırırız.

Exactly-once teslim sözü verebilir misiniz?

Uçtan uca hayır. Idempotent producer’lar ve transaction’lar, Kafka içinde topic’ten topic’e exactly-once işleme sağlar. Bir consumer veritabanına yazdığında ya da bir API çağırdığında mükerrer mesajlar orada, idempotent yazmalarla ya da tekilleştirme anahtarlarıyla ele alınmalıdır. Bu sınırları açıkça yazarız.

Kümemiz hâlâ ZooKeeper ile çalışıyor. Bu bir sorun mu?

Evet. Kafka 4.0 ZooKeeper desteğini kaldırdı; bu yüzden ZooKeeper tabanlı bir küme, 4.x’e yükseltilmeden önce bir 3.x sürümündeyken KRaft’a taşınmalıdır. Bu geçişi bir kopya üzerinde planlar ve prova ederiz, sonra son adıma kadar geri dönüş yolu açık kalacak şekilde uygularız.

Çalışma bittikten sonra ne oluyor?

Yapılandırmanın, panoların ve işletim kılavuzlarının sahibi ekibinizdir. Birçok ekip kendi başına devam eder; bazıları daha fazla akışı platforma taşırken haftada 2 ila 3 gün çalışan bir gömülü mimarla devam eder.

Önce kısa bir teknik sohbetle başlayalım

Otuz dakika. Kafka kurulumunuzu ve nerede zorlandığını anlatırsınız, biz nereden başlayacağımızı söyleriz.

Görüşme talep edin info@futureformative.net