Bangun sistem terdistribusi toleransi kesalahan dengan ASM - Alibaba Cloud Service Mesh

Konfigurasikan timeout, retry, pola bulkhead, dan circuit breaking di Alibaba Cloud Service Mesh (ASM) agar layanan Anda dapat mentoleransi kegagalan pada layanan dependensinya. Risiko ketidakstabilan dapat muncul dari infrastruktur, logika aplikasi, maupun proses operasional, dan salah satunya saja dapat menyebabkan gangguan pada sistem bisnis.

Informasi latar belakang

Toleransi kesalahan adalah kemampuan suatu sistem untuk tetap beroperasi meskipun sebagian komponennya mengalami kegagalan. Sistem yang andal dan tangguh memerlukan toleransi kesalahan pada setiap layanan yang dikandungnya. Sifat dinamis lingkungan cloud mengharuskan layanan untuk mengantisipasi kegagalan dan merespons situasi tak terduga secara elegan.

Setiap layanan dapat mengalami permintaan yang gagal, sehingga tindakan fallback yang tepat sangat penting saat permintaan gagal. Gangguan pada satu layanan saja dapat memicu reaksi berantai dengan konsekuensi bisnis serius. ASM menerapkan mekanisme toleransi kesalahan pada proxy sidecar, sehingga aplikasi Anda tidak perlu melakukan perubahan pada kode aplikasi.

Pilih mekanisme toleransi kesalahan

Tabel berikut menjelaskan mekanisme toleransi kesalahan yang disediakan oleh ASM, jenis kegagalan yang ditangani oleh masing-masing mekanisme, serta resource tempat Anda mengonfigurasikannya.

Mechanism	Failure mode it addresses	Configuration resource	Key field
Timeouts	Layanan upstream merespons lambat atau tidak sama sekali, dan client terus menunggu.	Virtual service	`timeout`
Retries	Satu permintaan gagal karena error seperti request timeout, connection timeout, atau service downtime.	Virtual service	`retries`
Bulkhead	Client mengirim lebih banyak koneksi atau permintaan daripada yang dapat ditangani oleh layanan target.	Destination rule	`connectionPool`
Circuit breaking	Host individual dari layanan upstream menghasilkan error berturut-turut.	Destination rule	`outlierDetection`

Timeout dan retry mengatur jalur permintaan tunggal, sedangkan pola bulkhead dan circuit breaking tingkat host mengatur beban yang diterima layanan target serta host mana yang tetap berada dalam pool load balancing. Konfigurasikan timeout pada rute yang sama dengan kebijakan retry: timeout rute inilah yang membatasi total waktu yang dihabiskan proxy sidecar untuk melakukan retry.

Catatan

Nilai dalam contoh pada topik ini hanya menunjukkan sintaksis masing-masing field. Turunkan nilai Anda sendiri berdasarkan latensi, kapasitas, dan perilaku error layanan Anda; jangan menyalin nilai contoh ke mesh produksi.

Prasyarat

Persyaratan berikut berlaku untuk mekanisme yang dijelaskan dalam topik ini:

Versi instans ASM — Mengonfigurasi kebijakan retry default untuk permintaan HTTP memerlukan instans ASM versi 1.15.3.120 atau lebih baru. Untuk informasi selengkapnya tentang cara upgrade instans, lihat Upgrade an ASM instance.
Pelaporan dan pengumpulan metrik — Metrik circuit breaking tingkat host hanya tersedia setelah proxy sidecar melaporkannya dan Prometheus mengumpulkannya. Selesaikan penyiapan yang dijelaskan dalam View host-level circuit breaking metrics dan Configure host-level circuit breaking metric collection and alerting sebelum Anda mengandalkan metrik ini.

Timeouts

Cara kerja timeout

Ketika suatu layanan mengirim permintaan ke layanan upstream, layanan upstream tersebut mungkin tidak pernah merespons. Tetapkan waktu tunggu untuk permintaan tersebut. Setelah waktu tunggu habis dan layanan upstream masih belum merespons, permintaan langsung gagal alih-alih terus menunggu respons.

