Zephyrnet Logosu

IAM erişim denetimi ve Kafka Kotaları ile Amazon MSK'de çok kiracılı Apache Kafka kümeleri – Bölüm 1 | Amazon Web Hizmetleri

Tarih:

İle Apache Kafka için Amazon Tarafından Yönetilen Akış (Amazon MSK), akış verilerini işlemek için Apache Kafka kullanan uygulamalar oluşturabilir ve çalıştırabilirsiniz. Akış verilerini işlemek için kuruluşlar, uygulama gruplamalarına, kullanım senaryolarına, uyumluluk gereksinimlerine ve diğer faktörlere göre birden çok Kafka kümesi veya tüm kuruluş için ayrılmış bir Kafka kümesi kullanır. Hangi kalıbın kullanıldığı önemli değildir, Kafka kümeleri tipik olarak çok kiracılıdır ve birden fazla üretici ve tüketici uygulamasının aynı anda akış verilerini tüketmesine ve üretmesine izin verir.

Bununla birlikte, çok kiracılı Kafka kümeleriyle ilgili zorluklardan biri, veri tüketicisi ve üretici uygulamalarının küme kaynaklarını aşırı kullanmadığından emin olmaktır. Kötü davranan birkaç uygulamanın küme kaynaklarını aşırı kullanması ve sonuç olarak iyi davranan uygulamaları etkileme olasılığı vardır. Bu nedenle, çok kiracılı Kafka kümelerini yöneten ekiplerin, sorunları önlemek için uygulamaların küme kaynaklarını aşırı tüketmesini önleyecek bir mekanizmaya ihtiyacı vardır. İşte burada Kafka kotaları devreye giriyor. Kafka kotaları, istemci uygulamalarının bir Kafka kümesi içinde kullanabileceği kaynak miktarını denetler.

Bu iki bölümden oluşan serinin 1. Bölümünde, MSK çok kiracılı Kafka kümelerinde Kafka kotalarının nasıl uygulanacağına ilişkin kavramları açıklıyoruz. AWS Kimlik ve Erişim Yönetimi Kimlik doğrulama ve yetkilendirme için (IAM) erişim kontrolü. İçinde Bölüm 2, örnek Kafka istemci uygulamalarıyla birlikte ayrıntılı uygulama adımlarını ele alıyoruz.

Kafka kotalarına kısa bir giriş

Kafka kotaları, istemci uygulamalarının bir Kafka kümesi içinde kullanabileceği kaynak miktarını denetler. Çok kiracılı Kafka kümesinin, bir veya daha fazla istemci uygulamasının büyük hacimlerde veri üretmesi veya tüketmesi veya sürekli bir süre boyunca çok yüksek oranda istekler oluşturması, tekelleştirmesi durumunda, kaynak kısıtlamaları nedeniyle performans düşüşü veya tam bir kesinti yaşaması mümkündür. Kafka kümesinin kaynakları.

Uygulamaların kümeyi aşmasını önlemek için Apache Kafka, her bir istemci uygulamasının bir kümedeki Kafka aracısı başına ne kadar trafik üretip tüketeceğini belirleyen kotaların yapılandırılmasına izin verir. Kafka aracıları, istemci uygulamalarının isteklerini tahsis edilen kotalarına göre kısıtlar. Kafka kotaları özel olarak yapılandırılabilir kullanıcılarveya belirli müşteri kimlikleriya da her ikisi de. Müşteri Kimliği Kafka aracılarının hangi uygulamanın mesaj gönderdiğini belirlemek için kullandığı uygulama kodunda tanımlanan mantıksal bir addır. bu kullanıcı kimlik doğrulaması etkinleştirilmiş güvenli bir Kafka kümesindeki bir istemci uygulamasının kimliği doğrulanmış kullanıcı sorumlusunu temsil eder.

