Skalabilitas dengan Event Hubs

Ada dua faktor yang memengaruhi penskalakan dengan Azure Event Hubs.

  • Unit throughput (tingkat standar) atau unit pemrosesan (tingkat premium)
  • Partitions

Unit throughput

Unit throughput mengontrol kapasitas throughput pusat aktivitas. Unit throughput adalah unit kapasitas yang telah dibeli sebelumnya. Satu unit throughput tunggal menyediakan kemampuan berikut:

  • Ingress: Hingga 1 MB per detik atau 1.000 peristiwa per detik (mana yang lebih dulu).
  • Egress: Hingga 2 MB per detik atau 4.096 peristiwa per detik.

Jika Anda melebihi kapasitas unit throughput yang Anda beli, pemasukan data dibatasi dan Azure Event Hubs melempar EventHubsException dengan nilai Alasan ServiceBusy. Egress tidak menghasilkan pengecualian pembatasan, tetapi tetap tidak dapat melampaui kapasitas unit throughput yang telah Anda beli. Jika Anda menerima pengecualian tarif untuk penerbitan atau mengharapkan egress yang lebih tinggi, periksa berapa banyak unit throughput yang telah Anda beli untuk namespace tersebut. Anda dapat mengelola unit throughput pada halaman Skala dari namespace tersebut di portal Azure. Anda juga dapat mengelola unit throughput secara terprogram dengan menggunakan API Azure Event Hubs.

Anda membeli unit throughput di muka dan membayarnya per jam. Setelah membeli unit throughput, Anda membayar setidaknya untuk satu jam. Anda dapat membeli hingga 40 unit throughput untuk namespace Event Hubs, dan semua Event Hubs dalam namespace tersebut berbagi unit throughput tersebut. Semua partisi dan konsumen dalam setiap hub acara berbagi kapasitas total masuk dan keluar dari unit throughput ini, sehingga konsumen yang membaca dari partisi yang sama akan berbagi bandwidth yang tersedia.

Fitur Auto-inflate Event Hubs secara otomatis meningkatkan skala dengan meningkatkan jumlah unit throughput untuk memenuhi kebutuhan penggunaan. Meningkatkan unit throughput mencegah skenario pembatasan, di mana:

  • Tingkat masuk data melebihi unit throughput yang ditetapkan.
  • Tingkat permintaan keluar data melebihi unit throughput yang ditetapkan.

Layanan Event Hubs meningkatkan throughput saat beban meningkat melampaui ambang minimum, tanpa ada permintaan yang gagal karena kesalahan ServerBusy.

Untuk informasi selengkapnya tentang fitur peningkatan otomatis, lihat Menyesuaikan skala unit throughput secara otomatis.

Unit pemrosesan

Azure Event Hubs Premium memberikan performa yang unggul dan isolasi yang lebih baik dalam lingkungan PaaS multipenyewa terkelola. Sumber daya dalam tingkat Premium diisolasi di tingkat CPU dan memori sehingga setiap beban kerja penyewa berjalan dalam isolasi. Kontainer sumber daya ini disebut Unit Pemrosesan (PU). Anda dapat membeli 1, 2, 4, 6, 8, 10, 12, atau 16 Unit pemrosesan untuk setiap namespace Layanan Azure Event Hubs Premium.

Seberapa banyak Anda dapat menelan dan mengalirkan dengan unit pemrosesan tergantung pada berbagai faktor seperti produsen Anda, konsumen, tingkat kemampuan Anda untuk menelan dan memproses, dan banyak lagi faktor lainnya.

Misalnya, namespace Premium Event Hubs dengan satu PU dan satu hub peristiwa (100 partisi) dapat kira-kira menawarkan kapasitas inti yang mendasar sekitar 5-10 MB/dtk untuk ingress dan 10-20 MB/dtk untuk egress pada beban kerja AMQP atau Kafka.

Untuk informasi selengkapnya tentang mengonfigurasi PUs untuk namespace tingkat premium, lihat Mengonfigurasi unit pemrosesan.

Catatan

Untuk informasi selengkapnya tentang kuota dan batasan, lihat Azure Event Hubs - kuota dan batasan.

Partitions

Azure Event Hubs mengatur urutan peristiwa yang dikirim ke event hub ke dalam satu atau beberapa partisi. Ketika peristiwa yang lebih baru tiba, peristiwa tersebut akan ditambahkan ke akhir urutan ini.

Gambar yang menunjukkan Event Hub dengan beberapa partisi.

Partisi dapat dianggap sebagai catatan komit. Partisi menyimpan data peristiwa yang berisi informasi berikut:

  • Isi peristiwa
  • Kumpulan properti yang ditentukan pengguna yang menjelaskan acara
  • Metadata seperti offsetnya dalam partisi, jumlahnya dalam urutan aliran
  • Tanda waktu sisi layanan saat diterima

