Pola Multi-AZ untuk Layanan Stateful

Layanan stateful — basis data, cache, dan sistem berkas — adalah komponen yang paling sulit dibuat sangat tersedia karena menyimpan data yang harus tetap ada saat terjadi kegagalan. Jika basis data pada satu AZ gagal, seluruh aplikasi Anda kehilangan penyimpanan datanya. Jawaban AWS adalah deployment Multi-AZ, yaitu ketika layanan mempertahankan replika sinkron atau hampir sinkron di Availability Zone kedua yang dapat mengambil alih dengan cepat saat primer gagal.

RDS Multi-AZ mempertahankan replika siaga sinkron di AZ yang berbeda. Setiap penulisan ke primer direplikasi secara sinkron sebelum keberhasilan dikonfirmasi — ini berarti tidak ada kehilangan data (RPO=0), tetapi latensi penulisan sedikit meningkat. Saat primer gagal, RDS secara otomatis memperbarui titik akhir DNS agar menunjuk ke siaga dalam 60–120 detik. Aplikasi Anda hanya perlu terhubung kembali ke titik akhir yang sama — tidak diperlukan perubahan kode.

Amazon Aurora mengembangkan Multi-AZ lebih jauh dengan lapisan penyimpanan terdistribusi bersama yang secara otomatis mereplikasi data ke tiga AZ dalam enam salinan. Instans Aurora tidak menyimpan status — instans tersebut membaca dan menulis ke penyimpanan bersama ini. Ketika Aurora writer PRIMARY gagal, read replica di AZ lain dipromosikan menjadi writer dalam waktu kurang dari 30 detik. Proses ini lebih cepat daripada Failover RDS Multi-AZ, dan data selalu konsisten di seluruh AZ tanpa Replication standby eksplisit.

ElastiCache for Redis mendukung Multi-AZ melalui kelompok Replication. Node PRIMARY menerima penulisan dan mereplikasi secara Asynchronous ke read replica di AZ lain. Ketika PRIMARY gagal, ElastiCache secara otomatis mempromosikan Replica menjadi PRIMARY. Untuk Redis dengan mode cluster yang diaktifkan, data dipecah ke beberapa kelompok node, yang masing-masing memiliki PRIMARY dan Replica sendiri di berbagai AZ — hal ini menyediakan HA sekaligus penskalaan horizontal.

Amazon Elastic File System (EFS) secara bawaan merupakan Multi-AZ — layanan regional yang menyimpan data secara redundan di beberapa AZ dalam satu Region. Anda membuat target Mount di subnet setiap AZ, dan instans EC2 di AZ mana pun dapat memasang sistem file melalui target Mount lokalnya. Tidak diperlukan konfigurasi Multi-AZ manual. EFS menyediakan penyimpanan file POSIX bersama yang dapat diakses secara bersamaan oleh beberapa instans di berbagai AZ.

Elastic Load Balancer itu sendiri bersifat Multi-AZ — ALB dan NLB menerapkan node penyeimbang beban di setiap AZ yang Anda tentukan. Dengan penyeimbangan beban lintas zona yang diaktifkan (default untuk ALB), setiap node penyeimbang beban mendistribusikan lalu lintas secara merata ke semua target yang terdaftar di semua AZ, bukan hanya AZ-nya sendiri. Dengan demikian, meskipun semua instans di satu AZ gagal, penyeimbang beban tetap melayani lalu lintas melalui instans di AZ yang tersisa.

Kesalahan umum adalah menerapkan satu NAT Gateway di satu AZ, sementara subnet privat di AZ lain merutekan lalu lintas melaluinya. Jika AZ tersebut gagal, semua instans privat kehilangan akses internet. Pola Multi-AZ yang benar adalah menerapkan satu NAT Gateway per AZ dan mengonfigurasi tabel rute privat setiap AZ agar merutekan 0.0.0.0/0 melalui NAT Gateway miliknya sendiri. Hal ini menghilangkan NAT Gateway sebagai SPOF lintas AZ dan mengurangi biaya transfer data lintas AZ.

DynamoDB adalah layanan yang dikelola sepenuhnya dan secara otomatis mereplikasi data ke tiga AZ dalam satu Region — Anda tidak perlu mengonfigurasi Multi-AZ secara manual. Setiap penulisan disimpan secara tahan lama di ketiga AZ sebelum keberhasilan dikembalikan. DynamoDB secara efektif toleran terhadap kegagalan pada tingkat AZ sejak awal. Karena itu, DynamoDB sering menjadi pilihan Database yang direkomendasikan ketika soal ujian menekankan ketersediaan tinggi dengan beban operasional minimal.

Selama Failover RDS Multi-AZ, aplikasi yang mempertahankan Connection Database persisten mungkin mengalami kegagalan saat Endpoint berubah. RDS Proxy berada di antara aplikasi dan RDS, serta mempertahankan kumpulan Connection ke Database. Selama Failover, RDS Proxy secara otomatis merutekan ulang ke PRIMARY yang baru — sehingga dampak Failover berkurang dari 60–120 detik menjadi kurang dari 30 detik bagi aplikasi yang menggunakan Endpoint Proxy. RDS Proxy juga membantu fungsi Lambda yang membuat banyak Connection berumur singkat.

Memahami mode Replication sangat penting untuk memilih pola Multi-AZ. Replication Synchronous (RDS Multi-AZ, EFS) memastikan RPO=0 karena setiap penulisan dikonfirmasi di kedua AZ sebelum keberhasilan. Konsekuensinya adalah latensi penulisan yang sedikit lebih tinggi. Replication Asynchronous (Replica Redis ElastiCache, Read Replica RDS) menawarkan latensi penulisan yang lebih rendah, tetapi menerima sedikit jeda Replication — artinya sebagian data dapat hilang jika PRIMARY gagal sebelum Replication selesai.

Anda sebaiknya menguji Failover Multi-AZ secara berkala untuk memvalidasi asumsi RTO Anda. Untuk RDS, Anda dapat memicu Failover menggunakan opsi Reboot with failover di konsol atau melalui CLI. Pantau CloudWatch untuk metrik FailedSQLServerAgentJobsCount dan periksa log aplikasi Anda untuk memastikan aplikasi berhasil terhubung kembali. Dokumentasikan durasi Failover yang sebenarnya — durasi tersebut dapat berbeda dari dokumentasi AWS, bergantung pada kelas instans dan beban kerja Anda.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini, Anda telah mempelajari bahwa: RDS Multi-AZ menggunakan Replication Synchronous dengan Failover DNS otomatis, Aurora menggunakan lapisan penyimpanan bersama di tiga AZ untuk Failover yang lebih cepat, dan EFS serta DynamoDB secara bawaan merupakan Multi-AZ tanpa konfigurasi manual. Terapkan satu NAT Gateway per AZ untuk menghindari SPOF lintas AZ. Selanjutnya, kita akan membahas pola active-active dan active-passive lintas Region.