Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memecahkan masalah kesalahan server internal di Amazon DynamoDB
Di DynamoDB, kesalahan server internal (500 kesalahan) menunjukkan bahwa layanan tidak dapat melayani permintaan. Kesalahan ini dapat terjadi karena berbagai alasan, seperti masalah jaringan sementara di armada, masalah infrastruktur, masalah terkait simpul penyimpanan, dan banyak lagi.
Anda mungkin mengalami beberapa kesalahan server internal selama siklus hidup tabel DynamoDB Anda. Hal ini diharapkan karena sifat layanan yang terdistribusi dan biasanya tidak perlu dikhawatirkan. DynamoDB secara otomatis memperbaiki dan menyembuhkan masalah sementara dengan layanan secara real time, tanpa memerlukan intervensi apa pun dari Anda. Namun, jika Anda mengamati jumlah kesalahan server internal yang tinggi secara konsisten pada permintaan ke tabel Anda (seperti yang terlihat dalam SystemErrors metrik), Anda harus menyelidiki lebih lanjut.
Topik
Menyelidiki kesalahan server internal
Jika Anda mengalami kesalahan server internal di tabel DynamoDB Anda, pertimbangkan opsi ini:
Periksa Dasbor AWS Kesehatan.
Untuk mengidentifikasi masalah, langkah pertama adalah memeriksa Dasbor Kesehatan AWS Layanan
dan Dasbor Kesehatan AWS Akun Anda. Dasbor ini memberikan informasi berharga tentang masalah di seluruh layanan, tabel yang terkena dampak, masalah yang sedang berlangsung, dan akar penyebab setelah masalah diselesaikan. Meninjau detail di dasbor ini akan memberi Anda pemahaman yang lebih baik tentang status saat ini yang Layanan AWS Anda gunakan dan masalah potensial apa pun yang memengaruhi akun Anda. Informasi ini dapat membantu Anda menentukan langkah selanjutnya untuk mengatasi masalah dan meminimalkan gangguan pada operasi Anda.
Jangkau ke Dukungan.
Jika Anda mengamati kesalahan yang berkepanjangan dan berkelanjutan dalam permintaan Anda, itu mungkin mengindikasikan masalah dengan layanan. Sebagai aturan umum, jika Anda melihat tingkat kegagalan keseluruhan 1% atau lebih selama 15 menit terakhir, ini adalah waktu yang tepat untuk meningkatkan masalah ke tim AWS Dukungan. Lihat, Perjanjian Tingkat Layanan DynamoDB
untuk mempelajari selengkapnya. Saat membuka kasus dengan tim AWS Dukungan, berikan detail berikut untuk membantu mempercepat proses pemecahan masalah:
-
DDB yang terkena dampak; tabel atau indeks sekunder
-
Jendela waktu ketika kesalahan diamati
-
ID permintaan DynamoDB, seperti
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, yang dapat Anda temukan di log aplikasi Anda.
Memasukkan detail ini dalam kasus dukungan akan membantu AWS tim memahami masalah dan memberikan resolusi yang lebih cepat. Jika Anda tidak memiliki ID permintaan, Anda masih harus mencatat kasus dengan detail lain yang tersedia.
-
Meminimalkan dampak dari kesalahan server internal
Jika kesalahan server internal terjadi saat menggunakan DynamoDB, minimalkan dampaknya pada aplikasi Anda, pertimbangkan praktik terbaik berikut:
-
Gunakan backoff dan percobaan ulang — Perilaku SDK default DynamoDB dirancang untuk menemukan keseimbangan yang tepat untuk sebagian besar aplikasi dalam hal strategi back-off dan coba lagi. Namun, Anda dapat menyesuaikan pengaturan ini berdasarkan toleransi aplikasi Anda terhadap waktu henti dan persyaratan kinerja. Pelajari selengkapnya tentang penundaan dan percobaan ulang untuk memahami cara menyempurnakan setelan coba ulang ini.
-
Gunakan pembacaan yang akhirnya konsisten — Jika aplikasi Anda tidak memerlukan pembacaan yang sangat konsisten, pertimbangkan untuk menggunakan bacaan yang akhirnya konsisten. Pembacaan ini berbiaya lebih rendah dan cenderung tidak mengalami masalah sementara karena kesalahan server internal karena akan dilayani dari salah satu Node Penyimpanan yang tersedia. Untuk informasi selengkapnya, lihat Konsistensi baca DynamoDB.
Meningkatkan kesadaran operasional
Menjaga ketersediaan dan keandalan aplikasi Anda yang tinggi sangat penting dalam lanskap digital saat ini. Salah satu aspek kunci dari ini adalah secara proaktif memantau kesalahan server internal (ISE) di tabel DynamoDB Anda dan indeks sekunder global (GSI). Dengan membuat CloudWatch alarm untuk memantau kesalahan ini, Anda dapat memperoleh kesadaran operasional yang lebih baik dan waspada terhadap potensi masalah sebelum berdampak pada pengguna akhir Anda. Pendekatan ini sejalan dengan pilar Operational Excellence AWS Well-Architected Framework, memastikan beban kerja DynamoDB Anda dioptimalkan untuk kinerja, keamanan, dan keandalan.
Membuat CloudWatch alarm
Anda harus mengatur CloudWatch alarm pada tabel DynamoDB Anda untuk menerima pemberitahuan untuk jumlah kesalahan server internal yang tinggi secara konsisten alih-alih mengamati metrik secara manual. Ini terkait dengan pilar keunggulan operasional Well-Architected kerangka kerja untuk setiap beban kerja AWS. Lihat Menggunakan DynamoDB Well-Architected Lens untuk mengoptimalkan beban kerja DynamoDB Anda untuk mempelajari lebih lanjut tentang tabel DynamoDB Well-Architecting Anda.
Saat Anda membuat alarm pada SystemErrors metrik, tentukan Operation dimensi TableName dan (atau TableName dan GlobalSecondaryIndexName untuk indeks sekunder global). DynamoDB memancarkan SystemErrors per operasi, tidak meny TableName ala sendiri, jadi alarm yang menentukan hanya TableName tetap dalam INSUFFICIENT_DATA status dan tidak pernah memperingatkan.
