Pola pembatas struktural

Pola Bulkhead adalah jenis desain aplikasi yang toleran terhadap kegagalan. Dalam arsitektur sekat, juga dikenal sebagai arsitektur berbasis sel, elemen aplikasi diisolasi ke dalam kumpulan sehingga jika satu gagal, elemen lain terus berfungsi. Pola Bulkhead dinamai sesuai dengan sekat yang terpisah dari lambung kapal. Jika lambung kapal dikompromikan, hanya bagian yang rusak yang terisi dengan air, yang mencegah kapal tenggelam.

Konteks dan masalah

Aplikasi berbasis cloud mungkin mencakup beberapa layanan, dan setiap layanan memiliki satu atau beberapa konsumen. Beban atau kegagalan yang berlebihan dalam layanan memengaruhi semua konsumen layanan.

Selain itu, konsumen dapat mengirim permintaan ke beberapa layanan secara bersamaan dan menggunakan sumber daya untuk setiap permintaan. Ketika konsumen mengirim permintaan ke layanan yang salah dikonfigurasi atau tidak responsif, sumber daya yang digunakan permintaan klien mungkin tetap tidak tersedia untuk jangka waktu yang lama. Saat permintaan ke layanan berlanjut, sumber daya tersebut mungkin kelelahan. Misalnya, kumpulan koneksi klien mungkin habis. Pada saat itu, permintaan konsumen ke layanan lain terpengaruh. Akhirnya, konsumen tidak dapat mengirim permintaan ke layanan lain, tidak hanya layanan asli yang tidak responsif.

Kelelahan sumber daya memengaruhi layanan yang memiliki beberapa konsumen. Banyak permintaan dari satu klien mungkin menghabiskan sumber daya yang tersedia dalam layanan. Kelelahan sumber daya dapat berarti bahwa konsumen lain tidak dapat menggunakan layanan, yang menyebabkan efek kegagalan berkala.

Solusi

Pisahkan instans layanan ke dalam kelompok yang berbeda berdasarkan beban penggunaan konsumen dan kebutuhan ketersediaan. Desain ini membantu mengisolasi kegagalan. Anda dapat mempertahankan fungsionalitas layanan untuk beberapa konsumen, bahkan selama kegagalan.

Konsumen juga dapat mempartisi sumber daya untuk memastikan bahwa sumber daya yang digunakan untuk memanggil satu layanan tidak memengaruhi sumber daya yang digunakan untuk memanggil layanan lain. Misalnya, konsumen yang memanggil beberapa layanan mungkin diberi kumpulan koneksi untuk setiap layanan. Jika sebuah layanan mengalami kegagalan, kegagalan tersebut hanya akan memengaruhi kumpulan koneksi yang ditetapkan untuk layanan itu. Konsumen dapat terus menggunakan layanan lain.

Pola ini memberikan manfaat sebagai berikut:

  • Mengisolasi konsumen dan layanan dari kegagalan secara meluas. Masalah yang memengaruhi konsumen atau layanan dapat diisolasi dalam sekatnya sendiri untuk mencegah seluruh solusi gagal.

  • Mempertahankan beberapa fungsionalitas jika kegagalan layanan terjadi. Layanan dan fitur lain dari aplikasi terus berfungsi.

  • Menyediakan kualitas tingkat layanan yang berbeda untuk mengkonsumsi aplikasi. Anda dapat mengonfigurasi kumpulan konsumen berprioritas tinggi untuk menggunakan layanan berprioritas tinggi.

Diagram berikut menunjukkan sekat terstruktur di sekitar kumpulan koneksi yang memanggil layanan individual. Jika Layanan A gagal atau menyebabkan masalah, kumpulan koneksi terisolasi, sehingga hanya beban kerja yang menggunakan kumpulan utas yang ditetapkan ke Layanan A yang terpengaruh. Beban kerja yang menggunakan Layanan B dan C tidak terpengaruh dan dapat terus bekerja tanpa gangguan.

Diagram yang memperlihatkan sekat yang terstruktur di sekitar kumpulan koneksi yang memanggil layanan individual.

Diagram berikut menunjukkan beberapa klien yang memanggil satu layanan. Setiap klien ditetapkan ke instans layanan terpisah. Klien 1 membuat terlalu banyak permintaan dan membuat instansnya kewalahan. Karena setiap instans layanan diisolasi dari yang lain, klien lain dapat terus melakukan panggilan.

