1. Empat Pilar Aplikasi Pendukung Ujian Online
Sistem ujian online yang ideal bukan cuma satu aplikasi monolith raksasa, melainkan gabungan dari modul-modul yang saling berbicara lewat API atau service terintegrasi.
+-------------------------------------------------------------------------+
| LMS ENGINE |
| (Portal Siswa, Manajemen Sesi, Timer Synchronizer, UI) |
+--------------------+------------------------------------+---------------+
| |
▼ ▼
+--------------------+------------+ +----------------+---------------+
| ITEM BANK | | AUTO-GRADER |
| (QTI/JSON Format, Tagging Topic,| | (Rule Engine, Regex Pattern, |
| Randomizer & Difficulty) | | Sub-string Similarity) |
+---------------------------------+ +--------------------------------+
│ │
└--------------------+---------------┘
│
▼
+-------------------------------------------------------------------------+
| PROCTORING & AUDIT LOG |
| (Kiosk Lockdown, Heartbeat Ping, Anti-Focus Loss, Audio-Video) |
+-------------------------------------------------------------------------+
A. Learning Management System (LMS)
LMS adalah hub utama. Untuk skenario ujian, pastikan LMS kalian hemat overhead:
PHP-FPM / Node.js Worker Optimization: Jika pakai Moodle/Canvas, optimalkan process manager. Matikan plugin yang tidak relevan (seperti forum notification atau badges) selama pekan ujian untuk menghemat RAM server.
Stateless Session: Usahakan session storage disimpan di Redis atau Memcached, bukan di sistem berkas (file system), supaya session tidak hilang kalau kita menambah nodus server (scaling).
B. Bank Soal (Item Bank)
Jangan simpan soal sebagai tabel plain text biasa. Gunakan struktur standar seperti QTI (Question and Test Interoperability) atau format JSON yang terstruktur.
Decoupled Media: Seluruh file gambar/audio dalam soal harus disimpan terpisah di Object Storage (S3 atau CDN lokal). Jangan simpan gambar dalam bentuk Base64 di database!
Randomization Hash: Pengacakan soal dilakukan di level server saat paket ujian di-generate, lalu di-cache per ID siswa, bukan diproses acak ulang setiap kali siswa me-refresh halaman.
C. Penilai Otomatis (Auto-Grader)
Soal Pilihan Ganda/Isian Singkat: Gunakan pattern matching berbasis Regex yang mentoleransi perbedaan huruf kapital (case-insensitive) dan spasi ganda.
Soal Esai Kompleks: Manfaatkan modul penilaian substring atau integrasikan natural language API jika sekolah menggunakan penilaian esai berbasis bobot kata kunci (keyword matching).
D. Pengawasan Digital (Proctoring)
Gunakan pendekatan berlapis (layered defense):
Client-Side (Lockdown App/Browser): Memanfaatkan fitur fullscreen mode, memblokir keyboard shortcut (
Alt+Tab,PrintScreen), serta mendeteksi pemutusan external monitor.Server-Side (Heartbeat Monitoring): Klien mengirimkan ping/heartbeat setiap 5–10 detik. Jika heartbeat terputus namun IP tetap aktif, ada potensi siswa mematikan skrip pengawasan secara paksa.
2. Bedah Level Teknis: Server & Infrastruktur
A. Estimasi Kebutuhan Hardware & Traffic
Skenario: 1.000 Siswa Ujian Serentak
Masalah Utama: Thundering Herd Problem (1.000 siswa menekan tombol “Submit” atau “Next Page” di detik yang sama).
Solusi Sizing Server:
Web/App Server: 8 vCPU, 16 GB RAM (bisa menggunakan load balancer membagi ke 2 unit server 4 vCPU).
Database Server: 8 vCPU, 32 GB RAM + NVMe Storage (karena I/O tinggi untuk tulisan jawaban).
In-Memory Cache (Redis): 2 vCPU, 4 GB RAM.
B. Taktik Menghemat Bandwidth Sekolah
Jika ujian dilakukan di jaringan lokal sekolah (on-premise atau semi-online):
Lokal CDN Caching: Tempatkan server Nginx/Varnish sebagai reverse proxy di LAN sekolah untuk men-cache seluruh file statis (CSS, JS, gambar soal).
Compression: Aktifkan Gzip/Brotli compression di server. Ini bisa memotong ukuran transfer payload hingga 70%.
3. Strategi Backup & Disaster Recovery (Anti-Panik)
Saat ujian berlangsung, musuh terbesar IT adalah listrik padam, jaringan drop, atau database deadlock.
LIVE EXAM SESSION
│
├─── Setiap 15-30 Detik ───► Local Storage Browser (Siswa)
│ (Backup Offline Sementara)
│
├─── Setiap 1 Menit ──────► Redis In-Memory Sync
│ (Fast Write)
│
└─── Setiap 5 Menit ──────► Disk Master Database + Offsite Backup
(Write-Ahead Logging / S3)
A. Triple-Layer Auto-Save
Layer 1 (Browser/Client): Simpan setiap klik jawaban ke
LocalStoragebrowser siswa. Jika Wi-Fi terputus, jawaban tidak hilang.Layer 2 (Redis Cache): Kirim payload jawaban via AJAX Background Worker secara asinkron (non-blocking) ke Redis.
Layer 3 (Database Relasional): Redis melakukan sinkronisasi berjadwal (batch write) ke PostgreSQL/MySQL untuk mengurangi beban I/O database utama.
B. Skema Database Backup
WAL (Write-Ahead Logging) / Binlog: Aktifkan fitur binary logging pada database. Jika database crash jam 09.15, kalian bisa melakukan Point-In-Time Recovery (PITR) tepat ke detik 09.14:59 tanpa kehilangan data jawaban.
Offsite Snapshot: Setiap 30 menit, kirim snapshot terenkripsi ke penyimpanan cloud terpisah atau server cadangan di ruangan lain.
Checklist Ringkas Tim IT Sebelum Hari-H Ujian
[ ] Stress Test / Load Test: Jalankan
JMeteratauk6dengan simulasi 1.5x jumlah siswa aktual untuk melihat di mana letak bottleneck-nya (CPU, RAM, atau Database Connection Pool).[ ] Isolasi Network: Pisahkan VLAN jaringan ujian dengan VLAN Wi-Fi guru/staf sekolah.
[ ] Disable Auto-Update: Matikan fitur auto-update pada sistem operasi server maupun aplikasi klien 3 hari sebelum ujian.
[ ] Persiapan Spare Unit: Sediakan minimal 5–10% laptop cadangan yang sudah diinstal lockdown browser untuk pertukaran cepat jika ada unit siswa yang rusak.
Dengan arsitektur yang terpisah (decoupled), penanganan cache yang pas, serta strategi backup yang matang, tim IT tidak perlu cemas lagi saat pekan ujian tiba!