Diagram yang menampilkan urutan peristiwa yang lebih lama ke yang lebih baru.

Manfaat menggunakan partisi

Azure Event Hubs dirancang untuk membantu pemrosesan acara dalam jumlah besar, dan partisi membantu dengan dua cara:

  • Meskipun Azure Event Hubs adalah layanan PaaS, ada realitas fisik di bawahnya. Memelihara log yang menjaga urutan peristiwa mensyaratkan bahwa peristiwa-peristiwa ini disimpan bersama-sama dalam penyimpanan dasar dan replikanya, yang mengakibatkan adanya batas throughput untuk log tersebut. Partisi memungkinkan penggunaan beberapa log paralel untuk hub peristiwa yang sama dan dengan demikian meningkatkan kapasitas throughput IO mentah yang tersedia.
  • Aplikasi Anda sendiri harus dapat mengikuti pemrosesan volume peristiwa yang dikirim ke hub peristiwa. Ini mungkin kompleks dan membutuhkan kapasitas pemrosesan paralel yang signifikan dan terukur. Kapasitas satu proses untuk menangani peristiwa terbatas, sehingga Anda memerlukan beberapa proses. Partisi adalah cara solusi Anda mendukung proses tersebut dan memastikan bahwa setiap kejadian memiliki pemilik pemrosesan yang jelas.

Jumlah partisi

Jumlah partisi ditentukan pada saat membuat hub peristiwa. Ini harus antara satu dan jumlah partisi maksimum yang diizinkan untuk setiap tingkat harga. Untuk batas jumlah partisi untuk setiap tingkat, lihat artikel ini.

Kami menyarankan Anda memilih setidaknya sebanyak partisi yang Anda perkirakan diperlukan selama beban puncak aplikasi Anda untuk hub peristiwa tertentu tersebut.

Untuk tingkatan selain tingkat premium dan khusus, Anda tidak dapat mengubah jumlah partisi untuk pusat aktivitas setelah pembuatannya. Untuk hub peristiwa di tingkat premium atau khusus, Anda dapat meningkatkan jumlah partisi setelah pembuatannya, tetapi Anda tidak dapat menguranginya lagi. Distribusi aliran di seluruh partisi akan berubah ketika kunci partisi dipetakan ulang ke partisi. Oleh karena itu, Anda harus berusaha keras untuk menghindari perubahan tersebut jika urutan peristiwa penting bagi aplikasi Anda.

Mengatur jumlah partisi ke nilai maksimum yang diizinkan mungkin menarik, tetapi selalu ingat bahwa aliran peristiwa Anda harus terstruktur sedemikian rupa sehingga Anda memang dapat memanfaatkan banyak partisi. Jika Anda memerlukan pelestarian urutan secara mutlak untuk semua kejadian atau hanya beberapa sub-aliran, Anda mungkin tidak dapat memanfaatkan banyak partisi. Juga, partisi dalam jumlah banyak membuat sisi pemrosesan lebih kompleks.

Tidak masalah berapa banyak partisi yang ada di event hub dalam hal harga. Hal ini bergantung pada jumlah unit harga (unit throughput (TU) untuk tingkat standar, unit pemrosesan (PU) untuk tingkat premium, dan unit kapasitas (CU) untuk tingkat khusus) untuk namespace atau kluster khusus. Misalnya, pusat aktivitas tingkat standar dengan 32 partisi atau dengan satu partisi dikenakan biaya yang sama persis ketika namespace diatur ke satu kapasitas TU. Selain itu, Anda dapat menskalakan TU atau PU pada namespace atau CU kluster khusus Anda terlepas dari jumlah partisi.

Partisi adalah mekanisme organisasi data yang memungkinkan penerbitan dan konsumsi paralel. Meskipun mendukung pemrosesan dan penskalaan paralel, total kapasitas tetap dibatasi oleh alokasi penskalaan namespace. Menyeimbangkan unit penskalaan (unit throughput untuk lapis standar, unit pemrosesan untuk lapis premium, atau unit kapasitas untuk lapis berdedikasi) dan partisi untuk mencapai skala optimal.

Mulailah dengan profil beban kerja Anda: ukuran payload rata-rata, peristiwa per detik, dan sensitivitas terhadap penurunan throughput atau lonjakan latensi. Gunakan throughput per partisi di bawah ini sebagai titik awal, lalu validasi dengan pengujian beban:

  • Tingkat standar: ~1 MB/dtk masuk dan ~2 MB/dtk keluar per partisi.
  • Tingkat premium dan Khusus: ~1-2 MB/dtk masuk dan ~2-5 MB/dtk keluar per partisi.

