Mengungkap Misteri Outage AWS us-east-1: Pelajaran Penting untuk Indonesia

Pada suatu hari, dunia digital dikejutkan dengan insiden masif yang melumpuhkan berbagai layanan penting. Mulai dari aplikasi komunikasi seperti Signal, Slack, dan Zoom, hingga berbagai layanan Amazon dan ribuan situs web serta aplikasi global, semuanya mengalami gangguan. Penyebab utamanya adalah gangguan layanan AWS (Amazon Web Services) yang berlangsung selama 14 jam di region us-east-1.

Insiden ini bukan sekadar gangguan teknis biasa; ini adalah pengingat keras akan betapa fundamentalnya infrastruktur komputasi awan dalam menopang kehidupan digital kita. Khususnya di Indonesia, di mana laju transformasi digital semakin pesat dan banyak perusahaan, mulai dari startup hingga korporasi besar, sangat bergantung pada penyedia layanan cloud global seperti AWS. Oleh karena itu, memahami apa yang terjadi, bagaimana hal itu terjadi, dan apa pelajarannya, menjadi sangat krusial.

Menganalisis Akar Masalah: Kegagalan DNS DynamoDB

AWS, sebagai salah satu penyedia layanan cloud terbesar di dunia, dengan cepat merilis laporan pasca-mortem (postmortem) yang detail tiga hari setelah insiden. Laporan tersebut mengungkapkan bahwa gangguan terbaru ini disebabkan oleh kegagalan DNS (Domain Name System) pada DynamoDB.

Mengenal DynamoDB dan Perannya

DynamoDB adalah basis data NoSQL nirserver (serverless) yang dirancang untuk durabilitas tinggi dan ketersediaan tinggi. Layanan ini menjanjikan waktu beroperasi (uptime) 99,99% dalam Perjanjian Tingkat Layanan (SLA) jika dikonfigurasi dengan replikasi multi-availability zone (AZ). Artinya, dalam satu region, DynamoDB menawarkan keandalan yang sangat tinggi dengan latensi rendah. Dengan model konsistensi data yang fleksibel (eventual consistency atau strong consistency), DynamoDB menjadi pilihan menarik untuk penyimpanan data bagi banyak aplikasi, termasuk berbagai layanan internal AWS sendiri. Mengingat rekam jejaknya, pertanyaan yang muncul bukan "mengapa harus menggunakan DynamoDB?", melainkan "mengapa tidak?".

Ketika Catatan DNS Menghilang

Dalam insiden ini, alamat dynamodb.us-east-1.amazonaws.com mengembalikan catatan DNS yang kosong. Ini berarti bagi setiap layanan—baik eksternal maupun internal AWS—DynamoDB di region us-east-1 seolah-olah lenyap dari muka bumi. Untuk memahami hal ini, kita perlu melihat bagaimana manajemen DNS DynamoDB bekerja.

Bagaimana Manajemen DNS DynamoDB Bekerja

Sistem manajemen DNS DynamoDB melibatkan beberapa komponen kunci:

• DNS Planner: Layanan ini bertugas memantau kesehatan load balancer (LB). Mengingat skala operasi DynamoDB yang masif, LB dapat dengan mudah kelebihan beban atau kurang dimanfaatkan. DNS Planner membuat rencana DNS, yaitu sekumpulan LB dengan bobot lalu lintas yang harus diberikan ke masing-masing LB.
• DNS Enactor: Ini adalah layanan yang bertanggung jawab untuk memperbarui rute di layanan DNS Amazon, Route 53. Untuk alasan resiliensi, ada satu DNS Enactor yang berjalan di setiap AZ. Di us-east-1, terdapat tiga AZ, sehingga ada tiga instans DNS Enactor.
• Kondisi Balapan (Race Conditions) yang Diantisipasi: Dengan tiga DNS Enactor yang bekerja secara paralel, kondisi balapan dapat terjadi. Sistem dirancang untuk mengatasi ini dengan asumsi konsistensi akhir (eventual consistency); bahkan jika sebuah DNS Enactor memperbarui Route 53 dengan rencana "lama", rencana DNS akan konsisten satu sama lain. Pembaruan terjadi dengan cepat, dan DNS Enactor hanya menggunakan rencana terbaru dari DNS Planner.

