Kasus penemuan race condition di Aurora RDS

• Kasus ketika bug race condition yang terjadi di AWS Aurora RDS diverifikasi secara eksperimental dan penyebabnya dikonfirmasi oleh AWS
• Saat Hightouch memperluas sistem pemrosesan event, mereka menemukan gejala kegagalan perpindahan instance penulis selama proses failover Aurora
• Hasil analisis log menunjukkan bahwa dua instance melakukan operasi tulis secara bersamaan, yang menyebabkan konflik pada lapisan penyimpanan dan penghentian proses
• AWS secara resmi mengonfirmasi bahwa penyebabnya adalah promosi writer baru sebelum penurunan peran writer lama selesai akibat masalah pemrosesan sinyal internal
• Kasus ini menekankan pentingnya kontrol konkurensi pada sistem terdistribusi berskala besar dan perlunya prosedur penghentian penulisan saat failover

---

Latar belakang

• Pada 20 Oktober 2025, terjadi gangguan di region AWS us-east-1 akibat bug race condition pada sistem manajemen DNS
• Karena hal ini, backlog pemrosesan event di Hightouch meningkat tajam hingga mencapai batas sistem
• Untuk mengamankan throughput, pada 23 Oktober dilakukan upgrade instance Aurora RDS, dan dalam proses ini ditemukan bug race condition baru

Arsitektur sistem event Hightouch

• Sistem yang bertanggung jawab untuk pengumpulan dan pengiriman event terdiri dari Kubernetes, Kafka, dan Postgres (Aurora)
• Postgres digunakan sebagai antrean metadata batch, memproses 500 ribu event per detik dalam waktu kurang dari 1 detik
• Aurora PostgreSQL terdiri dari instance khusus tulis (primary), instance khusus baca (replica), dan lapisan penyimpanan bersama

Rencana upgrade

• Menambahkan instance baca → meng-upgrade reader yang ada dan memberinya prioritas failover → menjalankan failover → meng-upgrade writer lama → menghapus reader sementara
• Prosedur ini adalah metode yang dijelaskan dalam dokumentasi AWS, dan merupakan prosedur yang telah diverifikasi melalui uji beban di lingkungan staging

Percobaan upgrade dan munculnya masalah

• Pada 23 Oktober pukul 16:39 EDT, setelah failover dijalankan, muncul gejala writer lama kembali menjadi primary
• Pada dua percobaan, hasilnya sama, dan pada sebagian layanan muncul error tidak bisa menulis (DatabaseError: cannot execute UPDATE in a read-only transaction)
• Hasil analisis log mengonfirmasi adanya log bahwa dua instance melakukan operasi tulis secara bersamaan lalu berhenti karena konflik penyimpanan

Penyebab race condition

• Selama proses failover Aurora, race condition terjadi di antara langkah 3 (penurunan peran writer lama) dan langkah 4 (promosi writer baru)
• Akibatnya, dua instance secara bersamaan memiliki hak tulis dan saling bertabrakan
• Ketika dicoba lagi dalam kondisi trafik tulis dihentikan, failover selesai dengan normal sehingga hipotesis race condition terbukti

Konfirmasi dan respons AWS

• Setelah peninjauan internal, AWS mengonfirmasi bahwa penyebabnya adalah kesalahan pemrosesan sinyal penurunan writer, dan tidak terkait dengan konfigurasi atau pola trafik Hightouch
• Perbaikan telah dimasukkan ke dalam roadmap, dan sebagai langkah sementara AWS merekomendasikan menghentikan penulisan selama failover

Tindakan akhir

• Hightouch menyelesaikan upgrade klaster, dan
  • menambahkan prosedur penghentian penulisan sebelum failover yang disengaja
  • memperkuat pemantauan perubahan peran writer
  • memperbarui manual operasional (playbook)

Pelajaran utama

1. Perlu kesiapan pemulihan untuk menghadapi transisi status tak terduga selama migrasi
2. Menjamin observability adalah kunci untuk mendeteksi masalah
3. Pentingnya desain yang meminimalkan dampak antar komponen sistem terdistribusi
4. Perlu menyadari perbedaan antara lingkungan pengujian dan lingkungan produksi nyata

Tidak ada informasi tambahan di sumber asli