Memahami kebutuhan ketersediaan

Merupakan hal normal ketika di awal, ketersediaan suatu aplikasi dianggap sebagai satu target tunggal untuk aplikasi secara keseluruhan. Namun demikian, setelah diselidiki lebih teliti, kita sering menemukan bahwa aspek-aspek tertentu yang ada dalam suatu aplikasi atau layanan memiliki persyaratan ketersediaan yang berbeda. Sebagai contoh, beberapa sistem mungkin mengutamakan kemampuan untuk menerima dan menyimpan data baru sebelum mengambil data yang sudah ada. Sedangkan sistem lainnya mengutamakan operasi waktu nyata daripada operasi yang akan mengubah konfigurasi atau lingkungan sistem. Layanan-layanan mungkin memiliki persyaratan ketersediaan yang sangat tinggi selama jam tertentu, tetapi dapat memberikan toleransi terhadap gangguan yang jauh lebih lama di luar jam-jam tersebut. Ini adalah beberapa cara untuk mengurai satu aplikasi menjadi bagian-bagian komponen, dan mengevaluasi persyaratan ketersediaan untuk masing-masing komponen. Manfaat dari melakukan hal ini adalah untuk memfokuskan upaya (serta pengeluaran) Anda pada ketersediaan berdasarkan kebutuhan khusus, bukan merekayasa keseluruhan sistem sesuai persyaratan paling ketat.

Di dalam AWS, kami biasanya membagi layanan menjadi “bidang data” dan “bidang kontrol.” Bidang data bertanggung jawab untuk menghadirkan layanan waktu nyata sedangkan bidang kontrol digunakan untuk mengonfigurasi lingkungan. Misalnya, EC2 instans Amazon, RDS database Amazon, dan operasi baca/tulis tabel Amazon DynamoDB adalah semua operasi bidang data. Sebaliknya, meluncurkan EC2 instance atau RDS database baru, atau menambahkan atau mengubah metadata tabel di DynamoDB semuanya dianggap sebagai operasi bidang kontrol. Meskipun tingkat ketersediaan yang tinggi penting untuk semua kemampuan ini, bidang data umumnya memiliki tujuan desain ketersediaan yang lebih tinggi daripada bidang kontrol. Oleh karena itu, beban kerja dengan persyaratan ketersediaan yang tinggi harus menghindari dependensi run-time pada operasi bidang kontrol.

Banyak AWS pelanggan mengambil pendekatan serupa untuk mengevaluasi aplikasi mereka secara kritis dan mengidentifikasi subkomponen dengan kebutuhan ketersediaan yang berbeda. Tujuan desain ketersediaan kemudian disesuaikan dengan aspek yang berbeda, dan upaya kerja yang tepat dilakukan untuk merekayasa sistem. AWS Memiliki pengalaman aplikasi rekayasa yang signifikan dengan berbagai tujuan desain ketersediaan, termasuk layanan dengan ketersediaan 99,999% atau lebih besar. AWS Solution Architects (SAs) dapat membantu Anda merancang dengan tepat untuk tujuan ketersediaan Anda. Melibatkan di AWS awal proses desain Anda meningkatkan kemampuan kami untuk membantu Anda memenuhi tujuan ketersediaan Anda. Perencanaan ketersediaan tidak hanya dilakukan sebelum peluncuran beban kerja Anda. Perencanaan ini juga dilakukan secara berkelanjutan untuk menyempurnakan desain Anda seiring Anda mendapatkan pengalaman operasional, belajar dari peristiwa dunia nyata, dan bertahan di tengah berbagai jenis kegagalan yang terjadi. Anda kemudian dapat menerapkan upaya kerja yang tepat untuk melakukan perbaikan setelah implementasi Anda.

Kebutuhan ketersediaan yang diperlukan untuk suatu beban kerja harus diselaraskan dengan kebutuhan dan kekritisan bisnis. Dengan terlebih dahulu mendefinisikan kerangka kerja kekritisan bisnis dengan definisiRTO,RPO, dan ketersediaan, Anda kemudian dapat menilai setiap beban kerja. Pendekatan seperti ini akan mengharuskan orang-orang yang terlibat di dalam implementasi beban kerja untuk memahami kerangka kerja tersebut, dan dampak yang diberikan oleh beban kerja mereka terhadap kebutuhan bisnis.