Timeout memastikan bahwa aplikasi menerima error return ketika layanan backend tidak merespons, sehingga aplikasi dapat menangani kegagalan tersebut dengan perilaku fallback yang sesuai. Timeout mengubah berapa lama client yang mengirim permintaan menunggu respons, tetapi tidak memengaruhi cara layanan target memproses permintaan. Oleh karena itu, timeout tidak berarti bahwa operasi yang diminta gagal.

Konfigurasikan timeout rute

ASM memungkinkan Anda mengubah nilai timeout dengan menetapkan kebijakan timeout untuk suatu rute dalam virtual service. Jika proxy sidecar tidak menerima respons dalam waktu yang dikonfigurasi, permintaan gagal. Dengan penyesuaian ini, semua permintaan yang menggunakan rute tersebut akan menggunakan pengaturan timeout yang sama.

Virtual service berikut menetapkan timeout untuk rute ke aplikasi httpbin:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    timeout: 5s

Field	Description
`timeout`	Menetapkan durasi timeout untuk rute. Jika layanan yang diminta tidak merespons dalam waktu yang dikonfigurasi, hasil error langsung dikembalikan dan client berhenti menunggu.

Penting

Timeout rute juga membatasi jumlah retry pada rute tersebut. Jika permintaan belum mencapai jumlah maksimum retry tetapi total waktu yang dihabiskan untuk semua retry sudah melebihi timeout, proxy sidecar berhenti melakukan retry dan mengembalikan timeout. Untuk informasi selengkapnya tentang kebijakan retry, lihat Retries.

Retries

Cara kerja retry

Jika permintaan ke layanan lain gagal karena error seperti request timeout, connection timeout, atau service downtime, konfigurasikan kebijakan retry agar proxy sidecar mengirim ulang permintaan tersebut ke layanan tersebut.

Penting

Jangan melakukan retry terlalu sering atau terlalu lama untuk menghindari kegagalan sistem berantai. Batasi setiap upaya dengan field perTryTimeout, dan batasi total waktu yang dihabiskan untuk retry dengan mengonfigurasi timeout pada rute yang sama. Untuk informasi selengkapnya, lihat Timeouts.

Konfigurasikan kebijakan retry untuk suatu rute

ASM mendukung pendefinisian kebijakan retry permintaan HTTP menggunakan virtual service. Pada contoh berikut, ketika layanan dalam mesh meminta aplikasi httpbin, proxy sidecar melakukan retry hingga tiga kali jika httpbin tidak merespons atau koneksi tidak dapat dibuat, dengan timeout per upaya sebesar 5 detik.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    retries:
      attempts: 3
      perTryTimeout: 5s
      retryOn: connect-failure,reset

Konfigurasikan field-field berikut di bawah field retries untuk menyesuaikan cara proxy sidecar melakukan retry permintaan.

Field	Description
attempts	Jumlah maksimum retry untuk suatu permintaan. Jika timeout dikonfigurasi untuk rute layanan sementara mekanisme retry diaktifkan, jumlah retry aktual bergantung pada pengaturan timeout. Untuk detailnya, lihat Timeouts.
perTryTimeout	Timeout untuk setiap retry, dalam milidetik (ms), detik (s), menit (m), atau jam (h).
retryOn	Menentukan kondisi di mana retry dilakukan. Pisahkan beberapa kondisi retry dengan koma (,). Untuk informasi selengkapnya, lihat Common HTTP request retry conditions dan Common gRPC request retry conditions.

Kondisi retry HTTP

Tabel berikut menjelaskan kondisi retry permintaan HTTP umum yang dapat Anda tetapkan di field retryOn.

