Bu, Tanzu CloudHealth'ten (VMware by Broadcom) Rivlin Pereira ve Vaibhav Pandey ile birlikte yazılan bir yazıdır.

VMware Tanzu CloudHealth Dünya çapında 20,000'den fazla kuruluşun tercih ettiği, en büyük ve en karmaşık çoklu bulut ortamlarını optimize etmek ve yönetmek için bulut maliyet yönetimi platformudur. Bu yazıda, VMware Tanzu CloudHealth DevOps ekibinin kendi kendini yöneten Apache Kafka iş yüklerini (sürüm 2.0 çalıştıran) Tanzu CloudHealth'e nasıl geçirdiğini tartışıyoruz. Apache Kafka için Amazon Tarafından Yönetilen Akış (Amazon MSK) 2.6.2 sürümünü çalıştırıyor. Sistem mimarilerini, dağıtım hatlarını, konu oluşturmayı, gözlemlenebilirliği, erişim kontrolünü, konu geçişini ve mevcut altyapıyla karşılaştığımız tüm sorunları, yeni Kafka kurulumuna nasıl ve neden geçtiğimizi ve öğrendiğimiz bazı dersleri tartışıyoruz.

Kafka kümesine genel bakış

Hızla gelişen dağıtılmış sistemler ortamında, VMware Tanzu CloudHealth'in yeni nesil mikro hizmet platformu, mesajlaşma omurgası olarak Kafka'ya güveniyor. Bizim için Kafka'nın yüksek performanslı dağıtılmış günlük sistemi, büyük veri akışlarını yönetme konusunda üstündür ve bu da onu kesintisiz iletişim için vazgeçilmez kılmaktadır. Dağıtılmış bir günlük sistemi olarak hizmet veren Kafka, HTTP sunucusu erişim günlüklerinden güvenlik olayı denetim günlüklerine kadar çeşitli günlükleri verimli bir şekilde yakalar ve saklar.

Kafka'nın çok yönlülüğü, önemli mesajlaşma modellerini desteklemesinde, mesajları temel günlükler veya yapılandırılmış anahtar/değer depoları olarak ele almasında ön plana çıkıyor. Dinamik bölümleme ve tutarlı sıralama, verimli mesaj organizasyonu sağlar. Kafka'nın sarsılmaz güvenilirliği, veri bütünlüğüne olan bağlılığımızla uyumludur.

Ruby hizmetlerinin Kafka ile entegrasyonu, Karafka kütüphanesi aracılığıyla kolaylaştırılmıştır ve üst düzey bir sarmalayıcı görevi görmektedir. Diğer dil yığını hizmetlerimiz de benzer sarmalayıcılar kullanır. Kafka'nın güçlü hata ayıklama özellikleri ve yönetim komutları, sorunsuz operasyonlar ve altyapı sağlığının sağlanmasında önemli bir rol oynar.

Mimari bir sütun olarak Kafka

VMware Tanzu CloudHealth'in yeni nesil mikro hizmet platformunda Kafka, kritik bir mimari yapı taşı olarak ortaya çıkıyor. Yüksek veri hızlarını yönetme, çeşitli mesajlaşma modellerini destekleme ve mesaj dağıtımını garanti etme yeteneği, operasyonel ihtiyaçlarımızla kusursuz bir şekilde uyum sağlar. Biz yenilik yapmaya ve ölçeklendirmeye devam ederken Kafka, dayanıklı ve verimli bir altyapı oluşturmamıza olanak tanıyan sadık bir yol arkadaşı olmaya devam ediyor.

Neden Amazon MSK'ya geçtik?

Bizim için Amazon MSK'ya geçiş üç önemli karar noktasına geldi:

