Pemilihan proyek

Sebelum kode klien yang pertama ditulis, lingkup proyek ditetapkan lebih dahulu agar keputusan teknis berikutnya tidak berubah arah di tengah pengerjaan. Topik ini membahas pemilihan proyek untuk sistem perekaman sensor suhu di satu gedung, mulai dari kriteria pemilihan, perbandingan alternatif teknologi, lingkup minimum, daftar bukan-tujuan, sampai kontrak keberhasilan yang terukur. Proyek yang menjadi pegangan pada modul ini menggunakan perangkat sensor suhu yang mengirim pembacaan, layanan perekam yang menuliskannya ke topic, layanan perekap yang menyetorkan rangkuman, dan satu antrean tampilan yang menyajikan data lama. Setelah membaca topik ini, lingkup proyek dapat ditulis sebagai keputusan yang menyebut komponennya dan angka keberhasilannya.

Kriteria pemilihan proyek kejadian#

Sebuah proyek layak dikerjakan di atas Kafka apabila datanya benar-benar aliran kejadian dan pembacanya menuntut kemandirian. Tiga kriteria berikut menjadi alat pengujian sebelum keputusan teknologi diambil. Proyek yang lolos ketiganya mendapat manfaat nyata dari model log kejadian, sedangkan proyek yang gagal pada salah satunya biasanya lebih tepat dikerjakan dengan sistem yang lebih sederhana.

• Aliran kejadian nyata hadir, artinya data lahir sebagai peristiwa pada waktu tertentu, misalnya pembacaan suhu yang dikirim per menit, dan bukan hasil kueri acak atas keadaan terkini.
• Consumer independen lebih dari satu, artinya beberapa pembaca membuka aliran yang sama dengan posisi dan kecepatan masing-masing, misalnya layanan perekap dan antrean tampilan pada proyek sensor suhu.
• Kebutuhan replay nyata, artinya hasil pemrosesan perlu dihitung ulang dari titik waktu tertentu, misalnya setelah perbaikan pada logika layanan perekap.

Ketiga kriteria hadir pada proyek sensor suhu. Pembacaan suhu lahir sebagai kejadian dengan waktu kejadiannya sendiri, sehingga aliran kejadiannya nyata dan bukan keadaan terkini yang terus diperbarui. Layanan perekap dan antrean tampilan membaca aliran yang sama pada kecepatan yang berbeda, dan rangkuman perlu dihitung ulang ketika logika perekap diperbaiki.

Apabila salah satu kriteria tidak hadir, pilihan lain biasanya lebih hemat. Satu pembaca tunggal tanpa riwayat cukup dilayani antrean sederhana, sedangkan data keadaan terkini lebih tepat disimpan pada basis data. Kriteria ini dengan demikian juga berfungsi sebagai alasan tertulis ketika Kafka dipilih atau ditolak.

Perbandingan alternatif teknologi#

Keputusan teknologi diambil dengan membandingkan cara kerja setiap alternatif terhadap ketiga kriteria pemilihan. Tabel berikut merangkum tiga keluarga teknologi yang paling umum dipertimbangkan untuk aliran data. Kolom kecocokannya mengikuti kriteria pada bagian sebelumnya.

Proyek sensor suhu berada pada baris ketiga karena ketiga kriterianya hadir sekaligus. Basis data dengan langganan perubahan menyimpan riwayatnya sendiri, tetapi pembacaannya melalui kueri dan bukan melalui posisi offset yang berlanjut. Antrean pesan klasik menghapus pesan setelah diambil, sehingga consumer kedua kehilangan aliran yang dibutuhkan consumer pertama. Pada proyek ini basis data tetap digunakan untuk keadaan terkini yang ditampilkan, sedangkan Kafka mengalirkan sejarah kejadiannya, sehingga keduanya melengkapi satu sama lain. Memilih Kafka bukan berarti membuang teknologi yang sudah ada.

Lingkup minimum proyek#

