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 node penyimpanan, dan banyak lagi.
Anda mungkin mengalami beberapa kesalahan server internal selama siklus hidup tabel DynamoDB Anda. Hal ini diharapkan karena sifat layanan yang didistribusikan dan biasanya tidak perlu dikhawatirkan. DynamoDB secara otomatis memperbaiki dan menyembuhkan masalah sementara dengan layanan secara real time, tanpa memerlukan intervensi 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 AWS Service Health Dashboard dan Dashboard
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 potensi masalah apa pun yang memengaruhi akun Anda. Informasi ini dapat membantu Anda menentukan langkah selanjutnya untuk mengatasi masalah dan meminimalkan gangguan pada operasi Anda.
Jangkau Dukungan.
Jika Anda melihat kesalahan yang berkepanjangan dan berkelanjutan dalam permintaan Anda, itu mungkin menunjukkan 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 Support. Lihat, Perjanjian Tingkat Layanan DynamoDB
untuk mempelajari lebih lanjut. Saat membuka kasus dengan tim AWS Support, 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,
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJGseperti, yang dapat Anda temukan di log aplikasi Anda.
Menyertakan detail ini dalam kasus dukungan akan membantu AWS tim memahami masalah dan memberikan resolusi yang lebih cepat. Jika Anda tidak memiliki ID permintaan, Anda harus tetap mencatat kasus dengan detail lain yang tersedia.
-
Meminimalkan dampak dari kesalahan server internal
Jika kesalahan server internal terjadi saat menggunakan DynamoDB, meminimalkan 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 lebih lanjut tentang back-off dan percobaan ulang untuk memahami bagaimana Anda dapat menyempurnakan pengaturan coba ulang ini.
-
Gunakan pembacaan yang konsisten pada akhirnya — Jika aplikasi Anda tidak memerlukan pembacaan yang sangat konsisten, pertimbangkan untuk menggunakan pembacaan yang konsisten pada akhirnya. Pembacaan ini berbiaya lebih rendah dan kecil kemungkinannya untuk mengalami masalah sementara karena kesalahan server internal karena akan disajikan dari salah satu Node Penyimpanan yang tersedia. Untuk informasi selengkapnya, lihat Konsistensi baca DynamoDB.
Meningkatkan kesadaran operasional
Mempertahankan ketersediaan tinggi dan keandalan aplikasi Anda sangat penting dalam lanskap digital saat ini. Salah satu aspek kunci dari ini adalah secara proaktif memantau kesalahan server internal (ISES) 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 diberi tahu tentang potensi masalah sebelum berdampak pada pengguna akhir Anda. Pendekatan ini sejalan dengan pilar Operational Excellence dari 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 AWS kerja. Lihat Menggunakan DynamoDB Lens untuk mengoptimalkan Well-Architected beban kerja DynamoDB untuk mempelajari lebih lanjut tentang tabel DynamoDB Well-Architecting Anda.
Saat Anda membuat alarm pada SystemErrors metrik, tentukan Operation dimensi TableName dan dimensi (atau TableName dan GlobalSecondaryIndexName untuk indeks sekunder global). DynamoDB SystemErrors memancarkan per operasi, tidak TableName menyala sendiri, jadi alarm yang menentukan TableName hanya tetap dalam INSUFFICIENT_DATA status dan tidak pernah memberi peringatan.
