Bu yazıda Apache Kafka için ortamları karşılaştıran bir çalışma sunuyorum. Nihai hedef, en etkili kurulumu bulmak ve en iyi fiyat-performans oranına ulaşmaktır. Veri platformumuz, diğer pazar çözümleriyle rekabet eden, büyük veri kümeleri için analitik platformlar oluşturmaya yönelik yönetilen hizmetler sağlar. Rekabetçi kalabilmek için, güçlü yönlerimizi belirleyip geliştirmek ve daha iyi anlaşmalar sağlamak amacıyla düzenli olarak şirket içi araştırmalar yapıyoruz. Bu makale böyle bir çalışmayı sergiliyor. Şu anda platformumuz bulut sağlayıcı olarak AWS ve GCP'yi desteklemektedir. Her ikisi de birden fazla bilgi işlem nesli ve iki CPU mimarisi (Intel ve AMD ile x86 ve ARM) sunar. Yeni sürümlerin daha yeni işlemcilerdeki performansını değerlendirmek için bu kurulumları çeşitli Java Sanal Makineleri (JVM'ler) kullanarak karşılaştırıyorum. TL istiyorsanız;DR: ARM sallanır. Modern pahalı mimari her zaman “daha iyi” anlamına gelmez. Doğrudan sonuçlara atlayabilir veya metodoloji ve kurulum hakkında daha fazla bilgi edinmeye devam edebilirsiniz. Metodoloji Performansı kendi hizmetimizle test etmeyi düşündüm ancak bunu henüz desteklemediğimiz farklı ortamlarla karşılaştırmak istedim. Yeni sanal makineleri, bölgeleri ve hatta diğer bulut sağlayıcılarını incelemek istedim. Böylece, temel Kafka'yı farklı temel konteyner görüntüleri ile kullanan bir oyuncak projesi uygulayarak başladım. Bu şekilde belirli donanımlar üzerinde kıyaslama araçlarını çalıştırabilir ve performansı ölçebilirim. En ilginç sonuçları belirlemek için çeşitli konfigürasyonları test etmeyi amaçlıyorum. Bunun için, ilk bulguları filtrelemek amacıyla test matrisi fikrini kullanıyorum. Performansı daha da iyileştirmek için perf ve eBPF gibi araçları kullanarak bu bulguları derinlemesine analiz edeceğim. Test vakaları Öncelikle test hedeflerini açıklayalım. OpenJDK JVM ile çok fazla deneyimim var ancak bugün Microsoft, Amazon ve diğer şirketlerin sunduğu birçok alternatif var. Örneğin Amazon Correto, AWS için optimize edilmiş ekstra özellikler ve yamalar içerir. Müşterilerimizin çoğu AWS kullandığından bu JVM'lerin bu platformda nasıl performans gösterdiğini görmek için Amazon Correto'yu testlere dahil etmek istedim. İlk karşılaştırma için bu versiyonları seçtim: OpenJDK 11 (geriye dönük bir karşılaştırma için, eski olmasına rağmen) OpenJDK 17 (şu anda kullanımda olan JVM) Amazon Coretto 11.0.22-amzn (alternatif bir geriye dönük karşılaştırma) Amazon Coretto 17.0.10-amzn (mevcut sürümümüze alternatif) Amazon Coretto 21.0.2-amzn (daha iyi olması gereken daha yeni bir LTS sürümü) Sürümler tanımlandıktan sonra ve kullanarak Kafka görselleri oluşturmak için birkaç script hazırladım. Amazon Correto OpenJDK Görüntü ayarları Karşılaştırma testleri için Kafka ayarlarını belirli performans ölçümlerine odaklanacak şekilde değiştirdim. Farklı kombinasyonlarını test etmek istedim, bu nedenle ağ bağlantısı ve disk performansının etkilerini en aza indirmek önemliydi. Bunu veri depolama için tmpfs içeren kapları çalıştırarak yaptım: [JVM] x [instance_type] x [architecture] x [cloud_provider] podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64 Doğal olarak bu kurulum üretime yönelik değildir ancak CPU ve bellek darboğazlarını izole etmek gerekliydi. En iyi yol, ağ ve disk etkilerini testlerden çıkarmaktır. Aksi takdirde, bu faktörler sonuçları çarpıtacaktır. Minimum gecikme ve daha yüksek tekrarlanabilirlik sağlamak için aynı örnekte karşılaştırma aracını kullandım. Ayrıca ana bilgisayar ağı yapılandırmaları olmadan ve grupla yalıtılmış sanal ağlarla testler de denedim, ancak bunlar yalnızca gereksiz gecikmeyi artırdı ve paket iletme için CPU kullanımını artırdı. Tmpfs belleği dinamik olarak ayırıp parçalanmaya ve gecikmeye neden olsa da testimiz için yeterliydi. Bunun yerine, belleği statik olarak ayıran ve bu sorunları önleyen ramdisk'i kullanabilirdim, ancak tmpfs'in uygulanması daha kolaydı ve yine de aradığımız bilgileri sağlıyordu. Bizim amaçlarımız açısından doğru dengeyi sağladı. Ek olarak, verileri bellekten daha sık çıkarmak için bazı uyguladım: ekstra Kafka ayarları ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0 İşte değişikliklerin özeti: Verilerin daha hızlı kaldırılması için 15 saniyeye ayarlanmıştır ve tmpfs'deki depolamayı yönetmek için 1 GB ile sınırlıdır. Dosyaları daha hızlı döndürmek için da 256 MB olarak değiştirildi günlük tutma süresi Günlük saklama boyutu günlük segmenti boyutu Eski verileri hızlı bir şekilde silmek için 1 saniyeye düşürülür Saklama kontrol aralığı Bellek sorunlarını önlemek için 0 olarak ayarlandı Segment silme gecikmesi Bu konfigürasyon üretimde kullanıma uygun değildir ancak alakasız faktörlerin etkilerini azalttığından kıyaslama testlerimiz için önemlidir. Örnek türleri DoubleCloud olarak, bu makalenin yazıldığı tarih itibariyle, şu ana nesil bilgi işlem kaynaklarını destekliyoruz: : m5a bulut sunucuları (i1, Intel işlemcili m5'i temsil eder) s1 ailesi : m6a bulut sunucuları (i2, Intel işlemcili m6i'yi temsil eder) s2 ailesi : AMD Rome işlemcilere sahip GCP n2 standardı bulut sunucuları sg1 ailesi Graviton işlemciler için şunları destekliyoruz: : m6g bulut sunucuları (Gaviton 2) g1 ailesi : m7g bulut sunucuları (Gaviton 3) g2 ailesi Ayrıca Ampere Altra'da Graviton'a alternatif olarak GCP'de t2a bulut sunucularını test ettim. AWS'nin sınırlı bölgesel desteği nedeniyle bunları müşterilerimize sunmuyoruz ancak performansı karşılaştırmak için bunları kıyaslamalara dahil ettim. Eğer “doğru” bölgelerden birindeyseniz bunlar iyi bir seçenek olabilir. Karşılaştırma aracı Karşılaştırma için temel alan hafif bir geliştirdim. Bu araç, kendisi bir darboğaza dönüşmeden Kafka'yı verimli bir şekilde doyurur. franz-go kütüphanesini ve örneğini araç güvenilirliği ve popülaritesi ile bilinse de cgo ile ilgili olası sorunlar nedeniyle bundan kaçındım. Librdkafka Ölçek Kafka, iş yüklerini aracılar arasında yatay olarak verimli bir şekilde dağıtmak için konuların birden fazla bölüme ayrılmasına olanak tanıyan ölçeklenebilirliğiyle tanınır. Ancak performans-fiyat oranına özel olarak odaklandığımız için tek çekirdek performansını değerlendirmeye odaklandım. Bu nedenle testlerde, bireysel çekirdek yeteneklerin tam olarak kullanılması için tek bölümlü konular kullanıldı. Her test senaryosu iki tür içeriyordu: Eşzamanlı üretim: Mesaj onayını bekler; gerçek zamanlı uygulamalar gibi milisaniyelerin önemli olduğu düşük gecikmeli ortamları ölçmek için idealdir Eşzamansız üretim: mesajları arabelleğe alır ve toplu olarak gönderir; bu, 10-100 ms'lik tolere edilebilir gecikme süresiyle neredeyse gerçek zamanlı ihtiyaçları dengeleyen Kafka istemcileri için tipiktir Konu bölümü konularını tamamen doyurmak için ortalama bir müşteri vakasından daha büyük olan 8 KB'lık mesajlar kullandım. Sonuçlar Farklı mimarileri değerlendirmek için sentetik bir kullanarak farklı test senaryolarını karşılaştıran bir dizi grafik sunuyorum. Bu ölçüm ölçerek mimari maliyet verimliliğinin basit bir değerlendirmesini sağlar. verimlilik ölçüsü , Kafka komisyoncusuna aktarabileceğimiz milyonlarca satırı yüzde olarak Bulut sağlayıcılarının ek indirimleri nedeniyle gerçek sonuçların değişebileceğini kabul etmek önemlidir. Mümkün olduğunda testler her iki bulut sağlayıcı için de Frankfurt'ta (veya bulut sunucusu türü seçeneklerinin kısıtlandığı durumlarda Hollanda'da) gerçekleştirildi. Grafikler Tüm çizelgelerde, örneğin sağlayıcılarının kullandığı geleneksel adları kullanıyorum. Bulut sunucuları önce bulut sağlayıcılarına (AWS, ardından GCP) ve ardından nesile göre eskiden yeniye doğru sıralanır. Ham biçimde de olsa sonuçların tamamı mevcuttur. Burada, gecikme ve bant genişliği sayıları ve farklı JVM'lerin karşılaştırmalı performansı da dahil olmak üzere bu makalede sunduğumdan daha fazla veri bulabilirsiniz. kapsamlı kıyaslama sayfamda AWS bulguları s1 ailesi: en yavaş performans 2019'un 3. çeyreğine kadar uzanan, AMD EPYC 7571'e sahip m5a neslini temel alan "1. nesil" s1 bulut sunucuları eski seçeneğimizdir. Bunlar Frankfurt'taki seçeneklerimiz arasında en az verimli ve en yavaş olanıdır ve talep üzerine yaklaşık ~0,2080 €/saat maliyeti vardır. ~0,2070 €/saat maliyetle daha yeni s2 ailesine geçiş, temelde aynı fiyata iki kat verimlilik sağlar. Analitik uygulamalar için sorgulama sürelerini ve alım hızını artırmak amacıyla müşterilerimizi bu daha uygun maliyetli ve performanslı seçeneklere geçmeye teşvik ediyoruz. g1 ailesi: s2 ile karşılaştırılabilir verimlilik g1 ailesi Graviton 2'yi temel alır ve tarihsel olarak iyi bir değer sağlar, ancak AMD işlemcili daha yeni s2 ailesi artık Apache Kafka'nın verimlilik düzeyine ulaşıyor. Biraz daha düşük bant genişliği ve marjinal fiyat avantajı sunmasına rağmen g1 ailesi, yeni seçeneklerle karşılaştırıldığında artık modası geçmiş sayılıyor. g2 ailesi: üstün verimlilik Graviton 3 tarafından desteklenen g2 ailesi, üstün verimliliği nedeniyle en iyi önerimiz olarak öne çıkıyor. Belirli senaryolarda s2 ve i2 ailelerinden %39'a kadar daha iyi performans göstererek neredeyse tüm bölgelerde uygun maliyetli bir çözüm sunarak çoğu Apache Kafka kullanım durumu için idealdir. Kafka'nın tipik IO'ya bağlı doğası göz önüne alındığında, hesaplama verimliliğini optimize etmenin maliyet tasarrufu açısından çok önemli olduğu ortaya çıkıyor. Arm64 mimarisini benimsemeye yönelik artan bir eğilim gözlemledim; kümelerimizin neredeyse yarısı halihazırda bu yeni teknolojiden yararlanıyor. x86_64 verimlilik trendleri Testler, her yeni AMD veya Intel işlemcinin genel verim ve gecikme açısından geliştiğini gösteriyor. Buna rağmen yeni m6 ve m7 nesillerinin verimlilik kazanımları sabitlendi. Testlerimize göre m7 nesli bile bazı bölgelerde potansiyel olarak daha düşük gecikme süresi sunsa da g2 ailesiyle karşılaştırıldığında verimliliğin altında kalıyor. m7a ailesi: lider gecikme performansı m7a ailesi, düşük gecikmeli uygulamalarda öne çıkıyor ve performans ve gecikme açısından hem Intel'i hem de önceki AMD nesillerini geride bırakıyor. Bu mimari, evrensel olarak mevcut olmasa da, AMD'nin performansı artırma konusundaki ilerlemesini yansıtıyor. Bölgenizde erişilebilirse üstün sonuçlar için m7a'yı düşünün. GCP bulguları AWS ile verimlilik karşılaştırması GCP bulut sunucularının verimliliği genellikle AWS alternatiflerine göre daha düşüktür. Müşteriler genellikle analitik uygulamalardaki maliyet etkinliği ve daha düşük faturalarla sonuçlanan GCP'yi tercih ettiğinden bu benim için harika bir fikirdi. Sg1 ailemiz, AWS s2 ailesiyle karşılaştırılabilecek şekilde n2 standart neslini kullanır. Ancak bu karşılaştırmayı diğer bulut sunucusu türlerini kapsayacak şekilde genişletme girişimim, özellikle c3 ve n2 nesilleri için bölgesel kullanılabilirlik nedeniyle kısıtlandı. Arm Tau işlemciler: maliyet etkinliği GCP'nin Tau işlemcilerini kullanan arm bulut sunucuları, Graviton 2'ye göre %5-7 verimlilik artışı sunarak, bunları makul bir maliyet tasarrufu seçeneği haline getiriyor. Kol bulut sunucuları için GCP desteği dört bölgeyle sınırlı olsa da g1 ailesiyle karşılaştırılabilir performans ve verimlilik sağlar. bölgenizde mevcut olması halinde Uzun süreli kullanım indirimleri Apache Kafka kümeleri sürekli VM kullanımına sahip olduğundan, yararlanmak %20'ye varan indirimlere olanak tanır. Bu, Ampere Altra gibi daha eski hesaplama güçlerini verimlilik açısından Graviton 3 ile rekabet edebilir hale getiriyor. Ancak geçerli olabilecek ek AWS indirimleri nedeniyle burada doğrudan karşılaştırmalar yapmak zordur. Uzun Süreli Kullanım İndirimlerinden JVM öngörüleri ARM mimarisindeki daha yeni JVM sürümleriyle önemli bir gelişme göreceğimi düşündüm. Ancak görünen o ki openjdk-11 ve corretto-11 zaten ARM için oldukça optimize edilmiş durumda. Kafka'nın yeni sürümleri Java 17 ve üstünü gerektirdiğinden Java 17'ye geçtim ve bu da kıyaslamalarımızda yaklaşık %4-8 performans artışı sağladı. Ayrıca 21.0.2-amzn, yeni bulut sunucusu türlerinde ekstra %10-20 performans artışı sunarak umut verici görünüyor. Sonuçlar Zaman zaman üretim kümelerimiz için en uygun çözümleri bulmak ve faydalı bilgiler toplamak amacıyla şirket içi araştırmalar yapıyorum. ARM mimarisine geçiş, yönetilen hizmetler için avantajlıdır çünkü para tasarrufu sağlar ve enerji kullanımını azaltır. ARM'lere güvenmenin yararlı olduğu, hem Apache Kafka için Yönetilen Hizmetin hem de ClickHouse için Yönetilen Hizmetin performansının ve maliyet verimliliğinin arttığı kanıtlanmıştır. Bu araştırma, daha fazla optimizasyon için en verimli ortamları ve alanları belirleyerek test matrisimizin iyileştirilmesine yardımcı oldu. Her zaman bunun üzerinde çalışıyoruz: başlık altında ince ayar ve iyileştirmeler yapıyoruz ve bilgimizi toplulukla paylaşmaktan mutluluk duyuyorum. Bizi izlemeye devam edin!
