View a markdown version of this page

Menerapkan rekayasa kekacauan pada AWS - AWS Bimbingan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menerapkan rekayasa kekacauan pada AWS

Rekayasa kekacauan adalah bagian dari tahap evaluasi dan pengujian siklus hidup AWS ketahanan, seperti yang diilustrasikan dalam diagram berikut. Aplikasi terdistribusi tidak beroperasi secara terpisah dari aplikasi atau klien lain, jadi kami sarankan Anda meninjau seluruh siklus hidup ketahanan. Perubahan konstan untuk aplikasi terdistribusi saat jaringan berkembang, aplikasi hulu dan hilir mengalami pergeseran, dan penggunaan klien berubah seiring waktu.

Lima tahap kunci dalam siklus AWS hidup ketahanan.

Untuk memahami bagaimana perubahan ini pada aplikasi Anda dapat memengaruhi ketahanannya, jadikan chaos engineering sebagai bagian dari operasi Anda day-to-day. Anda dapat menerapkan eksperimen kekacauan dengan berbagai cara:

  • Ad hoc — Anda dapat melakukan eksperimen chaos sebagai eksperimen satu kali untuk mengatasi masalah atau pertanyaan tertentu.

  • Chaos game days — Ini adalah peristiwa terstruktur dan berulang yang dirancang untuk memverifikasi keandalan dan ketahanan aplikasi. Tujuan dari chaos game day adalah untuk mengidentifikasi potensi masalah ketahanan atau kekurangan di seluruh orang, proses, dan teknologi, dan untuk mempraktikkan proses dan prosedur untuk mengidentifikasi, mengurangi, dan menanggapi insiden.

  • Chaos pipeline — Integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDpipa yang menyuntikkan peningkatan kehilangan paket untuk komponen hilir. Eksperimen itu berjalan 3 kali dan membutuhkan waktu 5 menit untuk menyelesaikannya setiap kali. Kehilangan paket meningkat dari 10 persen menjadi 20 persen menjadi 30 persen dengan setiap proses, dan percobaan membutuhkan waktu 15 menit secara keseluruhan untuk menyelesaikannya. Jika Anda memiliki 100 penerapan paralel, Anda harus menunggu 1500 menit hingga satu percobaan selesai. Jika Anda memiliki 10 eksperimen untuk dijalankan, dampaknya terhadap pengembang Anda tidak akan tertahankan. Dalam skala besar, chaos engineering membutuhkan pipeline sendiri yang memungkinkan Anda menjalankan eksperimen secara paralel dengan proses siklus hidup pengembangan perangkat lunak (SDLC) Anda.

  • Penyebaran kenari - Canary menyediakan lingkungan pengujian untuk eksperimen kekacauan. Dengan mengarahkan sebagian kecil lalu lintas ke layanan kenari atau menggunakan metode seperti pencerminan lalu lintas atau pemutaran ulang, Anda dapat memverifikasi infrastruktur baru atau perubahan kode tanpa dampak pada sistem produksi stabil Anda. Anda dapat menjalankan eksperimen terhadap kenari dan menyuntikkan kesalahan seperlunya, karena Anda dapat membatasi ruang lingkup dampak pada pengguna akhir.

  • Eksperimen terjadwal — Anda dapat menjadwalkan eksperimen untuk memverifikasi mekanisme pemulihan yang dapat diprediksi untuk aplikasi Anda. Gunakan eksperimen terjadwal untuk memutar ulang peristiwa umum untuk menangkap bagaimana sistem Anda dapat pulih dari peristiwa seperti menghentikan EC2 instance di belakang grup penskalaan otomatis, menghapus pod Kubernetes, atau menghapus tugas Amazon ECS.