Rangkaian Kejadian yang Melumpuhkan DynamoDB

Beberapa kejadian independen secara bersamaan menyebabkan DNS DynamoDB offline:

1. Keterlambatan Tinggi pada DNS Enactor #1: Pembaruan DNS memakan waktu yang sangat lama bagi salah satu DNS Enactor, yang tidak biasa.
2. DNS Planner Meningkatkan Laju Pembuatan Rencana: Bersamaan dengan lambatnya pembaruan DNS, DNS Planner mulai memproduksi rencana baru dengan kecepatan yang jauh lebih tinggi.
3. DNS Enactor #2 Memproses Rencana dengan Cepat: Sementara Enactor #1 lambat, Enactor #2 memproses rencana dengan sangat cepat. Setelah selesai menulis rencana ke Route 53, ia kembali ke DNS Planner dan menghapus rencana-rencana lama.

Kombinasi ketiga hal ini mendorong sistem ke dalam keadaan inkonsisten dan mengosongkan DNS DynamoDB:

1. DNS Enactor #1 Menggunakan Rencana DNS Lama tanpa Sadar: Ketika Enactor #2 selesai menerapkan rencana DNS terbaru, ia menghapus semua rencana lama dari DNS Planner. Seharusnya ini berarti Enactor lain tidak akan menggunakan rencana lama; namun, Enactor #1 yang lambat masih memproses rencana lama. Akibatnya, pemeriksaan oleh Enactor #1 menjadi usang.
2. DNS Enactor #2 Mendeteksi Penggunaan Rencana Lama dan Menghapus Catatan DNS: DNS Enactor memiliki pemeriksaan pembersihan lain: jika mendeteksi penggunaan rencana lama, ia menghapus rencana itu sendiri. Menghapus sebuah rencana berarti menghapus semua alamat IP untuk endpoint regional di Route 53. Maka, DNS Enactor #2 mengosongkan DNS dynamodb.us-east-1.amazonaws.com!

Gangguan DynamoDB juga melumpuhkan semua layanan AWS yang bergantung pada layanan DynamoDB us-east-1. Dampaknya, pelanggan dengan global tables DynamoDB dapat terhubung ke replika di region lain, namun mengalami keterlambatan replikasi yang parah.

Dampak Berantai pada Amazon EC2

Meskipun DynamoDB akhirnya pulih setelah sekitar tiga jam, masalah bagi AWS belum berakhir. Gangguan berlanjut pada Amazon EC2.

Bagaimana EC2 Terpengaruh

• DropletWorkflow Manager (DWFM): Subsistem ini mengelola server fisik untuk EC2, dapat diibaratkan sebagai "Kubernetes untuk EC2". Instans EC2 disebut "droplet".
• Lease: DWFM melacak lease (sewa) untuk setiap droplet untuk mengetahui apakah server sedang ditempati atau dapat dialokasikan kepada pelanggan EC2. DWFM melakukan pemeriksaan status server setiap beberapa menit.

Hasil pemeriksaan status disimpan di DynamoDB, sehingga gangguan DynamoDB menciptakan masalah:

1. Lease Mulai Kedaluwarsa: Karena hasil pemeriksaan status tidak kembali akibat gangguan DynamoDB, DWFM mulai menandai droplet sebagai tidak tersedia.
2. Kesalahan "Insufficient Capacity" pada EC2: Dengan sebagian besar lease yang kedaluwarsa, DWFM mulai mengembalikan pesan "insufficient capacity error" kepada pelanggan EC2 karena sistem mengira server tidak tersedia.
3. Pemulihan DynamoDB Tidak Segera Membantu: Ketika DynamoDB kembali online, seharusnya pembaruan status droplet dapat dilakukan. Namun, hal itu tidak terjadi. Karena banyaknya jumlah droplet, upaya untuk menetapkan lease droplet baru memakan waktu sangat lama sehingga tidak dapat diselesaikan sebelum kedaluwarsa. DWFM pun memasuki kondisi "congestive collapse", tidak dapat memulihkan lease droplet.

