Temu duga kejuruteraan data: Kinesis on-demand atau provisioned capacity?

Gesaan dan konteks

Anda memiliki platform data yang menyerap peristiwa pengguna untuk beberapa pengguna masa nyata (real-time consumers). Trafik adalah stabil untuk sebahagian besar hari dan memuncak semasa kempen. Perniagaan tidak boleh bertolak ansur dengan pendikit (throttling) yang berterusan, tetapi ia tidak mahu membayar kapasiti lebih awal untuk tempoh rendah (trough). Andaikan anda boleh membaca daya pemprosesan pengeluar, kependaman bacaan, throttling dan kelengahan pengguna (consumer lag), serta boleh menukar mod kapasiti semasa tetingkap penyelenggaraan.

Perkara yang dinilai oleh penemu duga

Penemu duga sedang menguji sama ada anda memahami bahawa mod kapasiti mengubah tanggungjawab operasi dan kos, bukan semantik penghantaran. Jawapan yang kukuh menggunakan puncak sejarah dan bentuk lonjakan untuk memutuskan sama ada penskalaan automatik memberi nilai, kemudian menyemak had setiap shard, bilangan pengguna, percubaan semula (retries) dan pemulihan lag. Jawapan yang lemah hanya mengatakan untuk memilih on-demand setiap kali trafik berubah-ubah.

Penjelasan yang perlu ditanya terlebih dahulu

• Berapa lamakah puncak berlangsung, dan adakah ia boleh diramal? Lonjakan pendek yang tidak dapat diramal memihak kepada pengurusan kapasiti automatik.
• Adakah penulisan dan pembacaan dikekang pada masa yang sama? Ukur bait, rekod, bacaan dan tingkah laku pengguna secara berasingan.
• Adakah terdapat siling kos yang ketat atau belanjawan kapasiti? Trafik stabil dengan belanjawan ketat lebih mudah dioptimumkan dalam mod provisioned.
• Adakah pengguna berkongsi daya pemprosesan atau memerlukan bacaan khusus? Pelbagai pengguna mengubah kuota bacaan dan kos.
• Bolehkah pasukan bertolak ansur dengan peralihan keadaan yang singkat? Pertukaran dan percubaan semula lonjakan memerlukan buku panduan (runbook) yang jelas.

Rangka kerja jawapan 30 saat

"Saya akan mengukur MB/s penulisan setiap jam, kadar rekod, MB/s bacaan, lag dan throttling, memisahkan puncak yang boleh diramal daripada lonjakan pantas (bursts). Trafik yang stabil dan boleh diramal boleh menggunakan provisioned capacity dengan jadual penskalaan; perubahan yang pantas atau sukar diramal memihak kepada on-demand, tetapi saya akan mengesahkan peningkatan berperingkat (ramp-up), kuota dan kos. Mana-mana pilihan mesti melepasi kawalan had untuk throttling, pemulihan lag, kependaman hujung ke hujung dan perbelanjaan bulanan."

Jawapan mendalam langkah demi langkah

1. Bina garis dasar kapasiti. Agregatkan penulisan dan bacaan mengikut minit, rekod P50, P95, P99, tempoh puncak dan kunci sekatan panas (hot partition keys); nilai purata menyembunyikan lonjakan.
2. Semak had daya pemprosesan. AWS mendokumentasikan had shard lalai sebanyak 1 MB/s atau 1,000 rekod sesaat untuk penulisan dan 2 MB/s untuk bacaan. Tukarkan saiz rekod dan pemprosesan kelompok kepada kedua-dua bait dan rekod.
3. Pilih mod. Gunakan provisioned capacity dengan pelan penskalaan untuk beban yang stabil; utamakan on-demand apabila beban berubah dengan cepat atau sukar diramal, dan rekod kependaman pelarasan automatik.
4. Modelkan pengguna. Bacaan kongsi, enhanced fan-out, percubaan semula dan pemprosesan pendua mempengaruhi kuota bacaan. Kelengahan pengguna tergolong dalam perancangan kapasiti, bukan hanya metrik pengeluar.
5. Modelkan kos. Untuk mod provisioned, sertakan jam shard (shard-hours) dan ruang kelegaan (headroom) penskalaan. Untuk on-demand, sertakan daya pemprosesan sebenar dan pengebilan puncak, ditambah ulang main (replay) dan penulisan berganda lonjakan.
6. Lakukan rintis dan undur balik. Tukar satu strim tidak kritikal, pantau throttling, pemulihan lag, kependaman P99 dan perbelanjaan bulanan. Jika kawalan had gagal, kembali ke mod yang disahkan sambil mengekalkan susunan dan tingkah laku percubaan semula.

