Konteks dan prompt
Sebuah kluster komputasi bersama menjalankan pekerjaan interaktif, tugas batch, dan pelatihan yang dapat diinterupsi (preemptible). Penyewa dapat melakukan burst, tetapi tidak ada penyewa yang boleh menguasai CPU, memori, atau GPU tanpa batas. Pekerjaan berprioritas tinggi membutuhkan waktu tunggu yang lebih rendah, sementara penyewa berprioritas rendah tidak boleh mengalami starvation.
Rancang antrean, buku besar sumber daya (resource ledger), kebijakan penjadwalan, preemption, dan pemulihan. Kubernetes memisahkan PriorityClass, ResourceQuota, dan preemption; panduan manajemen antrean IETF juga memperlakukan keadilan dan kontrol kongesti sebagai batasan yang saling terkait daripada satu FIFO global tunggal.
Apa yang sedang diuji oleh pewawancara
- Memisahkan kuota penyewa, prioritas pekerjaan, dan kelayakan node.
- Mendefinisikan keadilan yang tidak menyebabkan starvation pada pekerjaan berprioritas rendah.
- Membatasi efek samping preemption, amplifikasi percobaan ulang (retry), dan fragmentasi.
- Memulihkan dari kegagalan penjadwal, pengiriman duplikat, dan hilangnya pekerja (worker).
- Membuktikan keadilan dengan metrik tingkat penyewa alih-alih rata-rata kluster.
Pertanyaan klarifikasi
- Apakah sumber daya berupa CPU, memori, GPU, atau node heterogen dengan disk lokal?
- Apakah cakupan kuota berdasarkan penyewa, proyek, antrean, atau organisasi?
- Apakah prioritas boleh mem-preempt pekerjaan, dan berapa biaya pemulihan checkpoint?
- Bisakah pekerjaan dipecah, dibatalkan, atau dicoba kembali, dan apakah penulisan hasil bersifat idempoten?
- Apakah keadilan berupa pembagian max-min, pembagian berbobot (weighted share), atau batas waktu tunggu?
Jawaban tiga puluh detik
Saya akan mengelola kuota, penggunaan, dan kapasitas pinjaman yang kedaluwarsa per penyewa, kemudian menempatkan pekerjaan dalam antrean tingkat penyewa. Setelah memfilter batasan node, penjadwal memilih penyewa yang paling kurang terlayani berdasarkan weighted fair service; aging meningkatkan prioritas efektif sehingga pekerjaan tidak mengalami starvation. Preemption hanya diizinkan jika kebijakan, kuota, dan pemulihan memastikannya aman. Reservasi, lease, dan fencing token bersifat tahan lama (durable), dan metrik dipecah berdasarkan penyewa, antrean, dan jenis sumber daya.
Desain langkah demi langkah
Langkah 1: Bangun buku besar sumber daya dan kuota
Representasikan CPU, memori, GPU, dan label node sebagai vektor sumber daya. Penggunaan jangka panjang menghabiskan kuota penyewa; peminjaman burst akan kedaluwarsa. Reservasikan sumber daya secara atomik sebelum pengiriman dan kembalikan setelah selesai, dibatalkan, atau lease kedaluwarsa. Terapkan kuota pada saat penerimaan (admission) dan penjadwalan sehingga pemanggil tidak dapat memotongnya dengan prioritas tinggi.
Langkah 2: Gunakan antrean hierarkis dan pemilihan yang adil
Buat tingkatan organisasi, penyewa, dan kelas pekerjaan, lalu pilih di antara penyewa yang siap jalan berdasarkan bobot. Lacak layanan virtual atau penggunaan sumber daya terkini dan pilih penyewa yang kurang terlayani; tambahkan aging terbatas setelah ambang batas tunggu. Antrean prioritas global dapat membiarkan penyewa besar menguasai posisi terdepan selamanya, sedangkan rotasi tingkat penyewa membuat batasan keadilan menjadi eksplisit.
Langkah 3: Batasi prioritas, peminjaman, dan preemption
Prioritas mewakili urgensi, bukan kapasitas tak terbatas. Peminjaman dibatasi pada kapasitas menganggur (idle) atau jendela waktu eksplisit. Sebelum melakukan preemption, perkirakan sumber daya yang dilepaskan, biaya checkpoint, dan anggaran korban; utamakan pekerjaan berprioritas rendah yang dapat dipulihkan. Jika pemulihan tidak terbukti aman, biarkan pekerjaan mendesak menunggu alih-alih mengambil risiko efek samping duplikat.
Langkah 4: Filter node dan kendalikan fragmentasi
Filter arsitektur, model GPU, zona, afinitas, dan kapasitas sebelum memberi skor pada node. Mencampur permintaan besar dan kecil dalam satu antrean menciptakan fragmentasi; reservasikan pool terbatas untuk bentuk (shape) besar dan tetapkan batas waktu tunggu. Catat penyebab penolakan secara terpisah: kapasitas total, ketidakcocokan bentuk, dan kuota habis.
Langkah 5: Pengiriman dengan lease dan pemulihan idempoten
Simpan reservasi berversi secara persisten. Pekerja mengklaim lease singkat dengan fencing token. Pengiriman duplikat diperiksa oleh (job_id, attempt); hanya token yang lebih baru yang boleh mengambil alih lease yang kedaluwarsa. Lepaskan reservasi setelah hasil di-commit. Saat penjadwal dimulai ulang, bangun kembali pekerjaan yang belum selesai dari log atau basis data alih-alih menebak dari memori.
Langkah 6: Tangani kegagalan, pembatalan, dan percobaan ulang
Tandai pekerja yang hilang sebagai tidak diketahui (unknown) terlebih dahulu, lalu klaim kembali setelah jendela lease dan heartbeat berakhir. Lanjutkan pekerjaan yang dapat dipulihkan dari checkpoint; efek non-idempoten memerlukan pencarian status atau kompensasi. Percobaan ulang menghabiskan anggaran penyewa dan pekerjaan dengan backoff terbatas. Pemulihan tidak boleh mengirim ulang setiap tugas yang timed-out sekaligus.
Langkah 7: Skalakan kapasitas dan ubah kebijakan
Publikasikan kebijakan berversi saat node atau bobot berubah. Pertahankan kebijakan lama untuk pekerjaan yang sudah diantrekan dan migrasikan pekerjaan baru secara bertahap; perubahan bobot tidak boleh langsung membatalkan bagian yang telah dijanjikan. Lacak sumber daya langka seperti GPU, zona, dan disk lokal secara terpisah, dengan log peristiwa audit untuk peminjaman dan reklamasi.
Langkah 8: Verifikasi keadilan dan efisiensi
Uji beban dengan beban kerja sintetis dan nyata: satu penyewa jenuh, beberapa penyewa lambat, kehilangan node acak, pemulihan checkpoint, dan perubahan kebijakan langsung (hot policy change). Ukur p50/p95 waktu tunggu penyewa, pembagian sumber daya, interval starvation maksimum, preemption, eksekusi duplikat, usia antrean, fragmentasi, dan waktu pemulihan. Bandingkan FIFO, prioritas ketat, dan penjadwalan yang adil untuk menunjukkan trade-off-nya.
Contoh jawaban berkualitas tinggi
Saya akan memisahkan kuota, prioritas, dan kelayakan node. Antrean penyewa dipilih berdasarkan layanan terbobot yang kurang terlayani ditambah aging terbatas. Peminjaman menggunakan kapasitas menganggur yang kedaluwarsa; preemption memerlukan bukti pemulihan, pemeriksaan kuota, dan anggaran checkpoint. Setiap penetapan mempertahankan reservasi, lease, dan fencing token, sementara hasilnya idempoten per percobaan. Penjadwal membangun kembali status dari log-nya dan percobaan ulang menghabiskan anggaran penyewa. Pengujian kegagalan menciptakan noisy neighbor dan kehilangan pekerja, lalu membandingkan waktu tunggu penyewa, pembagian, starvation, pekerjaan duplikat, fragmentasi, dan waktu pemulihan.
Kesalahan umum
- Satu antrean prioritas global → penyewa besar menguasai bagian depan → pilih penyewa sebelum pekerjaan lokal-penyewa.
- Memperlakukan kuota sebagai prioritas → pekerjaan mendesak melewati batas → jaga agar pemeriksaan kuota tetap atomik dan independen.
- Preemption tanpa batas → biaya checkpoint dan efek samping duplikat melonjak → tambahkan anggaran dan waktu cooldown.
- Antrean hanya dalam memori → restart menduplikasi atau menghilangkan pengiriman → pertahankan reservasi, lease, dan token.
- Hanya rata-rata kluster → penyewa dapat mengalami starvation tanpa terlihat → pecah waktu tunggu dan pembagian berdasarkan penyewa.
- Percobaan ulang langsung setelah kehilangan pekerja → eksekusi lama mungkin masih berjalan → tunggu fencing atau gunakan jalur idempoten.
Pertanyaan lanjutan
Bagaimana Anda membuktikan tidak adanya starvation?
Reservasikan bagian layanan minimum untuk setiap penyewa yang siap jalan dan batasi aging. Di bawah kapasitas tetap dan pekerjaan yang dapat dijadwalkan secara terus-menerus, verifikasi bahwa waktu tunggu maksimum tetap berada dalam batas kebijakan.
Bagaimana Anda menghindari penagihan ganda setelah preemption?
Tagih pekerjaan logis atau tahap yang telah di-commit, bukan setiap percobaan. Efek eksternal menggunakan kunci idempotensi dan pencarian status.
Bagaimana jika kuota berkonflik dengan kapasitas menganggur?
Izinkan peminjaman yang dapat kedaluwarsa dan catat kapasitas yang dapat direklamasi. Hentikan peminjaman baru terlebih dahulu, lalu tunggu penyelesaian atau preempt hanya pekerjaan yang dapat dipulihkan.
Apakah penjadwal membutuhkan konsistensi yang kuat (strong consistency)?
Reservasi, lease, dan fencing memerlukan pembaruan bersyarat yang linearizable; dasbor dapat bersifat asinkron. Cache yang usang tidak boleh mengalokasikan GPU terakhir.
Kapan penjadwalan yang adil tidak diperlukan?
Untuk satu penyewa, jendela batch tetap, atau prioritas ketat di mana starvation dapat diterima, antrean prioritas sederhana lebih mudah diverifikasi.
Apa yang memicu rollback?
Eksekusi duplikat, pemulihan yang gagal, pelanggaran batas tunggu, atau pembagian penyewa di luar anggaran akan menghentikan kebijakan baru. Pulihkan versi lama dan simpan log reservasi untuk replay.