Masalah dan ruang lingkup
Diskusikan distribusi latensi permintaan tunggal, permintaan gabungan (composed requests), dan sasaran layanan. Asumsikan 100.000 permintaan per menit, rata-rata 80 ms, p95 180 ms, dan p99 2 detik. Ini adalah asumsi wawancara, bukan tolok ukur industri. Fokuslah pada penalaran dan verifikasi daripada alat vendor tertentu.
Apa yang sedang dievaluasi oleh pewawancara
Pewawancara ingin melihat pemahaman bahwa nilai rata-rata menggambarkan total beban kerja, bukan bentuk distribusi. Permintaan ekor (tail requests) dapat mengelompok berdasarkan tenant, rute, dependensi, wilayah, ukuran permintaan, atau jalur percobaan ulang (retry path). Jawaban yang kuat mendefinisikan batasan pengukuran, dimensi agregasi, dampak pengguna, penyebab di sisi server, dan SLO yang dapat ditindaklanjuti.
Pertanyaan klarifikasi
- Apakah latensi diukur hingga byte pertama atau respons lengkap?
- Apakah p99 per instans, rute, wilayah, atau seluruh layanan, dan dalam rentang waktu (window) berapa?
- Apakah timeout, pembatalan, retry, dan cache hit disertakan?
- Apakah ukuran permintaan, tenant, panggilan dependensi, atau kesalahan mengalami perubahan pada bagian ekor?
- Apakah tujuannya untuk meningkatkan performa secara keseluruhan atau melindungi anggaran ekor pada jalur kritis (critical path)?
Kerangka jawaban 30 detik
"Rata-rata 80 ms dapat berdampingan dengan p99 sebesar 2 detik; 1% yang paling lambat masih dapat memicu timeout bagi pengguna dan upstream. Saya akan menetapkan batasan dan rentang waktu, lalu membagi distribusi berdasarkan rute, wilayah, instans, tenant, ukuran permintaan, dan dependensi. Saya akan memeriksa antrean, pool, GC, disk, lock, panggilan downstream, dan retry. Perbaikan harus sesuai dengan bottleneck: antrean terikat (bounded queues), timeout yang wajar, batching atau caching, pengurangan dependensi serial, isolasi tenant yang berisik, dan anggaran retry yang terbatas. Validasi dengan SLO p95/p99 dan anggaran kesalahan (error budget)."
Desain mendalam langkah demi langkah
Tentukan titik pengamatan: waktu total klien, edge-to-service, pemrosesan layanan, waktu tunggu downstream, dan transfer respons. Pilih semantik byte pertama atau respons lengkap, gunakan jam monotonik (monotonic clock), dan dokumentasikan pengambilan sampel. Hitung timeout dan pembatalan secara terpisah; tautkan retry ke permintaan asli agar satu tindakan pengguna tidak dihitung sebagai beberapa keberhasilan independen.
Persentil harus berasal dari sampel permintaan; merata-ratakan nilai p99 instans adalah tindakan yang tidak valid. Uraikan persentil dan jumlah sampel berdasarkan rute, status, wilayah, instans, tenant, ukuran permintaan, dan dependensi. Rentang waktu pendek mengungkap regresi tetapi mengalami fluktuasi (jitter); rentang waktu panjang menstabilkan SLO tetapi dapat menyembunyikan rilis yang bermasalah. Tunjukkan keduanya.
Permintaan gabungan memperbesar latensi ekor. Panggilan serial menjumlahkan tahap-tahapnya; panggilan paralel selesai mendekati latensi anak maksimum. Tetapkan anggaran untuk setiap tahap, catat trace span, dan periksa fan-out. Rata-rata suatu layanan tidak dapat memprediksi pengalaman halaman secara menyeluruh (end-to-end).
Diagnosis korelasi sebelum menebak. Usia antrean yang meningkat menunjukkan tekanan kapasitas atau penerimaan (admission); waktu tunggu pool menunjukkan batas konkurensi; jitter pada GC, disk, dan CPU menciptakan tail; p99 downstream yang lambat merambat ke upstream. Bandingkan sampel yang berhasil dan yang mengalami timeout berdasarkan atribut permintaan, serta pertahankan konteks terkontrol untuk trace yang lambat.
Sesuaikan solusi dengan penyebabnya. Lebih sedikit panggilan serial, caching, atau batching akan mengurangi overhead tetap; konkurensi terikat, backpressure, dan isolasi tenant mencegah kemacetan; timeout terbatas dan retry dengan jitter menghindari retry storm; pekerjaan asinkron menghapus tugas-tugas yang tidak dapat diprediksi dari jalur sinkron. Hanya menambahkan thread atau replika saja justru dapat memperpanjang ekor.
Nyatakan SLO sebagai fraksi dari permintaan yang memenuhi syarat yang mencapai ambang batas tertentu, seperti 99,9% di bawah 300 ms. Error budget menggabungkan pelanggaran latensi dan kesalahan dalam keputusan rilis. Sebutkan ingress, status, semantik cache, dan rentang waktunya. Target yang hanya berbasis rata-rata dapat tetap berstatus hijau sementara pengguna yang paling lambat mengalami kendala.
Validasi perubahan distribusi dalam rilis dan simulasi gangguan. Bandingkan p50, p95, p99, nilai maksimum, tingkat timeout, dan jumlah sampel sebelum dan sesudah perubahan. Injeksikan latensi dependensi, buat permintaan tenant besar, dan habiskan pool untuk memverifikasi isolasi dan degradasi. Setelah pemulihan, periksa pengosongan antrean dan amplifikasi retry, bukan hanya nilai rata-ratanya.
Contoh jawaban berkualitas tinggi
"Rata-rata 80 ms dan p99 sebesar 2 detik menunjukkan adanya long tail yang jelas; 1% yang paling lambat dapat memicu timeout bagi pengguna atau upstream. Saya akan menstandardisasi batasan waktu, memisahkan byte pertama, respons lengkap, pembatalan, dan retry, lalu membaginya berdasarkan rute, wilayah, instans, tenant, ukuran permintaan, dan dependensi. Sebuah halaman juga menjumlahkan panggilan serial dan mengambil nilai maksimum dari panggilan paralel, sehingga trace span memerlukan anggaran per tahap.
Setelah mengidentifikasi antrean, pool, GC, disk, atau latensi downstream, saya akan menerapkan konkurensi terikat, caching atau batching, pengurangan dependensi serial, isolasi tenant, dan retry terbatas. Saya akan memvalidasinya dengan SLO 99,9% di bawah 300 ms, error budget, dan perbandingan persentil di seluruh rilis, memastikan ekor membaik tanpa menyembunyikan kesalahan atau masalah kebenaran (correctness)."
Kesalahan umum
- Hanya melaporkan rata-rata → pengguna pada bagian ekor tidak terlihat → laporkan persentil, sampel, dan timeout.
- Merata-ratakan nilai p99 instans → persentil tidak dapat dirata-ratakan secara linear → agregasikan sampel atau bucket histogram dengan benar.
- Menghitung retry sebagai permintaan pengguna baru → beban dan pengalaman pengguna salah terwakili → tautkan percobaan ke permintaan awal.
- Hanya mengukur waktu server → jaringan, antrean, dan transfer terlewatkan → tentukan batasan end-to-end.
- Menambahkan thread tanpa batas → perebutan sumber daya (contention) dan antrean memperpanjang ekor → gunakan konkurensi terikat dan backpressure.
- Mengulang (retry) setiap timeout secara membabi buta → retry storm melumpuhkan dependensi → gunakan anggaran, jitter, dan tenggat waktu (deadlines).
- Menetapkan satu SLO global → suatu tenant atau wilayah dapat terdegradasi secara diam-diam → bagi berdasarkan dimensi kritis.
- Hanya memantau nilai rata-rata setelah rilis → regresi tetap tersembunyi → bandingkan beberapa persentil dan rentang waktu.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Mengapa p99 bukan merupakan permintaan yang paling lambat?
p99 berarti sekitar 99% sampel tidak lebih lambat dari nilai tersebut; sekitar 1% lebih lambat. Nilai maksimum sangat sensitif terhadap satu anomali dan ukuran sampel, sehingga keduanya memiliki kegunaan yang berbeda.
Pertanyaan lanjutan 2: Sebuah halaman memiliki lima panggilan paralel. Bagaimana Anda memperkirakan pengalamannya?
Tahap paralel mendekati latensi anak maksimum ditambah penjadwalan klien dan transfer. Ukur waktu total halaman dan lacak anak mana yang paling sering menjadi nilai maksimum.
Pertanyaan lanjutan 3: Kapan latensi ekor yang lebih tinggi dapat diterima?
Ekspor offline atau tugas latar belakang berfrekuensi rendah dapat mengorbankan latensi demi throughput; jalur kritis interaktif biasanya tidak dapat melakukannya. Definisikan SLO per kelas permintaan.
Pertanyaan lanjutan 4: Mengapa histogram lebih baik daripada rata-rata?
Histogram mempertahankan bucket dan bentuk distribusi, memungkinkan beberapa estimasi persentil dan pemeriksaan ekor. Agregasi tetap memerlukan perhatian terhadap batas bucket dan jumlah sampel.
Pertanyaan lanjutan 5: Bagaimana Anda memisahkan ekor antrean dari ekor downstream?
Catat rentang waktu tunggu, pemrosesan, dan downstream secara terpisah. Waktu antrean dan layanan yang meningkat bersamaan menunjukkan masalah kapasitas; hanya peningkatan downstream yang mengarah pada dependensi atau retry-nya.
Pertanyaan lanjutan 6: Bagaimana error budget membantu pengelolaan latensi?
Hitung pelanggaran ambang batas sebagai konsumsi anggaran. Pengurangan anggaran yang cepat akan menjeda rilis berisiko dan memprioritaskan perbaikan ekor; sisa anggaran memungkinkan dilakukannya eksperimen terkontrol.