Alternatif termasuk membahagikan hot partition key, mengelompokkan penulisan, mengecilkan peristiwa, menimbal dengan Firehose, atau membuat pra-skala untuk kempen yang boleh diramal. Mod kapasiti tidak boleh membaiki kunci yang condong, pengguna yang lambat atau percubaan semula tanpa had.

Model jawapan

"Saya akan memeriksa keluk penulisan dan bacaan per minit selama 30 hari, mengira P95/P99, tempoh puncak dan kecondongan kunci sekatan. Saya akan menterjemahkan saiz rekod melalui had shard AWS kepada MB/s penulisan dan kadar rekod, kemudian menyemak daya pemprosesan pengguna kongsi dan pemulihan lag. Untuk puncak boleh diramal yang berlarutan selama berjam-jam, saya akan menggunakan provisioned capacity dan membuat pra-skala sebelum kempen. Untuk puncak pendek yang tidak dapat diramal, saya akan merintis on-demand pada strim tidak kritikal dengan throttling di bawah 0.1%, p99 pemulihan lag di bawah 5 minit, kependaman hujung ke hujung dalam lingkungan 20% daripada garis dasar, dan had kos bulanan. Saya akan memantau partition panas dan pendua dalam kedua-dua mod; menukar mod kapasiti tidak boleh menyembunyikan punca utama."

Kesilapan biasa

• Kesilapan: Menganggar daripada purata daya pemprosesan → Sebab ia gagal: Lonjakan dan kunci panas menyebabkan throttling setempat → Penyelesaian: Gunakan P95/P99, tempoh puncak dan pengedaran kunci.
• Kesilapan: Menganggap on-demand sebagai daya pemprosesan tanpa had → Sebab ia gagal: Kuota perkhidmatan dan ramp-up masih penting → Penyelesaian: Sahkan tingkah laku ramp-up, kuota dan ujian lonjakan.
• Kesilapan: Mengira kos pengeluar sahaja → Sebab ia gagal: Pengguna, percubaan semula dan replay menguatkan daya pemprosesan → Penyelesaian: Bina senario kos hujung ke hujung.
• Kesilapan: Mengabaikan semantik penghantaran → Sebab ia gagal: Mod kapasiti tidak menghapuskan risiko sekurang-kurangnya sekali (at-least-once) dan pemprosesan pendua → Penyelesaian: Kekalkan keidempotensian (idempotency), titik semak (checkpoints) dan pemulihan lag.

Soalan susulan dan respons

On-demand masih mengalami throttling; apakah yang anda laraskan dahulu?

Asingkan kekurangan daya pemprosesan keseluruhan, kunci sekatan panas dan pengguna yang ketinggalan. Semak kadar rekod, pengedaran kunci dan peristiwa penskalaan sebelum memilih backoff, pembahagian semula partition atau menambah lebih banyak pengguna.

Bilakah provisioned capacity lebih murah?

Apabila penulisan dan bacaan stabil, puncak boleh dijadualkan dan penggunaan kekal tinggi, modelkan shard-hours dan ruang kelegaan penskalaan. Jangan hanya membandingkan harga unit.

Bagaimana jika trafik kempen meningkat sepuluh kali ganda?

Sahkan kuota on-demand dan tingkah laku ramp-up sejarah terlebih dahulu. Buat pra-skala untuk kempen yang boleh diramal, tambah backoff pengeluar serta amaran lag, dan tentukan degradasi perkhidmatan bagi peristiwa tidak kritikal.

Bagaimanakah anda membuktikan pilihan itu betul?

Bandingkan throttling, p99 pemulihan lag, kependaman hujung ke hujung, kadar pendua dan kos bulanan sebelum dan selepas rintis dengan takrifan yang sama. Kembangkan pelaksanaan selepas dua kitaran perniagaan memenuhi kawalan had yang ditetapkan.