• Basitleştirilmiş teknik işlemler – Kafka'yı kendi kendini yöneten bir altyapı üzerinde çalıştırmak bizim için operasyonel bir yüktü. Bir süredir Kafka sürüm 2.0.0'ı güncellememiştik ve Kafka aracıları üretimde kalıyordu, bu da konuların çevrimdışına çıkmasıyla ilgili sorunlara neden oluyordu. Ayrıca çoğaltma faktörlerini artırmak ve liderleri yeniden dengelemek için komut dosyalarını manuel olarak çalıştırmak zorunda kaldık; bu da ek bir manuel çaba gerektiriyordu.
• Kullanımdan kaldırılan eski işlem hatları ve basitleştirilmiş izinler – Yazılı mevcut boru hatlarımızdan uzaklaşmak istiyorduk yanıtlayıcı ' küme üzerinde Kafka konularını oluşturmak için. Ayrıca ekip üyelerine sahneleme ve prodüksiyon sırasında Kafka makinelerine erişim verme konusunda hantal bir süreç yaşadık ve bunu basitleştirmek istedik.
• Maliyet, yama ve destek - Çünkü Apaçi Hayvanat Bahçesi Bekçisi Tamamen AWS tarafından yönetiliyor ve yamalanıyor, Amazon MSK'ya geçmek bize zaman ve para tasarrufu sağlayacaktı. Ayrıca Amazon MSK'yı aynı tür aracılarla çalıştırmanın Amazon Elastik Bilgi İşlem Bulutu (Amazon EC2) Amazon MSK'da çalıştırmak daha ucuzdu. AWS tarafından aracılara güvenlik yamalarının uygulanmasını sağladığımız gerçeğiyle birleştiğinde, Amazon MSK'ya geçiş kolay bir karar oldu. Bu aynı zamanda ekibin diğer önemli şeyler üzerinde çalışmak üzere serbest kalması anlamına da geliyordu. Son olarak, yönetilen bir çözüme geçme konusundaki nihai kararımızda AWS'den kurumsal destek almak da kritik öneme sahipti.

Amazon MSK'ya nasıl geçtik?

Belirlenen temel etkenlerin ardından, kendi kendini yöneten mevcut Kafka'yı Amazon MSK'ya geçirmek için önerilen bir tasarımla ilerlemeye başladık. Gerçek uygulamadan önce aşağıdaki geçiş öncesi adımları gerçekleştirdik:

• Değerlendirme:
  • Mevcut EC2 Kafka kümesinin yapılandırmalarını ve bağımlılıklarını anlayarak titiz bir değerlendirme gerçekleştirdik
  • Amazon MSK ile doğrulanmış Kafka sürümü uyumluluğu
• Terraform ile Amazon MSK kurulumu
• Ağ yapılandırması:
  • EC2 Kafka ve MSK kümeleri arasında kesintisiz ağ bağlantısı sağlandı, güvenlik gruplarına ve güvenlik duvarı ayarlarına ince ayar yapıldı

Geçiş öncesi adımlardan sonra yeni tasarım için aşağıdakileri uyguladık:

• MSK kümeleri için otomatik dağıtım, yükseltme ve konu oluşturma işlem hatları:
  • Yeni kurulumda, bir IaC aracı kullanarak MSK kümelerinin otomatik dağıtımlarını ve yükseltmelerini tekrarlanabilir bir şekilde yapmak istedik. Bu nedenle MSK kümesi dağıtımları ve yükseltmeleri için özel Terraform modülleri oluşturduk. Bu modüller bir yerden çağrıldığında Jenkins MSK kümelerinin otomatik dağıtımları ve yükseltmeleri için boru hattı. Kafka konusu oluşturmak için, Ansible tabanlı, evde yetiştirilen bir işlem hattı kullanıyorduk; bu, istikrarlı değildi ve geliştirme ekiplerinden çok sayıda şikayete yol açtı. Sonuç olarak, dağıtım seçeneklerini değerlendirdik. Kubernetes kümeler oluşturduk ve kullandık Strimzi Konu Operatörü MSK kümelerinde konular oluşturmak için. Konu oluşturma, geliştirici ekiplerinin kendi kendine hizmet verebileceği Jenkins işlem hatları kullanılarak otomatikleştirildi.