Kafka'da desteklenen iki tür kota vardır:

  • Ağ bant genişliği kotaları – Bayt hızı eşikleri, istemci uygulamalarının ne kadar veri aktarabileceğini tanımlar. üretmek ve tüketmek Saniyede bayt olarak ölçülen bir Kafka kümesindeki her bir aracıdan.
  • Oran kotalarını talep edin – Bu, her aracının istemci uygulamaları isteklerini işlemek için harcadığı sürenin yüzdesini sınırlar.

İş gereksinimlerine bağlı olarak, bu kota yapılandırmalarından herhangi birini kullanabilirsiniz. Bununla birlikte, ağ bant genişliği kotalarının kullanımı yaygındır, çünkü kuruluşların platform kaynakları tüketimini uygulamalar tarafından saniyede üretilen ve tüketilen veri miktarına göre sınırlandırmasına olanak tanır.

Bu gönderi, IAM erişim kontrolüne sahip bir MSK kümesi kullandığından, özellikle yapılandırmayı tartışıyoruz. ağ bant genişliği kotaları uygulamalara bağlı olarak müşteri kimlikleri ve kimliği doğrulanmış kullanıcı sorumluları.

Kafka kotalarına ilişkin hususlar

Kafka kotalarıyla çalışırken aşağıdakileri aklınızda bulundurun:

  • Uygulama seviyesi – Kotalar, küme düzeyinde değil aracı düzeyinde uygulanır. Bir Kafka kümesinde altı aracı olduğunu ve bir müşteri kimliği ve kullanıcı için 12 MB/sn'lik bir üretim kotası belirttiğinizi varsayalım. İstemci kimliğini ve kullanıcıyı kullanan üretici uygulaması, aynı anda her aracıda maksimum 12 MB/sn, altı aracının tamamında toplam maksimum 72 MB/sn üretebilir. Bununla birlikte, bir konunun her bölümü için liderlik bir aracıda bulunuyorsa, aynı üretici uygulaması en fazla 12 MB/sn üretebilir. Kısıtlamanın aracı başına gerçekleşmesi nedeniyle, tüm aracılar arasında konuların bölüm liderliğinde eşit bir denge sağlamak önemlidir.
  • daraltma – Bir uygulama kotasına ulaştığında, kısıtlanır, başarısız olmaz, yani aracı bir istisna atmaz. Bir aracıda kotasına ulaşan müşterilerin istekleri, kotayı aşmamak için aracı tarafından kısıtlanmaya başlar. Aracı, bir istemci kotayı aştığında hata göndermek yerine kotayı yavaşlatmaya çalışır. Komisyoncular, müşterileri kotaların altına getirmek için gereken gecikme miktarını hesaplar ve yanıtları buna göre geciktirir. Bu yaklaşımın bir sonucu olarak, kota ihlalleri müşteriler için şeffaftır ve müşterilerin herhangi bir özel geri çekme veya yeniden deneme politikası uygulaması gerekmez. Ancak, eşzamansız bir üretici kullanıldığında ve kota nedeniyle aracının kabul edebileceğinden daha yüksek bir hızda iletiler gönderilirken, iletiler önce istemci uygulama belleğinde sıraya alınır. Mesaj gönderme hızı, mesaj kabul etme oranını aşmaya devam ederse, istemcinin arabellek alanı sonunda tükenecek ve bu da bir sonraki hataya neden olacaktır. Producer.send() engellenmek için arayınız. Producer.send() sonunda bir atacak TimeoutException zaman aşımı gecikmesi aracının üretici uygulamasını yakalamasına izin vermek için yeterli değilse.
  • Paylaşılan kotalar – Birden fazla istemci uygulaması aynı istemci kimliğine ve kullanıcıya sahipse, istemci kimliği ve kullanıcı için yapılandırılan kota tüm bu uygulamalar arasında paylaştırılır. kombinasyonu için 5 MB/sn'lik bir üretim kotası yapılandırdığınızı varsayalım. client-id="marketing-producer-client" ve user="marketing-app-user". Bu durumda, sahip olan tüm üretici uygulamaları marketing-producer-client bir şekilde Müşteri Kimliği ve marketing-app-user kimliği doğrulanmış olarak kullanıcı müdür, birbirlerinin iş hacmini etkileyen 5 MB/sn üretim kotasını paylaşacaktır.
  • Kısma üretmek – Üretim azaltma davranışı, aşağıdakiler gibi müşteri ölçütleri aracılığıyla üretici müşterilere gösterilir: produce-throttle-time-avg ve produce-throttle-time-max. Bunların sıfırdan farklı olması, hedef aracıların üreticiyi yavaşlattığını ve kota yapılandırmasının gözden geçirilmesi gerektiğini gösterir.
  • Kısıtlamayı kullan – Tüketimi azaltma davranışı, aşağıdakiler gibi istemci ölçümleri yoluyla tüketici istemcilere gösterilir: fetch-throttle-time-avg ve fetch-throttle-time-max. Bunlar sıfır değilse, kaynak aracıların tüketiciyi yavaşlattığını ve kota yapılandırmasının gözden geçirilmesi gerektiğini gösterir.

