Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik App Mesh
**penting**
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak akan lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Untuk mencapai tujuan nol permintaan yang gagal selama penerapan yang direncanakan dan selama kehilangan beberapa host yang tidak direncanakan, praktik terbaik dalam topik ini menerapkan strategi berikut:
+ Tingkatkan kemungkinan permintaan akan berhasil dari perspektif aplikasi dengan menggunakan strategi coba ulang default yang aman. Untuk informasi selengkapnya, lihat [Instrumen semua rute dengan percobaan ulang](#route-retries).
+ Tingkatkan kemungkinan permintaan yang dicoba ulang berhasil dengan memaksimalkan kemungkinan permintaan yang dicoba ulang dikirim ke tujuan yang sebenarnya. Lihat informasi selengkapnya di [Sesuaikan kecepatan penyebaran](#reduce-deployment-velocity), [Skalakan sebelum skala di](#scale-out), dan [Melaksanakan pemeriksaan kesehatan kontainer](#health-checks).
Untuk mengurangi atau menghilangkan kegagalan secara signifikan, kami sarankan Anda menerapkan rekomendasi dalam semua praktik berikut.
## Instrumen semua rute dengan percobaan ulang
Konfigurasikan semua layanan virtual untuk menggunakan router virtual dan tetapkan kebijakan coba ulang default untuk semua rute. Ini akan mengurangi permintaan yang gagal dengan memilih ulang host dan mengirim permintaan baru. Untuk kebijakan coba lagi, kami merekomendasikan nilai minimal dua untuk`maxRetries`, dan menentukan opsi berikut untuk setiap jenis peristiwa coba lagi di setiap jenis rute yang mendukung jenis peristiwa coba lagi:
+ **TCP** — `connection-error`
+ **HTTP dan HTTP/2** — dan `stream-error` `gateway-error`
+ **gRPC** — dan `cancelled` `unavailable`
Peristiwa coba lagi lainnya perlu dipertimbangkan karena case-by-case mungkin tidak aman, seperti jika permintaan tidak idempoten. Anda perlu mempertimbangkan dan menguji nilai untuk `maxRetries` dan `perRetryTimeout` yang membuat trade off yang tepat antara latensi maksimum permintaan (`maxRetries`\$1`perRetryTimeout`) versus tingkat keberhasilan yang meningkat dari lebih banyak percobaan ulang. Selain itu, ketika Envoy mencoba untuk terhubung ke titik akhir yang tidak lagi ada, Anda harus mengharapkan permintaan itu untuk mengkonsumsi penuh. `perRetryTimeout` Untuk mengonfigurasi kebijakan coba lagi, lihat [Membuat rute](routes.md#create-route) lalu pilih protokol yang ingin Anda rutekan.
**catatan**
Jika Anda menerapkan rute pada atau setelah 29 Juli 2020 dan tidak menentukan kebijakan coba lagi, App Mesh mungkin telah secara otomatis membuat kebijakan coba ulang default yang serupa dengan kebijakan sebelumnya untuk setiap rute yang Anda buat pada atau setelah 29 Juli 2020. Untuk informasi selengkapnya, lihat [Kebijakan coba lagi rute default](envoy-defaults.md#default-retry-policy).
## Sesuaikan kecepatan penyebaran
Saat menggunakan penerapan bergulir, kurangi kecepatan penyebaran secara keseluruhan. Secara default, Amazon ECS mengonfigurasi strategi penyebaran minimal 100 persen tugas sehat dan 200 persen total tugas. Pada penerapan, ini menghasilkan dua titik penyimpangan tinggi:
+ Ukuran armada tugas baru 100 persen mungkin terlihat oleh Utusan sebelum siap untuk menyelesaikan permintaan (lihat [Melaksanakan pemeriksaan kesehatan kontainer](#health-checks) untuk mitigasi).
+ Ukuran armada 100 persen dari tugas-tugas lama mungkin terlihat oleh Utusan saat tugas sedang dihentikan.
Ketika dikonfigurasi dengan batasan penerapan ini, orkestra kontainer dapat memasuki status di mana mereka secara bersamaan menyembunyikan semua tujuan lama dan membuat semua tujuan baru terlihat. Karena jalur data Utusan Anda pada akhirnya konsisten, ini dapat menghasilkan periode di mana kumpulan tujuan yang terlihat di jalur data Anda telah menyimpang dari sudut pandang orkestrator. Untuk mengurangi ini, kami sarankan mempertahankan minimal 100 persen tugas sehat, tetapi menurunkan total tugas menjadi 125 persen. Ini akan mengurangi divergensi dan meningkatkan keandalan percobaan ulang. Kami merekomendasikan pengaturan berikut untuk runtime kontainer yang berbeda:
**Amazon ECS**
Jika layanan Anda memiliki hitungan dua atau tiga yang diinginkan, atur `maximumPercent` ke 150 persen. Jika tidak, atur `maximumPercent` ke 125 persen.
**Kubernetes**
Konfigurasikan penerapan Anda`update strategy`, setel `maxUnavailable` ke 0 persen dan `maxSurge` hingga 25 persen. [Untuk informasi selengkapnya tentang penerapan, lihat dokumentasi Penerapan Kubernetes.](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
## Skalakan sebelum skala di
Scale out dan scale in keduanya dapat menghasilkan beberapa kemungkinan permintaan gagal dalam percobaan ulang. Meskipun ada rekomendasi tugas yang mengurangi skala, satu-satunya rekomendasi untuk skala adalah meminimalkan persentase tugas yang diskalakan pada satu waktu. Sebaiknya gunakan strategi penerapan yang mengukur tugas Amazon ECS baru atau penerapan Kubernetes sebelum melakukan penskalaan pada tugas atau penerapan lama. Strategi penskalaan ini menjaga persentase penskalaan tugas atau penerapan Anda lebih rendah, sambil mempertahankan kecepatan yang sama. Praktik ini berlaku untuk tugas Amazon ECS dan penerapan Kubernetes.
## Melaksanakan pemeriksaan kesehatan kontainer
Dalam skenario peningkatan skala, kontainer dalam tugas Amazon ECS mungkin rusak dan mungkin pada awalnya tidak responsif. Kami merekomendasikan saran berikut untuk runtime kontainer yang berbeda:
**Amazon ECS**
Untuk mengurangi hal ini, sebaiknya gunakan pemeriksaan kesehatan kontainer dan pemesanan ketergantungan kontainer untuk memastikan bahwa Utusan berjalan dan sehat sebelum kontainer apa pun yang memerlukan konektivitas jaringan keluar dimulai. Untuk mengonfigurasi wadah aplikasi dan wadah Envoy dengan benar dalam definisi tugas, lihat Ketergantungan [kontainer](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency).
**Kubernetes**
[Tidak ada, karena probe [keaktifan dan kesiapan](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) Kubernetes tidak dipertimbangkan dalam registrasi dan de-registrasi instance di AWS Cloud Map pengontrol App Mesh untuk Kubernetes.](https://github.com/aws/aws-app-mesh-controller-for-k8s) Untuk informasi selengkapnya, lihat GitHub edisi [\$1132](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132).
## Optimalkan resolusi DNS
Jika Anda menggunakan DNS untuk penemuan layanan, penting untuk memilih protokol IP yang sesuai untuk mengoptimalkan resolusi DNS saat mengonfigurasi jerat Anda. App Mesh mendukung keduanya `IPv4` dan`IPv6`, dan pilihan Anda dapat memengaruhi kinerja dan kompatibilitas layanan Anda. Jika infrastruktur Anda tidak mendukung`IPv6`, kami sarankan Anda menentukan setelan IP yang selaras dengan infrastruktur Anda daripada mengandalkan perilaku default`IPv6_PREFERRED`. `IPv6_PREFERRED`Perilaku default dapat menurunkan kinerja layanan.
+ **IPv6\$1PREFERRED** — Ini adalah pengaturan default. Utusan melakukan pencarian DNS untuk IPv6 alamat terlebih dahulu dan kembali ke `IPv4` jika tidak ada `IPv6` alamat yang ditemukan. Ini bermanfaat jika infrastruktur Anda terutama mendukung `IPv6` tetapi membutuhkan `IPv4` kompatibilitas.
+ **IPv4\$1PREFERRED** — Utusan pertama mencari `IPv4` alamat dan kembali ke `IPv6` jika tidak ada `IPv4` alamat yang tersedia. Gunakan pengaturan ini jika infrastruktur Anda terutama mendukung `IPv4` tetapi memiliki beberapa `IPv6` kompatibilitas.
+ **IPv6\$1ONLY** — Pilih opsi ini jika layanan Anda secara eksklusif mendukung `IPv6` lalu lintas. Utusan hanya melakukan pencarian DNS untuk `IPv6` alamat, memastikan semua lalu lintas dialihkan. `IPv6`
+ **IPv4\$1ONLY** — Pilih pengaturan ini jika layanan Anda secara eksklusif mendukung `IPv4` lalu lintas. Utusan hanya melakukan pencarian DNS untuk `IPv4` alamat, memastikan semua lalu lintas dialihkan. `IPv4`
Anda dapat mengatur preferensi versi IP pada level mesh dan tingkat node virtual, dengan pengaturan node virtual mengesampingkan yang ada di level mesh.
Untuk informasi selengkapnya, lihat [Service Meshes](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html) dan [Virtual Nodes](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html).