• Kümeler için daha iyi gözlemlenebilirlik:
  • Eski Kafka kümelerinin gözlemlenebilirliği iyi değildi. Yalnızca Kafka komisyoncusu disk boyutuyla ilgili uyarılar aldık. Amazon MSK'nın avantajlarından yararlandık açık izleme kullanma Prometheus. MSK kümelerinden ölçümler alan ve bunları dahili gözlemlenebilirlik aracımıza gönderen bağımsız bir Prometheus sunucusu kurduk. Geliştirilmiş gözlemlenebilirliğin bir sonucu olarak, Amazon MSK için eski kurulumumuzla mümkün olmayan güçlü uyarıları ayarlayabildik.
• Geliştirilmiş COGS ve daha iyi bilgi işlem altyapısı:
  • Eski Kafka altyapımız için, Kafka ve Zookeeper bulut sunucularının yönetiminin yanı sıra ek aracı depolama maliyetleri ve veri aktarım maliyetlerini ödemek zorundaydık. Amazon MSK'ya geçişle birlikte Zookeeper tamamen AWS tarafından yönetildiği için yalnızca Kafka düğümleri, aracı depolama ve veri aktarım maliyetlerini ödemek zorunda kalıyoruz. Sonuç olarak, Amazon MSK'nın üretime yönelik nihai kurulumunda yalnızca altyapı maliyetlerinden değil aynı zamanda operasyonel maliyetlerden de tasarruf ettik.
• Basitleştirilmiş işlemler ve gelişmiş güvenlik:
  • Amazon MSK'ya geçişle birlikte herhangi bir Zookeeper bulut sunucusunu yönetmek zorunda kalmadık. Broker güvenlik yaması da bizim için AWS tarafından halledildi.
  • Amazon MSK'ya geçişle küme yükseltmeleri daha kolay hale geldi; Amazon MSK konsolundan başlatılması kolay bir işlemdir.
  • Amazon MSK ile komisyoncumuz var otomatik ölçeklendirme kutudan dışarı. Sonuç olarak, aracıların disk alanının yetersiz kalması konusunda endişelenmemize gerek kalmadı, bu da MSK kümesinin daha fazla kararlılığa sahip olmasını sağladı.
  • Amazon MSK'nın varsayılan olarak kullanımda olmayan şifrelemeyi desteklemesi ve aktarım sırasında şifrelemeye yönelik çeşitli seçeneklerin de mevcut olması nedeniyle küme için ek güvenliğe de sahip olduk. Daha fazla bilgi için bkz. Apache Kafka için Amazon Yönetilen Akışta veri koruması.

Geçiş öncesi adımlarımız sırasında, üretime geçmeden önce hazırlama ortamındaki kurulumu doğruladık.

Kafka konu taşıma stratejisi

MSK kümesi kurulumu tamamlandıktan sonra, Kafka konularının Amazon EC2 üzerinde çalışan eski kümeden yeni MSK kümesine veri geçişini gerçekleştirdik. Bunu başarmak için aşağıdaki adımları gerçekleştirdik:

• MirrorMaker'ı Terraform ile kurma – Bir uygulamanın dağıtımını düzenlemek için Terraform'u kullandık Ayna Yapıcı 15 düğümden oluşan küme. Bu, geçişin eş zamanlı çoğaltma ihtiyaçlarına göre düğüm sayısını ayarlayarak ölçeklenebilirliği ve esnekliği gösterdi.
• Eşzamanlı bir çoğaltma stratejisi uygulayın – Geçiş sürecini hızlandırmak için 15 MirrorMaker düğümüyle eşzamanlı bir çoğaltma stratejisi uyguladık. Terraform odaklı yaklaşımımız, geçiş sırasında kaynakları verimli bir şekilde yöneterek maliyet optimizasyonuna katkıda bulundu ve MSK ile MirrorMaker kümelerinin güvenilirliğini ve tutarlılığını sağladı. Ayrıca seçilen kurulumun veri aktarımını nasıl hızlandırdığını, hem zamanı hem de kaynakları nasıl optimize ettiğini gösterdi.
• Verileri taşı – 2 TB veriyi son derece kısa bir zaman diliminde başarıyla taşıdık, kesinti süresini en aza indirdik ve eşzamanlı çoğaltma stratejisinin verimliliğini sergiledik.
• Taşıma sonrası izlemeyi ayarlama – Geçiş sırasında güçlü bir izleme ve uyarı sistemi uyguladık ve sorunları hızlı bir şekilde belirleyip ele alarak sorunsuz bir sürece katkıda bulunduk.