İstemci ölçümlerinin, Kafka kümelerine bağlanan istemciler tarafından sunulan ölçümler olduğunu unutmayın.

  • kota yapılandırması – Kafka kotalarını Kafka yapılandırma dosyası aracılığıyla statik olarak veya dinamik olarak yapılandırmak mümkündür. kafka-config.sh veya Kafka Yönetici API'sı. Dinamik yapılandırma mekanizması, yeni üretici ve tüketici uygulamaları için kotaların aracıları yeniden başlatmaya gerek kalmadan herhangi bir zamanda yapılandırılmasına izin verdiği için çok daha kullanışlı ve yönetilebilir. Uygulama istemcileri veri üretirken veya tüketirken bile, dinamik yapılandırma değişiklikleri gerçek zamanlı olarak etkili olur.
  • Yapılandırma anahtarları - İle kafka-config.sh komut satırı aracıyla, sırasıyla aşağıdaki üç yapılandırma anahtarını kullanarak dinamik tüketim, üretim ve istek kotaları ayarlayabilirsiniz: consumer_byte_rate, producer_byte_rate, ve request_percentage.

Kafka kotaları hakkında daha fazla bilgi için bkz. Kafka belgeleri.

IAM erişim kontrolü ile ağ bant genişliği kotalarını zorunlu kılın

Kafka kotalarını öğrendikten sonra, kimlik doğrulama ve yetkilendirme için IAM erişim kontrolünü kullanırken bunların bir MSK kümesinde nasıl uygulanacağına bakalım. Amazon MSK'deki IAM erişim denetimi, kimlik doğrulama ve yetkilendirme için iki ayrı mekanizmaya olan ihtiyacı ortadan kaldırır.

Aşağıdaki şekil, demo hesabında IAM erişim kontrolünü kullanacak şekilde yapılandırılmış bir MSK kümesini göstermektedir. Her üretici ve tüketici uygulamasının, saniyede bayt cinsinden ne kadar veri üretebileceğini veya tüketebileceğini belirleyen bir kotası vardır. Örneğin, ProducerApp-1 üretim kotası var 1024 bayt/sn, ve ConsumerApp-1 ve ConsumerApp-2 her birinin bir tüketim kotası vardır 5120 ve 1024 bayt/sn, sırasıyla. Kafka kotalarının istemci uygulamaları yerine Kafka kümesinde belirlendiğini unutmamak önemlidir.