Perkirakan partisi dengan membagi ingress dan egress yang Anda harapkan dengan tarif per partisi yang berlaku dan mengambil hasil yang lebih besar. Jika throughput atau latensi yang diamati tidak memenuhi ekspektasi, tingkatkan partisi (hanya tingkat Premium dan Khusus) dan coba lagi.

Partisi juga menetapkan batas untuk paralelisme pelanggan. Cara kerja batas itu tergantung pada jenis konsumen:

  • Konsumen Epoch (eksklusif) — Digunakan oleh EventProcessorClient (.NET, Java) dan EventHubConsumerClient (Python, JavaScript), yang merupakan pola yang direkomendasikan untuk beban kerja AMQP dalam produksi. Hanya satu konsumen epok yang dapat memiliki partisi spesifik dalam suatu grup konsumen pada satu waktu. Jika Anda menyebarkan lebih banyak instans prosesor daripada partisi, instans tambahan tidak diberi partisi apa pun dan tidak aktif hingga pemilik yang sudah ada melepaskannya. Jika konsumen epoch baru terhubung dengan level pemilik yang lebih tinggi, layanan memutuskan pemilik saat ini dengan kesalahan ConsumerDisconnected, dan konsumen baru mengambil alih.
  • Konsumen non-epoch — Hingga 5 penerima non-epoch dapat membaca partisi yang sama secara bersamaan dalam grup konsumen. Setiap penerima melihat peristiwa yang sama (fan-out), sehingga mode ini tidak meningkatkan throughput pemrosesan per partisi. Menyambungkan konsumen epoch ke partisi memutuskan semua konsumen non-epoch pada partisi tersebut.
  • Konsumen Kafka — Konsumen Kafka menggunakan protokol koordinasi grup (group.id) alih-alih epoch AMQP, tetapi model kepemilikan partisi setara: setiap partisi ditetapkan untuk tepat satu anggota konsumen dalam grup konsumen pada satu waktu. Saat anggota baru bergabung atau anggota yang sudah ada keluar, grup menyeimbangkan kembali dan mendistribusikan ulang penetapan partisi. Jika ada lebih banyak anggota konsumen daripada partisi, kelebihan anggota tidak menerima penugasan dan tetap menganggur sampai penyeimbangan ulang di masa mendatang membebaskan partisi. Untuk mengurangi penyeimbangan ulang yang tidak perlu dari pemutusan sementara, atur instans unik group.instance.id per konsumen (keanggotaan statis).

Dalam praktiknya, jumlah partisi sama dengan jumlah maksimum konsumen paralel per grup konsumen terlepas dari apakah Anda menggunakan konsumen epoch AMQP atau konsumen Kafka. Faktorkan ini ke dalam jumlah partisi Anda saat Anda merencanakan peluasan skala.

Jika aplikasi Anda memiliki afinitas ke partisi tertentu, meningkatkan jumlah partisi tidak bermanfaat. Untuk informasi selengkapnya, lihat ketersediaan dan konsistensi.

Pemetaan peristiwa ke partisi

Anda dapat menggunakan kunci partisi untuk memetakan data peristiwa yang masuk ke dalam partisi tertentu untuk tujuan organisasi data. Kunci partisi adalah nilai yang disediakan pengirim yang diteruskan ke event hub. Ini diproses melalui fungsi hashing statis, yang membuat penetapan partisi. Jika Anda tidak menentukan kunci partisi saat menerbitkan peristiwa, maka penugasan round-robin akan digunakan.

Penerbit acara hanya mengetahui kunci partisinya, bukan partisi di mana peristiwa diterbitkan. Pemisahan kunci dan partisi ini membuat pengirim tidak perlu mengetahui terlalu banyak tentang pemrosesan hilir. Identitas unik per perangkat atau pengguna membuat kunci partisi yang baik, tetapi atribut lain seperti geografi juga dapat digunakan untuk mengelompokkan peristiwa terkait ke dalam satu partisi.

Menentukan kunci partisi memungkinkan menyimpan peristiwa terkait bersama-sama di partisi yang sama dan dalam urutan yang tepat di mana mereka tiba. Kunci partisi adalah beberapa untai yang diturunkan dari konteks aplikasi Anda dan mengidentifikasi keterkaitan peristiwa. Urutan peristiwa yang diidentifikasi oleh kunci partisi adalah aliran. Partisi adalah penyimpanan log multipleks untuk banyak aliran seperti itu.

Catatan

Meskipun Anda dapat mengirim acara langsung ke partisi, kami tidak merekomendasikannya, terutama jika ketersediaan tinggi penting bagi Anda. Ini mengurangi ketersediaan event hub ke tingkat partisi. Untuk informasi selengkapnya, lihat Ketersediaan dan Konsistensi.

Konten terkait

Untuk mempelajari selengkapnya tentang Azure Event Hubs, lihat artikel berikut ini:

  • Last updated on