REL10-BP04 Menggunakan arsitektur bulkhead untuk membatasi cakupan dampak

Implementasikan arsitektur bulkhead (juga disebut sebagai arsitektur berbasis sel) untuk membatasi efek kegagalan dalam beban kerja hingga jumlah komponen yang terbatas.

Hasil yang diinginkan: Arsitektur berbasis sel menggunakan beberapa instans terisolasi beban kerja, di mana setiap instans disebut sebagai sel. Setiap sel bersifat mandiri, tidak berbagi status dengan sel lain, dan menangani subset permintaan beban kerja secara keseluruhan. Hal ini mengurangi potensi dampak kegagalan, seperti pembaruan perangkat lunak yang buruk, ke satu sel individu dan permintaan yang diprosesnya. Jika beban kerja menggunakan 10 sel untuk melayani 100 permintaan, ketika kegagalan terjadi, 90% dari seluruh permintaan akan tidak dipengaruhi oleh kegagalan.

Antipola umum:

• Membiarkan sel bertumbuh tanpa batas.

• Menerapkan pembaruan kode atau deployment ke semua sel pada waktu yang sama.

• Berbagi status atau komponen antara sel (dengan pengecualian lapisan router).

• Menambahkan bisnis yang kompleks atau mengarahkan rute logika ke lapisan router.

• Tidak meminimalkan interaksi lintas sel.

Manfaat menjalankan praktik terbaik ini: Dengan arsitektur berbasis sel, banyak jenis kegagalan umum dibatasi dalam lingkup sel itu sendiri, yang memberikan isolasi kesalahan tambahan. Batas kesalahan ini dapat memberikan ketangguhan terhadap jenis kegagalan yang sulit dibatasi, seperti deployment kode yang gagal atau permintaan yang rusak atau memicu mode kegagalan tertentu (juga disebut sebagai permintaan poison pill).

Panduan implementasi

Di kapal, bulkhead memastikan kebocoran lambung kapal hanya dibatasi dalam satu bagian lambung kapal saja. Di sistem yang kompleks, pola ini sering kali direplikasi untuk memungkinkan isolasi kesalahan. Batas isolasi kesalahan membatasi efek kegagalan di dalam beban kerja hingga jumlah komponen yang terbatas. Komponen di luar batas ini tidak terpengaruh oleh kegagalan tersebut. Menggunakan beberapa batas isolasi kesalahan, Anda dapat membatasi dampak pada beban kerja Anda. Di AWS, pelanggan dapat menggunakan beberapa Zona Ketersediaan dan Wilayah untuk memberikan isolasi kesalahan, tetapi konsep isolasi kesalahan dapat diperluas ke arsitektur beban kerja juga.

Beban kerja secara keseluruhan adalah sel-sel yang dipartisi oleh kunci partisi. Kunci ini harus sesuai dengan grain layanan, atau cara alami beban kerja layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minim. Contoh kunci partisi yakni ID pelanggan, ID sumber daya, atau parameter lainnya yang dapat diakses dengan mudah dalam sebagian besar panggilan API. Lapisan perutean sel mendistribusikan permintaan ke masing-masing sel berdasarkan kunci partisi dan menyampaikan satu titik akhir ke klien.

Gambar 11: Arsitektur berbasis sel

Langkah implementasi

Ketika mendesain arsitektur berbasis sel, ada beberapa pertimbangan desain untuk dipikirkan:

1. Kunci partisi: Pemilihan kunci partisi harus dipertimbangkan baik-baik.

   • Kunci ini harus sesuai dengan grain layanan, atau cara alami beban kerja layanan dapat dibagi lebih lanjut dengan interaksi lintas sel yang minim. Contohnya, ID pelanggan atau ID sumber daya.

   • Kunci partisi harus tersedia dalam semua permintaan, baik secara langsung atau dengan cara yang dapat disimpulkan dengan pasti dan mudah oleh parameter lain.

2. Pemetaan sel persisten: Layanan sebelumnya dalam proses hanya boleh berinteraksi dengan satu sel selama siklus hidup sumber dayanya.

   • Bergantung pada beban kerjanya, strategi migrasi sel mungkin diperlukan untuk memigrasikan data dari satu sel ke yang lain. Kemungkinan skenario ketika migrasi sel mungkin diperlukan yakni jika sumber daya atau pengguna tertentu di beban kerja Anda menjadi terlalu besar dan memerlukan sel khusus.

   • Sel tidak boleh berbagi status atau komponen antara sel.

   • Oleh karena itu, interaksi lintas sel harus dihindari atau dijaga agar tetap minim, karena interaksi tersebut menimbulkan dependensi antara sel, sehingga mengurangi peningkatan isolasi kesalahan.