Önceki şekil, Kafka istemci uygulamalarının (ProducerApp-1, ConsumerApp-1, ve ConsumerApp-2) erişim Topic-B Yazma ve okuma IAM rollerini üstlenerek MSK kümesinde. İş akışı aşağıdaki gibidir:

  • P1 - ProducerApp-1 (üzerinden ProducerApp-1-Role IAM rolü) Topic-B-Write-Role İleti göndermek için IAM rolü Topic-B MSK kümesinde.
  • P2 - İle Topic-B-Write-Role IAM rolü üstlendi, ProducerApp-1 mesaj göndermeye başlar Topic-B.
  • C1 - ConsumerApp-1 (üzerinden ConsumerApp-1-Role IAM rolü) ve ConsumerApp-2 (üzerinden ConsumerApp-2-Role IAM rolü) Topic-B-Read-Role Gelen mesajları okumak için IAM rolü Topic-B MSK kümesinde.
  • C2 - İle Topic-B-Read-Role IAM rolü üstlendi, ConsumerApp-1 ve ConsumerApp-2 gelen mesajları tüketmeye başla Topic-B.

ConsumerApp-1 ve ConsumerApp-2 iki ayrı tüketici uygulamasıdır. Aynı tüketici grubuna ait değiller.

İstemci kimliklerini yapılandırma ve kimliği doğrulanmış kullanıcı sorumlusunu anlama

Daha önce açıklandığı gibi, Kafka kotaları belirli kullanıcılar, belirli müşteri kimlikleri veya her ikisi için yapılandırılabilir. Hadi keşfedelim Müşteri Kimliği ve kullanıcı Kafka kota tahsisi için gerekli kavramlar ve yapılandırmalar.

müşteri kimliği

Bir uygulamanın mantıksal adını temsil eden bir istemci kimliği, bir uygulamanın kodu içinde yapılandırılabilir. Örneğin, Java uygulamalarında üreticinin ve tüketicinin müşteri kimliklerini kullanarak ayarlayabilirsiniz. ProducerConfig.CLIENT_ID_CONFIG ve ConsumerConfig.CLIENT_ID_CONFIG sırasıyla yapılandırmalar. Aşağıdaki kod parçacığı nasıl olduğunu gösterir ProducerApp-1 müşteri kimliğini şu şekilde ayarlar: this-is-me-producerapp-1 kullanma ProducerConfig.CLIENT_ID_CONFIG:

Properties props = new Properties();
props.put(ProducerConfig.CLIENT_ID_CONFIG,"this-is-me-producerapp-1");

kullanıcı

Kullanıcı, kimlik doğrulaması etkinken Kafka kümesindeki istemci uygulamasının kimliği doğrulanmış bir kullanıcı sorumlusuna atıfta bulunur. Çözüm mimarisinde gösterildiği gibi, üretici ve tüketici uygulamaları Topic-B-Write-Role ve Topic-B-Read-Role üzerinde yazma ve okuma işlemlerini gerçekleştirmek için sırasıyla IAM rolleri Topic-B. Bu nedenle, kimliği doğrulanmış kullanıcı sorumluları, aşağıdaki IAM tanımlayıcısı gibi görünecektir:

arn:aws:sts::<AWS Account Id>:assumed-role/<assumed Role Name>/<role session name>

Daha fazla bilgi için, bkz. IAM tanımlayıcıları.

The rol oturumu adı IAM sorumluları, birleştirilmiş kimlikler veya uygulamalar bir IAM rolü üstlendiğinde bir oturumu benzersiz şekilde tanımlayan bir dizi tanımlayıcıdır. Bizim durumumuzda, ProducerApp-1, ConsumerApp-1, ve ConsumerApp-2 uygulamaları kullanarak bir IAM rolü üstlenir AWS Security Token Hizmeti (AWS STS) SDK ve AWS STS SDK çağrısında bir rol oturumu adı sağlayın. Örneğin, eğer ProducerApp-1 varsayar Topic-B-Write-Role IAM rolü ve kullanımları this-is-producerapp-1-role-session rol oturum adı olarak, kimliği doğrulanmış kullanıcı sorumlusu aşağıdaki gibi olacaktır:

arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Write-Role/this-is-producerapp-1-role-session

Aşağıda, örnek bir kod parçacığı yer almaktadır. ProducerApp-1 kullanarak uygulama this-is-producerapp-1-role-session gibi rol oturumu adı varsayarken Topic-B-Write-Role AWS STS SDK'yı kullanan IAM rolü:

StsClient stsClient = StsClient.builder().region(region).build();
AssumeRoleRequest roleRequest = AssumeRoleRequest.builder() .roleArn("<Topic-B-Write-Role ARN>") .roleSessionName("this-is-producerapp-1-role-session") //role-session-name string literal .build();

Ağ bant genişliği (üret ve tüket) kotalarını yapılandırın

Aşağıdaki komutlar, üretmek ve tüketmek dayalı olarak istemci uygulamaları için dinamik olarak kotalar Müşteri Kimliği ve kimliği doğrulanmış kullanıcı IAM erişim denetimi ile yapılandırılmış MSK kümesindeki sorumlu.

Aşağıdaki kod, üretim kotasını yapılandırır:

kafka-configs.sh --bootstrap-server <MSK cluster bootstrap servers IAM endpoint> --command-config config_iam.properties --alter --add-config "producer_byte_rate=<number of bytes per second>" --entity-type clients --entity-name <ProducerApp client Id> --entity-type users --entity-name <ProducerApp user principal>

The producer_byes_rate tarafından tanımlanan bir üretici istemcinin bayt cinsinden mesaj sayısını ifade eder. Müşteri Kimliği ve kullanıcı saniyede tek bir komisyoncuya üretmesine izin verilir. Seçenek --command-config işaret config_iam.properties, IAM erişim kontrolü için gerekli özellikleri içerir.

Aşağıdaki kod, tüketim kotasını yapılandırır:

kafka-configs.sh --bootstrap-server <MSK cluster bootstrap servers IAM endpoint> --command-config config_iam.properties --alter --add-config "consumer_byte_rate=<number of bytes per second>" --entity-type clients --entity-name <ConsumerApp client Id> --entity-type users --entity-name <ConsumerApp user principal>

The consumer_bytes_rate tarafından tanımlanan bir tüketici istemcisinin bayt cinsinden mesaj sayısını ifade eder. Müşteri Kimliği ve kullanıcı saniyede tek bir komisyoncudan tüketilmesine izin verilir.

için bazı örnek kota yapılandırma komutlarına bakalım. ProducerApp-1, ConsumerApp-1, ve ConsumerApp-2 istemci uygulamaları:

  • ProducerApp-1 kota yapılandırması üretir – varsayalım ProducerApp-1 vardır this-is-me-producerapp-1 uygulama kodunda istemci kimliği olarak yapılandırılır ve kullanır this-is-producerapp-1-role-session varsayıldığında rol oturumu adı olarak Topic-B-Write-Role IAM rolü. Aşağıdaki komut, üretim kotasını ayarlar. ProducerApp-1 saniyede 1024 bayta kadar:
kafka-configs.sh --bootstrap-server <MSK Cluster Bootstrap servers IAM endpoint> --command-config config_iam.properties --alter --add-config "producer_byte_rate=1024" --entity-type clients --entity-name this-is-me-producerapp-1 --entity-type users --entity-name arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Write-Role/this-is-producerapp-1-role-session

  • ConsumerApp-1 kota yapılandırmasını kullanır – varsayalım ConsumerApp-1 vardır this-is-me-consumerapp-1 uygulama kodunda istemci kimliği olarak yapılandırılır ve kullanır this-is-consumerapp-1-role-session varsayıldığında rol oturumu adı olarak Topic-B-Read-Role IAM rolü. Aşağıdaki komut, tüketim kotasını ayarlar. ConsumerApp-1 saniyede 5120 bayta kadar:
kafka-configs.sh --bootstrap-server <MSK Cluster Bootstrap servers IAM endpoint> --command-config config_iam.properties --alter --add-config "consumer_byte_rate=5120" --entity-type clients --entity-name this-is-me-consumerapp-1 --entity-type users --entity-name arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Read-Role/this-is-consumerapp-1-role-session


ConsumerApp-2 kota yapılandırmasını kullanır
– varsayalım ConsumerApp-2 vardır this-is-me-consumerapp-2 uygulama kodunda istemci kimliği olarak yapılandırılır ve kullanır this-is-consumerapp-2-role-session varsayıldığında rol oturumu adı olarak Topic-B-Read-Role IAM rolü. Aşağıdaki komut, tüketim kotasını ayarlar. ConsumerApp-2 Aracı başına saniyede 1024 bayta kadar:

kafka-configs.sh --bootstrap-server <MSK Cluster Bootstrap servers IAM endpoint> --command-config config_iam.properties --alter --add-config "consumer_byte_rate=1024" --entity-type clients --entity-name this-is-me-consumerapp-2 --entity-type users --entity-name arn:aws:sts::<AWS Account Id>:assumed-role/Topic-B-Read-Role/this-is-consumerapp-2-role-session

Önceki komutların bir sonucu olarak, ProducerApp-1, ConsumerApp-1, ve ConsumerApp-2 İstemci uygulamaları, sırasıyla atanan üretim ve tüketim kotalarını aşarsa, IAM erişim denetimi kullanılarak MSK kümesi tarafından kısıtlanır.

Çözümü uygula

Bölüm 2 Bu dizinin bir kısmı, örnek üretici ve tüketici istemci uygulamaları ile birlikte IAM erişim kontrolü ile Kafka kota yapılandırmasının adım adım ayrıntılı uygulamasını gösterir.

Sonuç

Kafka kotaları, ekiplere üretici ve tüketici uygulamaları için sınırlar belirleme olanağı sunar. Amazon MSK ile Kafka kotaları iki önemli amaca hizmet eder: varsayımları ortadan kaldırmak ve kötü tasarlanmış üretici veya tüketici uygulamalarının kotalarını sınırlayarak neden olduğu sorunları önlemek ve merkezi bir veri akışı platformunun işletim maliyetlerini farklı maliyet merkezleri ve kiracılar (uygulama ve ürün ekipleri) arasında dağıtmak. ).

Bu gönderide, IAM erişim denetimi kullanılırken Amazon MSK içinde ağ bant genişliği kotalarının nasıl yapılandırılacağını öğrendik. Kotaları yapılandırırken istemci kimliğinin ve kimliği doğrulanmış sorumlunun nasıl kullanıldığını açıklığa kavuşturmak için bazı örnek komutları ve kod parçacıklarını da ele aldık. Kafka kotalarını yalnızca IAM erişim denetimi kullanarak göstermiş olsak da, bunları Amazon MSK destekli diğer kimlik doğrulama mekanizmalarını kullanarak da yapılandırabilirsiniz.

In Bölüm 2 Bu seride, Amazon MSK'de IAM erişim denetimi ile ağ bant genişliği kotalarının nasıl yapılandırılacağını gösteriyoruz ve bunları çalışırken görebilmeniz için size örnek üretici ve tüketici uygulamaları sunuyoruz.

Daha fazla bilgi edinmek için aşağıdaki kaynaklara göz atın:


Yazar Hakkında

Vikas Bajaj Amazon Web Services'ta Finansal Hizmetler, Çözüm Mimarları Kıdemli Yöneticisidir. Finansal hizmetler kuruluşları ve dijital yerli müşterilerle çalışmış biri olarak, Avustralya'daki finansal hizmetler müşterilerine teknoloji kararları, mimariler ve ürün yol haritaları konusunda danışmanlık yapmaktadır.

spot_img

En Son İstihbarat

spot_img