Retry condition	Description
`connect-failure`	Retry jika permintaan gagal karena koneksi ke layanan upstream tidak dapat dibuat, seperti connection timeout.
`refused-stream`	Retry jika layanan upstream mengembalikan frame REFUSED_STREAM untuk mereset stream.
`reset`	Retry jika terjadi event disconnection, reset, atau read timeout sebelum layanan upstream merespons.
`5xx`	Retry jika layanan upstream mengembalikan kode respons 5xx apa pun, seperti 500 atau 503, atau jika layanan upstream tidak merespons. Catatan Kondisi `5xx` mencakup kondisi `connect-failure` dan `refused-stream`.
`gateway-error`	Retry ketika layanan upstream mengembalikan kode status 502, 503, atau 504.
`envoy-ratelimited`	Retry ketika permintaan berisi header `x-envoy-ratelimited`.
`retriable-4xx`	Retry ketika layanan upstream mengembalikan kode status 409.
`retriable-status-codes`	Retry ketika kode status yang dikembalikan oleh layanan upstream ditentukan sebagai kode status yang dapat diretry. Catatan Anda dapat menambahkan kode status valid langsung ke field retryOn, dan kode status tersebut kemudian ditentukan sebagai kode status yang dapat diretry. Misalnya, `403,404,retriable-status-codes`.
`retriable-headers`	Retry ketika header respons yang dikembalikan oleh layanan upstream berisi header yang menunjukkan retry dimungkinkan. Catatan Anda dapat menambahkan header `x-envoy-retriable-header-names` ke permintaan yang dikirim ke layanan upstream untuk menentukan header respons mana yang dapat diretry. Misalnya, tambahkan `x-envoy-retriable-header-names: X-Upstream-Retry,X-Try-Again` ke header permintaan.

Kondisi retry gRPC

Permintaan gRPC berbasis HTTP/2, sehingga Anda juga dapat menetapkan kondisi retry gRPC di field retryOn kebijakan retry permintaan HTTP. Tabel berikut menjelaskan kondisi retry permintaan gRPC umum.

Retry condition	Description
`cancelled`	Retry jika kode status gRPC dalam header respons layanan gRPC upstream adalah cancelled (1).
`unavailable`	Retry jika kode status gRPC dalam header respons layanan gRPC upstream adalah unavailable (14).
`deadline-exceeded`	Retry jika kode status gRPC dalam header respons layanan gRPC upstream adalah deadline-exceeded (4).
`internal`	Retry jika kode status gRPC dalam header respons layanan gRPC upstream adalah internal (13).
`resource-exhausted`	Retry jika kode status gRPC dalam header respons layanan gRPC upstream adalah resource-exhausted (8).

Konfigurasikan kebijakan retry permintaan HTTP default

Secara default, meskipun Anda tidak mendefinisikan kebijakan retry permintaan HTTP dalam virtual service, layanan dalam mesh tetap menerapkan kebijakan retry permintaan HTTP default saat mengakses layanan HTTP lain. Kebijakan retry default memiliki jumlah retry sebanyak 2, tanpa timeout retry, dan menggunakan connect-failure, refused-stream, unavailable, cancelled, dan retriable-status-codes sebagai kondisi retry defaultnya. Untuk mengganti kebijakan default ini untuk instans Anda, konfigurasikan kebijakan retry permintaan HTTP default pada halaman Basic Information di Konsol ASM.

Fitur ini memerlukan versi instans ASM yang didukung. Untuk detailnya, lihat Prerequisites.

Masuk ke ASM console. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi kiri, pilih ASM Instance > Base Information.
Pada halaman Basic Information, di bagian Config Info, klik Edit di samping Default HTTP retry policy.
Pada kotak dialog Default HTTP retry policy, konfigurasikan pengaturan yang dijelaskan dalam tabel berikut lalu klik OK.

Setelah Anda mengirimkan pengaturan, kebijakan retry permintaan HTTP baru akan menggantikan kebijakan retry default untuk layanan dalam mesh.

Configuration item	Description
Retries	Berkorespondensi dengan attempts di atas. Dalam kebijakan retry permintaan HTTP default, field ini dapat diatur ke 0, yang menonaktifkan retry permintaan HTTP secara default.
Timeout	Berkorespondensi dengan perTryTimeout di atas.
Retry On	Berkorespondensi dengan retryOn di atas.

Bulkhead

Cara kerja pola bulkhead

