Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Observabilitas multi-AZ
Untuk dapat mengevakuasi Availability Zone selama peristiwa yang diisolasi ke Availability Zone tunggal, pertama-tama Anda harus dapat mendeteksi bahwa kegagalan tersebut, pada kenyataannya, diisolasi ke satu Availability Zone. Ini membutuhkan visibilitas kesetiaan tinggi tentang bagaimana sistem berperilaku di setiap Availability Zone. Banyak AWS layanan menyediakan out-of-the-box metrik yang memberikan wawasan operasional tentang sumber daya Anda. Misalnya, Amazon EC2 menyediakan banyak metrik seperti CPU pemanfaatan, membaca dan menulis disk, dan lalu lintas jaringan masuk dan keluar.
Namun, saat Anda membangun beban kerja yang menggunakan layanan ini, Anda memerlukan lebih banyak visibilitas daripada hanya metrik standar tersebut. Anda ingin visibilitas ke dalam pengalaman pelanggan yang disediakan oleh beban kerja Anda. Selain itu, metrik Anda harus disejajarkan dengan Availability Zone tempat metrik tersebut diproduksi. Ini adalah wawasan yang Anda butuhkan untuk mendeteksi kegagalan abu-abu yang dapat diamati secara berbeda. Tingkat visibilitas itu membutuhkan instrumentasi.
Instrumentasi membutuhkan penulisan kode eksplisit. Kode ini harus melakukan hal-hal seperti mencatat berapa lama tugas berlangsung, menghitung berapa banyak item yang berhasil atau gagal, mengumpulkan metadata tentang permintaan, dan sebagainya. Anda juga perlu menentukan ambang batas sebelumnya untuk menentukan apa yang dianggap normal dan apa yang tidak. Anda harus menguraikan tujuan dan ambang batas keparahan yang berbeda untuk latensi, ketersediaan, dan jumlah kesalahan dalam beban kerja Anda. Artikel Perpustakaan Pembangun Amazon [Instrumentasi sistem terdistribusi untuk visibilitas operasional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) menyediakan sejumlah praktik terbaik.
Metrik harus dihasilkan dari sisi server maupun sisi klien. Praktik terbaik untuk menghasilkan metrik sisi klien dan memahami pengalaman pelanggan adalah menggunakan [kenari](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), perangkat lunak yang secara teratur memeriksa beban kerja Anda dan mencatat metrik.
Selain menghasilkan metrik ini, Anda juga perlu memahami konteksnya. Salah satu cara untuk melakukannya adalah dengan menggunakan [dimensi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Dimensi memberi metrik identitas unik, dan membantu menjelaskan apa yang dikatakan metrik kepada Anda. [Untuk metrik yang digunakan untuk mengidentifikasi kegagalan dalam beban kerja Anda (misalnya, latensi, ketersediaan, atau jumlah kesalahan), Anda perlu menggunakan dimensi yang sejajar dengan batas isolasi kesalahan Anda.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
Misalnya, jika Anda menjalankan layanan web di satu Wilayah, di beberapa Availability Zone, menggunakan kerangka web [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC), Anda harus menggunakan `Region` [https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html),`Controller`,`Action`,, dan `InstanceId` sebagai dimensi untuk kumpulan dimensi Anda (jika Anda menggunakan layanan mikro, Anda mungkin menggunakan nama dan HTTP metode layanan alih-alih nama pengontrol dan tindakan). Ini karena Anda mengharapkan berbagai jenis kegagalan diisolasi oleh batas-batas ini. Anda tidak akan mengharapkan bug dalam kode layanan web Anda yang memengaruhi kemampuannya untuk membuat daftar produk untuk juga memengaruhi halaman beranda. Demikian pula, Anda tidak akan mengharapkan EBS volume penuh pada satu EC2 instance untuk memengaruhi EC2 instance lain dari menyajikan konten web Anda. Dimensi ID Availability Zone adalah hal yang memungkinkan Anda mengidentifikasi dampak terkait Availability Zone secara konsisten. Akun AWS Anda dapat menemukan ID Availability Zone di beban kerja Anda dengan berbagai cara. Lihat [Lampiran A — Mendapatkan ID Availability Zone](appendix-a-getting-the-availability-zone-id.md) untuk beberapa contoh.
Meskipun dokumen ini terutama menggunakan Amazon EC2 sebagai sumber daya komputasi dalam contoh, `InstanceId` dapat diganti dengan ID penampung untuk [Amazon Elastic Container Service (Amazon](https://aws.amazon.com/ecs/)ECS) dan [Amazon Elastic Kubernetes Service EKS (Amazon](https://aws.amazon.com/eks/)) menghitung sumber daya sebagai komponen dimensi Anda.
Kenari Anda juga dapat menggunakan`Controller`,, `Action``AZ-ID`, dan `Region` sebagai dimensi dalam metriknya jika Anda memiliki titik akhir zona untuk beban kerja Anda. Dalam hal ini, sejajarkan kenari Anda untuk berjalan di Availability Zone yang sedang mereka uji. Ini memastikan bahwa jika peristiwa Availability Zone yang terisolasi memengaruhi Availability Zone tempat kenari Anda berjalan, itu tidak merekam metrik yang membuat Availability Zone berbeda yang sedang diuji tampak tidak sehat. [Misalnya, kenari Anda dapat menguji setiap titik akhir zona untuk layanan di belakang Network Load Balancer () atau Application Load Balancer NLB () menggunakan nama zonalnyaALB. DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Diagram yang menunjukkan kenari yang berjalan pada CloudWatch Synthetics atau fungsi AWS Lambda yang menguji setiap titik akhir zona NLB\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
Dengan menghasilkan metrik dengan dimensi ini, Anda dapat membuat [ CloudWatch alarm Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) yang memberi tahu Anda saat perubahan ketersediaan atau latensi terjadi dalam batas-batas tersebut. Anda juga dapat dengan cepat menganalisis data tersebut menggunakan [dasbor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Untuk menggunakan metrik dan log secara efisien, Amazon CloudWatch menawarkan [format metrik tertanam](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) yang memungkinkan Anda menyematkan metrik kustom dengan data log. CloudWatchsecara otomatis mengekstrak metrik kustom sehingga Anda dapat memvisualisasikan dan alarm pada mereka. AWS menyediakan beberapa [pustaka klien](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) untuk berbagai bahasa pemrograman yang membuatnya mudah untuk memulaiEMF. Mereka dapat digunakan dengan AmazonEC2, AmazonECS, Amazon EKS [AWS Lambda](https://aws.amazon.com/lambda/), dan lingkungan lokal. Dengan metrik yang disematkan ke dalam log, Anda juga dapat menggunakan [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) untuk membuat grafik deret waktu yang menampilkan data kontributor. Dalam skenario ini, kita dapat menampilkan data yang dikelompokkan berdasarkan dimensi seperti `AZ-ID``InstanceId`,, atau `Controller` serta bidang lain di log seperti `SuccessLatency` atau`HttpResponseCode`.
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
Log ini memiliki tiga set dimensi. Mereka berkembang dalam urutan perincian, dari instance ke Availability Zone ke Region (`Controller`dan selalu `Action` disertakan dalam contoh ini). Mereka mendukung pembuatan alarm di seluruh beban kerja Anda yang menunjukkan kapan ada dampak pada tindakan pengontrol tertentu dalam satu instance, dalam satu Availability Zone, atau dalam keseluruhan. Wilayah AWS Dimensi ini digunakan untuk menghitung metrik HTTP respons 2xx, 3xx, 4xx, dan 5xx, serta latensi untuk metrik permintaan yang berhasil (jika permintaan gagal, itu juga akan merekam metrik untuk latensi permintaan yang gagal). Log juga mencatat informasi lain seperti HTTP jalur, IP sumber pemohon, dan apakah permintaan ini memerlukan cache lokal untuk di-refresh. Titik data ini kemudian dapat digunakan untuk menghitung ketersediaan dan latensi dari setiap beban kerja API yang disediakan.
**Catatan tentang penggunaan kode HTTP respons untuk metrik ketersediaan**
Biasanya, Anda dapat menganggap respons 2xx dan 3xx berhasil, dan 5xx sebagai kegagalan. Kode respons 4xx jatuh di suatu tempat di tengah. Biasanya, mereka diproduksi karena kesalahan klien. Mungkin parameter berada di luar jangkauan yang mengarah ke [respons 400](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), atau mereka meminta sesuatu yang tidak ada, menghasilkan respons 404. Anda tidak akan menghitung tanggapan ini terhadap ketersediaan beban kerja Anda. Namun, ini juga bisa menjadi hasil dari bug dalam perangkat lunak.
Misalnya, jika Anda telah memperkenalkan validasi masukan yang lebih ketat yang menolak permintaan yang akan berhasil sebelumnya, respons 400 mungkin dihitung sebagai penurunan ketersediaan. Atau mungkin Anda membatasi pelanggan dan mengembalikan respons 429. Sementara membatasi pelanggan melindungi layanan Anda untuk mempertahankan ketersediaannya, dari perspektif pelanggan, layanan tidak tersedia untuk memproses permintaan mereka. Anda harus memutuskan apakah kode respons 4xx adalah bagian dari perhitungan ketersediaan Anda atau tidak.
Meskipun bagian ini telah menguraikan penggunaan CloudWatch sebagai cara untuk mengumpulkan dan menganalisis metrik, itu bukan satu-satunya solusi yang dapat Anda gunakan. Anda dapat memilih untuk juga mengirim metrik ke Amazon Managed Service untuk Prometheus dan Amazon Managed Grafana, tabel Amazon DynamoDB, atau menggunakan solusi pemantauan pihak ketiga. Kuncinya adalah metrik yang dihasilkan oleh beban kerja Anda harus berisi konteks tentang batas isolasi kesalahan beban kerja Anda.
Dengan beban kerja yang menghasilkan metrik dengan dimensi yang disejajarkan dengan batas isolasi kesalahan, Anda dapat membuat observabilitas yang mendeteksi kegagalan terisolasi Availability Zone. Bagian berikut menjelaskan tiga pendekatan gratis untuk mendeteksi kegagalan yang timbul dari penurunan satu Availability Zone.
**Topics**
+ [Deteksi kegagalan dengan CloudWatch alarm komposit](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Deteksi kegagalan menggunakan deteksi outlier](failure-detection-using-outlier-detection.md)
+ [Deteksi kegagalan sumber daya zona instance tunggal](failure-detection-of-single-instance-zonal-resources.md)
+ [Ringkasan](summary.md)
# Deteksi kegagalan dengan CloudWatch alarm komposit
Dalam CloudWatch metrik, setiap set dimensi adalah metrik unik, dan Anda dapat membuat CloudWatch alarm pada masing-masing metrik. Anda kemudian dapat membuat [alarm CloudWatch komposit Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) untuk menggabungkan metrik ini.
Untuk mendeteksi dampak secara akurat, contoh-contoh dalam paper ini akan menggunakan dua struktur CloudWatch alarm yang berbeda untuk setiap dimensi yang disetel alarm. Setiap alarm akan menggunakan **Periode** satu menit, yang berarti metrik dievaluasi sekali per menit. Pendekatan pertama akan menggunakan tiga titik data pelanggaran berturut-turut dengan menetapkan **Periode Evaluasi** dan Titik Data **ke Alarm menjadi tiga, yang berarti dampak** total tiga menit. Pendekatan kedua akan menggunakan “M out of N” ketika ada 3 titik data dalam jendela lima menit yang dilanggar dengan mengatur **Periode Evaluasi** menjadi lima dan **Datapoint** ke Alarm menjadi tiga. Ini memberikan kemampuan untuk mendeteksi sinyal konstan, serta sinyal yang berfluktuasi dalam waktu singkat. Durasi waktu dan jumlah titik data yang terkandung di sini adalah saran, gunakan nilai yang masuk akal untuk beban kerja Anda.
## Mendeteksi dampak dalam satu Availability Zone
Dengan menggunakan konstruksi ini, pertimbangkan beban kerja yang menggunakan`Controller`,,, `Action` `InstanceId``AZ-ID`, dan `Region` sebagai dimensi. Beban kerja memiliki dua pengontrol, Produk dan Rumah, dan satu tindakan per pengontrol, Daftar dan Indeks masing-masing. Ini beroperasi di tiga Availability Zone di `us-east-1` Wilayah. Anda akan membuat dua alarm untuk ketersediaan untuk masing-masing `Controller` dan `Action` kombinasi di setiap Availability Zone serta dua alarm untuk latensi untuk masing-masing. Kemudian, Anda dapat memilih untuk membuat alarm komposit untuk ketersediaan untuk masing-masing `Controller` dan `Action` kombinasi. Terakhir, Anda membuat alarm komposit yang menggabungkan semua alarm ketersediaan untuk Availability Zone. Ini ditunjukkan pada gambar berikut untuk Availability Zone tunggal,`use1-az1`, menggunakan alarm komposit opsional untuk masing-masing `Controller` dan `Action` kombinasi (alarm serupa akan ada untuk `use1-az2` dan `use1-az3` Availability Zones juga, tetapi tidak ditampilkan untuk kesederhanaan).
![\[Diagram yang menunjukkan struktur alarm komposit untuk ketersediaan di use1-az1\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
Anda juga akan membangun struktur alarm serupa untuk latensi juga, yang ditunjukkan pada gambar berikutnya.
![\[Diagram yang menunjukkan struktur alarm Komposit untuk latensi di use1-az1\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Untuk sisa angka di bagian ini, hanya alarm `az1-availability` dan `az1-latency` komposit yang akan ditampilkan di tingkat atas. Alarm komposit ini, `az1-availability` dan`az1-latency`, akan memberi tahu Anda jika ketersediaan turun di bawah atau latensi naik di atas ambang batas yang ditentukan di Zona Ketersediaan tertentu untuk bagian mana pun dari beban kerja Anda. Anda mungkin juga ingin mempertimbangkan untuk mengukur throughput untuk mendeteksi dampak yang mencegah beban kerja Anda di satu Availability Zone menerima pekerjaan. Anda dapat mengintegrasikan alarm yang dihasilkan dari metrik yang dipancarkan oleh kenari Anda ke dalam alarm komposit ini juga. Dengan begitu, jika sisi server atau sisi klien melihat dampak ketersediaan atau latensi, alarm akan membuat peringatan.
## Pastikan dampaknya tidak Regional
Satu set alarm komposit lainnya dapat digunakan untuk memastikan bahwa hanya peristiwa Availability Zone yang terisolasi yang menyebabkan alarm diaktifkan. Ini dilakukan dengan memastikan bahwa alarm komposit Availability Zone berada dalam `ALARM` status sementara alarm komposit untuk Availability Zone lainnya berada dalam `OK` status. Ini akan menghasilkan satu alarm komposit per Availability Zone yang Anda gunakan. Contoh ditunjukkan pada gambar berikut (ingat bahwa ada alarm untuk latensi dan ketersediaan di `use1-az2` dan`use1-az3`,,,`az2-latency`, dan `az2-availability` `az3-latency``az3-availability`, yang tidak digambarkan untuk kesederhanaan).
![\[Diagram yang menunjukkan struktur alarm komposit untuk mendeteksi dampak yang diisolasi ke satu AZ\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Pastikan dampaknya tidak disebabkan oleh satu contoh
Satu instance (atau sebagian kecil dari keseluruhan armada Anda) dapat menyebabkan dampak yang tidak proporsional terhadap ketersediaan dan metrik latensi yang dapat membuat seluruh Availability Zone tampak terpengaruh, padahal sebenarnya tidak. Lebih cepat dan sama efektifnya untuk menghapus satu instance bermasalah daripada mengevakuasi Availability Zone.
Instans dan kontainer biasanya diperlakukan sebagai sumber daya sementara, sering diganti dengan layanan seperti. [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) Sulit untuk membuat CloudWatch alarm baru setiap kali instance baru dibuat (tetapi tentu saja mungkin menggunakan kait [siklus hidup [Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) atau Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). Sebagai gantinya, Anda dapat menggunakan [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) untuk mengidentifikasi jumlah kontributor terhadap ketersediaan dan metrik latensi.
Sebagai contoh, untuk aplikasi HTTP web, Anda dapat membuat aturan untuk mengidentifikasi kontributor teratas untuk HTTP tanggapan 5xx di setiap Availability Zone. Ini akan mengidentifikasi instance mana yang berkontribusi terhadap penurunan ketersediaan (metrik ketersediaan kami yang ditentukan di atas didorong oleh adanya kesalahan 5xx). Dengan menggunakan contoh EMF log, buat aturan menggunakan kunci dari`InstanceId`. Kemudian, filter log berdasarkan `HttpResponseCode` bidang. Contoh ini adalah aturan untuk `use1-az1` Availability Zone.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch Alarm dapat dibuat berdasarkan aturan-aturan ini juga. Anda dapat membuat alarm berdasarkan aturan Contributor Insights menggunakan [matematika metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dan `INSIGHT_RULE_METRIC` fungsi dengan metrik. `UniqueContributors` Anda juga dapat membuat aturan Contributor Insights tambahan dengan CloudWatch alarm untuk metrik seperti latensi atau jumlah kesalahan selain yang tersedia. Alarm ini dapat digunakan dengan alarm komposit dampak Zona Ketersediaan yang terisolasi untuk memastikan bahwa satu instans tidak mengaktifkan alarm. Metrik untuk aturan wawasan `use1-az1` mungkin terlihat seperti berikut:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Anda dapat menentukan alarm ketika metrik ini lebih besar dari ambang batas; untuk contoh ini, dua. Ini diaktifkan ketika kontributor unik untuk respons 5xx melampaui ambang batas itu, menunjukkan dampaknya berasal dari lebih dari dua contoh. Alasan alarm ini menggunakan perbandingan yang lebih besar daripada kurang adalah untuk memastikan bahwa nilai nol untuk kontributor unik tidak memicu alarm. Ini memberi tahu Anda bahwa dampaknya *bukan* dari satu contoh. Sesuaikan ambang batas ini untuk beban kerja pribadi Anda. Panduan umum adalah membuat angka ini 5% atau lebih dari total sumber daya di Availability Zone. Lebih dari 5% sumber daya Anda yang terpengaruh menunjukkan signifikansi statistik, mengingat ukuran sampel yang cukup.
## Menyatukan semuanya
Gambar berikut menunjukkan struktur alarm komposit lengkap untuk Availability Zone tunggal:
![\[Diagram yang menunjukkan struktur alarm komposit lengkap untuk menentukan dampak Single-AZ\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
Alarm komposit terakhir`use1-az1-isolated-impact`,, diaktifkan ketika alarm komposit yang menunjukkan dampak Zona Ketersediaan terisolasi dari latensi atau ketersediaan`use1-az1-aggregate-alarm`,, dalam `ALARM` keadaan dan saat alarm berdasarkan aturan Wawasan Kontributor untuk Zona Ketersediaan yang sama`not-single-instance-use1-az1`,, juga dalam `ALARM` keadaan (artinya dampaknya lebih dari satu instance). Anda akan membuat tumpukan alarm ini untuk setiap Availability Zone yang digunakan oleh beban kerja Anda.
Anda dapat melampirkan peringatan [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) ke alarm terakhir ini. Semua alarm sebelumnya dikonfigurasi tanpa tindakan. Peringatan dapat memberi tahu operator melalui email untuk memulai penyelidikan manual. Itu juga bisa memulai otomatisasi untuk mengevakuasi Availability Zone. Namun, kata hati-hati dalam membangun otomatisasi untuk menanggapi peringatan ini. Setelah evakuasi Availability Zone terjadi, hasilnya adalah bahwa tingkat kesalahan yang meningkat dikurangi dan alarm kembali ke keadaan. `OK` Jika dampak terjadi di Availability Zone lain, ada kemungkinan bahwa otomatisasi dapat mengevakuasi Availability Zone kedua atau ketiga, berpotensi menghapus semua kapasitas beban kerja yang tersedia. Otomatisasi harus memeriksa untuk melihat apakah evakuasi telah dilakukan sebelum mengambil tindakan apa pun. Anda mungkin juga perlu menskalakan sumber daya di Availability Zone lainnya sebelum evakuasi berhasil.
Saat Anda menambahkan pengontrol atau tindakan baru ke aplikasi MVC web Anda, atau layanan mikro baru, atau secara umum, fungsionalitas tambahan apa pun yang ingin Anda pantau secara terpisah, Anda hanya perlu memodifikasi beberapa alarm dalam pengaturan ini. Anda akan membuat alarm ketersediaan dan latensi baru untuk fungsionalitas baru itu dan kemudian menambahkannya ke ketersediaan selaras Availability Zone dan alarm komposit latensi, `az1-latency` dan `az1-availability` dalam contoh yang telah kami gunakan di sini. Alarm komposit yang tersisa tetap statis setelah dikonfigurasi. Ini membuat orientasi fungsionalitas baru dengan pendekatan ini menjadi proses yang lebih sederhana.
# Deteksi kegagalan menggunakan deteksi outlier
Satu celah dengan pendekatan sebelumnya dapat muncul ketika Anda melihat tingkat kesalahan yang meningkat di beberapa Availability Zone yang terjadi karena alasan yang *tidak berkorelasi*. Bayangkan sebuah skenario di mana Anda memiliki EC2 instance yang diterapkan di tiga Availability Zone dan ambang batas alarm ketersediaan Anda adalah 99%. Kemudian, kerusakan Availability Zone tunggal terjadi, mengisolasi banyak instance dan menyebabkan ketersediaan di zona tersebut turun menjadi 55%. Pada saat yang sama, tetapi di Availability Zone yang berbeda, satu EC2 instance menghabiskan semua penyimpanan pada EBS volumenya, dan tidak dapat lagi menulis file log. Ini menyebabkannya mulai mengembalikan kesalahan, tetapi masih melewati pemeriksaan kesehatan penyeimbang beban karena itu tidak memicu file log untuk ditulis. Hal ini mengakibatkan ketersediaan turun menjadi 98% di Availability Zone tersebut. Dalam hal ini, alarm dampak Availability Zone tunggal Anda tidak akan aktif karena Anda melihat dampak ketersediaan di beberapa Availability Zone. Namun, Anda masih bisa mengurangi hampir semua dampak dengan mengevakuasi Zona Ketersediaan yang terganggu.
Di beberapa jenis beban kerja, Anda mungkin mengalami kesalahan secara konsisten di semua Availability Zone yang metrik ketersediaan sebelumnya mungkin tidak berguna. Ambil AWS Lambda contoh. AWS memungkinkan pelanggan untuk membuat kode mereka sendiri untuk dijalankan dalam fungsi Lambda. Untuk menggunakan layanan ini, Anda harus mengunggah kode Anda dalam ZIP file, termasuk dependensi, dan menentukan titik masuk ke fungsi tersebut. Tetapi kadang-kadang pelanggan mendapatkan bagian ini salah, misalnya, mereka mungkin lupa ketergantungan kritis dalam ZIP file, atau salah ketik nama metode dalam definisi fungsi Lambda. Hal ini menyebabkan fungsi gagal untuk dipanggil dan menghasilkan kesalahan. AWS Lambda melihat kesalahan semacam ini sepanjang waktu, tetapi itu tidak menunjukkan bahwa ada sesuatu yang tidak sehat. Namun, sesuatu seperti kerusakan Availability Zone juga dapat menyebabkan kesalahan ini muncul.
Untuk menemukan sinyal dalam jenis noise ini, Anda dapat menggunakan deteksi outlier untuk menentukan apakah ada kemiringan yang signifikan secara statistik dalam jumlah kesalahan di antara Availability Zones. Meskipun kami melihat kesalahan di beberapa Availability Zone, jika benar-benar ada kegagalan di salah satunya, kami berharap untuk melihat tingkat kesalahan yang jauh lebih tinggi di Availability Zone tersebut dibandingkan dengan yang lain, atau berpotensi jauh lebih rendah. Tapi seberapa tinggi atau lebih rendah?
Salah satu cara untuk melakukan analisis ini adalah dengan menggunakan uji [chi-kuadrat](https://en.wikipedia.org/wiki/Chi-squared_test) (*χ* 2) untuk mendeteksi perbedaan yang signifikan secara statistik dalam tingkat kesalahan antara Availability Zones (ada [banyak algoritma berbeda untuk](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html) melakukan deteksi outlier). Mari kita lihat bagaimana tes chi-kuadrat bekerja.
Tes chi-kuadrat mengevaluasi probabilitas bahwa beberapa distribusi hasil mungkin terjadi. Dalam hal ini, kami tertarik pada distribusi kesalahan di beberapa set yang ditentukanAZs. Untuk contoh ini, untuk mempermudah matematika, pertimbangkan empat Availability Zones.
Pertama, buat *hipotesis nol*, yang mendefinisikan apa yang Anda yakini sebagai hasil default. Dalam pengujian ini, hipotesis nol adalah bahwa Anda mengharapkan kesalahan didistribusikan secara merata di setiap Availability Zone. Kemudian, hasilkan *hipotesis alternatif*, yaitu bahwa kesalahan tidak terdistribusi secara merata yang menunjukkan penurunan Zona Ketersediaan. Sekarang Anda dapat menguji hipotesis ini menggunakan data dari metrik Anda. Untuk tujuan ini, Anda akan mengambil sampel metrik Anda dari jendela lima menit. Misalkan Anda mendapatkan 1000 titik data yang diterbitkan di jendela itu, di mana Anda melihat 100 kesalahan total. Anda berharap bahwa dengan distribusi genap kesalahan akan terjadi 25% dari waktu di masing-masing dari empat Availability Zone. Asumsikan tabel berikut menunjukkan apa yang Anda harapkan dibandingkan dengan apa yang sebenarnya Anda lihat.
*Tabel 1: Kesalahan yang diharapkan versus aktual terlihat*
| AZ | Expected | Aktual |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Jadi, Anda melihat bahwa distribusi pada kenyataannya tidak genap. Namun, Anda mungkin percaya bahwa ini terjadi karena beberapa tingkat keacakan dalam titik data yang Anda sampel. Ada beberapa tingkat probabilitas bahwa jenis distribusi ini dapat terjadi dalam set sampel dan masih berasumsi bahwa hipotesis nol benar. Ini mengarah pada pertanyaan berikut: Berapa probabilitas mendapatkan hasil setidaknya ekstrem ini? Jika probabilitas itu di bawah ambang batas yang ditentukan, Anda menolak hipotesis nol. Agar [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), probabilitas ini harus 5% atau kurang. 1
1 Craparo, Robert M. (2007). “Tingkat signifikansi”. Dalam Salkind, Neil J. Ensiklopedia Pengukuran dan Statistik 3. Thousand Oaks, CA: SAGE Publikasi. hal.889—891. ISBN1-412-91611-9.
Bagaimana Anda menghitung probabilitas hasil ini? Anda menggunakan statistik *χ 2* yang memberikan distribusi yang dipelajari dengan sangat baik dan dapat digunakan untuk menentukan probabilitas mendapatkan hasil yang ekstrem atau lebih ekstrem ini menggunakan rumus ini.
![\[Rumus untuk Ei, Oi, dan X 2\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
Sebagai contoh kami, ini menghasilkan:
![\[Rumus untuk Ei, Oi, dan X 2 menggunakan contoh kita, menghasilkan jawaban 6.\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Jadi, apa `6` artinya dalam hal probabilitas kita? Anda perlu melihat distribusi chi-kuadrat dengan tingkat kebebasan yang sesuai. Gambar berikut menunjukkan beberapa distribusi chi-kuadrat untuk tingkat kebebasan yang berbeda.
![\[Grafik yang menunjukkan distribusi chi-kuadrat untuk derajat kebebasan yang berbeda\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
Tingkat kebebasan dihitung sebagai satu kurang dari jumlah pilihan dalam tes. Dalam hal ini, karena ada empat Availability Zone, tingkat kebebasannya adalah tiga. Kemudian, Anda ingin mengetahui luas di bawah kurva (integral) untuk *x ≥ 6* pada plot *k = 3*. Anda juga dapat menggunakan tabel pra-perhitungan dengan nilai yang umum digunakan untuk memperkirakan nilai tersebut.
*Tabel 2: Nilai kritis Chi-kuadrat*
| Derajat kebebasan | Probabilitas kurang dari nilai kritis | | **0,75** | **0,90** | **0,95** | **0,99** | **0,999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1.323 | 2.706 | 3.841 | 6.635 | 10.828 |
| 2 | 2.773 | 4.605 | 5.991 | 9.210 | 13.816 |
| 3 | 4.108 | 6.251 | 7.815 | 11.345 | 16.266 |
| 4 | 5.385 | 7.779 | 9.488 | 13.277 | 18.467 |
Untuk tiga derajat kebebasan, nilai chi-kuadrat enam jatuh di antara kolom probabilitas 0,75 dan 0,9. Apa artinya ini adalah ada kemungkinan lebih besar dari 10% dari distribusi ini terjadi, yang tidak kurang dari ambang batas 5%. Oleh karena itu, Anda menerima *hipotesis nol* dan menentukan *tidak* ada perbedaan yang signifikan secara statistik dalam tingkat kesalahan di antara Availability Zones.
Melakukan tes statistik chi-kuadrat tidak didukung secara native dalam matematika CloudWatch metrik, jadi Anda perlu mengumpulkan metrik kesalahan yang berlaku dari CloudWatch dan menjalankan pengujian di lingkungan komputasi seperti Lambda. Anda dapat memutuskan untuk melakukan tes ini pada sesuatu seperti MVC Controller/Action atau tingkat layanan mikro individu, atau di tingkat Availability Zone. Anda harus mempertimbangkan apakah penurunan Availability Zone akan memengaruhi setiap Controller/Action atau microservice secara setara, atau apakah sesuatu seperti DNS kegagalan dapat menyebabkan dampak pada layanan throughput rendah dan bukan pada layanan throughput tinggi, yang dapat menutupi dampak saat digabungkan. Dalam kedua kasus, pilih dimensi yang sesuai untuk membuat kueri. Tingkat granularitas juga akan memengaruhi CloudWatch alarm yang dihasilkan yang Anda buat.
Kumpulkan metrik hitungan kesalahan untuk setiap AZ dan Controller/Action di jendela waktu yang ditentukan. Pertama, hitung hasil uji chi-kuadrat sebagai benar (ada kemiringan yang signifikan secara statistik) atau salah (tidak ada, yaitu hipotesis nol berlaku). Jika hasilnya salah, publikasikan titik data 0 ke aliran metrik Anda untuk hasil chi-kuadrat untuk setiap Availability Zone. Jika hasilnya benar, publikasikan 1 titik data untuk Availability Zone dengan kesalahan terjauh dari nilai yang diharapkan dan 0 untuk yang lain (lihat [Lampiran B - Contoh perhitungan chi-kuadrat](appendix-b-example-chi-squared-calculation.md) untuk kode contoh yang dapat digunakan dalam fungsi Lambda). Anda dapat mengikuti pendekatan yang sama seperti alarm ketersediaan sebelumnya dengan menggunakan membuat alarm CloudWatch metrik 3 berturut-turut dan alarm CloudWatch metrik 3 dari 5 berdasarkan titik data yang dihasilkan oleh fungsi Lambda. Seperti pada contoh sebelumnya, pendekatan ini dapat dimodifikasi untuk menggunakan lebih banyak atau lebih sedikit titik data dalam jendela yang lebih pendek atau lebih panjang.
Kemudian, tambahkan alarm ini ke alarm ketersediaan Availability Zone yang ada untuk kombinasi Controller dan Action, yang ditunjukkan pada gambar berikut.
![\[Diagram yang menunjukkan integrasi uji statistik chi-kuadrat dengan alarm komposit\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Seperti disebutkan sebelumnya, saat Anda memasukkan fungsionalitas baru di beban kerja Anda, Anda hanya perlu membuat alarm CloudWatch metrik yang sesuai yang khusus untuk fungsionalitas baru tersebut dan memperbarui tingkat berikutnya dalam hierarki alarm komposit untuk menyertakan alarm tersebut. Sisa struktur alarm tetap statis.
# Deteksi kegagalan sumber daya zona instance tunggal
Dalam beberapa kasus, Anda mungkin memiliki satu instance aktif dari sumber daya zona, paling umum sistem yang memerlukan komponen penulis tunggal seperti database relasional (seperti AmazonRDS) atau cache terdistribusi (seperti [Amazon ElastiCache (OSSRedis](https://aws.amazon.com/elasticache/redis/))). Jika satu kerusakan Availability Zone memengaruhi Availability Zone tempat sumber daya utama berada, hal itu dapat berdampak pada setiap Availability Zone yang mengakses sumber daya tersebut. Hal ini dapat menyebabkan ambang batas ketersediaan dilintasi di setiap Availability Zone, yang berarti pendekatan pertama tidak akan mengidentifikasi dengan benar sumber dampak Availability Zone tunggal. Selain itu, Anda mungkin akan melihat tingkat kesalahan serupa di setiap Availability Zone, yang berarti analisis outlier juga tidak akan mendeteksi masalah. Artinya, Anda perlu menerapkan observabilitas tambahan untuk mendeteksi skenario ini secara khusus.
Kemungkinan sumber daya yang Anda khawatirkan akan menghasilkan metriknya sendiri tentang kesehatannya, tetapi selama penurunan Zona Ketersediaan, sumber daya tersebut mungkin tidak dapat memberikan metrik tersebut. Dalam skenario ini, Anda harus membuat atau memperbarui alarm untuk mengetahui kapan Anda *terbang buta*. Jika ada metrik penting yang sudah Anda pantau dan alarm aktif, Anda dapat mengonfigurasi alarm untuk memperlakukan [data yang hilang](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) sebagai pelanggaran. Ini akan membantu Anda mengetahui apakah sumber daya berhenti melaporkan data, dan dapat dimasukkan dalam hal yang sama *dalam satu baris* dan *m dari n* alarm yang digunakan sebelumnya.
Mungkin juga dalam beberapa metrik yang menunjukkan kesehatan sumber daya yang menerbitkan titik data bernilai nol ketika tidak ada aktivitas. Jika gangguan mencegah interaksi dengan sumber daya, Anda tidak dapat menggunakan pendekatan data yang hilang untuk jenis metrik ini. Anda juga mungkin tidak ingin khawatir nilainya nol, karena mungkin ada skenario yang sah di mana itu berada dalam ambang batas normal. Pendekatan terbaik untuk mendeteksi jenis masalah ini adalah dengan metrik yang dihasilkan oleh sumber daya menggunakan ketergantungan ini. Dalam hal ini kami ingin mendeteksi dampak di *beberapa* Availability Zone menggunakan alarm komposit. Alarm ini harus menggunakan beberapa kategori metrik penting yang terkait dengan sumber daya. Beberapa contoh tercantum di bawah ini:
+ **Throughput** — Tingkat unit kerja yang masuk. Ini bisa berupa transaksi, membaca, menulis, dan sebagainya.
+ **Ketersediaan** — Ukur jumlah unit kerja yang berhasil vs gagal.
+ **Latensi** — Ukur beberapa persentil latensi untuk pekerjaan yang berhasil dilakukan di seluruh operasi kritis.
Sekali lagi, Anda dapat membuat alarm metrik *dalam baris* dan *m dari n* untuk setiap metrik di setiap kategori metrik yang ingin Anda ukur. Seperti sebelumnya, ini dapat digabungkan menjadi alarm komposit untuk menentukan bahwa sumber daya bersama ini adalah sumber dampak di seluruh Availability Zone. Anda ingin dapat mengidentifikasi dampak ke lebih dari satu Availability Zone dengan alarm komposit, tetapi dampaknya tidak harus *semua* Availability Zone. Struktur alarm komposit tingkat tinggi untuk pendekatan semacam ini ditunjukkan pada gambar berikut.
![\[Diagram yang menunjukkan contoh pembuatan alarm untuk mendeteksi dampak ke beberapa Availability Zone yang disebabkan oleh satu sumber daya\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Anda akan melihat bahwa diagram ini kurang preskriptif tentang jenis alarm metrik apa yang harus digunakan dan hierarki alarm komposit. Ini karena menemukan masalah semacam ini bisa sulit dan akan membutuhkan perhatian yang cermat terhadap sinyal yang tepat untuk sumber daya bersama. Sinyal-sinyal tersebut mungkin juga perlu dievaluasi dengan cara tertentu.
Selain itu, Anda harus memperhatikan bahwa `primary-database-impact` alarm tidak terkait dengan Availability Zone tertentu. Hal ini karena instance database utama dapat ditemukan di Availability Zone yang dikonfigurasi untuk digunakan, dan tidak ada CloudWatch metrik yang menentukan di mana itu berada. Ketika Anda melihat alarm ini diaktifkan, Anda harus menggunakannya sebagai sinyal bahwa mungkin ada masalah dengan sumber daya dan memulai failover ke Availability Zone lain, jika belum dilakukan secara otomatis. Setelah memindahkan sumber daya ke Availability Zone lain, Anda dapat menunggu dan melihat apakah alarm Availability Zone terisolasi diaktifkan, atau Anda dapat memilih untuk memanggil rencana evakuasi Availability Zone terlebih dahulu.
# Ringkasan
Bagian ini menjelaskan tiga pendekatan untuk membantu mengidentifikasi gangguan Availability Zone tunggal. Setiap pendekatan harus digunakan bersama untuk memberikan pandangan holistik tentang kesehatan beban kerja Anda.
Pendekatan alarm CloudWatch komposit memungkinkan Anda menemukan masalah di mana kemiringan ketersediaan tidak signifikan secara statistik, katakanlah ketersediaan 98% (Zona Ketersediaan yang terganggu), 100%, dan 99,99%, yang tidak disebabkan oleh satu sumber daya bersama.
Deteksi outlier akan membantu mendeteksi gangguan Availability Zone tunggal di mana Anda memiliki kesalahan tidak berkorelasi yang terjadi di beberapa Availability Zone yang semuanya melampaui ambang alarm Anda.
Terakhir, mengidentifikasi degradasi sumber daya zona instance tunggal membantu mengetahui kapan gangguan Availability Zone memengaruhi sumber daya yang dibagikan di seluruh Availability Zone.
Alarm yang dihasilkan dari masing-masing pola ini dapat digabungkan menjadi hierarki alarm CloudWatch komposit untuk mengetahui kapan gangguan Zona Ketersediaan tunggal terjadi dan berdampak pada ketersediaan atau latensi beban kerja Anda.