DynamoDB の場合、内部サーバーエラー (500 エラー) は、サービスがリクエストを処理できないことを示します。これらのエラーは、フリート内の一時的なネットワーク問題、インフラストラクチャの問題、ストレージノード関連の問題など、さまざまな理由で発生する場合があります。
内部サーバーエラーは、DynamoDB テーブルのライフサイクル中に発生する場合があります。これはサービスの分散性が原因であると予想されるため、通常、懸念の原因とはならないはずです。DynamoDB は、ユーザーの介入を必要とせずに、サービスの一時的な問題をリアルタイムで自動的に修復します。ただし、テーブルへのリクエストで内部サーバーエラーが (SystemErrors メトリクスに示されるように) 一貫して多く発生する場合は、さらに調査する必要があります。
内部サーバーエラーの調査
DynamoDB テーブルで内部サーバーエラーが発生した場合は、以下のオプションを検討してください。
AWS Health Dashboard を確認します。
問題を特定するには、最初のステップとして、AWS Service Health Dashboard
と AWS Account Health Dashboard を確認します。これらのダッシュボードには、サービス全体の問題、影響を受けたテーブル、進行中の問題、問題解決後の根本原因に関する貴重な情報が表示されます。 これらのダッシュボードの詳細を確認すると、使用している AWS のサービスの現在のステータスと、アカウントに影響している可能性がある問題をよりよく理解できます。これらの情報は、問題に対処するための次のステップを決定したり、運用の中断を最小限に抑えたりするのに役立ちます。
サポートに問い合わせます。
リクエストでのエラーが長く続く場合は、サービスに問題がある可能性があります。一般的に、直近の 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 ワークロードを最適化する」を参照してください。
これらのアラームは、カスタムメトリクス計算を使用して、5 分間のウィンドウで失敗したリクエストの割合を計算します。推奨されるベストプラクティスは、3 つの連続したデータポイントが 1% のしきい値を超えたときに ALARM 状態に入るようにアラームを設定することです。これは、リクエスト全体の 1% が 15 分以内に失敗することを意味します。
次のサンプルの AWS CloudFormation テンプレートは、テーブルに CloudWatch アラームと GSI を作成するのに役立ちます。
AWSTemplateFormatVersion: "2010-09-09"
Description: Sample template for monitoring DynamoDB
Parameters:
DynamoDBProvisionedTableName:
Description: Name of DynamoDB Provisioned Table to create
Type: String
MinLength: 3
MaxLength: 255
ConstraintDescription : https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-naming-rules
DynamoDBSNSEmail:
Description : Email Address subscribed to newly created SNS Topic
Type: String
AllowedPattern: "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$"
MinLength: 1
MaxLength: 255
Resources:
DynamoDBMonitoringSNSTopic:
Type: AWS::SNS::Topic
Properties:
DisplayName: DynamoDB Monitoring SNS Topic
Subscription:
- Endpoint: !Ref DynamoDBSNSEmail
Protocol: email
TopicName: dynamodb-monitoring
DynamoDBTableSystemErrorAlarm:
Type: 'AWS::CloudWatch::Alarm'
Properties:
AlarmName: 'DynamoDBTableSystemErrorAlarm'
AlarmDescription: 'Alarm when system errors exceed 1% of total number of requests for 15 minutes'
AlarmActions:
- !Ref DynamoDBMonitoringSNSTopic
Metrics:
- Id: 'e1'
Expression: 'm1/(m1+m2+m3)'
Label: SystemErrorsOverTotalRequests
- Id: 'm1'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'SystemErrors'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm2'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedReadCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm3'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedWriteCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
EvaluationPeriods: 3
Threshold: 1.0
ComparisonOperator: 'GreaterThanThreshold'
DynamoDBGSISystemErrorAlarm:
Type: 'AWS::CloudWatch::Alarm'
Properties:
AlarmName: 'DynamoDBGSISystemErrorAlarm'
AlarmDescription: 'Alarm when GSI system errors exceed 2% of total number of requests for 15 minutes'
AlarmActions:
- !Ref DynamoDBMonitoringSNSTopic
Metrics:
- Id: 'e1'
Expression: 'm1/(m1+m2+m3)'
Label: GSISystemErrorsOverTotalRequests
- Id: 'm1'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'SystemErrors'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm2'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedReadCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm3'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedWriteCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
EvaluationPeriods: 3
Threshold: 1.0
ComparisonOperator: 'GreaterThanThreshold'