Lingkup minimum adalah komponen terkecil yang tetap menuntut consumer nyata dan tetap menunjukkan pola arsitektur kejadian. Komponen itu dirumuskan sebelum diagramnya digambar, sehingga setiap kotak pada diagram memiliki alasan keberadaan. Lingkup minimum proyek sensor suhu terdiri atas empat bagian berikut.

• Dua layanan, yaitu layanan perekam sebagai producer dan layanan perekap sebagai consumer yang menyetorkan rangkuman.
• Satu topic utama bernama m8-suhu-kejadian yang menyimpan pembacaan mentah dari seluruh perangkat.
• Satu topic rangkuman bernama m8-suhu-rangkuman yang menyimpan rangkuman per jam hasil layanan perekap.
• Satu broker tunggal mode KRaft yang menampung kedua topic tersebut pada lingkungan pengembangan.

Antrean tampilan tetap muncul pada diagram karena menyajikan data lama, tetapi komponen itu cukup berupa pembaca topic rangkuman sehingga tidak menambah topic baru. Diagram berikut memperlihatkan alur minimum tersebut. Pembacaan mengalir dari perangkat menuju topic utama, lalu rangkumannya mengalir menuju topic rangkuman dan antrean tampilan.

Alur minimum ini sudah memuat semua peran yang dituntut Kafka, yaitu producer nyata, consumer yang membaca topic yang sama, dan data yang dibaca ulang ketika rangkuman dihitung ulang. Komponen lain diundur sampai alur ini berjalan penuh. Setiap keputusan teknis pada modul ini mengacu pada diagram yang sama.

Bukan-tujuan proyek#

Daftar bukan-tujuan menyatakan pekerjaan yang sengaja tidak dikerjakan pada siklus proyek ini. Daftar semacam itu melindungi lingkup karena setiap usulan tambahan dibandingkan dengan daftarnya sebelum diterima. Bukan-tujuan proyek sensor suhu ditetapkan sebagai berikut.

• membangun antarmuka pengguna berupa grafik atau dasbor, karena antrean tampilan cukup menyajikan data yang dibaca dari topic rangkuman
• mengubah protokol perangkat sensor, karena perangkat diperlakukan sebagai sumber kejadian yang siap digunakan
• menjalankan cluster multi-broker, karena satu broker memenuhi lingkup minimum pada tahap ini
• menerapkan deteksi anomali atau prediksi suhu, karena proyek hanya menyimpan dan merangkum kejadian
• menggantikan penyimpanan yang sudah ada, karena basis data tetap berperan menyimpan keadaan terkini

Usulan fitur yang tidak tercakup pada lingkup minimum dan tidak tercantum di atas diundur ke siklus berikutnya. Cara ini menjaga proyek tetap dapat diselesaikan dalam waktu yang dijanjikan. Daftar bukan-tujuan ditinjau ulang bersama lingkup minimum ketika siklus baru dimulai, sehingga item yang berpindah statusnya tercatat sebagai keputusan dan bukan sebagai perubahan diam-diam.

Kontrak keberhasilan yang diukur#

Kontrak keberhasilan menyatakan angka yang menentukan kapan proyek berjalan sesuai harapan. Angka itu dapat diperiksa ulang oleh siapa pun yang membaca sistemnya, sehingga keberhasilan bukan kesimpulan yang bergantung pada penilaian sewaktu-waktu. Tiga angka diperjanjikan untuk proyek sensor suhu, yaitu lag, ketersediaan, dan retensi.

• Backlog layanan perekap pada topic utama, yang diukur sebagai lag, tidak melewati sepuluh menit pada keadaan normal.
• Alur tulis topic utama tersedia paling sedikit 99 persen dari waktu operasional gedung setiap hari.
• Kejadian mentah tersimpan tujuh hari dan rangkuman tersimpan tiga puluh hari, sehingga penghitungan ulang satu minggu ke belakang dijamin.

Ketiga angka dihitung dari skala kejadian yang diperkirakan. Setiap perangkat mengirim satu pembacaan per menit, dan jumlah perangkat yang terpasang pada tahap ini adalah 20 buah. Skrip berikut menghitung skala kejadian harian, kebutuhan throughput-nya, serta diska yang diperlukan untuk retensi yang dijanjikan. Skrip dijalankan dari folder topik dengan perintah python3 -B hitung-skala.py.

