Pilar Keandalan dan Efisiensi Kinerja

Pilar Reliability dalam Kerangka Kerja yang Dirancang dengan Baik memastikan beban kerja menjalankan fungsi yang dimaksud dengan benar dan konsisten saat diperlukan. Reliability mencakup tiga area: fondasi (batas layanan, topologi jaringan), arsitektur beban kerja (sistem terdistribusi, menghindari SPOF), serta pengelolaan perubahan dan kegagalan (pemantauan, penskalaan, pemulihan dari kegagalan). Tujuannya adalah membangun sistem yang pulih secara otomatis dari gangguan infrastruktur atau layanan.

AWS menerapkan kuota layanan (sebelumnya disebut batas) pada sumber daya untuk melindungi semua pelanggan. Contohnya adalah batas default instans EC2 per wilayah, batas VPC, dan eksekusi Lambda serentak. Jika beban kerja Anda tiba-tiba mencapai kuota, permintaan akan dibatasi atau ditolak sehingga menyebabkan kegagalan Reliability. Gunakan konsol Service Quotas atau CLI untuk melihat batas saat ini dan meminta peningkatan sebelum Anda membutuhkannya. Pantau metrik penggunaan untuk mendeteksi saat Anda mendekati batas sebelum batas tersebut memengaruhi ketersediaan.

Pilar Reliability menekankan pemulihan otomatis tanpa campur tangan manusia. AWS menyediakan berbagai mekanisme pemulihan otomatis: EC2 Auto Recovery secara otomatis memulihkan instans pada perangkat keras yang sama atau memindahkannya ke perangkat keras yang sehat ketika instans gagal dalam pemeriksaan dasarnya. pemeriksaan kondisi ASG menghentikan instans yang tidak sehat dan meluncurkan penggantinya. RDS Multi-AZ secara otomatis melakukan failover ke instans siaga. Rancang arsitektur Anda agar sebagian besar skenario kegagalan memicu tindakan pemulihan otomatis yang tercatat dalam alarm CloudWatch.

Pilar Reliability merekomendasikan penskalaan secara horizontal (menambahkan lebih banyak instans berukuran kecil), bukan secara vertikal (meningkatkan ukuran instans), untuk memperoleh Reliability yang lebih baik. Satu instans besar merupakan satu titik kegagalan. Banyak instans kecil di belakang penyeimbang beban berarti kegagalan satu instans hanya berdampak minimal. AWS Auto Scaling secara otomatis menyesuaikan ukuran kumpulan instans untuk memenuhi permintaan, sehingga kapasitas selalu mencukupi dan Anda tidak membayar sumber daya yang menganggur selama periode sepi.

Pilar Reliability mewajibkan pengujian prosedur pemulihan — bukan menganggap prosedur tersebut akan berfungsi. Gunakan AWS Fault Injection Simulator (FIS) untuk menyuntikkan kegagalan ke dalam sistem secara terkendali: menghentikan instans EC2 secara acak, membatasi panggilan API, dan menyuntikkan latensi jaringan. Jalankan eksperimen ini di lingkungan produksi (dengan perlindungan yang sesuai) untuk memvalidasi bahwa pemantauan mendeteksi kegagalan, penskalaan otomatis merespons, dan pemulihan selesai dalam RTO Anda. Prosedur pemulihan yang tidak pernah diuji sering kali gagal saat menghadapi tekanan insiden nyata.

Pilar Efisiensi Kinerja berfokus pada penggunaan sumber daya komputasi secara efisien untuk memenuhi kebutuhan sistem serta mempertahankan efisiensi tersebut ketika permintaan berubah dan teknologi berkembang. Prinsip desain utama: Demokratisasikan teknologi canggih — gunakan layanan terkelola (RDS, SageMaker) daripada membangun semuanya dari awal. Jangkau seluruh dunia dalam hitungan menit — lakukan deployment ke beberapa wilayah dengan CloudFormation. Gunakan arsitektur tanpa server — hilangkan pengelolaan infrastruktur. Lakukan eksperimen lebih sering — uji berbagai jenis dan konfigurasi instans.