3. Lapisan router: Lapisan router adalah komponen bersama antara sel, oleh karena itu tidak dapat mengikuti strategi kompartementalisasi yang sama seperti sel.

   • Sebaiknya lapisan router mendistribusikan permintaan ke sel secara individu menggunakan algoritme pemetaan partisi dengan cara yang efisien secara komputasi, seperti menggabungkan fungsi hash kriptografi dan aritmetika modul untuk memetakan kunci partisi ke sel.

   • Untuk menghindari dampak multi-sel, lapisan perutean harus tetap sesederhana mungkin dan dapat diskalakan sehorizontal mungkin, yang memerlukan penghindaran logika bisnis kompleks di dalam lapisan ini. Hal ini memiliki manfaat tambahan mempermudah pemahaman ekspektasi perilakunya di setiap waktu, yang memberikan kemampuan untuk diuji secara menyeluruh. Sebagaimana dijelaskan oleh Colm MacCárthaigh dalam Reliability, constant work, and a good cup of coffee, desain sederhana dan pola kerja konstan menghasilkan sistem yang andal dan mengurangi anti-kerentanan.

4. Ukuran sel: Sel harus memiliki ukuran maksimum dan tidak boleh diizinkan untuk bertumbuh melampauinya.

   • Ukuran maksimum harus diidentifikasi dengan melakukan pengujian yang menyeluruh, sampai titik rusak tercapai dan margin pengoperasian yang aman ditetapkan. Untuk detail selengkapnya tentang cara mengimplementasikan praktik pengujian, lihat REL07-BP04 Menguji beban untuk beban kerja Anda

   • Beban kerja secara keseluruhan harus bertumbuh dengan menambahkan sel tambahan, sehingga beban kerja dapat diskalakan seiring peningkatan permintaan.

5. Strategi Multi-AZ atau Multi-Wilayah: Beberapa lapisan ketangguhan harus dimanfaatkan untuk melindungi dari berbagai macam domain kegagalan.

   • Untuk ketahanan, Anda harus menggunakan pendekatan yang membangun lapisan pertahanan. Satu lapisan melindungi dari gangguan yang lebih kecil dan lebih umum dengan membangun arsitektur yang memiliki ketersediaan tinggi menggunakan beberapa AZ. Lapisan pertahanan lainnya ditujukan untuk memberikan perlindungan terhadap peristiwa langka seperti bencana alam yang meluas dan gangguan tingkat Wilayah. Lapisan kedua ini melibatkan perancangan aplikasi agar menjangkau beberapa Wilayah AWS. Mengimplementasikan strategi multi-Wilayah untuk beban kerja membantu melindunginya dari bencana alam yang menjangkau dan memengaruhi wilayah geografis yang luas di suatu negara, atau kesalahan teknis yang mencakup seluruh Wilayah. Perhatikan bahwa mengimplementasikan arsitektur multi-Wilayah dapat menjadi sangat kompleks, dan biasanya tidak diperlukan untuk sebagian besar beban kerja. untuk detail selengkapnya, lihat REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi.

6. Deployment kode: Strategi deployment kode bergiliran harus didahulukan dibandingkan deployment perubahan kode ke semua sel pada waktu yang sama.

   • Hal ini akan membantu meminimalkan potensi kegagalan pada beberapa sel karena deployment yang buruk atau kesalahan manusia. Untuk detail selengkapnya, lihat Mengotomatiskan deployment aman tanpa campur tangan.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Tinggi

Sumber daya

Praktik Terbaik Terkait:

• REL07-BP04 Menguji beban untuk beban kerja Anda

• REL10-BP02 Memilih lokasi yang sesuai untuk deployment multilokasi

Dokumen terkait:

• Reliability, constant work, and a good cup of coffee

• AWS dan Kompartementalisasi

• Isolasi beban kerja menggunakan shuffle-sharding

• Mengotomatiskan deployment aman tanpa campur tangan

Video terkait:

• AWS re:Invent 2018: Menutup Lingkaran dan Membuka Pikiran: Cara Mengendalikan Sistem, Besar dan Kecil

• AWS re:Invent 2018: Cara AWS Meminimalkan Radius Dampak Kegagalan (ARC338)

• Shuffle-sharding: AWS re:Invent 2019: Memperkenalkan Pustaka Pengembang Amazon (DOP328)

• AWS Summit ANZ 2021 - Segala sesuatu gagal, setiap waktu: Mendesain agar memiliki ketangguhan

Contoh terkait:

• Well-Architected Lab - Isolasi kesalahan dengan shuffle sharding