Ketika Amazon Web Services mengalami pemadaman besar di wilayah Northern Virginia pada 19-20 Oktober 2025, penyebab langsungnya tampak sederhana: kondisi race dalam sistem manajemen DNS DynamoDB. Namun saat komunitas teknis menyelami postmortem mendetail dari Amazon, muncul cerita yang lebih kompleks tentang tantangan inherent dalam mengelola sistem terdistribusi yang sangat rumit dan apakah pendekatan tradisional terhadap keandalan sudah cukup dalam skala cloud.
Kondisi Race DNS yang Memulai Semuanya
Pemadaman ini dimulai dengan apa yang tampak seperti masalah sistem terdistribusi klasik - beberapa DNS Enactor yang bekerja secara independen di berbagai Availability Zones menjadi tidak tersinkronisasi. Satu enactor mengalami penundaan tidak biasa saat memproses pembaruan, sementara yang lain melaju lebih cepat dengan rencana yang lebih baru. Waktu yang terjadi menciptakan badai sempurna di mana rencana DNS yang sudah kedaluwarsa menimpa rencana yang sedang berlaku, kemudian proses pembersihan menghapus rencana aktif sepenuhnya. Ini meninggalkan endpoint regional DynamoDB tanpa alamat IP, yang secara efektif membuat layanan tidak dapat diakses.
Apa yang membuat ini sangat mengkhawatirkan bagi para insinyur adalah kurangnya pengaman sistem terdistribusi dasar yang tampak. Seperti yang dicatat seorang komentator, Kedengarannya seperti kasus 'membuat algoritma sistem terdistribusi sendiri' tanpa investasi di depan dalam mengimplementasikan sistem terdistribusi yang benar-benar kuat. Sistem tersebut tidak memiliki operasi compare-and-swap yang tepat atau pengecekan versi yang dapat mencegah rencana yang basi menimpa data yang lebih baru.
Sistem Internal AWS Utama yang Disebutkan
- DNS Planner: Memantau kesehatan load balancer dan membuat rencana DNS
- DNS Enactor: Menerapkan perubahan DNS ke Route53 (berjalan di 3 AZ)
- DWFM (Droplet Workflow Manager): Mengelola server fisik untuk EC2
- Network Manager: Menangani propagasi konfigurasi jaringan
- NLB Health Check Subsystem: Memantau kesehatan node load balancer
Kegagalan Berantai Mengungkap Masalah Arsitektur yang Lebih Dalam
Sementara masalah DNS diselesaikan dalam beberapa jam, kerusakan nyata datang dari kegagalan berantai di seluruh infrastruktur AWS. Droplet Workflow Manager (DWFM), yang mengelola server fisik untuk instance EC2, memasuki apa yang disebut para insinyur sebagai congestive collapse. Saat DWFM mencoba membangun kembali lease dengan droplet di seluruh fleet EC2, volume pekerjaan yang sangat besar menciptakan loop umpan balik di mana upaya mengalami timeout dan mengantri lebih banyak pekerjaan percobaan ulang, mencegah kemajuan apa pun.
Karena situasi ini tidak memiliki prosedur pemulihan operasional yang mapan, para insinyur berhati-hati dalam upaya menyelesaikan masalah dengan DWFM tanpa menyebabkan masalah lebih lanjut.
Pengakuan dalam laporan Amazon ini khususnya membuat komunitas teknis waspada. Bahwa komponen inti dari infrastruktur EC2 seperti itu tidak memiliki prosedur pemulihan yang mapan untuk mode kegagalan ini menunjukkan masalah yang lebih dalam dalam kesiapan operasional. Solusi akhirnya - membatasi pekerjaan masuk dan me-restart host DWFM secara selektif - pada dasarnya adalah operasi darurat pada sistem yang masih hidup.
Debat Sistem Kompleks
Pemadaman ini memicu debat hangat tentang bagaimana kita memikirkan kegagalan dalam sistem kompleks. Banyak insinyur menunjuk pada esai Richard Cook How Complex Systems Fail sebagai penyedia konteks penting. Cook berargumen bahwa dalam sistem yang benar-benar kompleks, konsep akar penyebab tunggal menyesatkan - kegagalan muncul dari kombinasi kondisi laten yang secara individual mungkin tidak berbahaya.
Perspektif ini menantang pendekatan respons insiden tradisional. Seperti yang dijelaskan seorang komentator, Mengingat sumber daya yang terbatas, haruskah Anda menanggapi insiden ini dengan mengaudit sistem manajemen DNS Anda untuk kondisi race? Atau haruskah Anda mencari cara membuat Droplet Manager bertahan dari partisi dari DynamoDB tanpa masuk ke congestive collapse? Jawabannya kemungkinan melibatkan keduanya, tetapi memprioritaskan peningkatan mana yang memberikan keandalan paling besar menjadi semakin sulit seiring sistem tumbuh lebih kompleks.
Realitas Operasional vs Kesempurnaan Teoretis
Diskusi ini mengungkap ketegangan antara praktik terbaik sistem terdistribusi teoretis dan realitas operasional menjalankan layanan dalam skala AWS. Beberapa komentator dengan pengalaman di perusahaan teknologi besar menggambarkan tantangan rotasi on-call dan akumulasi bertahap technical debt yang membuat sistem lebih rapuh seiring waktu.
Seorang kontraktor berbagi: Saya belum pernah bekerja di perusahaan yang memperlakukan on-call sebagai bisnis yang sangat serius. Di atas kertas, mereka mengatakan itu serius dan semua hal SLA disiapkan, tetapi dalam kenyataannya tidak ada dukungan yang cukup. Ini menunjukkan bahwa bahkan di penyedia cloud utama, faktor manusia dan organisasi mungkin sama pentingnya dengan faktor teknis dalam mempertahankan keandalan.
Insiden ini juga menyoroti tantangan ketergantungan lintas region. Meskipun model region AWS dipasarkan sebagai sepenuhnya independen, pemadaman ini mengungkapkan bahwa beberapa layanan global masih bergantung pada us-east-1, menciptakan single point of failure yang mempengaruhi pelanggan di seluruh dunia. Ini bukan pertama kalinya hal ini terjadi, menunjukkan bahwa menghilangkan ketergantungan ini lebih menantang daripada kelihatannya.
Layanan AWS yang Terdampak
- Inti: DynamoDB, EC2, Network Load Balancer
- Komputasi: Lambda, ECS, EKS, Fargate
- Identitas: IAM, AWS Management Console, Security Token Service
- Analitik: Redshift
- Bisnis: Amazon Connect
- Pendukung: Managed Workflows for Apache Airflow, Outposts, Support Center
Melihat ke Depan
Amazon telah mengambil tindakan segera dengan menonaktifkan otomasi DNS yang bermasalah di seluruh dunia. Perbaikan yang mereka rencanakan termasuk mengatasi kondisi race, menambahkan kontrol kecepatan ke failover pemeriksaan kesehatan NLB, dan membangun pengujian yang lebih baik untuk alur kerja pemulihan DWFM. Namun pertanyaan yang lebih luas tetap: dapatkah organisasi mana pun benar-benar mengantisipasi dan mencegah semua mode kegagalan dalam sistem dengan kompleksitas seperti ini?
Diskusi komunitas teknis menunjukkan bahwa seiring sistem tumbuh lebih kompleks, pendekatan kita terhadap keandalan harus berkembang melampaui menemukan dan memperbaiki akar penyebab menuju merancang sistem yang dapat mengalami degradasi secara elegan dan pulih dengan cepat. Pemadaman AWS ini berfungsi sebagai pengingat bahwa dalam sistem terdistribusi, kegagalan tidak dapat dihindari - tetapi kegagalan katastrofik tidak harus terjadi.
Percakapan berlanjut tentang apakah sistem AI saat ini dapat membantu dengan skenario pemecahan masalah kompleks seperti ini, dengan pendapat yang terbagi tentang apakah pengenalan pola saja dapat menyelesaikan masalah yang membutuhkan pemahaman mendalam tentang interaksi sistem. Yang jelas adalah bahwa seiring infrastruktur cloud menjadi lebih penting bagi bisnis global, taruhan untuk melakukan ini dengan benar terus meningkat.
Referensi: Ringkasan Gangguan Layanan Amazon DynamoDB di Region Northern Virginia (US-EAST-1)