Wawancara system design: Membangun model registry yang dapat diaudit dan aman untuk rollback

Petunjuk dan konteks

Platform Anda melayani ratusan model yang artefak pelatihannya berasal dari berbagai pipeline yang berbeda. Layanan online memerlukan referensi stabil ke versi yang telah disetujui, sementara tim riset menginginkan eksperimen cepat dan kepatuhan (compliance) memerlukan snapshot data pelatihan, metrik evaluasi, pemberi persetujuan, serta riwayat deployment. Asumsikan file model berada di object storage dan layanan inferensi me-resolve versi serta alias melalui registry.

Apa yang dievaluasi oleh pewawancara

Pewawancara ingin Anda memisahkan versi model yang immutable dari penunjuk rilis (release pointer) yang mutable. Jawaban yang kuat mencakup konsistensi metadata, integritas artefak, perubahan alias secara atomik, isolasi lingkungan, persetujuan, dan rollback. Jawaban yang lemah hanya membangun layanan CRUD yang menyimpan nama file.

Klarifikasi yang perlu ditanyakan terlebih dahulu

• Apakah model dapat digunakan kembali di lintas lingkungan? Jika development, staging, dan production diisolasi, alias dan izin memerlukan batasan terpisah.
• Apakah rollback dilakukan ke versi sebelumnya, versi yang ditentukan, atau versi sehat (healthy) terakhir? Setiap target mengubah model kesehatan dan audit.
• Bukti evaluasi apa saja yang wajib disertakan? Versi yang kehilangan snapshot dataset atau metrik tidak dapat disetujui.
• Bisakah layanan inferensi melakukan caching model? TTL cache dan propagasi alias menentukan waktu rollback.
• Apakah diperlukan canary atau beberapa versi aktif sekaligus? Jika ya, perutean traffic harus diikat ke metrik versi model.

Kerangka jawaban 30 detik

“Saya akan membuat file model dan metadata versi bersifat immutable, mengidentifikasi artefak berdasarkan digest konten dan versi, serta menggunakan satu alias dengan cakupan lingkungan (environment-scoped) untuk versi yang disetujui. Pendaftaran, evaluasi, persetujuan, deployment, dan rollback adalah transisi status yang diaudit. Inferensi me-resolve alias ke snapshot versi, lalu memverifikasi digest dan otorisasi. Rilis menggunakan conditional update, dan pelanggaran guardrail akan memindahkan alias secara atomik kembali ke versi sehat terakhir.”

Jawaban mendalam langkah demi langkah

1. Definisikan objek. RegisteredModel menyimpan pemilik dan kebijakan. ModelVersion menyimpan URI artefak, digest, framework, signature input/output, snapshot data pelatihan, dan metrik evaluasi. Alias adalah penunjuk mutable dengan cakupan lingkungan.
2. Jadikan artefak immutable. Hitung digest saat pengunggahan dan tulis artefak ke object storage. Sebuah versi hanya menerima penambahan metadata; filenya tidak dapat ditimpa. Verifikasi digest saat mengunduh.
3. Gunakan state machine. Versi bergerak melalui tahapan registered, validated, approved, deployed, dan retired. Setiap transisi mencatat pelaku, alasan, waktu, dan tautan bukti; transisi yang tidak valid akan ditolak.
4. Beralih alias secara aman. Alias seperti candidate, staging, dan champion menunjuk ke satu versi pada satu waktu. Gunakan conditional write atau transaksi agar pembaca tidak pernah melihat peralihan parsial.
5. Resolve selama deployment. Layanan me-resolve alias ke snapshot versi, memeriksa tenant, lingkungan, dan digest, lalu mengunduh dan menyimpan model di cache. Cache menyimpan versi tersebut, bukan hanya aliasnya.
6. Canary dan rollback. Sebuah controller mengikat grup traffic ke alias atau aturan perutean serta mengumpulkan metrik kesalahan, latensi, dan bisnis. Pelanggaran memindahkan alias ke versi yang sehat dan mencatat peristiwa rollback otomatis.

Simpan metadata dalam database relasional dan file besar di object storage. Event stream dapat membatalkan cache dan mengindeks peristiwa audit secara asinkron. Replikasi lintas wilayah hanya boleh menyalin versi yang telah disetujui, sehingga artefak yang belum selesai tidak dapat masuk ke production.

Jawaban model

“Saya akan menerapkan tiga batasan: versi immutable, alias mutable, dan transisi status yang diaudit. Setiap versi berisi digest artefak, signature, snapshot data pelatihan, metrik evaluasi, dan run sumbernya. Persetujuan ditolak jika bukti yang diperlukan tidak lengkap. Alias champion production diubah melalui conditional update ke tepat satu versi; inferensi me-resolve dan menyimpan nomor versi di cache, lalu memverifikasi digest-nya. Canary controller mengaitkan versi model dengan metrik kesalahan, latensi, dan bisnis serta secara atomik mengembalikan alias ke versi sehat terakhir saat guardrail gagal. Izin dipisahkan berdasarkan model, lingkungan, dan tindakan, serta perpindahan alias, persetujuan, pengunduhan, dan rollback dicatat ke dalam log audit yang tahan manipulasi (tamper-evident).”

Kesalahan umum

• Kesalahan: Menimpa file untuk versi yang sudah ada → Mengapa gagal: Deployment tidak dapat direproduksi dan audit merujuk pada konten yang berubah-ubah → Perbaikan: Jadikan versi dan artefak immutable.
• Kesalahan: Men-deploy string literal latest → Mengapa gagal: Pergeseran alias membuat cache dan audit menjadi tidak konsisten → Perbaikan: Resolve ke snapshot versi dan catat digest-nya.
• Kesalahan: Menyimpan status persetujuan sebagai Boolean → Mengapa gagal: Tidak ada yang bisa menjelaskan siapa yang menyetujui apa dan mengapa → Perbaikan: Gunakan transisi status yang didukung bukti dan peristiwa audit.
• Kesalahan: Hanya me-rollback traffic → Mengapa gagal: Cache atau dependensi mungkin masih memuat versi baru → Perbaikan: Berikan versi pada cache, periksa dependensi, dan pindahkan alias kembali secara atomik.

Pertanyaan lanjutan dan tanggapan

Mengapa menggunakan alias alih-alih men-deploy nomor versi secara langsung?

Nomor versi memberikan reproduktibilitas; alias memberikan kontrol rilis. Memisahkan keduanya memungkinkan peralihan tanpa mengubah konfigurasi klien sembari mempertahankan jejak audit versi yang eksplisit.

Bagaimana Anda mencegah pembaruan alias yang konkuren agar tidak saling menimpa?

Simpan nomor versi atau revisi bersama dengan alias dan gunakan conditional update. Saat terjadi konflik, baca ulang kebijakan dan coba lagi; jangan pernah menimpa rilis lain secara diam-diam.

Apa yang disimpan registry ketika data pelatihan bersifat sensitif?

Simpan versi dataset, kebijakan akses, dan digest, bukan sampel mentahnya. Gunakan kembali izin data saat mengambil bukti evaluasi dan catat audit aksesnya.

Kapan versi model lama dapat dihapus?

Hapus artefak hanya setelah masa retensi, deployment aktif, dan hold audit telah selesai. Pertahankan metadata dan digest rollback selama masa retensi kepatuhan.