Diagram yang memperlihatkan beberapa klien memanggil satu layanan.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

  • Tentukan partisi seputar persyaratan bisnis dan teknis dari sebuah aplikasi.

  • Jika Anda menggunakan desain berbasis domain taktis untuk merancang layanan mikro, batas partisi harus selaras dengan konteks terikat.

  • Ketika Anda mempartisi layanan atau pengguna menjadi sekat, pertimbangkan tingkat isolasi yang ditawarkan oleh teknologi dan kelebihan beban yang dihadapi dalam hal biaya, kinerja, dan pengelolaan.

  • Untuk memberikan penanganan kesalahan yang lebih canggih, pertimbangkan untuk menggabungkan sekat dengan pola coba lagi, pemutus sirkuit, dan pembatasan.

  • Saat Anda mempartisi konsumen menjadi sekat, pertimbangkan untuk menggunakan proses, kumpulan utas, dan semaphore. Proyek-proyek seperti resilience4j dan Polly menawarkan kerangka kerja untuk menciptakan sekat konsumen.

  • Saat Anda mempartisi layanan ke dalam sekat, pertimbangkan untuk menyebarkannya ke dalam komputer virtual, kontainer, atau proses terpisah. Kontainer menawarkan keseimbangan isolasi sumber daya yang baik dengan pengeluaran tambahan yang cukup rendah.

  • Layanan yang berkomunikasi dengan menggunakan pesan asinkron dapat diisolasi melalui serangkaian antrean yang berbeda. Setiap antrean dapat memiliki sekumpulan instans khusus yang memproses pesan pada antrean atau satu grup instans yang menggunakan algoritma untuk mengeluarkan pesan dari antrean dan mendistribusikan pemrosesan.

  • Tentukan tingkat granularitas untuk sekat. Misalnya, jika Anda ingin mendistribusikan penyewa di seluruh partisi, Anda dapat menempatkan setiap penyewa ke dalam partisi terpisah atau menempatkan beberapa penyewa ke dalam satu partisi.

  • Pantau performa setiap partisi dan perjanjian tingkat layanan (SLA).

  • Gunakan kontrol platform bawaan, seperti batas laju Azure API Management, isolasi unit permintaan (RU) Azure Cosmos DB, dan batas sumber daya di Azure Kubernetes Service (AKS) atau Azure Container Apps. Jangan buat ulang mekanisme pembatasan dan isolasi ini dalam kode aplikasi Anda.

  • Beban kerja AI dan inferensi sering memerlukan sekat yang ketat karena kuota tingkat penyebaran dan batas konkurensi, misalnya, mengisolasi penyebaran Azure OpenAI per beban kerja atau per penyewa.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

  • Anda ingin mengisolasi sumber daya untuk dependensi tertentu sehingga gangguan dalam satu layanan tidak memengaruhi seluruh aplikasi.
  • Anda ingin mengisolasi konsumen penting dari konsumen standar.
  • Anda perlu melindungi aplikasi dari kegagalan berkala.

Pola ini mungkin tidak cocok ketika:

  • Penggunaan sumber daya yang kurang efisien mungkin tidak dapat diterima dalam proyek.
  • Kompleksitas tambahan tidak diperlukan.

Desain beban kerja

Evaluasi cara menggunakan pola Bulkhead dalam desain beban kerja untuk mencapai tujuan dan prinsip yang tercakup dalam pilar-pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi. Strategi isolasi kegagalan yang diperkenalkan melalui segmentasi yang disengaja dan lengkap antara komponen bertujuan untuk menahan kesalahan pada sekat yang mengalami masalah, sehingga mencegah dampaknya pada sekat lainnya.

- RE:02 Alur Kritis
- RE:07 Perlindungan Diri
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda. Segmentasi antar komponen membantu membatasi insiden keamanan ke dinding pembatas yang terkompromi.

- Segmentasi SE:04
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode. Setiap sekat dapat diskalakan secara individual untuk secara efisien memenuhi kebutuhan tugas yang dienkapsulasi dalam sekat.

- Perencanaan kapasitas PE:02
- PE:05 Penskalaan dan pemartisian

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

File konfigurasi Kubernetes berikut membuat kontainer terisolasi untuk menjalankan satu layanan, dengan sumber daya dan batasan CPU dan memorinya sendiri.

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

Langkah berikutnya

  • Last updated on