Aşağıdaki şemada konu geçişi tamamlandıktan sonraki mimari gösterilmektedir.

Zorluklar ve öğrenilen dersler

Özellikle büyük veri kümeleriyle geçiş yolculuğuna çıkmak çoğu zaman öngörülemeyen zorlukları da beraberinde getirir. Bu bölümde, MirrorMaker kullanarak konuların EC2 Kafka'dan Amazon MSK'ya taşınması sırasında karşılaşılan zorlukları inceliyor ve geçişimizin başarısını şekillendiren değerli öngörüleri ve çözümleri paylaşıyoruz.

Zorluk 1: Dengeleme tutarsızlıkları

Karşılaştığımız zorluklardan biri, MirrorMaker'da dengeleme senkronizasyonu etkinleştirildiğinde bile kaynak ve hedef kümeler arasındaki konu dengelemelerindeki uyumsuzluktu. Buradan öğrenilen ders, konuların verileri okumak için doğru konuma sahip olmasını sağlayan ofset senkronizasyonu etkinleştirildiği sürece ofset değerlerinin mutlaka aynı olmasının gerekmediğiydi.

Bu sorunu, tüketici grupları üzerinde testler yürütmek için özel bir araç kullanarak çözdük; çevrilmiş ofsetlerin daha küçük olduğunu veya yakalandığını doğrulayarak MirrorMaker'a göre senkronizasyonu gösterdik.

2. Zorluk: Yavaş veri geçişi

Geçiş süreci bir darboğazla karşı karşıya kaldı; özellikle 2 TB'lık önemli bir veri kümesiyle veri aktarımı beklenenden daha yavaştı. 20 düğümlü MirrorMaker kümesine rağmen hız yetersizdi.

Ekip, bunun üstesinden gelmek için MirrorMaker düğümlerini benzersiz bağlantı noktası numaralarına göre stratejik olarak gruplandırdı. Her biri farklı bir bağlantı noktasına sahip olan beş MirrorMaker düğümünden oluşan kümeler, verimi önemli ölçüde artırarak verileri günler yerine saatler içinde taşımamıza olanak sağladı.

Zorluk 3: Ayrıntılı süreç dokümantasyonunun eksikliği

MirrorMaker'ı kullanarak büyük veri kümelerini taşımanın keşfedilmemiş bölgesinde gezinmek, bu tür senaryolar için ayrıntılı belgelerin bulunmadığını ortaya çıkardı.

Ekip, deneme yanılma yoluyla Terraform'u kullanarak bir IaC modülü hazırladı. Bu modül, tüm küme oluşturma sürecini optimize edilmiş ayarlarla kolaylaştırarak geçişin dakikalar içinde sorunsuz bir şekilde başlatılmasını sağladı.

Son kurulum ve sonraki adımlar

Amazon MSK'ya taşınmamız sonucunda konu geçişi sonrasındaki son kurulumumuz aşağıdaki şemaya benzedi.

Gelecekteki aşağıdaki iyileştirmeleri düşünüyoruz:

SONUÇ

