View a markdown version of this page

Amazon DynamoDB の内部サーバーエラーのトラブルシューティング - Amazon DynamoDB
内部サーバーエラーの調査内部サーバーエラーの影響を最小限に抑える運用意識の向上

Amazon DynamoDB の内部サーバーエラーのトラブルシューティング

DynamoDB の場合、内部サーバーエラー (500 エラー) は、サービスがリクエストを処理できないことを示します。これらのエラーは、フリート内の一時的なネットワーク問題、インフラストラクチャの問題、ストレージノード関連の問題など、さまざまな理由で発生する場合があります。

内部サーバーエラーは、DynamoDB テーブルのライフサイクル中に発生する場合があります。これはサービスの分散性が原因であると予想されるため、通常、懸念の原因とはならないはずです。DynamoDB は、ユーザーの介入を必要とせずに、サービスの一時的な問題をリアルタイムで自動的に修復します。ただし、テーブルへのリクエストで内部サーバーエラーが (SystemErrors メトリクスに示されるように) 一貫して多く発生する場合は、さらに調査する必要があります。

内部サーバーエラーの調査

DynamoDB テーブルで内部サーバーエラーが発生した場合は、以下のオプションを検討してください。

  1. AWS Health Dashboard を確認します。

    問題を特定するには、最初のステップとして、AWS Service Health Dashboard と AWS Account Health Dashboard を確認します。これらのダッシュボードには、サービス全体の問題、影響を受けたテーブル、進行中の問題、問題解決後の根本原因に関する貴重な情報が表示されます。

    これらのダッシュボードの詳細を確認すると、使用している AWS のサービスの現在のステータスと、アカウントに影響している可能性がある問題をよりよく理解できます。これらの情報は、問題に対処するための次のステップを決定したり、運用の中断を最小限に抑えたりするのに役立ちます。

  2. に問い合わせます。サポート

    リクエストでのエラーが長く続く場合は、サービスに問題がある可能性があります。一般的に、直近の 15 分間に全体的な障害率が 1% 以上に達した場合は、問題を AWS サポートチームにエスカレーションするのが適切な対応です。詳細については、「DynamoDB サービスレベルアグリーメント」を参照してください。

    AWS サポートチームへのケースを開くときは、トラブルシューティングプロセスを迅速化するために、以下の詳細を入力します。

    • 影響を受けている DDB、テーブル、またはセカンダリインデックス

    • エラーが観察された時間枠

    • 4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG などの DynamoDB リクエスト ID (アプリケーションログで確認できます)

    これらの詳細をサポートケースに含めると、AWS チームが問題を理解し、より迅速に解決できるようになります。リクエスト ID がない場合でも、他の利用可能な詳細でケースを記録する必要があります。

内部サーバーエラーの影響を最小限に抑える

DynamoDB の使用時に内部サーバーエラーが発生した場合は、これらがアプリケーションに与える影響を最小限に抑え、以下のベストプラクティスを検討してください。

  • バックオフと再試行を使用する: DynamoDB のデフォルトの SDK 動作は、バックオフと再試行戦略の観点から、ほとんどのアプリケーションに適したバランスを見つけるように設計されています。ただし、ダウンタイムとパフォーマンス要件に対するアプリケーションの許容度に基づいて、これらの設定を調整できます。バックオフと再試行の詳細を確認して、これらの再試行設定を微調整する方法を理解します。

  • 結果整合性のある読み込みを使用する: アプリケーションに強力な整合性のある読み込みが必要ない場合は、結果整合性のある読み込みを使用することを検討します。これらの読み込みは、使用可能なストレージノードのいずれかで処理されるため、コストが低く、内部サーバーエラーによる一時的な問題が発生する可能性が低くなります。詳細については、「DynamoDB の読み取り整合性」を参照してください。

運用意識の向上

今日のデジタル環境ではアプリケーションの高可用性と信頼性を維持することが不可欠です。この場合、重要な側面の 1 つは、DynamoDB テーブルの内部サーバーエラー (ISE) とグローバルセカンダリインデックス (GSI) をプロアクティブにモニタリングすることです。これらのエラーをモニタリングする CloudWatch アラームを作成することで、運用意識を高め、潜在的な問題がエンドユーザーに影響を与える前にアラートを受け取ることができます。このアプローチは、AWS Well-Architected フレームワークの運用上の優秀性の柱と一致し、DynamoDB ワークロードをパフォーマンス、セキュリティ、信頼性に向けて最適化します。

CloudWatch アラームの作成

内部サーバーエラーの発生数が一貫して高い場合は、メトリクスを手動で監視するのではなく、DynamoDB テーブルに CloudWatch アラームを設定して通知を受け取るようにする必要があります。これは、AWS のあらゆるワークロードに対する Well-Architected フレームワークの運用上の優秀性の柱と一貫します。DynamoDB テーブルの優れた設計の詳細については、「DynamoDB の Well-Architected レンズを使用して DynamoDB ワークロードを最適化する」を参照してください。

SystemErrors メトリクスでアラームを作成するときは、TableName および Operation ディメンション (グローバルセカンダリインデックスの場合は TableName および GlobalSecondaryIndexName) の両方を指定します。DynamoDB は TableName 単独ではなくオペレーションごとに SystemErrors を出力するため、TableName のみを指定するアラームは INSUFFICIENT_DATA 状態のままになり、アラートを出力しません。