Pola bulkhead membatasi jumlah koneksi dan jumlah permintaan akses yang dapat dilakukan client ke layanan target, sehingga mencegah satu client saja membebani layanan tersebut. Jika ambang batas yang dikonfigurasi terlampaui, permintaan akan dibuang. Pola bulkhead membantu mengisolasi sumber daya yang digunakan oleh layanan dan mencegah kegagalan berantai.

Jumlah maksimum koneksi dan timeout koneksi adalah pengaturan koneksi umum yang berlaku untuk TCP dan HTTP, sedangkan jumlah maksimum permintaan per koneksi dan jumlah maksimum permintaan tertunda hanya berlaku untuk koneksi HTTP/1.1, HTTP/2, dan gRPC.

Bulkhead pattern

Konfigurasikan batas connection pool

ASM mendukung konfigurasi pola bulkhead menggunakan destination rule. Dalam destination rule berikut, permintaan dari layanan lain ke aplikasi httpbin dibatasi hingga satu koneksi TCP, satu permintaan per koneksi, dan satu permintaan tertunda. Permintaan yang melebihi ambang batas connection pool ini ditolak dengan respons 503. Proxy sidecar menunggu paling lama 10 detik untuk membuat koneksi ke host layanan.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
      tcp:
        connectTimeout: 10s
        maxConnections: 1

Field	Description
`http1MaxPendingRequests`	Jumlah maksimum permintaan tertunda. Hanya berlaku untuk koneksi HTTP/1.1, HTTP/2, dan gRPC.
`maxRequestsPerConnection`	Jumlah maksimum permintaan per koneksi. Hanya berlaku untuk koneksi HTTP/1.1, HTTP/2, dan gRPC.
`connectTimeout`	Timeout koneksi, yaitu waktu maksimum yang ditunggu proxy sidecar untuk membuat koneksi ke host layanan target. Berlaku untuk TCP dan HTTP.
`maxConnections`	Jumlah maksimum koneksi. Berlaku untuk TCP dan HTTP.

Circuit breaking

Bagian ini menjelaskan circuit breaking tingkat host, yang Anda konfigurasikan menggunakan destination rule. ASM juga menyediakan ASMCircuitBreaker, yang merupakan mekanisme circuit breaking berbeda. Dengan circuit breaking tingkat host, proxy sidecar pada client mendeteksi laju error setiap host layanan upstream secara individual, dan mengeluarkan host dari pool load balancing layanan tersebut ketika host tersebut menghasilkan error berturut-turut.

Cara kerja circuit breaking tingkat host

Circuit breaking berarti permintaan tidak dikirim berulang kali ke layanan yang tidak responsif. Sebagai gantinya, jumlah kegagalan yang terjadi dalam periode tertentu diamati.

Jika laju error melebihi ambang batas, pemutus sirkuit membuang permintaan dan semua permintaan berikutnya gagal hingga pemutus sirkuit ditutup kembali.

Circuit breaking

Konfigurasikan circuit breaking tingkat host

ASM mendukung konfigurasi circuit breaking tingkat host menggunakan destination rule. Dalam destination rule berikut, proxy sidecar memindai host aplikasi httpbin untuk ejection setiap 5 detik. Host yang menghasilkan tiga error berturut-turut dikeluarkan dari pool load balancing httpbin selama minimal 5 menit. Host yang tidak dieject tetap melayani permintaan dari layanan lain, dalam batas ejection yang ditetapkan oleh maxEjectionPercent. Untuk risiko nilai yang digunakan dalam contoh ini, lihat baris maxEjectionPercent dalam tabel berikut.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 3
      interval: 5s
      baseEjectionTime: 5m
      maxEjectionPercent: 100

Field	Description
`consecutiveErrors`	Jumlah error berturut-turut yang menyebabkan host dikeluarkan dari pool load balancing layanan.
`interval`	Interval waktu untuk deteksi ejection.
`baseEjectionTime`	Durasi ejection minimum.
`maxEjectionPercent`	Presentase maksimum host dalam pool load balancing yang boleh dieject. Penting Nilai 100 memungkinkan semua host layanan dieject secara bersamaan, sehingga tidak ada host yang tersisa untuk melayani permintaan.