Efisiensi Kinerja dimulai dengan memilih jenis komputasi yang tepat untuk beban kerja Anda. EC2 memiliki puluhan keluarga instans yang dioptimalkan untuk berbagai kasus penggunaan: c-series untuk beban kerja intensif komputasi (pengodean video, pemrosesan batch), r-series untuk beban kerja intensif memori (basis data dalam memori, caching), i-series untuk beban kerja intensif penyimpanan (NoSQL, pergudangan data), dan p/g-series untuk beban kerja GPU (pelatihan ML). Menggunakan jenis instans yang salah berarti membayar kapasitas yang tidak dapat Anda gunakan atau mengalami penurunan kinerja.

Caching merupakan teknik dasar efisiensi kinerja yang mengurangi latensi dan beban basis data. ElastiCache (Redis/Memcached) menyimpan hasil kueri basis data di memori sehingga dapat diakses dalam hitungan milidetik. CloudFront menyimpan respons HTTP di lokasi edge yang dekat dengan pengguna. caching API Gateway mengurangi pemanggilan Lambda dengan menyimpan respons API. DAX (DynamoDB Accelerator) menambahkan cache dalam memori dengan akses mikrodetik di depan DynamoDB. Pilih lapisan caching yang tepat berdasarkan lokasi hambatan — basis data, API, atau pengiriman edge.

Pilihan penyimpanan sangat memengaruhi kinerja. io2 Block Express EBS menyediakan hingga 256.000 IOPS untuk basis data berkinerja tinggi. gp3 merupakan pilihan default untuk sebagian besar beban kerja dengan biaya lebih rendah. penyimpanan instans menyediakan IOPS tertinggi (NVMe) untuk data sementara. S3 dapat menangani ribuan permintaan per detik untuk penyimpanan objek. EFS menyediakan akses file POSIX bersama. Sesuaikan penyimpanan dengan pola I/O: pembacaan berurutan mendapatkan manfaat dari st1 (HDD yang Dioptimalkan untuk Throughput), sedangkan I/O acak memerlukan volume SSD.

Efisiensi Kinerja bukanlah keputusan sekali jadi — Anda harus terus memantau metrik kinerja dan mengevaluasi kembali pilihan Anda ketika AWS merilis layanan baru. Gunakan dasbor CloudWatch untuk melacak persentil latensi p50, p90, dan p99 (bukan hanya rata-rata, yang menyembunyikan latensi ekor). Gunakan pelacakan X-Ray untuk mengidentifikasi bagian paling lambat dalam rangkaian permintaan. Atur deteksi anomali CloudWatch untuk secara otomatis menetapkan garis dasar dan memberikan peringatan tentang penyimpangan kinerja yang tidak normal. Tinjau pengumuman AWS secara berkala — jenis instans yang lebih baru sering memberikan kinerja lebih baik dengan biaya lebih rendah.

Efisiensi Kinerja terkadang memerlukan kompromi dengan pilar lain. Menambahkan cache (ElastiCache) meningkatkan kinerja, tetapi menambah kompleksitas operasional (kompromi dengan Keunggulan Operasional) dan biaya (kompromi dengan Optimasi Biaya). Menggunakan DynamoDB alih-alih RDS meningkatkan kinerja dalam skala besar, tetapi memerlukan perancangan ulang model data (upaya Keunggulan Operasional). Kerangka Kerja yang Dirancang dengan Baik mengakui kompromi ini dan meminta Anda mengambil keputusan secara sadar dengan mendokumentasikan alasannya. Dalam soal ujian, carilah pilihan yang mencapai sasaran kinerja dengan beban operasional paling kecil.

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

Dalam pelajaran ini Anda mempelajari bahwa: Reliability memerlukan pemulihan otomatis, penskalaan horizontal, dan pengujian kegagalan secara berkala, Efisiensi Kinerja memerlukan pemilihan komputasi, penyimpanan, dan jenis basis data yang tepat untuk setiap beban kerja, serta caching di beberapa lapisan mengurangi latensi dan beban basis data. Kedua pilar tersebut memerlukan pemantauan berkelanjutan dan kesediaan untuk meninjau kembali keputusan arsitektur. Selanjutnya, kita akan membahas pilar Optimasi Biaya dan Keberlanjutan.