Dibutuhkan waktu tiga jam lagi bagi para insinyur untuk menemukan mitigasi agar alokasi instans EC2 dapat berfungsi kembali.

Masalah Propagasi Jaringan

Bahkan ketika EC2 terlihat sehat secara internal, instans masih belum dapat berkomunikasi dengan dunia luar. Terjadi kemacetan dalam sistem yang disebut Network Manager. Network Manager mulai mengalami peningkatan latensi dalam waktu propagasi jaringan saat memproses tumpukan perubahan status jaringan. Akibatnya, instans EC2 baru yang diluncurkan tidak memiliki konektivitas jaringan yang diperlukan.

Insinyur bekerja keras untuk mengurangi beban pada Network Manager dan mempercepat pemulihan. Setelah sekitar lima jam, waktu propagasi konfigurasi jaringan kembali normal, dan peluncuran instans EC2 beroperasi kembali.

Pembersihan Akhir

Setelah ketiga sistem utama – DynamoDB, DropletWorkflow Manager EC2, dan Network Manager – diperbaiki, masih ada sedikit pekerjaan pembersihan yang tersisa. Ini melibatkan penghapusan penuh pembatasan permintaan (request throttles) yang telah diterapkan untuk mengurangi beban pada berbagai subsistem EC2. Secara total, butuh waktu 14 jam hingga semua API EC2 dan peluncuran instans EC2 baru beroperasi normal kembali. Sebuah upaya luar biasa dari tim AWS.

Pelajaran Penting untuk Keandalan Sistem di Era Digital Indonesia

Insiden AWS us-east-1 ini memberikan banyak pelajaran berharga bagi kita, terutama di Indonesia yang sedang gencar mengadopsi teknologi cloud dan bertransformasi digital. Beberapa poin kunci yang bisa kita renungkan:

• Pentingnya Arsitektur Multi-Regional: Meskipun AWS menyediakan replikasi multi-AZ dalam satu region, insiden ini menunjukkan bahwa kegagalan regional pun bisa terjadi dan melumpuhkan layanan. Bagi bisnis yang sangat bergantung pada layanan cloud, merancang arsitektur multi-regional atau multi-cloud menjadi sebuah keharusan untuk memastikan keberlanjutan bisnis.
• Ketergantungan Layanan Internal: Insiden ini memperlihatkan bagaimana layanan inti AWS seperti EC2 sangat bergantung pada layanan lain, dalam hal ini DynamoDB. Hal ini menyoroti kompleksitas sistem terdistribusi skala besar dan potensi kegagalan berantai yang sulit diprediksi.
• Transparansi dan Pembelajaran: AWS patut diacungi jempol atas transparansi dan kecepatan dalam merilis postmortem. Hal ini memungkinkan komunitas teknis untuk belajar dari insiden dan mengembangkan praktik terbaik untuk resiliensi sistem. Bagi perusahaan di Indonesia, budaya transparansi dan pembelajaran dari insiden (termasuk yang berskala kecil) sangat penting untuk terus meningkatkan keandalan sistem informasi.
• Pertanyaan yang Belum Terjawab: Laporan postmortem, meskipun detail, masih menyisakan beberapa pertanyaan krusial. Misalnya, mengapa DNS Enactor #1 melambat secara drastis? Mengapa DNS Enactor #2 menghapus semua catatan DNS sebagai bagian dari pembersihan? Apakah kondisi balapan seperti ini baru pertama kali terjadi, dan bagaimana solusinya agar tidak terulang? Pertanyaan-pertanyaan ini adalah pengingat bahwa bahkan sistem yang paling canggih pun memiliki kompleksitas dan titik-titik rentan yang perlu terus dianalisis dan diperbaiki.

Bagi Indonesia, yang sedang menggenjot pertumbuhan ekonomi digital dan mendukung UMKM untuk naik kelas melalui platform digital, keandalan infrastruktur teknologi adalah tulang punggung yang tak tergantikan. Memahami seluk-beluk insiden seperti ini membantu kita semua untuk lebih siap, merancang sistem yang lebih kuat, dan membangun ekosistem digital yang lebih tangguh di masa depan.