Lihat metrik circuit breaking tingkat host

Circuit breaking tingkat host di ASM menghasilkan serangkaian metrik terkait yang membantu Anda menentukan apakah circuit breaking terjadi. Tabel berikut menjelaskan beberapa metrik tersebut.

Metric	Metric type	Description
`envoy_cluster_outlier_detection_ejections_active`	Gauge	Jumlah host yang saat ini dieject.
`envoy_cluster_outlier_detection_ejections_enforced_total`	Counter	Jumlah event ejection host yang terjadi.
`envoy_cluster_outlier_detection_ejections_overflow`	Counter	Jumlah kali ejection host dibatalkan karena presentase ejection maksimum terlampaui.
`ejections_detected_consecutive_5xx`	Counter	Jumlah kali host terdeteksi menghasilkan error 5xx berturut-turut.

Agar metrik ini tersedia, konfigurasikan pengaturan proxyStatsMatcher pada proxy sidecar agar proxy sidecar melaporkan metrik terkait, lalu gunakan Prometheus untuk mengumpulkan dan melihat metrik terkait circuit breaking. Lakukan langkah-langkah berikut secara berurutan:

Konfigurasikan proxy sidecar untuk melaporkan metrik circuit breaking menggunakan proxyStatsMatcher. Saat mengonfigurasi proxyStatsMatcher, pilih Regular Expression Match dan atur nilainya ke .*outlier_detection.*. Untuk informasi selengkapnya, lihat proxyStatsMatcher.
Redeploy workload stateless httpbin. Untuk informasi selengkapnya, lihat Redeploy a workload.

Konfigurasikan pengumpulan metrik dan peringatan circuit breaking tingkat host

Setelah Anda mengonfigurasi pelaporan metrik circuit breaking tingkat host, Anda dapat mengumpulkan metrik terkait ke Prometheus dan mengonfigurasi aturan peringatan berdasarkan metrik kunci, sehingga Anda segera diberi tahu saat circuit breaking terjadi. Langkah-langkah berikut menggunakan Managed Service for Prometheus untuk menjelaskan cara mengonfigurasi pengumpulan dan peringatan untuk metrik circuit breaking tingkat host.

Di Managed Service for Prometheus, integrasikan komponen Alibaba Cloud ASM untuk kluster bidang data atau upgrade ke versi terbaru, sehingga Managed Service for Prometheus dapat mengumpulkan metrik circuit breaking yang dipaparkan. Untuk informasi selengkapnya tentang cara memperbarui komponen integrasi, lihat Manage integration components. (Jika Anda telah mengonfigurasi instans Prometheus self-managed untuk mengumpulkan metrik service mesh dengan mengikuti Integrate a self-managed Prometheus for mesh monitoring, Anda tidak perlu melakukan langkah ini.)
Buat aturan peringatan untuk circuit breaking tingkat host. Untuk informasi selengkapnya, lihat Create a Prometheus alert rule by using a custom PromQL query. Tabel berikut memberikan contoh cara mengisi parameter kunci aturan peringatan. Anda dapat mengisi parameter lainnya sesuai kebutuhan dengan merujuk pada dokumen di atas.

Parameter	Example	Description
Custom PromQL query	`(sum (envoy_cluster_outlier_detection_ejections_active) by (cluster_name, namespace)) > 0`	Contoh ini mengkueri metrik `envoy_cluster_outlier_detection_ejections_active` untuk menentukan apakah ada host dalam kluster saat ini yang sedang dieject, dan mengelompokkan hasil kueri berdasarkan namespace layanan dan nama layanan.
Alert content	Host-level circuit breaking triggered. A workload produced consecutive errors and was ejected from the load balancing pool of the service. Namespace: {{$labels.namespace}}, service where the ejection occurred: {{$labels.cluster_name}}. Number of ejections: {{ $value }}	Pesan peringatan contoh ini menunjukkan namespace dan nama layanan yang memicu circuit breaking, serta jumlah ejection saat ini untuk layanan tersebut.