Modern da\u011f\u0131t\u0131k sistemlerde veri ak\u0131\u015f\u0131, operasyonlar\u0131n kalbinde yer al\u0131r. Peki, farkl\u0131 bulut a\u011flar\u0131 aras\u0131nda yer alan Kafka k\u00fcmenize g\u00fcvenli, d\u00fc\u015f\u00fck gecikmeli ve y\u00fcksek performansl\u0131 bir \u015fekilde nas\u0131l eri\u015firsiniz? Bu makale, Apache Kafka’n\u0131n karma\u015f\u0131k adresleme mekanizmalar\u0131n\u0131 ve Amazon VPC Peering’in g\u00fcc\u00fcn\u00fc birle\u015ftirerek, \u00e7oklu bulut a\u011flar\u0131 aras\u0131nda sorunsuz ve g\u00fcvenli ileti\u015fim kurman\u0131n inceliklerini ad\u0131m ad\u0131m a\u00e7\u0131klayacak. Amac\u0131m\u0131z, ister yeni ba\u015flayan ister deneyimli bir m\u00fchendis olun, bu kritik entegrasyonu ba\u015far\u0131yla hayata ge\u00e7irmek i\u00e7in ihtiyac\u0131n\u0131z olan t\u00fcm teknik bilgiye ve pratik \u00f6rneklere ula\u015fman\u0131z\u0131 sa\u011flamakt\u0131r.<\/p>\n
Da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131k d\u00fcnyas\u0131nda, g\u00fcvenilir ve verimli veri ak\u0131\u015f\u0131 sa\u011flamak, her organizasyonun \u00f6nceliklerinden biridir. Bu hedefe ula\u015fmada Apache Kafka ve bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n sundu\u011fu sanal a\u011f \u00e7\u00f6z\u00fcmleri, \u00f6zellikle de VPC Peering, kritik bir rol oynar. Bu b\u00f6l\u00fcmde, konuya yabanc\u0131 olan okuyucular\u0131m\u0131z i\u00e7in bu iki temel teknolojinin ne anlama geldi\u011fini, neden bu kadar \u00f6nemli olduklar\u0131n\u0131 ve birbirleriyle nas\u0131l bir ili\u015fki i\u00e7inde olduklar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Bu temel bilgileri edinmek, ilerleyen b\u00f6l\u00fcmlerdeki daha karma\u015f\u0131k entegrasyon senaryolar\u0131n\u0131 anlamak i\u00e7in vazge\u00e7ilmezdir.<\/p>\n
Apache Kafka, LinkedIn taraf\u0131ndan geli\u015ftirilen ve daha sonra a\u00e7\u0131k kaynak haline getirilen, da\u011f\u0131t\u0131k bir olay ak\u0131\u015f\u0131 platformudur (distributed event streaming platform). Temel olarak, ger\u00e7ek zamanl\u0131 veri ak\u0131\u015flar\u0131n\u0131 y\u00f6netmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Geleneksel mesaj kuyruklar\u0131ndan farkl\u0131 olarak, Kafka, y\u00fcksek verim (throughput), d\u00fc\u015f\u00fck gecikme (low latency), y\u00fcksek \u00f6l\u00e7eklenebilirlik (scalability) ve kal\u0131c\u0131l\u0131k (durability) \u00f6zellikleriyle \u00f6ne \u00e7\u0131kar. Bu \u00f6zellikleri sayesinde, modern mikroservis mimarileri, ger\u00e7ek zamanl\u0131 analiz sistemleri, olay kaynakl\u0131 mimariler (event sourcing) ve veri entegrasyonu gibi bir\u00e7ok senaryoda vazge\u00e7ilmez bir ara\u00e7 haline gelmi\u015ftir.<\/p>\n
Kafka’n\u0131n mimarisi birka\u00e7 temel bile\u015fenden olu\u015fur:<\/p>\n
Kafka’n\u0131n bu da\u011f\u0131t\u0131k yap\u0131s\u0131, onu hem g\u00fc\u00e7l\u00fc hem de karma\u015f\u0131k hale getirir. \u00d6zellikle, \u00fcreticilerin ve t\u00fcketicilerin broker’lara nas\u0131l ba\u011flanaca\u011f\u0131 ve veri ak\u0131\u015f\u0131n\u0131n g\u00fcvenli bir \u015fekilde nas\u0131l sa\u011flanaca\u011f\u0131, sistemin do\u011fru \u00e7al\u0131\u015fmas\u0131 i\u00e7in kritik \u00f6neme sahiptir. \u0130\u015fte bu noktada a\u011f yap\u0131land\u0131rmalar\u0131 ve VPC Peering devreye girer.<\/p>\n
Bulut bili\u015fim ortamlar\u0131nda, \u00f6zellikle Amazon Web Services (AWS) gibi platformlarda, Sanal \u00d6zel Bulut (Virtual Private Cloud – VPC), kullan\u0131c\u0131lar\u0131n kendi izole edilmi\u015f sanal a\u011flar\u0131n\u0131 olu\u015fturmalar\u0131na olanak tan\u0131yan temel bir servistir. Bir VPC, kendi IP adres aral\u0131\u011f\u0131na, alt a\u011flar\u0131na (subnets), y\u00f6nlendirme tablolar\u0131na (route tables) ve a\u011f ge\u00e7itlerine (internet gateway, NAT gateway) sahip, mant\u0131ksal olarak izole edilmi\u015f bir a\u011f ortam\u0131d\u0131r. Bu izolasyon, kullan\u0131c\u0131lar\u0131n bulut kaynaklar\u0131n\u0131 g\u00fcvenli ve kontrol edilebilir bir \u015fekilde da\u011f\u0131tmalar\u0131n\u0131 sa\u011flar.<\/p>\n
Ancak, bir organizasyonun farkl\u0131 departmanlar\u0131, farkl\u0131 projeleri veya hatta farkl\u0131 co\u011frafi b\u00f6lgelerdeki uygulamalar\u0131 genellikle ayr\u0131 VPC’lerde bar\u0131nd\u0131r\u0131l\u0131r. Bu senaryolarda, bu izole VPC’ler aras\u0131nda g\u00fcvenli ve d\u00fc\u015f\u00fck gecikmeli bir \u015fekilde ileti\u015fim kurma ihtiyac\u0131 do\u011far. \u0130\u015fte tam bu noktada VPC Peering devreye girer.<\/p>\n
VPC Peering Nedir?<\/strong><\/p>\n VPC Peering (VPC E\u015fle\u015ftirme), iki farkl\u0131 VPC aras\u0131nda \u00f6zel bir a\u011f ba\u011flant\u0131s\u0131 kurman\u0131z\u0131 sa\u011flayan bir AWS servisidir. Bu ba\u011flant\u0131 sayesinde, her iki VPC’deki kaynaklar (\u00f6rne\u011fin, EC2 \u00f6rnekleri, veritabanlar\u0131, Kafka broker’lar\u0131) birbirleriyle \u00f6zel IP adresleri \u00fczerinden do\u011frudan ileti\u015fim kurabilirler. Bu, trafi\u011fin internet \u00fczerinden ge\u00e7mek zorunda kalmadan, AWS’nin kendi omurga a\u011f\u0131 (backbone network) \u00fczerinden y\u00f6nlendirildi\u011fi anlam\u0131na gelir. Bu durumun bir\u00e7ok \u00f6nemli avantaj\u0131 vard\u0131r:<\/p>\n VPC Peering ba\u011flant\u0131s\u0131 kurmak i\u00e7in, iki VPC’nin IP adres aral\u0131klar\u0131n\u0131n \u00e7ak\u0131\u015fmamas\u0131 (overlapping CIDR blocks) gerekir. E\u011fer \u00e7ak\u0131\u015fma varsa, peering ba\u011flant\u0131s\u0131 kurulamaz. Ba\u011flant\u0131 kurulduktan sonra, her iki VPC’nin y\u00f6nlendirme tablolar\u0131na (route tables), di\u011fer VPC’nin IP aral\u0131\u011f\u0131na giden trafi\u011fi peering ba\u011flant\u0131s\u0131 \u00fczerinden y\u00f6nlendirecek rotalar eklenmelidir. Ayr\u0131ca, g\u00fcvenlik gruplar\u0131 ve a\u011f ACL’leri de bu ileti\u015fime izin verecek \u015fekilde yap\u0131land\u0131r\u0131lmal\u0131d\u0131r.<\/p>\n \u00d6zetle, Kafka da\u011f\u0131t\u0131k bir veri ak\u0131\u015f\u0131 platformu olarak y\u00fcksek performansl\u0131 ileti\u015fime ihtiya\u00e7 duyarken, VPC Peering bu ileti\u015fimi farkl\u0131 a\u011flar aras\u0131nda g\u00fcvenli ve verimli bir \u015fekilde sa\u011flaman\u0131n anahtar\u0131d\u0131r. Bu iki teknolojinin do\u011fru entegrasyonu, modern bulut mimarilerinde veri ak\u0131\u015f\u0131n\u0131n omurgas\u0131n\u0131 olu\u015fturur.<\/p>\n Kafka, da\u011f\u0131t\u0131k bir sistem oldu\u011fu i\u00e7in, \u00fcreticilerin ve t\u00fcketicilerin k\u00fcmedeki broker’lara do\u011fru bir \u015fekilde ula\u015fabilmesi kritik \u00f6neme sahiptir. Bu “adresleme” s\u00fcreci, Kafka’n\u0131n sa\u011fl\u0131kl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131n temelini olu\u015fturur. Ancak, bulut ortamlar\u0131nda, \u00f6zellikle farkl\u0131 VPC’ler veya b\u00f6lgeler aras\u0131nda ileti\u015fim kurulmas\u0131 gerekti\u011finde, bu adresleme s\u00fcreci karma\u015f\u0131k hale gelebilir. Bu b\u00f6l\u00fcmde, Kafka’n\u0131n adresleme mekanizmalar\u0131n\u0131 ve bu s\u00fcre\u00e7te kar\u015f\u0131la\u015f\u0131lan ba\u015fl\u0131ca zorluklar\u0131 ve olas\u0131 \u00e7\u00f6z\u00fcm yakla\u015f\u0131mlar\u0131n\u0131 ele alaca\u011f\u0131z.<\/p>\n Kafka istemcileri (\u00fcreticiler ve t\u00fcketiciler), bir Kafka k\u00fcmesine ba\u011flanmak i\u00e7in ba\u015flang\u0131\u00e7ta bir veya daha fazla broker’\u0131n adresini ( Kafka broker’lar\u0131, Bir Kafka istemcisi, ba\u015flang\u0131\u00e7 broker’\u0131ndan ald\u0131\u011f\u0131 meta verilerdeki Bulut ortamlar\u0131nda, bir Kafka k\u00fcmesi genellikle bir VPC i\u00e7inde \u00f6zel IP adresleriyle da\u011f\u0131t\u0131l\u0131r. Ancak, bu k\u00fcmeye eri\u015fmesi gereken uygulamalar (\u00fcreticiler ve t\u00fcketiciler) farkl\u0131 VPC’lerde veya hatta farkl\u0131 AWS b\u00f6lgelerinde (regions) bulunabilir. Bu senaryolarda a\u015fa\u011f\u0131daki adresleme zorluklar\u0131 ortaya \u00e7\u0131kar:<\/p>\n Bu zorluklar\u0131n \u00fcstesinden gelmek i\u00e7in en g\u00fcvenli, performansl\u0131 ve maliyet etkin \u00e7\u00f6z\u00fcmlerden biri, VPC Peering ile Kafka’n\u0131n Bu yakla\u015f\u0131m, Kafka trafi\u011finin tamamen \u00f6zel a\u011f i\u00e7inde kalmas\u0131n\u0131 sa\u011flayarak hem g\u00fcvenli\u011fi art\u0131r\u0131r hem de gecikmeyi minimuma indirir. Ayr\u0131ca, karma\u015f\u0131k NAT yap\u0131land\u0131rmalar\u0131na veya pahal\u0131 genel IP’lere olan ihtiyac\u0131 ortadan kald\u0131r\u0131r. Bir sonraki b\u00f6l\u00fcmde, bu entegrasyonun ad\u0131m ad\u0131m nas\u0131l ger\u00e7ekle\u015ftirilece\u011fine dair pratik detaylara odaklanaca\u011f\u0131z.<\/p>\n Kafka broker’lar\u0131n\u0131n farkl\u0131 bir VPC’deki istemcilerle g\u00fcvenli ve verimli bir \u015fekilde ileti\u015fim kurabilmesi i\u00e7in VPC Peering’in do\u011fru bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Bu b\u00f6l\u00fcmde, AWS ortam\u0131nda VPC Peering ba\u011flant\u0131s\u0131n\u0131 nas\u0131l kuraca\u011f\u0131n\u0131z\u0131, y\u00f6nlendirme tablolar\u0131n\u0131 nas\u0131l g\u00fcncelleyece\u011finizi ve g\u00fcvenlik gruplar\u0131n\u0131 nas\u0131l yap\u0131land\u0131raca\u011f\u0131n\u0131z\u0131 ad\u0131m ad\u0131m anlataca\u011f\u0131z. Bu ad\u0131mlar, Kafka trafi\u011finizin tamamen \u00f6zel a\u011f\u0131n\u0131z i\u00e7inde kalmas\u0131n\u0131 sa\u011flayarak, d\u0131\u015far\u0131dan gelebilecek tehditlere kar\u015f\u0131 koruma sa\u011flar ve performans kayb\u0131n\u0131 en aza indirir.<\/p>\n VPC Peering ba\u011flant\u0131s\u0131 kurmak i\u00e7in, AWS Y\u00f6netim Konsolu, AWS CLI (Komut Sat\u0131r\u0131 Aray\u00fcz\u00fc) veya AWS SDK’lar\u0131 kullan\u0131labilir. Burada, temel ad\u0131mlar\u0131 ve kavramsal CLI \u00f6rneklerini sunaca\u011f\u0131z.<\/p>\n \u0130lk olarak, Kafka k\u00fcmenizin bulundu\u011fu VPC’den (talepte bulunan VPC) di\u011fer VPC’ye (kabul eden VPC) bir peering ba\u011flant\u0131 talebi g\u00f6nderilir. \u0130ki VPC’nin CIDR bloklar\u0131n\u0131n \u00e7ak\u0131\u015fmad\u0131\u011f\u0131ndan emin olun.<\/p>\n Yukar\u0131daki komutta:<\/p>\n Talep olu\u015fturulduktan sonra, hedef VPC’nin sahibi bu talebi kabul etmelidir. Ayn\u0131 hesap i\u00e7indeyseniz, bu i\u015flemi ayn\u0131 hesaptan yapabilirsiniz. Farkl\u0131 hesaplar aras\u0131ndaysa, hedef hesap sahibi bu talebi kendi konsolundan veya CLI \u00fczerinden kabul eder.<\/p>\n Peering ba\u011flant\u0131s\u0131 aktif hale geldikten sonra, her iki VPC’deki alt a\u011flar\u0131n (subnets) y\u00f6nlendirme tablolar\u0131n\u0131, di\u011fer VPC’nin CIDR blo\u011funa giden trafi\u011fi peering ba\u011flant\u0131s\u0131 \u00fczerinden y\u00f6nlendirecek \u015fekilde g\u00fcncellemeniz gerekir. Bu, trafi\u011fin do\u011fru yoldan gitmesini sa\u011flar.<\/p>\n Kafka k\u00fcmenizin bulundu\u011fu VPC’deki alt a\u011flar\u0131n y\u00f6nlendirme tablolar\u0131na, hedef uygulama VPC’sinin CIDR blo\u011funa giden rotay\u0131 ekleyin.<\/p>\n Uygulamalar\u0131n\u0131z\u0131n bulundu\u011fu VPC’deki alt a\u011flar\u0131n y\u00f6nlendirme tablolar\u0131na, Kafka VPC’sinin CIDR blo\u011funa giden rotay\u0131 ekleyin.<\/p>\n Y\u00f6nlendirme tablolar\u0131 trafi\u011fin yolunu a\u00e7sa da, g\u00fcvenlik gruplar\u0131 ve A\u011f ACL’leri (Network ACLs) trafi\u011fe izin veren veya reddeden firewall kurallar\u0131d\u0131r. Kafka ileti\u015fimi i\u00e7in gerekli portlar\u0131n (varsay\u0131lan olarak 9092) a\u00e7\u0131ld\u0131\u011f\u0131ndan emin olman\u0131z gerekir.<\/p>\n Kafka broker’lar\u0131n\u0131z\u0131n ba\u011fl\u0131 oldu\u011fu g\u00fcvenlik grubuna, uygulama VPC’sindeki istemcilerden gelen Kafka trafi\u011fine (\u00f6rne\u011fin TCP 9092) izin veren bir giri\u015f kural\u0131 (inbound rule) ekleyin. Kaynak olarak, ya uygulama VPC’sinin CIDR blo\u011funu ya da uygulamalar\u0131n ba\u011fl\u0131 oldu\u011fu g\u00fcvenlik grubunun ID’sini belirtebilirsiniz. G\u00fcvenlik grubu ID’si kullanmak daha dinamik ve \u00f6nerilen bir yakla\u015f\u0131md\u0131r.<\/p>\n Veya CIDR blo\u011fu ile:<\/p>\n Uygulamalar\u0131n\u0131z\u0131n ba\u011fl\u0131 oldu\u011fu g\u00fcvenlik grubuna, Kafka broker’lar\u0131na giden trafi\u011fe izin veren bir \u00e7\u0131k\u0131\u015f kural\u0131 (outbound rule) ekleyin. \u00c7o\u011fu g\u00fcvenlik grubu varsay\u0131lan olarak t\u00fcm \u00e7\u0131k\u0131\u015f trafi\u011fine izin verse de, daha s\u0131k\u0131 g\u00fcvenlik politikalar\u0131 uyguluyorsan\u0131z bu kural\u0131 eklemeniz gerekebilir.<\/p>\n Bu ad\u0131mlar\u0131 tamamlad\u0131\u011f\u0131n\u0131zda, iki VPC aras\u0131nda g\u00fcvenli ve \u00f6zel bir a\u011f ba\u011flant\u0131s\u0131 kurulmu\u015f olur. Art\u0131k uygulama VPC’sindeki istemciler, Kafka VPC’sindeki broker’lara \u00f6zel IP adresleri \u00fczerinden eri\u015febilirler. Ancak, Kafka’n\u0131n VPC Peering ba\u011flant\u0131s\u0131n\u0131 ba\u015far\u0131yla kurduktan ve a\u011f seviyesindeki eri\u015fimi sa\u011flad\u0131ktan sonra, Kafka k\u00fcmesinin kendisini istemcilere do\u011fru \u015fekilde duyurmas\u0131 gerekir. \u0130\u015fte bu noktada Kafka’n\u0131n Kafka istemcileri (\u00fcreticiler ve t\u00fcketiciler), ba\u015flang\u0131\u00e7ta E\u011fer bir Kafka broker’\u0131, istemcinin eri\u015femeyece\u011fi bir IP adresi veya ana bilgisayar ad\u0131 duyurursa (\u00f6rne\u011fin, sadece kendi VPC’sindeki \u00f6zel IP’sini duyururken, istemci farkl\u0131 bir VPC’den geliyorsa), istemci di\u011fer broker’lara ba\u011flanmakta sorun ya\u015fayacakt\u0131r. VPC Peering sayesinde, farkl\u0131 VPC’ler art\u0131k \u00f6zel IP adresleri \u00fczerinden birbirine eri\u015febildi\u011finden, Kafka broker’lar\u0131n\u0131n da bu \u00f6zel IP adreslerini duyurmas\u0131 gerekir.<\/p>\n Genellikle en esnek ve g\u00fcvenli yakla\u015f\u0131m, Kafka broker’lar\u0131nda birden fazla dinleyici (listener) tan\u0131mlamakt\u0131r. Bu dinleyicilerden biri, k\u00fcme i\u00e7i ileti\u015fim ve ayn\u0131 VPC’deki istemciler i\u00e7in kullan\u0131l\u0131rken, di\u011feri VPC Peering \u00fczerinden gelen d\u0131\u015f istemciler i\u00e7in yap\u0131land\u0131r\u0131l\u0131r. Bu sayede, her istemci t\u00fcr\u00fc i\u00e7in optimize edilmi\u015f ve g\u00fcvenli bir ileti\u015fim kanal\u0131 sa\u011flan\u0131r.<\/p>\n \u00d6rnek bir Yukar\u0131daki \u00f6rnekte:<\/p>\n \u00d6nemli Not:<\/strong> Uygulama VPC’sindeki Kafka istemcileri (\u00fcreticiler ve t\u00fcketiciler), Burada IP adresleri yerine DNS adlar\u0131 kullanmak, daha esnek bir yap\u0131land\u0131rma sa\u011flar, \u00f6zellikle broker IP adresleri de\u011fi\u015fti\u011finde. E\u011fer Kafka broker’lar\u0131n\u0131z i\u00e7in \u00f6zel DNS adlar\u0131 kullan\u0131yorsan\u0131z (\u00f6rne\u011fin, AWS’de, Route 53 Resolver Endpoints kullanarak VPC’ler aras\u0131 \u00f6zel DNS \u00e7\u00f6z\u00fcmlemesi sa\u011flayabilirsiniz. Bu, bir VPC’deki kaynaklar\u0131n di\u011fer VPC’deki \u00f6zel DNS adlar\u0131n\u0131 \u00e7\u00f6z\u00fcmlemesine olanak tan\u0131r. B\u00f6ylece Bu senaryoda, Bu entegrasyon ad\u0131mlar\u0131yla, VPC Peering \u00fczerinden Kafka ileti\u015fimini g\u00fcvenli ve verimli bir \u015fekilde kurmu\u015f olursunuz. Do\u011fru Kurumsal uygulamalar giderek daha da\u011f\u0131t\u0131k hale geliyor ve mikroservis mimarileri, bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn merkezinde yer al\u0131yor. Genellikle, bir \u015firketin farkl\u0131 i\u015f birimleri veya uygulama katmanlar\u0131, farkl\u0131 VPC’lerde hatta farkl\u0131 AWS b\u00f6lgelerinde (regions) bar\u0131nd\u0131r\u0131l\u0131r. Bu senaryolarda, merkezi bir Kafka k\u00fcmesinin farkl\u0131 uygulama VPC’lerindeki mikroservisler taraf\u0131ndan kullan\u0131lmas\u0131 yayg\u0131n bir gereksinimdir. \u0130\u015fte bu noktada VPC Peering ve Kafka’n\u0131n do\u011fru adresleme stratejileri, karma\u015f\u0131k a\u011f yap\u0131lar\u0131n\u0131 basitle\u015ftiren ve g\u00fcvenli\u011fi art\u0131ran kritik \u00e7\u00f6z\u00fcmler sunar.<\/p>\n Hayal edelim ki, global bir e-ticaret platformunuz var. Bu platform, a\u015fa\u011f\u0131daki gibi farkl\u0131 uygulama ve veri i\u015fleme katmanlar\u0131na sahip:<\/p>\n Bu senaryoda, farkl\u0131 VPC’lerdeki ve hatta farkl\u0131 b\u00f6lgelerdeki mikroservislerin, merkezi Kafka k\u00fcmesiyle g\u00fcvenli, d\u00fc\u015f\u00fck gecikmeli ve y\u00fcksek bant geni\u015fli\u011fine sahip bir \u015fekilde ileti\u015fim kurmas\u0131 gerekmektedir. \u0130nternet \u00fczerinden veya VPN t\u00fcnelleri \u00fczerinden ileti\u015fim kurmak, g\u00fcvenlik riskleri, y\u00fcksek gecikme ve y\u00f6netim karma\u015f\u0131kl\u0131\u011f\u0131 nedeniyle ideal bir \u00e7\u00f6z\u00fcm de\u011fildir.<\/p>\n Bu karma\u015f\u0131k senaryoyu \u00e7\u00f6zmek i\u00e7in VPC Peering ve Kafka’n\u0131n Bu ba\u011flant\u0131lar i\u00e7in yukar\u0131da belirtilen y\u00f6nlendirme tablosu ve g\u00fcvenlik grubu yap\u0131land\u0131rmalar\u0131 eksiksiz yap\u0131lmal\u0131d\u0131r.<\/p>\n<\/li>\n B\u00f6lgeler aras\u0131 peering de ayn\u0131 VPC Peering mant\u0131\u011f\u0131na sahiptir, ancak farkl\u0131 b\u00f6lgelerdeki VPC’leri ba\u011flar. Y\u00f6nlendirme tablolar\u0131 ve g\u00fcvenlik gruplar\u0131 yine her iki tarafta do\u011fru \u015fekilde yap\u0131land\u0131r\u0131lmal\u0131d\u0131r.<\/p>\n<\/li>\n Merkezi Kafka k\u00fcmesindeki her broker, birden fazla Her bir dinleyici i\u00e7in farkl\u0131 bir port kullanmak veya farkl\u0131 g\u00fcvenlik protokolleri (\u00f6rne\u011fin, Bu mimari, e-ticaret platformuna a\u015fa\u011f\u0131daki faydalar\u0131 sa\u011flar:<\/p>\n \u0130pu\u00e7lar\u0131:<\/strong><\/p>\n\n
Kafka Mimarilerinde Adresleme Zorluklar\u0131 ve \u00c7\u00f6z\u00fcmleri Nelerdir?<\/h2>\n
Kafka Broker’lar\u0131n\u0131n Kendilerini Duyurmas\u0131: Advertised Listeners<\/h3>\n
bootstrap.servers<\/code>) kullan\u0131r. Bu adresler genellikle k\u00fcmenin bir alt k\u00fcmesini temsil eder. \u0130stemci bu ba\u015flang\u0131\u00e7 broker’\u0131na ba\u011fland\u0131ktan sonra, k\u00fcmedeki t\u00fcm broker’lar\u0131n ve ilgili konular\u0131n meta verilerini al\u0131r. Bu meta veriler, her broker’\u0131n kendi “duyurdu\u011fu” (advertised) adres bilgilerini i\u00e7erir. \u0130\u015fte bu duyurulan adresler, Kafka’n\u0131n adresleme mekanizmas\u0131n\u0131n merkezindedir.<\/p>\nserver.properties<\/code> dosyas\u0131nda a\u015fa\u011f\u0131daki gibi \u00e7e\u015fitli dinleyici (listener) ayarlar\u0131 ile yap\u0131land\u0131r\u0131l\u0131r:<\/p>\n\n
listeners<\/code>: Broker’\u0131n hangi aray\u00fczlerde ve portlarda dinleme yapaca\u011f\u0131n\u0131 belirler. \u00d6rne\u011fin, PLAINTEXT:\/\/:9092,SSL:\/\/:9093<\/code> gibi.<\/li>\nadvertised.listeners<\/code>: Broker’\u0131n istemcilere kendisini hangi adres ve port ile duyuraca\u011f\u0131n\u0131 belirler. Bu, istemcilerin broker’a ula\u015fmak i\u00e7in kullanaca\u011f\u0131 adrestir. Bu ayar, \u00f6zellikle a\u011f yap\u0131land\u0131rmas\u0131n\u0131n karma\u015f\u0131k oldu\u011fu durumlarda (NAT, Docker, \u00e7oklu a\u011f aray\u00fczleri, bulut ortamlar\u0131) hayati \u00f6neme sahiptir.<\/li>\nlistener.security.protocol.map<\/code>: Dinleyiciler ve g\u00fcvenlik protokolleri aras\u0131ndaki e\u015fle\u015fmeyi tan\u0131mlar.<\/li>\n<\/ul>\nadvertised.listeners<\/code> bilgisi \u00fczerinden di\u011fer broker’lara ba\u011flanmaya \u00e7al\u0131\u015f\u0131r. E\u011fer bu duyurulan adresler, istemcinin bulundu\u011fu a\u011fdan eri\u015filebilir de\u011filse, ba\u011flant\u0131 ba\u015far\u0131s\u0131z olur. Bu durum, \u00f6zellikle bulut ortamlar\u0131nda, \u00f6zel (private) IP adresleri ve genel (public) IP adresleri aras\u0131ndaki farklar nedeniyle s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir sorundur.<\/p>\n\u00c7oklu VPC ve B\u00f6lgeler Aras\u0131 Adresleme Zorluklar\u0131<\/h3>\n
\n
\n
\u00c7\u00f6z\u00fcm Yakla\u015f\u0131mlar\u0131: VPC Peering ve Advertised Listeners’\u0131n Entegrasyonu<\/h3>\n
advertised.listeners<\/code> yap\u0131land\u0131rmas\u0131n\u0131 birle\u015ftirmektir. Bu entegrasyon a\u015fa\u011f\u0131daki prensiplere dayan\u0131r:<\/p>\n\n
\n
INTERNAL_PLAINTEXT<\/code> veya INTERNAL_SSL<\/code>).<\/li>\nPEERED_PLAINTEXT<\/code> veya PEERED_SSL<\/code>).<\/li>\n<\/ul>\n<\/li>\nVPC Peering ile Kafka Ba\u011flant\u0131s\u0131n\u0131 G\u00fcvenli Hale Getirme: Ad\u0131m Ad\u0131m Yap\u0131land\u0131rma<\/h2>\n
1. VPC Peering Ba\u011flant\u0131s\u0131 Olu\u015fturma<\/h3>\n
\n
\n# Talepte bulunan VPC (Kafka'n\u0131n bulundu\u011fu VPC)\naws ec2 create-vpc-peering-connection \\\n --vpc-id vpc-0abcdef1234567890 \\\n --peer-vpc-id vpc-0fedcba9876543210 \\\n --peer-owner-id 123456789012 \\\n --tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=Kafka-App-Peering}]'\n <\/code><\/pre>\n<\/p><\/div>\n\n
vpc-id<\/code>: Kafka k\u00fcmenizin bulundu\u011fu VPC ID’si.<\/li>\npeer-vpc-id<\/code>: Uygulamalar\u0131n\u0131z\u0131n bulundu\u011fu hedef VPC ID’si.<\/li>\npeer-owner-id<\/code>: Hedef VPC’nin ait oldu\u011fu AWS hesap ID’si (e\u011fer farkl\u0131 bir hesaptaysa). Ayn\u0131 hesapta ise bu parametreye gerek yoktur.<\/li>\n<\/ul>\n<\/li>\n\n# Kabul eden VPC (Uygulamalar\u0131n bulundu\u011fu VPC)\naws ec2 accept-vpc-peering-connection \\\n --vpc-peering-connection-id pcx-0123456789abcdef0\n <\/code><\/pre>\n<\/p><\/div>\npcx-0123456789abcdef0<\/code> de\u011feri, create-vpc-peering-connection<\/code> komutunun \u00e7\u0131kt\u0131s\u0131nda veya VPC Peering ba\u011flant\u0131lar\u0131 listesinde bulabilece\u011finiz peering ba\u011flant\u0131 ID’sidir.<\/p>\n<\/li>\n<\/ol>\n2. Y\u00f6nlendirme Tablolar\u0131n\u0131 (Route Tables) G\u00fcncelleme<\/h3>\n
\n
\n# Kafka VPC'sindeki y\u00f6nlendirme tablosunu bul (veya yeni bir tane olu\u015ftur)\n# \u00d6rne\u011fin, Kafka broker'lar\u0131n\u0131n bulundu\u011fu alt a\u011f\u0131n y\u00f6nlendirme tablosu\naws ec2 create-route \\\n --route-table-id rtb-0fedcba9876543210 \\\n --destination-cidr-block 10.0.0.0\/16 \\ # Hedef uygulama VPC'sinin CIDR blo\u011fu\n --vpc-peering-connection-id pcx-0123456789abcdef0\n <\/code><\/pre>\n<\/p><\/div>\n<\/li>\n\n# Uygulama VPC'sindeki y\u00f6nlendirme tablosunu bul (veya yeni bir tane olu\u015ftur)\n# \u00d6rne\u011fin, uygulamalar\u0131n bulundu\u011fu alt a\u011f\u0131n y\u00f6nlendirme tablosu\naws ec2 create-route \\\n --route-table-id rtb-0abcdef1234567890 \\\n --destination-cidr-block 172.16.0.0\/16 \\ # Kafka VPC'sinin CIDR blo\u011fu\n --vpc-peering-connection-id pcx-0123456789abcdef0\n <\/code><\/pre>\n<\/p><\/div>\ndestination-cidr-block<\/code> parametresine, di\u011fer VPC’nin CIDR blo\u011funu do\u011fru bir \u015fekilde girdi\u011finizden emin olun.<\/p>\n<\/li>\n<\/ol>\n3. G\u00fcvenlik Gruplar\u0131n\u0131 (Security Groups) Yap\u0131land\u0131rma<\/h3>\n
\n
\n# Kafka broker g\u00fcvenlik grubuna kural ekle\naws ec2 authorize-security-group-ingress \\\n --group-id sg-0123456789abcdef0 \\ # Kafka broker g\u00fcvenlik grubu ID'si\n --protocol tcp \\\n --port 9092 \\\n --source-security-group-id sg-0fedcba9876543210 # Uygulama g\u00fcvenlik grubu ID'si\n <\/code><\/pre>\n<\/p><\/div>\n\naws ec2 authorize-security-group-ingress \\\n --group-id sg-0123456789abcdef0 \\\n --protocol tcp \\\n --port 9092 \\\n --cidr 10.0.0.0\/16 # Uygulama VPC'sinin CIDR blo\u011fu\n <\/code><\/pre>\n<\/p><\/div>\n<\/li>\n\n# Uygulama g\u00fcvenlik grubuna kural ekle (e\u011fer \u00e7\u0131k\u0131\u015f k\u0131s\u0131tlamalar\u0131 varsa)\naws ec2 authorize-security-group-egress \\\n --group-id sg-0fedcba9876543210 \\ # Uygulama g\u00fcvenlik grubu ID'si\n --protocol tcp \\\n --port 9092 \\\n --destination-security-group-id sg-0123456789abcdef0 # Kafka broker g\u00fcvenlik grubu ID'si\n <\/code><\/pre>\n<\/p><\/div>\n<\/li>\n<\/ol>\nadvertised.listeners<\/code> yap\u0131land\u0131rmas\u0131 olmadan bu ba\u011flant\u0131 tam olarak i\u015flevsel olmayacakt\u0131r. Bir sonraki b\u00f6l\u00fcmde, bu kritik Kafka yap\u0131land\u0131rmas\u0131n\u0131 nas\u0131l yapaca\u011f\u0131m\u0131z\u0131 detayl\u0131ca ele alaca\u011f\u0131z.<\/p>\nKafka Advertised Listeners ve VPC Peering Entegrasyonu: Do\u011fru Adresleme Stratejileri<\/h2>\n
advertised.listeners<\/code> yap\u0131land\u0131rmas\u0131 devreye girer. Bu ayar, Kafka broker’lar\u0131n\u0131n istemcilere kendilerini hangi adres ve port \u00fczerinden eri\u015filebilir k\u0131ld\u0131\u011f\u0131n\u0131 bildirir. Yanl\u0131\u015f yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131nda, istemciler broker’lara ba\u011flanamaz veya ba\u011flant\u0131 sorunlar\u0131 ya\u015far. Bu b\u00f6l\u00fcmde, VPC Peering ortam\u0131nda advertised.listeners<\/code>‘\u0131 nas\u0131l do\u011fru bir \u015fekilde yap\u0131land\u0131raca\u011f\u0131n\u0131z\u0131 ve farkl\u0131 senaryolar i\u00e7in en iyi uygulamalar\u0131 inceleyece\u011fiz.<\/p>\nNeden Advertised Listeners \u00d6nemlidir?<\/h3>\n
bootstrap.servers<\/code> listesindeki broker’lardan birine ba\u011flan\u0131r. Bu broker, k\u00fcmedeki di\u011fer t\u00fcm broker’lar\u0131n ve ilgili konular\u0131n meta verilerini istemciye g\u00f6nderir. Bu meta veriler i\u00e7inde, her broker’\u0131n advertised.listeners<\/code> ayar\u0131nda tan\u0131mlad\u0131\u011f\u0131 adres bilgileri de bulunur. \u0130stemci daha sonra bu duyurulan adresleri kullanarak di\u011fer broker’larla do\u011frudan ileti\u015fim kurar.<\/p>\n\u00c7oklu Dinleyici (Multiple Listeners) Yakla\u015f\u0131m\u0131<\/h3>\n
server.properties<\/code> yap\u0131land\u0131rmas\u0131 a\u015fa\u011f\u0131daki gibi olabilir:<\/p>\n\n# Dinleyicilerin tan\u0131m\u0131\nlisteners=INTERNAL_PLAINTEXT:\/\/:9092,PEERED_PLAINTEXT:\/\/:9093\n\n# Her dinleyici i\u00e7in g\u00fcvenlik protokol\u00fc e\u015fle\u015fmesi\nlistener.security.protocol.map=INTERNAL_PLAINTEXT:PLAINTEXT,PEERED_PLAINTEXT:PLAINTEXT\n\n# Her dinleyici i\u00e7in duyurulan adresler\n# INTERNAL_PLAINTEXT: K\u00fcme i\u00e7i ve ayn\u0131 VPC'deki istemciler i\u00e7in\nadvertised.listeners=INTERNAL_PLAINTEXT:\/\/<Kafka_Broker_Private_IP>:9092,PEERED_PLAINTEXT:\/\/<Kafka_Broker_Peered_IP>:9093\n\n# Dinleyici ayarlar\u0131\n# E\u011fer broker'\u0131n birden fazla NIC'i varsa, hangi aray\u00fczden dinleyece\u011fini belirtebilirsiniz.\n# listener.interfaces=INTERNAL_PLAINTEXT:eth0,PEERED_PLAINTEXT:eth1 (\u00f6rnek, genellikle gerekli de\u011fildir)\n\n# E\u011fer farkl\u0131 bir IP adresi duyurman\u0131z gerekiyorsa (\u00f6rne\u011fin, NAT sonras\u0131)\n# Bu senaryoda <Kafka_Broker_Peered_IP> genellikle broker'\u0131n kendi private IP'sidir.\n# Ancak farkl\u0131 bir senaryoda bu bir NAT IP'si veya \u00f6zel bir DNS ad\u0131 olabilir.\n <\/code><\/pre>\n<\/p><\/div>\n\n
listeners=INTERNAL_PLAINTEXT:\/\/:9092,PEERED_PLAINTEXT:\/\/:9093<\/code>: Broker’\u0131n 9092 portunda dahili trafik i\u00e7in ve 9093 portunda peering trafi\u011fi i\u00e7in dinleme yapaca\u011f\u0131n\u0131 belirtir. Farkl\u0131 portlar kullanmak, g\u00fcvenlik gruplar\u0131 ve a\u011f ACL’leri \u00fczerinde daha iyi kontrol sa\u011flar.<\/li>\nlistener.security.protocol.map=INTERNAL_PLAINTEXT:PLAINTEXT,PEERED_PLAINTEXT:PLAINTEXT<\/code>: Her bir dinleyici i\u00e7in kullan\u0131lacak g\u00fcvenlik protokol\u00fcn\u00fc e\u015fle\u015ftirir. Burada basitlik ad\u0131na PLAINTEXT<\/code> kullan\u0131lm\u0131\u015ft\u0131r, ancak \u00fcretim ortamlar\u0131nda SSL<\/code> veya SASL_SSL<\/code> tercih edilmelidir.<\/li>\nadvertised.listeners=INTERNAL_PLAINTEXT:\/\/<Kafka_Broker_Private_IP>:9092,PEERED_PLAINTEXT:\/\/<Kafka_Broker_Peered_IP>:9093<\/code>: Bu, en kritik k\u0131s\u0131md\u0131r.\n\n
<Kafka_Broker_Private_IP><\/code>: Kafka broker’\u0131n\u0131n kendi VPC’sindeki \u00f6zel IP adresidir. K\u00fcme i\u00e7i ileti\u015fim ve ayn\u0131 VPC’deki istemciler bu adresi kullan\u0131r.<\/li>\n<Kafka_Broker_Peered_IP><\/code>: Bu da asl\u0131nda Kafka broker’\u0131n\u0131n kendi \u00f6zel IP adresidir. Ancak bu adres, VPC Peering ba\u011flant\u0131s\u0131 \u00fczerinden di\u011fer VPC’deki istemciler taraf\u0131ndan eri\u015filebilir olmal\u0131d\u0131r. Yani, Kafka broker’\u0131 kendi \u00f6zel IP’sini hem dahili hem de peering \u00fczerinden eri\u015filebilir olarak duyurur.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<Kafka_Broker_Private_IP><\/code> ve <Kafka_Broker_Peered_IP><\/code> yer tutucular\u0131n\u0131, her bir Kafka broker’\u0131n\u0131n ger\u00e7ek \u00f6zel IP adresleriyle de\u011fi\u015ftirmeniz gerekmektedir. Bu IP adresleri genellikle EC2 \u00f6rne\u011finin \u00f6zel IP adresidir. Dinamik ortamlarda, bu yap\u0131land\u0131rmay\u0131 otomatikle\u015ftirmek i\u00e7in ba\u015flatma komut dosyalar\u0131 (startup scripts) veya yap\u0131land\u0131rma y\u00f6netim ara\u00e7lar\u0131 (Ansible, Chef, Puppet) kullan\u0131labilir.<\/p>\n\u0130stemci Taraf\u0131 Yap\u0131land\u0131rmas\u0131<\/h3>\n
bootstrap.servers<\/code> listesini, peering i\u00e7in \u00f6zel olarak duyurulan dinleyicinin adreslerini i\u00e7erecek \u015fekilde yap\u0131land\u0131rmal\u0131d\u0131r. Yani, PEERED_PLAINTEXT<\/code> dinleyicisinin duyurdu\u011fu adresleri kullanacaklard\u0131r.<\/p>\n\n# Java Kafka Producer\/Consumer yap\u0131land\u0131rmas\u0131\nProperties props = new Properties();\nprops.put(\"bootstrap.servers\", \"<Kafka_Broker_Peered_IP_1>:9093,<Kafka_Broker_Peered_IP_2>:9093\");\nprops.put(\"security.protocol\", \"PLAINTEXT\"); \/\/ veya SSL\/SASL_SSL\n\n\/\/ Di\u011fer Kafka yap\u0131land\u0131rmalar\u0131...\n <\/code><\/pre>\n<\/p><\/div>\n<Kafka_Broker_Peered_IP_1><\/code> ve <Kafka_Broker_Peered_IP_2><\/code>, Kafka k\u00fcmenizdeki broker’lar\u0131n peering i\u00e7in duyurulan IP adresleridir. Bu listeye t\u00fcm broker’lar\u0131 eklemek yerine, k\u00fcmenin bir alt k\u00fcmesini eklemek yeterlidir, \u00e7\u00fcnk\u00fc istemci birine ba\u011fland\u0131ktan sonra t\u00fcm k\u00fcmenin meta verilerini alacakt\u0131r.<\/p>\nDNS \u00c7\u00f6z\u00fcmlemesi ile Daha Esnek Adresleme<\/h3>\n
kafka-broker-1.internal.example.com<\/code>), bu adlar\u0131 advertised.listeners<\/code> i\u00e7inde kullanabilirsiniz. Ancak, bu durumda, istemci VPC’sinin bu \u00f6zel DNS adlar\u0131n\u0131 \u00e7\u00f6zebilmesi gerekir.<\/p>\nadvertised.listeners<\/code> i\u00e7inde IP adresleri yerine \u00f6zel DNS adlar\u0131 kullanabilir ve y\u00f6netimi kolayla\u015ft\u0131rabilirsiniz.<\/p>\n\n# DNS tabanl\u0131 advertised.listeners \u00f6rne\u011fi\nadvertised.listeners=INTERNAL_PLAINTEXT:\/\/kafka-broker-1.internal.example.com:9092,PEERED_PLAINTEXT:\/\/kafka-broker-1.peered.example.com:9093\n <\/code><\/pre>\n<\/p><\/div>\nkafka-broker-1.peered.example.com<\/code> DNS ad\u0131n\u0131n, uygulama VPC’sinden sorguland\u0131\u011f\u0131nda Kafka broker’\u0131n\u0131n \u00f6zel IP adresine \u00e7\u00f6z\u00fcmlenmesi gerekmektedir. Bu da Route 53 Resolver Endpoints ile sa\u011flanabilir.<\/p>\nadvertised.listeners<\/code> yap\u0131land\u0131rmas\u0131, bu \u00e7\u00f6z\u00fcm\u00fcn kalbidir ve istemcilerin Kafka k\u00fcmesine sorunsuz bir \u015fekilde eri\u015febilmesini sa\u011flar.<\/p>\nGer\u00e7ek D\u00fcnya Senaryosu: Mikroservisler ve \u00c7ok B\u00f6lgeli Kafka \u0130leti\u015fimi<\/h2>\n
Vaka Analizi: Global Bir E-ticaret Platformu<\/h3>\n
\n
VPC Peering \u00c7\u00f6z\u00fcm\u00fc Nas\u0131l Uygulan\u0131r?<\/h3>\n
advertised.listeners<\/code> entegrasyonunu kullanabiliriz:<\/p>\n\n
\n
\n
advertised.listeners<\/code> tan\u0131mlamal\u0131d\u0131r:<\/p>\n\n
INTERNAL_PLAINTEXT:\/\/<private_ip>:9092<\/code>: K\u00fcme i\u00e7i ileti\u015fim i\u00e7in.<\/li>\nPEERED_EAST:\/\/<private_ip>:9093<\/code>: Us-east-1 b\u00f6lgesindeki peered VPC’lerden gelen istemciler i\u00e7in.<\/li>\nPEERED_WEST:\/\/<private_ip>:9094<\/code>: Eu-west-1 b\u00f6lgesindeki peered VPC’lerden gelen istemciler i\u00e7in.<\/li>\n<\/ul>\nPEERED_EAST_SSL<\/code>) tan\u0131mlamak, daha fazla esneklik ve g\u00fcvenlik sa\u011flar. Her dinleyici, broker’\u0131n kendi \u00f6zel IP adresini duyuracakt\u0131r, \u00e7\u00fcnk\u00fc bu adresler peering ba\u011flant\u0131lar\u0131 \u00fczerinden eri\u015filebilirdir.<\/p>\n<\/li>\n\n
bootstrap.servers<\/code> olarak PEERED_EAST<\/code> dinleyicisinin duyurdu\u011fu adresleri kullan\u0131r (\u00f6rne\u011fin, 172.16.1.10:9093,172.16.1.11:9093<\/code>).<\/li>\nPEERED_EAST<\/code> dinleyicisinin duyurdu\u011fu adresleri kullan\u0131r.<\/li>\nbootstrap.servers<\/code> olarak PEERED_WEST<\/code> dinleyicisinin duyurdu\u011fu adresleri kullan\u0131r (\u00f6rne\u011fin, 172.16.1.10:9094,172.16.1.11:9094<\/code>).<\/li>\nPEERED_WEST<\/code> dinleyicisinin duyurdu\u011fu adresleri kullan\u0131r.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\nFaydalar\u0131 ve \u0130pu\u00e7lar\u0131<\/h3>\n
\n