Perintah dan kasus penggunaan
Sebuah layanan global telah menetapkan penyewa ke beberapa sel, namun satu rilis yang buruk, kegagalan dependensi bersama, atau peristiwa kapasitas masih menyebabkan pemadaman yang luas. Audit arsitektur saat ini, identifikasi jalur yang menyebarkan dampak antar-sel, dan rancang pemeriksaan injeksi kegagalan serta pemulihan yang dapat diulang untuk membuktikan bahwa setiap sel merupakan batas isolasi yang nyata.
Hal yang diuji oleh pewawancara
- Apakah Anda mendefinisikan sel sebagai replika lengkap yang dapat berjalan, menskalakan, dan melakukan rollback secara independen.
- Apakah Anda dapat mempertimbangkan radius dampak (blast radius), peta perutean, dan penetapan pengguna baru yang konsisten.
- Apakah Anda menangani bidang kendali (control plane) bersama, data lintas-sel, ketimpangan kapasitas, dan migrasi penyewa yang padat (hot-tenant).
- Apakah Anda mengubah peluncuran bertahap, batasan metrik, dan latihan pemulihan menjadi operasi yang konkret.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah kunci isolasi berupa pengguna, penyewa, wilayah, atau partisi bisnis, dan apakah akses lintas-wilayah diizinkan?
- Data mana yang harus konsisten secara global, dan data mana yang boleh konsisten pada akhirnya (eventually consistent) di dalam sel?
- Apakah tujuannya untuk membatasi dampak penerapan, bertahan dari bencana regional, atau keduanya?
- Apakah beban dapat diprediksi, dapatkah penyewa padat dipindahkan, dan bagaimana idempoten dipertahankan selama migrasi?
Kerangka jawaban 30 detik
Pertama-tama, saya akan memetakan dependensi komputasi, cache, antrean, data, dan bidang kendali di setiap sel serta menandai setiap jalur bersama. Kemudian, saya akan menentukan invarian isolasi untuk perutean, kapasitas, rilis, dan pekerjaan lintas-sel. Saya akan menginjeksikan kelebihan beban satu sel, rilis yang buruk, pemadaman dependensi data, dan hilangnya bidang kendali, serta memverifikasi bahwa tingkat kesalahan dan latensi sel yang sehat tetap berada dalam batasan. Setiap dependensi yang menyebarkan dampak harus dipartisi, dibatasi kuota, atau didukung oleh fallback snapshot lokal. Waktu pemulihan, persentase penyewa yang terpengaruh, dan bukti latihan menentukan apakah isolasi tersebut nyata.
Pembahasan mendalam langkah demi langkah
1. Batas sel
Sel adalah unit sistem yang dapat diterapkan, diskalakan, dan dipulihkan secara independen, biasanya berisi instans layanan, cache, antrean, dan shard data khusus. Layanan DNS, identitas, atau konfigurasi bersama harus tetap berhak istimewa rendah dan terhubung secara longgar, dengan perilaku penurunan fungsi (degradation) yang terdefinisi.
2. Perutean dan pemetaan
Lapisan perutean mencari peta berdasarkan kunci pengguna atau penyewa dan meneruskan permintaan ke sel target. Peta tersebut memerlukan versi, checksum, dan kebijakan kedaluwarsa. Selama migrasi, tulis peta baru terlebih dahulu dan kurangi permintaan lama agar satu entitas tidak menulis ke dua sel sekaligus.
3. Isolasi data
Setiap sel memiliki batas penulisan lokal; kueri lintas-sel lebih memilih proyeksi baca yang direplikasi secara asinkron. Keunikan global berada di koordinator khusus, atau menjadi keunikan lokal partisi ditambah rekonsiliasi akhir, daripada memusatkan setiap penulisan pada satu titik bersama.
4. Kapasitas dan titik padat (hot spots)
Tetapkan kuota permintaan, antrean, koneksi basis data, dan penyimpanan per sel untuk membatasi radius dampak maksimum. Pantau distribusi penyewa dan batas penggunaan sumber daya. Penyewa yang padat dapat dipindahkan ke sel yang menganggur, tetapi migrasi memerlukan pembacaan ganda, penulisan tunggal, dan peristiwa yang dapat diputar ulang.
5. Risiko bidang kendali bersama
Bidang kendali mengelola peta, versi, dan orkestrasi; ini tidak boleh membawa semua data bisnis. Selama pemadaman bidang kendali, perute dapat melayani dari snapshot lokal dengan TTL. Setelah kedaluwarsa, izinkan hanya pembacaan yang aman atau kembalikan kesalahan yang dapat dicoba lagi.
6. Peluncuran dan rollback
Jalankan versi baru di satu sel dan bandingkan dengan sel acuan pada tingkat kesalahan, latensi ekor (tail latency), saturasi sumber daya, dan metrik bisnis. Perluas dalam kelompok setelah melewati batas metrik. Regresi apa pun akan menjeda ekspansi dan melakukan rollback pada sel tersebut tanpa menurunkan performa sel yang sehat.
7. Operasi lintas-sel
Laporan lintas-sel, tugas batch, dan migrasi akun berjalan melalui orkestrator dengan kunci idempoten, sewa (lease), dan titik pemeriksaan kemajuan. Jika terjadi kegagalan, coba lagi hanya shard yang belum selesai dan tampilkan penyelesaian parsial secara eksplisit kepada pemanggil.
8. Pemulihan bencana dan latihan
Cadangkan data dan konfigurasi setiap sel, dengan tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang telah ditentukan. Lakukan latihan isolasi sel tunggal, kehilangan bidang kendali, kegagalan regional, dan kerusakan pemetaan untuk memverifikasi pengalihan lalu lintas, pemulihan data, dan skrip rollback daripada mengandalkan redundansi teoretis.
Contoh Jawaban Berkualitas Tinggi
“Saya tidak akan berasumsi isolasi telah terjadi hanya karena layanan diterapkan ke beberapa sel. Saya akan melacak permintaan penyewa melalui basis data, antrean, cache, identitas, konfigurasi, perutean, dan alur rilis untuk mengidentifikasi domain kegagalan bersama. Kemudian saya akan menetapkan tiga invarian: kehabisan sumber daya di satu sel tidak boleh menghabiskan sumber daya sel lain, build yang buruk hanya boleh masuk ke satu batch peluncuran, dan bidang data dapat melanjutkan dari snapshot perutean lokal selama pemadaman singkat pada bidang kendali.
Di lingkungan staging atau latihan produksi yang terisolasi ketat, saya akan menginjeksikan beban berlebih pada satu sel, hilangnya basis data, konfigurasi yang buruk, dan hilangnya direktori perutean. Sel yang sehat harus tetap berada dalam batas tingkat kesalahan, latensi P99, dan saturasi. Setiap dependensi bersama yang menyebarkan kegagalan akan mendapatkan partisi, kuota per sel, atau fallback snapshot lokal yang memiliki versi. Pemeriksaan pemulihan mencakup isolasi lalu lintas, integritas data, dan rollback pemetaan. Saya akan menjadikan persentase penyewa yang terpengaruh, waktu pemulihan, dan kesehatan lintas-sel sebagai bukti rilis, sehingga tim membuktikan isolasi secara berulang alih-alih mengandalkan diagram arsitektur.”
Kesalahan Umum
- Mereplikasi komputasi stateless sementara tetap berbagi basis data, antrean, atau kumpulan koneksi.
- Memeriksa apakah sel yang gagal pulih tanpa memeriksa tingkat kesalahan dan latensi ekor sel yang sehat.
- Menggunakan perutean acak alih-alih pemetaan penyewa yang stabil, yang menyebabkan penulisan lintas-sel.
- Menguji hilangnya infrastruktur tetapi melewatkan rilis yang buruk, penyewa padat, dan kegagalan bidang kendali.
Pertanyaan Lanjutan dan Tanggapan
Bagaimana Anda mengetahui apakah bidang kendali bersama merusak isolasi?
Putuskan sambungannya selama latihan dan verifikasi bahwa perute dapat melayani dari pemetaan lokal berversi dengan TTL. Setelah snapshot kedaluwarsa, sistem memerlukan status penurunan fungsi aman yang eksplisit.
Apa yang harus diukur oleh gerbang penerimaan isolasi?
Tetapkan batas untuk tingkat kesalahan sel yang sehat, latensi P99, saturasi, dan persentase penyewa yang terpengaruh, serta catat waktu pemulihan. Pemulihan sel yang gagal saja tidak membuktikan adanya isolasi.
Apakah sel yang lebih banyak selalu berarti isolasi yang lebih baik?
Tidak. Sel yang lebih kecil mengurangi radius dampak teoretis tetapi meningkatkan fragmentasi kapasitas, batch peluncuran, dan biaya operasional lintas-sel. Tentukan jumlahnya dari target persentase penyewa yang terpengaruh, kapasitas sel, dan biaya operasional yang berkelanjutan.
Bisakah pelaporan lintas-sel menciptakan kembali kegagalan bersama?
Ya. Pelaporan harus membaca proyeksi asinkron dengan kuota dan penurunan fungsi yang terpisah. Permintaan online tidak boleh disebarkan secara sinkron ke setiap sel.