Yandex Cloud Kehilangan Data Center Ketiga: Anatomi Kegagalan Multi-AZ yang Seharusnya Tidak Terjadi
TechPulse Editorial | Kategori: DevOps / Cloud Infrastructure
---
Apa yang Terjadi
Yandex Cloud mengonfirmasi bahwa data center ketiga mereka mengalami insiden signifikan, sebagaimana dilaporkan di halaman status resmi mereka. Ini bukan data center pertama atau kedua. Ini yang ketiga. Fakta ini sendiri sudah menjadi problem statement yang serius.
Dengan 513 points dan 615 thread diskusi di Hacker News, komunitas engineering global tidak sekadar penasaran. Mereka mempertanyakan fondasi arsitektur availability yang selama ini dijual sebagai standar industri cloud computing.
---
Problem Statement: Multi-AZ Bukan Jaminan
Hampir semua cloud provider besar menjual konsep Availability Zone (AZ) sebagai solusi high availability. Premisnya sederhana: distribusikan workload ke beberapa data center yang terpisah secara fisik, dan jika satu jatuh, yang lain tetap melayani traffic. Tiga AZ adalah angka minimum yang umum direkomendasikan untuk quorum-based systems.
Pertanyaan brutal yang muncul dari insiden Yandex: apa yang terjadi ketika asumsi independensi antar AZ ternyata tidak sepenuhnya benar?
Ini bukan pertanyaan hipotetis. Ini sudah terjadi berulang kali di berbagai provider:
- AWS us-east-1 pernah mengalami cascading failure yang menyeret beberapa AZ sekaligus karena shared control plane.
- Google Cloud pada 2022 mengalami outage multi-zone karena konfigurasi cooling yang saling terkait secara fisik.
- Sekarang Yandex, dengan track record tiga data center terdampak.
Pola yang konsisten: failure domain yang terlihat independen di diagram arsitektur ternyata memiliki coupling tersembunyi di layer yang tidak terlihat oleh customer.
---
Arsitektur di Balik Layar: Di Mana Coupling Tersembunyi Hidup
Untuk memahami kenapa multi-AZ bisa gagal secara bersamaan, kita perlu membedah layer-layer yang biasanya di-abstract-kan dari pengguna cloud.
1. Control Plane Terpusat
Sebagian besar cloud provider menjalankan control plane (API server, scheduler, identity management, metadata service) secara terpusat atau semi-terpusat. Ketika control plane ini mengalami masalah, semua AZ yang bergantung padanya ikut terdampak.
yaml
Contoh strategi deployment staged per AZ
stages:
- name: deploy-az-1
target: az-1 canary_percentage: 10 bake_time: 30m rollback_trigger: error_rate_increase: 5% latency_p99_increase: 20%
- name: deploy-az-2
target: az-2 depends_on: deploy-az-1 bake_time: 30m
- name: deploy-az-3
target: az-3 depends_on: deploy-az-2 bake_time: 30m
### 4. Bangun Kemampuan Operasi Degraded
Aplikasi Anda harus bisa beroperasi dalam mode degraded ketika satu AZ hilang. Ini berarti:
- Circuit breaker yang benar-benar berfungsi (bukan sekadar library yang di-import tapi tidak di-tune)
- Graceful degradation di level fitur (matikan fitur non-critical, pertahankan core functionality)
- Client-side retry dengan backoff yang tidak akan membuat masalah lebih buruk (thundering herd)
### 5. Pertimbangkan Static Stability
Konsep dari AWS Well-Architected Framework ini layak diadopsi secara universal: sistem Anda harus bisa terus beroperasi dengan state yang sudah ada, bahkan jika control plane tidak bisa dijangkau. Artinya, jangan bergantung pada dynamic configuration fetch, service discovery refresh, atau certificate renewal yang harus terjadi real-time untuk menjaga sistem tetap berjalan.
### 6. Chaos Engineering Bukan Opsional
Jika Anda menjalankan workload production di multi-AZ, Anda harus secara berkala mensimulasikan kehilangan satu AZ penuh. Bukan hanya mematikan satu instance. Matikan seluruh AZ. Blok semua traffic dari dan ke AZ tersebut. Lihat apa yang terjadi. Perbaiki apa yang rusak. Ulangi.
---
## Perspektif yang Lebih Luas
Insiden Yandex ini bukan anomali. Ini adalah pengingat bahwa **distributed systems tidak menghilangkan single points of failure, mereka memindahkannya ke tempat yang lebih sulit dilihat.**
Setiap layer abstraksi yang kita tambahkan (dari bare metal ke VM, dari VM ke container, dari container ke serverless, dari single DC ke multi-AZ) memberikan ilusi reliability yang lebih tinggi. Tapi di balik setiap abstraksi, ada infrastruktur fisik yang bisa gagal, software yang bisa memiliki bug, dan manusia yang bisa membuat kesalahan.
Tugas kita sebagai engineer bukan mempercayai abstraksi tersebut secara buta. Tugas kita adalah memahami apa yang ada di baliknya, mengidentifikasi di mana asumsi independensi bisa dilanggar, dan membangun sistem yang bisa bertahan ketika asumsi tersebut ternyata salah.
Tiga data center Yandex yang terdampak adalah bukti bahwa pekerjaan ini belum selesai. Bukan hanya untuk Yandex, tapi untuk semua orang yang menjalankan workload di cloud manapun.
---
*Referensi: [Yandex Cloud Status - Incident 2136](https://status.yandex.cloud/en/incidents/2136) | Diskusi HN: 513 points, 615 comments*
## Arsitektur & Alur Visual Sistem
