Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tahap 2: Desain dan implementasi
Pada tahap sebelumnya, Anda menetapkan tujuan ketahanan Anda. Sekarang pada tahap desain dan implementasi, Anda mencoba mengantisipasi mode kegagalan dan mengidentifikasi pilihan desain, sebagaimana dipandu oleh tujuan yang Anda tetapkan pada tahap sebelumnya. Anda juga menentukan strategi untuk manajemen perubahan dan mengembangkan kode perangkat lunak dan konfigurasi infrastruktur. Bagian berikut menyoroti praktik AWS terbaik yang harus Anda pertimbangkan saat mengambil trade-off seperti biaya, kompleksitas, dan overhead operasional.
AWS Kerangka Well-Architected
Ketika Anda merancang aplikasi Anda berdasarkan tujuan ketahanan yang Anda inginkan, Anda perlu mengevaluasi beberapa faktor dan membuat trade-off pada arsitektur yang paling optimal. Untuk membangun aplikasi yang sangat tangguh, Anda harus mempertimbangkan aspek desain, bangunan dan penyebaran, keamanan, dan operasi. The AWS Well-Architected
Berikut ini adalah contoh bagaimana AWS Well-Architected Framework dapat membantu Anda merancang dan mengimplementasikan aplikasi yang memenuhi tujuan ketahanan Anda:
-
Pilar keandalan: Pilar keandalan menekankan pentingnya membangun aplikasi yang dapat beroperasi dengan benar dan konsisten, bahkan selama kegagalan atau gangguan. Misalnya, AWS Well-Architected Framework merekomendasikan agar Anda menggunakan arsitektur microservices untuk membuat aplikasi Anda lebih kecil dan lebih sederhana, sehingga Anda dapat membedakan antara kebutuhan ketersediaan komponen yang berbeda dalam aplikasi Anda. Anda juga dapat menemukan deskripsi rinci tentang praktik terbaik untuk membangun aplikasi dengan menggunakan pelambatan, coba lagi dengan mundur eksponensial, gagal cepat (pelepasan beban), idempotensi, kerja konstan, pemutus sirkuit, dan stabilitas statis.
-
Tinjauan komprehensif: The AWS Well-Architected Framework mendorong tinjauan komprehensif arsitektur Anda terhadap praktik terbaik dan prinsip desain. Ini menyediakan cara untuk secara konsisten mengukur arsitektur Anda dan mengidentifikasi area untuk perbaikan.
-
Manajemen risiko: The AWS Well-Architected Framework membantu Anda mengidentifikasi dan mengelola risiko yang mungkin memengaruhi keandalan aplikasi Anda. Dengan mengatasi skenario kegagalan potensial secara proaktif, Anda dapat mengurangi kemungkinannya atau kerusakan yang diakibatkannya.
-
Peningkatan berkelanjutan: Ketahanan adalah proses yang berkelanjutan, dan Kerangka AWS Well-Architected menekankan perbaikan berkelanjutan. Dengan secara teratur meninjau dan menyempurnakan arsitektur dan proses Anda berdasarkan panduan AWS Well-Architected Framework, Anda dapat memastikan bahwa sistem Anda tetap tangguh dalam menghadapi tantangan dan persyaratan yang berkembang.
Memahami dependensi
Memahami dependensi sistem adalah kunci untuk ketahanan. Dependensi mencakup koneksi antara komponen dalam aplikasi, dan koneksi ke komponen di luar aplikasi, seperti API pihak ketiga dan layanan bersama milik bisnis. Memahami koneksi ini membantu Anda mengisolasi dan mengelola gangguan, karena gangguan pada satu komponen dapat memengaruhi komponen lainnya. Pengetahuan ini membantu para insinyur menilai dampak gangguan dan merencanakan yang sesuai, dan memastikan bahwa sumber daya digunakan secara efektif. Memahami dependensi membantu Anda membuat strategi alternatif dan mengoordinasikan proses pemulihan. Ini juga membantu Anda menentukan kasus di mana Anda dapat mengganti ketergantungan keras dengan dependensi lunak, sehingga aplikasi Anda dapat terus melayani fungsi bisnisnya ketika ada gangguan ketergantungan. Dependensi juga memengaruhi keputusan tentang load balancing dan penskalaan aplikasi. Memahami dependensi sangat penting ketika Anda membuat perubahan pada aplikasi Anda, karena dapat membantu Anda menentukan potensi risiko dan dampak. Pengetahuan ini membantu Anda membuat aplikasi yang stabil dan tangguh, membantu dalam manajemen kesalahan, penilaian dampak, pemulihan gangguan, penyeimbangan beban, penskalaan, dan manajemen perubahan. Anda dapat melacak dependensi secara manual atau menggunakan alat dan layanan seperti AWS X-Ray
Strategi pemulihan bencana
Strategi pemulihan bencana (DR) memainkan peran penting dalam membangun dan mengoperasikan aplikasi yang tangguh, terutama dengan memastikan kelangsungan bisnis. Ini menjamin bahwa operasi bisnis yang penting dapat bertahan dengan penurunan sesedikit mungkin, bahkan selama peristiwa bencana, sehingga meminimalkan waktu henti dan potensi hilangnya pendapatan. Strategi DR sangat penting untuk perlindungan data karena sering menggabungkan cadangan data reguler dan replikasi data di beberapa lokasi, yang membantu melindungi informasi bisnis yang berharga dan membantu mencegah kerugian total selama bencana. Selain itu, banyak industri diatur oleh kebijakan yang mengharuskan bisnis untuk memiliki strategi DR untuk melindungi data sensitif dan untuk memastikan bahwa layanan tetap tersedia selama bencana. Dengan memastikan gangguan layanan minimal, strategi DR juga meningkatkan kepercayaan dan kepuasan pelanggan. Strategi DR yang diterapkan dengan baik dan sering dipraktikkan mengurangi waktu pemulihan setelah bencana, dan membantu memastikan bahwa aplikasi dengan cepat dibawa kembali online. Selain itu, bencana dapat menimbulkan biaya besar, tidak hanya dari kehilangan pendapatan karena downtime, tetapi juga dari biaya pemulihan aplikasi dan data. Strategi DR yang dirancang dengan baik membantu melindungi dari kerugian finansial ini.
Strategi yang Anda pilih tergantung pada kebutuhan spesifik aplikasi Anda, RTO dan RPO Anda, dan anggaran Anda. AWS Elastic Disaster Recovery
Untuk informasi selengkapnya, lihat Disaster Recovery of Workloads on AWS and AWS Multi-Region Fundamentals di situs web. AWS
Mendefinisikan strategi CI/CD
Salah satu penyebab umum gangguan aplikasi adalah kode atau perubahan lain yang mengubah aplikasi dari keadaan kerja yang diketahui sebelumnya. Jika Anda tidak menangani manajemen perubahan dengan hati-hati, itu dapat menyebabkan kerusakan yang sering terjadi. Frekuensi perubahan meningkatkan peluang untuk dampak. Namun, membuat perubahan lebih jarang menghasilkan set perubahan yang lebih besar, yang jauh lebih mungkin mengakibatkan penurunan karena kompleksitasnya yang tinggi. Praktik Continuous Integration and Continuous Delivery (CI/CD) dirancang untuk menjaga perubahan kecil dan sering (menghasilkan peningkatan produktivitas) sambil menundukkan setiap perubahan ke tingkat inspeksi yang tinggi melalui otomatisasi. Beberapa strategi dasar adalah:
-
Otomatisasi penuh: Konsep dasar CI/CD adalah untuk mengotomatiskan proses build dan deployment sebanyak mungkin. Ini termasuk pembangunan, pengujian, penyebaran, dan bahkan pemantauan. Pipa otomatis membantu mengurangi kemungkinan kesalahan manusia, memastikan konsistensi, dan membuat proses lebih andal dan efisien.
-
Test-driven development (TDD): Tulis tes sebelum menulis kode aplikasi. Praktik ini memastikan bahwa semua kode memiliki pengujian terkait, yang meningkatkan keandalan kode dan kualitas inspeksi otomatis. Pengujian ini dijalankan di pipeline CI untuk memvalidasi perubahan.
-
Komit dan integrasi yang sering: Dorong pengembang untuk sering melakukan kode dan sering melakukan integrasi. Perubahan kecil dan sering lebih mudah untuk diuji dan di-debug, yang mengurangi risiko masalah yang signifikan. Otomatisasi mengurangi biaya setiap komit dan penyebaran, membuat integrasi yang sering menjadi mungkin.
-
Infrastruktur yang tidak dapat diubah: Perlakukan server Anda dan komponen infrastruktur lainnya seperti entitas statis dan tidak dapat diubah. Ganti infrastruktur alih-alih memodifikasinya sebanyak mungkin, dan bangun infrastruktur baru melalui kode yang diuji, dan diterapkan melalui pipeline Anda.
-
Mekanisme rollback: Selalu miliki cara yang mudah, andal, dan sering diuji untuk mengembalikan perubahan jika terjadi kesalahan. Mampu dengan cepat kembali ke keadaan baik yang diketahui sebelumnya dengan cepat sangat penting untuk keselamatan penerapan. Ini bisa menjadi tombol sederhana untuk kembali ke keadaan sebelumnya, atau dapat sepenuhnya otomatis dan diprakarsai oleh alarm.
-
Kontrol versi: Pertahankan semua kode aplikasi, konfigurasi, dan bahkan infrastruktur sebagai kode dalam repositori yang dikendalikan versi. Praktik ini membantu memastikan bahwa Anda dapat dengan mudah melacak perubahan dan mengembalikannya jika diperlukan.
-
Penerapan Canary dan penerapan biru/hijau: Menerapkan versi baru aplikasi Anda ke subset infrastruktur Anda terlebih dahulu, atau mempertahankan dua lingkungan (biru/hijau), memungkinkan Anda memverifikasi perilaku perubahan dalam produksi dan memutar kembali dengan cepat jika perlu.
CI/CD bukan hanya tentang alat tetapi juga tentang budaya. Menciptakan budaya yang menghargai otomatisasi, pengujian, dan pembelajaran dari kegagalan sama pentingnya dengan menerapkan alat dan proses yang tepat. Rollback, jika dilakukan dengan sangat cepat dengan dampak minimal, tidak boleh dianggap sebagai kegagalan tetapi pengalaman belajar.
Melakukan ORR
Tinjauan kesiapan operasional (ORR) membantu mengidentifikasi kesenjangan operasional dan prosedural. Di Amazon, kami menciptakan ORR untuk menyaring pembelajaran dari beberapa dekade mengoperasikan layanan skala tinggi menjadi pertanyaan yang dikuratori dengan panduan praktik terbaik. ORR menangkap pelajaran sebelumnya dan membutuhkan tim baru untuk memastikan bahwa mereka telah memperhitungkan pelajaran ini dalam aplikasi mereka. ORR dapat memberikan daftar mode kegagalan atau penyebab kegagalan yang dapat dibawa ke dalam aktivitas pemodelan ketahanan yang dijelaskan di bagian pemodelan ketahanan di bawah ini. Untuk informasi lebih lanjut, lihat Ulasan Kesiapan Operasional (ORR) di situs web Well-Architected AWS Framework.
Memahami batas-batas isolasi AWS kesalahan
AWS menyediakan beberapa batasan isolasi kesalahan untuk membantu Anda mencapai tujuan ketahanan Anda. Anda dapat menggunakan batas-batas ini untuk memanfaatkan ruang lingkup penahanan dampak yang dapat diprediksi yang mereka berikan. Anda harus terbiasa dengan bagaimana AWS layanan dirancang dengan menggunakan batas-batas ini sehingga Anda dapat membuat pilihan yang disengaja tentang dependensi yang Anda pilih untuk aplikasi Anda. Untuk memahami cara menggunakan batasan dalam aplikasi Anda, lihat Batas Isolasi AWS Kesalahan di AWS situs web.
Memilih tanggapan
Sebuah sistem dapat merespons dengan berbagai cara untuk alarm. Beberapa alarm mungkin memerlukan respons dari tim operasi sedangkan yang lain mungkin memicu mekanisme penyembuhan diri dalam aplikasi. Anda mungkin memutuskan untuk menyimpan tanggapan yang dapat diotomatisasi sebagai operasi manual untuk mengontrol biaya otomatisasi atau untuk mengelola kendala teknik. Jenis respons terhadap alarm kemungkinan akan dipilih sebagai fungsi dari biaya penerapan respons, frekuensi alarm yang diantisipasi, keakuratan alarm, dan potensi kerugian bisnis karena tidak menanggapi alarm sama sekali.
Misalnya, ketika proses server mogok, proses mungkin dimulai ulang oleh sistem operasi, atau server baru mungkin disediakan dan yang lama dihentikan, atau operator mungkin diinstruksikan untuk terhubung dari jarak jauh ke server dan memulai ulang. Respons ini memiliki hasil yang sama — memulai kembali proses server aplikasi — tetapi memiliki berbagai tingkat implementasi dan biaya pemeliharaan.
catatan
Anda dapat memilih beberapa tanggapan untuk mengambil pendekatan ketahanan yang mendalam. Misalnya, dalam skenario sebelumnya, tim aplikasi mungkin memilih untuk mengimplementasikan ketiga respons dengan waktu tunda di antara masing-masing. Jika indikator proses server gagal masih dalam keadaan khawatir setelah 30 detik, tim dapat berasumsi bahwa sistem operasi telah gagal me-restart server aplikasi. Oleh karena itu, mereka mungkin membuat grup penskalaan otomatis untuk membuat server virtual baru dan memulihkan proses server aplikasi. Jika indikator masih dalam keadaan alarm setelah 300 detik, peringatan mungkin dikirim ke staf operasional untuk terhubung ke server asli dan mencoba memulihkan proses.
Tanggapan bahwa tim aplikasi dan pilihan bisnis harus mencerminkan selera bisnis untuk mengimbangi overhead operasional dengan investasi di muka dalam waktu rekayasa. Anda harus memilih respons — pola arsitektur seperti stabilitas statis, pola perangkat lunak seperti pemutus sirkuit, atau prosedur operasional―dengan mempertimbangkan secara cermat kendala dan pemeliharaan yang diantisipasi dari setiap opsi respons. Beberapa tanggapan standar mungkin ada untuk memandu tim aplikasi, sehingga Anda dapat menggunakan pustaka dan pola yang dikelola oleh fungsi arsitektur terpusat Anda sebagai masukan untuk pertimbangan ini.
Pemodelan ketahanan
Pemodelan ketahanan mendokumentasikan bagaimana aplikasi akan merespons berbagai gangguan yang diantisipasi. Dengan mengantisipasi gangguan, tim Anda dapat menerapkan observabilitas, kontrol otomatis, dan proses pemulihan untuk mengurangi atau mencegah gangguan meskipun ada gangguan. AWS telah menciptakan panduan untuk mengembangkan model ketahanan dengan menggunakan kerangka analisis ketahanan. Kerangka kerja ini dapat membantu Anda mengantisipasi gangguan dan dampaknya terhadap aplikasi Anda. Dengan mengantisipasi gangguan, Anda dapat mengidentifikasi mitigasi yang diperlukan untuk membangun aplikasi yang tangguh dan andal. Kami menyarankan Anda menggunakan kerangka analisis ketahanan untuk memperbarui model ketahanan Anda dengan setiap iterasi siklus hidup aplikasi Anda. Menggunakan kerangka kerja ini dengan setiap iterasi membantu mengurangi insiden dengan mengantisipasi gangguan selama fase desain dan menguji aplikasi sebelum dan sesudah penerapan produksi. Mengembangkan model ketahanan dengan menggunakan kerangka kerja ini membantu Anda memastikan bahwa Anda memenuhi tujuan ketahanan Anda.
Gagal dengan aman
Jika Anda tidak dapat menghindari gangguan, gagal dengan aman. Pertimbangkan untuk membuat aplikasi Anda dengan mode operasi fail-safe default, di mana tidak ada kerugian bisnis yang signifikan yang dapat terjadi. Contoh status fail-safe untuk database adalah default ke operasi hanya-baca, di mana pengguna tidak diizinkan untuk membuat atau mengubah data apa pun. Bergantung pada sensitivitas data, Anda bahkan mungkin ingin aplikasi default ke status shutdown dan bahkan tidak melakukan kueri hanya-baca. Pertimbangkan status fail-safe untuk aplikasi Anda seharusnya, dan default ke mode operasi ini dalam kondisi ekstrim.