Bu yazıda VMware Tanzu CloudHealth'in mevcut Amazon EC2 tabanlı Kafka altyapısını Amazon MSK'ya nasıl taşıdığını ele aldık. Yeni mimari, dağıtım ve konu oluşturma işlem hatları, gözlemlenebilirlik ve erişim kontrolü iyileştirmeleri, konu taşıma zorlukları ve mevcut altyapıda karşılaştığımız sorunların yanı sıra yeni Amazon MSK kurulumuna nasıl ve neden geçtiğimizi size anlattık. Ayrıca Amazon MSK'nın bize sağladığı tüm avantajlardan, bu geçişle elde ettiğimiz son mimariden ve öğrendiğimiz derslerden de bahsettik.

Bizim için dengeleme senkronizasyonu, stratejik düğüm gruplaması ve IaC arasındaki etkileşim, engellerin aşılmasında ve Amazon EC2 Kafka'dan Amazon MSK'ya başarılı bir geçişin sağlanmasında çok önemli olduğunu kanıtladı. Bu gönderi, göçün getirdiği zorluklarda uyum sağlama ve yenilikçiliğin gücünün bir kanıtı olarak hizmet ediyor ve benzer yolda ilerleyen diğer kişilere içgörüler sunuyor.

AWS'de kendi kendini yöneten Kafka'yı çalıştırıyorsanız yönetilen Kafka teklifini denemenizi öneririz. Amazon MSK'sı.

Yazarlar Hakkında

Rivlin Pereira VMware Tanzu Bölümünde Personel DevOps Mühendisidir. Kubernetes konusunda oldukça tutkulu ve ölçeklenebilir, güvenilir ve uygun maliyetli bulut çözümleri oluşturmak ve işletmek için CloudHealth Platformu üzerinde çalışıyor.

Vaibhav PandeyBroadcom'da Kadrolu Yazılım Mühendisi olan , bulut bilişim çözümlerinin geliştirilmesine önemli katkıda bulunanlardan biridir. Veri depolama katmanlarının mimarisinde ve mühendisliğinde uzmanlaşan kendisi, SaaS uygulamalarını optimum performans için oluşturma ve ölçeklendirme konusunda tutkulu.

Raj Ramasubbu Amazon Web Services ile büyük veri ve analitiğe ve AI/ML'ye odaklanan Kıdemli Analitik Uzmanı Çözüm Mimarıdır. Müşterilerin AWS üzerinde yüksek düzeyde ölçeklenebilir, performanslı ve güvenli bulut tabanlı çözümler tasarlamasına ve oluşturmasına yardımcı olur. Raj, AWS'ye katılmadan önce 18 yılı aşkın bir süredir veri mühendisliği, büyük veri analitiği, iş zekası ve veri bilimi çözümleri oluşturma konusunda teknik uzmanlık ve liderlik sağladı. Sağlık hizmetleri, tıbbi cihazlar, yaşam bilimleri, perakende, varlık yönetimi, araba sigortası, konut GYO'su, tarım, tapu sigortası, tedarik zinciri, belge yönetimi ve emlak gibi çeşitli sektörlerdeki müşterilere yardımcı oldu.

Todd McGrath Amazon Web Services'te veri akışı uzmanıdır ve müşterilere akış stratejileri, entegrasyon, mimari ve çözümler konusunda tavsiyelerde bulunur. Kişisel olarak, 3 gencini tercih ettikleri aktivitelerde izlemeyi ve desteklemenin yanı sıra balık tutmak, turşu oynamak, buz hokeyi yapmak ve arkadaşları ve ailesiyle duba teknelerinde mutlu saatler geçirmek gibi kendi uğraşlarını takip etmekten hoşlanıyor. LinkedIn'de onunla bağlantı kurun.

Satya Pattanaik AWS'de Kıdemli Çözüm Mimarıdır. ISV'lerin AWS Cloud'da ölçeklenebilir ve dayanıklı uygulamalar oluşturmasına yardımcı oluyor. AWS'ye katılmadan önce Kurumsal segmentlerin büyümesi ve başarısıyla önemli bir rol oynadı. İş dışında, "lezzetli bir barbekünün nasıl pişirileceğini" öğrenerek ve yeni tarifler deneyerek vakit geçiriyor.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/