# skala kejadian harian proyek sensor suhu dan kebutuhan yang mengikutinya

jumlah_perangkat = 20         # sensor suhu terpasang pada tahap ini
interval_detik = 60           # satu pembacaan per menit per perangkat
payload_byte = 250            # perkiraan ukuran satu kejadian
payload_rangkuman = 200       # perkiraan ukuran satu rangkuman

detik_per_hari = 24 * 60 * 60
kejadian_harian = jumlah_perangkat * (detik_per_hari // interval_detik)
rata_rata = kejadian_harian / detik_per_hari
puncak = rata_rata * 10       # lonjakan pembacaan serentak diperkirakan sepuluh kali rata-rata
volume_harian_mb = kejadian_harian * payload_byte / (10 ** 6)
rangkuman_harian = jumlah_perangkat * 24  # satu rangkuman per jam per perangkat
volume_rangkuman_mb = rangkuman_harian * payload_rangkuman / (10 ** 6)

print(f"kejadian per hari        : {kejadian_harian:,}")
print(f"throughput rata-rata     : {rata_rata:.2f} kejadian per detik")
print(f"throughput puncak (10x)  : {puncak:.2f} kejadian per detik")
print(f"volume kejadian harian   : {volume_harian_mb:.1f} MB")
print(f"diske kejadian 7 hari    : {volume_harian_mb * 7:.1f} MB")
print(f"diske rangkuman 30 hari  : {volume_rangkuman_mb * 30:.1f} MB")

kejadian per hari        : 28,800
throughput rata-rata     : 0.33 kejadian per detik
throughput puncak (10x)  : 3.33 kejadian per detik
volume kejadian harian   : 7.2 MB
diske kejadian 7 hari    : 50.4 MB
diske rangkuman 30 hari  : 2.9 MB

Skala proyek ini kecil dibandingkan kapasitas Kafka. Rata-ratanya kurang dari satu kejadian per detik dan seluruh retensi tujuh hari hanya membutuhkan 50.4 MB diska, sehingga kapasitas bukan alasan pemilihan Kafka pada proyek ini. Alasan pemilihannya adalah ketiga kriteria pada bagian pertama, yaitu aliran kejadian nyata, consumer independen, dan kebutuhan replay. Angka hasil perhitungan tetap berguna karena angka itulah yang digunakan untuk menetapkan ambang lag berbasis durasi dan untuk memastikan retensi tidak membebani diska. Apabila jumlah perangkat berlipat pada siklus berikutnya, skrip yang sama dijalankan ulang dengan angka baru sebelum kontrak direvisi.

Ringkasan#

• Kriteria pemilihan proyek kejadian mencakup aliran kejadian nyata, consumer independen, dan kebutuhan replay, dan proyek yang gagal pada salah satunya biasanya lebih tepat dikerjakan dengan sistem yang lebih sederhana.
• Proyek sensor suhu dipilih berjalan di atas Kafka karena ketiga kriterianya hadir, sedangkan basis data tetap digunakan untuk keadaan terkini yang ditampilkan.
• Lingkup minimum terdiri atas dua layanan, satu topic utama, satu topic rangkuman, dan satu broker tunggal, dengan daftar bukan-tujuan yang melindungi lingkup dari penggelembungan.
• Kontrak keberhasilan menyebut angka yang dapat diperiksa ulang, yaitu lag berbasis durasi, ketersediaan tulis, dan retensi yang dihitung dari skala kejadian.

Referensi#

• Apache Kafka documentation — Apache Software Foundation — dokumentasi resmi yang menjadi dasar pengujian kriteria pemilihan sistem berbasis kejadian.
• Introduction — Apache Software Foundation — pengantar resmi log kejadian, topic, dan partisi yang membedakan Kafka dari antrean pesan.
• Topic configs — Apache Software Foundation — konfigurasi retention.ms yang menyatakan batas simpan topic pada kontrak retensi.