運用上の認識を高めるための Amazon DynamoDB のモニタリング

Amazon DynamoDB はサーバーレスデータベースです。このサービスは、この分散システムの背後にあるインフラストラクチャの運用と保守に関連する、未分化の困難な作業を扱います。お客様は、API を使用して、テーブルのモニタリングと操作に使用できる操作データをキャプチャします。この記事では、DynamoDB を運用するためにダッシュボードとアラームを構築する際に考慮する一連のメトリクスについて説明します。

DynamoDB によって公開された Amazon CloudWatch メトリクスを使用すると、データモデルのコンテキストで進化するワークロードと DynamoDB の相互作用を理解するのに役立ちます。メトリクスは、適用されるリソースレベルに基づいて、次の 3 つのカテゴリーに分類されます。

DynamoDB で箱から出してすぐに使用できるメトリクス (「箱から出してすぐに」と注記)。
メトリクス計算によるコンピューティングを必要とするメトリクス (「メトリクス計算が必要」と注記)。
カスタム AWS Lambda 関数を使用して Amazon CloudWatch に自己公開する必要があるメトリクス。

本番環境に移行すると、DynamoDB で運用の卓越性を実現するための推奨事項も取得できます。

この例で必要なカスタムメトリクスを公開するコードをダウンロードするには、「GitHub リポジトリ」を参照してください。カスタム CloudWatch メトリクスを公開するための Lambda 関数は、デフォルト設定をオーバーライドするための多くの環境変数を受け入れます。詳細については、README を確認してください。この記事の公開時点で、環境変数は次のとおりです。

CLOUDWATCH_CUSTOM_NAMESPACE – デフォルトでは、AWS Lambda 関数は「Custom_DynamoDB」名前空間にメトリクスを公開します。変更する場合は、CLOUDWATCH_CUSTOM_NAMESPACE 環境変数を設定します
DYNAMODB_ACCOUNT_TABLE_LIMIT – デフォルトでは、AWS Lambda 関数は DynamoDB アカウントテーブルの制限が 256 であると想定します。アカウントテーブルの制限を決定する API 呼び出しはないため、AWS にアカウントのこの制限を増やすように依頼した場合は、DYNAMODB_ACCOUNT_TABLE_LIMIT を AWS Lambda 関数の値に設定して AccountTableLimitPct カスタムメトリクスを適切に計算します。

この記事の AWS CloudFormation の例は、通知を送信するアラーム用に DynamoDBMonitoringSNSTopic と呼ばれる SNS トピックが存在し、テンプレートに DynamoDBProvisionedTableName、DynamoDBOnDemandTableName、DynamoDBGlobalTableName、および DynamoDBGlobalTableReceivingRegion などのパラメータが含まれていることを前提としています。さらに、グローバルセカンダリインデックス (GSI) の名前はテーブルと同じですが、-gsi1 が追加されています。たとえば、dynamodb-monitoring-gsi1 があります。

各セクションで提供されるアラームしきい値は、合理的な開始点の推奨事項であり、要件とワークロードパターンに基づいて調整できます。

各アカウントとリージョンのメトリクス

アカウント内の AWS リージョンごとに、モニタリングする必要があるアカウントレベルのメトリクスがいくつかあります。複数のチームが DynamoDB テーブルを同じアカウントにデプロイしている場合、これらは特に重要です。1 つのチームの変更は、たとえば、別のチームのテーブルの Auto Scaling 機能に影響を与え、アカウント管理者はアカウントの制限を引き上げるためにアクションを実行する必要がある場合があります。次のテーブルは、DynamoDB メトリクスと、AWS アカウントの各リージョンの推奨されるアラーム設定をまとめたものです。

説明	メトリクス	アラーム設定	注意
割り当てられたアカウント制限読み取りプロビジョニング済みキャパシティの割合	`AccountProvisionedReadCapacityUtilization`	MAX > 80%	箱から出してすぐ
割り当てられたアカウント制限書き込みプロビジョニング済みキャパシティの割合	`AccountProvisionedWriteCapacityUtilization`	MAX > 80%	箱から出してすぐ
アカウントの最も高い読み取りプロビジョニングされたテーブルによって使用される、読み取りプロビジョニングされたキャパシティの割合	`MaxProvisionedTableReadCapacityUtilization`	MAX > 80%	箱から出してすぐ
アカウントの最も高い書き込みプロビジョニングされたテーブルで使用される、読み取りプロビジョニングされたキャパシティの割合	`MaxProvisionedTableWriteCapacityUtilization`	MAX > 80%	箱から出してすぐ
使用中のテーブルカウント制限の割合	`AccountTableLimitPct`	> 80%	カスタム AWS Lambda 関数が必要

次のコードは、上記のテーブルの最初のメトリクス用の AWS CloudFormation テンプレートの例であり、他のメトリクス用に変更できます。

  DynamoDBAccountReadCapAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBAccountReadCapAlarm'
      AlarmDescription: 'Alarm when account approaches maximum read capacity limit'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Namespace: 'AWS/DynamoDB'
      MetricName: 'AccountProvisionedReadCapacityUtilization'
      Statistic: 'Maximum'
      Threshold: 80
      ComparisonOperator: 'GreaterThanThreshold'
      Period: 300
      EvaluationPeriods: 1

DynamoDB コンソールを使用してアラームを作成するには、次の手順を実行します。

DynamoDB コンソールで、[テーブル] を選択します。
テーブル内で、次のように選択します
[アラームの作成] を選択します。

次のスクリーンショットは、[アラームの作成] セクションを示しています。詳細については、「CloudWatch アラームを作成して DynamoDB をモニタリングする」を参照してください。

DynamoDB Cloudwatch Alarm スクリーンショットの作成

各テーブルと GSI のメトリクス

一部のメトリクスでは、すべてのテーブルと GSI のモニタリングとアラートが必要です。たとえば、継続的に重度のスロットリングが発生する場合、スキーマの設計上の問題、Auto Scaling のないテーブルの構成ミス、またはAuto Scaling 制限の設定が低すぎることを示している場合があります。このような問題には、介入が必要な場合があり、また問題を解決するには AWS の設定またはアプリケーションコードを変更する必要がある場合もあります。Amazon CloudWatch Contributor Insights for DynamoDB は、頻繁にアクセスするアイテムが持続的なスロットリングを引き起こしているかどうかを調べるのに役立ちます。

次の表は、課金モードに関係なく、各 DynamoDB テーブルと GSI の DynamoDB メトリクスと推奨されるアラーム設定をまとめたものです。

説明	メトリクス	アラーム設定	注意
持続的な読み取りスロットル	`サンプル数 ReadThrottleEvents / (サンプル数 ConsumedReadCapacityUnits)`	> 2%	メトリクス計算が必要
持続的な書き込みスロットル	`サンプルカウント書き込み ThrottleEvents / (サンプルカウント ConsumedWriteCapacityUnits)`	> 2%	メトリクス計算が必要
システムエラーの持続的かつ大幅な上昇	`サンプルカウント SystemErrors / (サンプルカウント ConsumedReadCapacityUnits +サンプルカウント ConsumedWriteCapacityUnits)`	> 2%	メトリクス計算が必要
ユーザーエラーの持続的かつ大幅な上昇	`サンプルカウント UserErrors / (サンプルカウント ConsumedReadCapacityUnits +サンプルカウント ConsumedWriteCapacityUnits)`	> 2%	メトリクス計算が必要
状態チェックエラーの持続的かつ大幅な上昇 (オプション)	`ConditionalCheckFailedRequests`	SUM > 100	箱から出してすぐ
トランザクションの競合の持続的かつ大幅な上昇 (オプション)	`TransactionConflict`	SUM > 100	箱から出してすぐ

次のコードは、上記の表の最初のメトリクス用の AWS CloudFormation テンプレートの例で、他のメトリクス用に変更できます。この例では、GSI ディメンションの動作を示すために、ベーステーブルの代わりに GSI の読み取りスロットルでメトリクス計算とアラームを使用します。範囲 [0、100] の合計読み取りイベントに対してスロットルされたイベントの比率をスケーリングするために、コードは 100 で乗算します。

  DynamoDBGSIReadThrottlingAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBGSIReadThrottlingAlarm'
      AlarmDescription: 'Alarm when GSI read throttle requests exceed 2% of total number of read requests'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Metrics:
        - Id: 'e1'
          Expression: '(m1/m2) * 100'
          Label: GSIReadThrottlesOverTotalReads
        - Id: 'm1'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ReadThrottleEvents'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
                - Name: 'GlobalSecondaryIndexName'
                  Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
            Period: 60
            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: 60
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
      EvaluationPeriods: 2
      Threshold: 2.0
      ComparisonOperator: 'GreaterThanThreshold'

プロビジョニングされた各スループットテーブルと GSI のメトリクス

ベストプラクティスとして、ベーステーブルとすべての GSI の両方に対して、プロビジョニングされたスループット (「PROVISIONED Billing Mode」) を使用して、テーブルの Auto Scaling を有効にする必要があります。そうすることで、使用率の低い時間帯に縮小してコストを削減し、予期しない負荷ピーク時のプロビジョニング不足によるスロットルを最小限に抑えることができます。

次のテーブルは、テーブルのプロビジョニングされたスループット設定の割合として、または Auto Scaling の最大値の割合としてスケーリングされたテーブルおよび GSI メトリクスを示しています。テーブルが設定された最大値に近づくと、アラートを受信するため、最大値を増やすか、アプリケーションの負荷の異常なレベルを調査できます。

説明	メトリクス	アラーム設定	注意
Auto Scaling の最大読み取り使用率	`ProvisionedReadCapacityAutoScalingPct`	> 90%	カスタム AWS Lambda 関数が必要
Auto Scaling の最大書き込み使用率	`ProvisionedWriteCapacityAutoScalingPct`	> 90%	カスタム AWS Lambda 関数が必要

次のコードは、前のテーブルの最初のメトリクス用の AWS CloudFormation テンプレートの例であり、他のメトリクス用に変更できます。このメトリクスは、AWS Lambda 関数から公開されたカスタムメトリクスに基づいています。

  DynamoDBTableASReadAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBTableASReadAlarm'
      AlarmDescription: 'Alarm when table auto scaling read setting approaches table AS maximum'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Namespace: !Ref DynamoDBCustomNamespace
      MetricName: 'ProvisionedReadCapacityAutoScalingPct'
      Dimensions:
        - Name: 'TableName'
          Value: !Ref DynamoDBProvisionedTableName
      Statistic: 'Maximum'
      Unit: 'Percent'
      Threshold: 90
      ComparisonOperator: 'GreaterThanThreshold'
      Period: 60
      EvaluationPeriods: 2

各オンデマンドキャパシティテーブルと GSI のメトリクス

オンデマンドキャパシティモード (PAY_PER_REQUEST Billing Mode) を使用するテーブルは、現在のキャパシティ設定を増減できないため、モニタリングする必要が少なくなります。主な懸念は、テーブルがテーブルレベルの読み取りと書き込みのアカウントの上限に近づいているかどうかです。次のテーブルは、DynamoDB メトリクスと、PAY_PER_REQUEST Billing Mode を使用した各 DynamoDB テーブルと GSI の推奨アラーム設定をまとめたものです。

説明	メトリクス	アラーム設定	注意
テーブル制限の割合としての読み取り消費	`SUM ConsumedReadCapacityUnits / MAXIMUM AccountMaxTableLevelReads`	> 90%	メトリクス計算が必要
テーブル制限の割合としての書き込み消費	`SUM ConsumedWriteCapacityUnits / MAXIMUM AccountMaxTableLevelWrites`	> 90%	メトリクス計算が必要

次のコードは、上記のテーブルの最初のメトリクス用の AWS CloudFormation テンプレートの例で、他のメトリクス用に変更できます。ConsumedCapacity メトリクスは、1 分間に蓄積された 1 秒あたりの送信リクエストのメトリクスです。AccountMaxTableLevelWrites は 1 秒あたりのリクエストを表すため、値を [0、100] の範囲に保つために式でスケーリングする必要があります。

  DynamoDBOnDemandTableWriteLimitAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBOnDemandTableWriteLimitAlarm'
      AlarmDescription: 'Alarm when consumed table reads approach the account limit'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Metrics:
        - Id: 'e1'
          Expression: '(((m1 / 300) / m2) * 100)'
          Label: TableWritesOverMaxWriteLimit
        - Id: 'm1'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ConsumedWriteCapacityUnits'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBOnDemandTableName
            Period: 300
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
        - Id: 'm2'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'AccountMaxTableLevelWrites'
            Period: 300
            Stat: 'Maximum'
          ReturnData: False
      EvaluationPeriods: 2
      Threshold: 90
      ComparisonOperator: 'GreaterThanThreshold'

DynamoDB グローバルテーブルのモニタリング

DynamoDB グローバルテーブルは、完全マネージド型のマルチマスター形式で、異なるリージョンのテーブル間でデータをレプリケートします。

プロビジョニングされたスループットを使用するグローバルテーブルでは、すべてのテーブルレプリカにわたって同じ WCU 設定をプロビジョニングする必要があります。そうしないと、あるリージョンのレプリカが別のリージョンからの変更のレプリケートに遅れることがあります。これにより、レプリカが他のレプリカから分岐する可能性があります。テーブルで Auto Scaling を使用する場合、一貫したエクスペリエンスを実現するには、すべてのレプリカテーブルで同じ Auto Scaling 設定を使用する必要があります。オンデマンドスループットを使用するテーブルでは、この問題を考慮する必要はありません。

各 AWS リージョンのレプリケーションレイテンシーを把握し、そのレプリケーションレイテンシーが継続的に増加する場合は警告することが役立ちます。グローバルテーブルのリージョンごとに異なる WCU 設定があり、レプリケートされた要求が失敗し、レイテンシーが長くなるという誤った設定を示している可能性があります。また、リージョンの混乱があることを示している可能性もあります。実際のレイテンシーは、関係するリージョン (地理的にどれだけ離れているか) に依存し、ある程度のリージョンの変動の影響を受けます。ただし、通常、3 分を超えるレプリケーションレイテンシーが調査の原因になりますが、ユースケースと要件に合った数値を選択する必要があります。

次のテーブルは、DynamoDB グローバルテーブルのメトリクスと、各グローバルテーブルの推奨されるアラーム設定をまとめたものです。グローバルテーブルに参加している各リージョンでアラームとダッシュボードを設定する必要があります。

説明	メトリクス	アラーム設定	注意
2 つのリージョン間のレプリケーションレイテンシーの上昇	`ReplicationLatency`	平均 > 180,000 ミリ秒 (3 分)	箱から出してすぐ

次のコードは、前のテーブルの最初のメトリクス用の AWS CloudFormation テンプレートの例であり、他のメトリクス用に変更できます。このアラームでは、レイテンシーを測定するリージョン (DynamoDBGlobalTableReceivingRegion パラメータで参照) を指定する必要があります。グローバルテーブルに 3 つ以上のリージョンが参加している場合、各リージョンで複数のアラームを設定する必要があります。

  DynamoDBGTReplLatencyAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBGTReplLatencyAlarm'
      AlarmDescription: 'Alarm when global table replication latency exceeds 3 minutes (180k ms)'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Namespace: 'AWS/DynamoDB'
      MetricName: 'ReplicationLatency'
      Dimensions:
        - Name: 'TableName'
          Value: !Ref DynamoDBGlobalTableName
        - Name: 'ReceivingRegion'
          Value: !Ref DynamoDBGlobalTableReceivingRegion
      Statistic: 'Average'
      Threshold: 180000
      ComparisonOperator: 'GreaterThanThreshold'
      Period: 60
      EvaluationPeriods: 15

DynamoDB Streams Lambda ユーザー

DynamoDB テーブルの変更によってトリガーされる AWS Lambda 関数を作成するユーザーは、オブジェクトが Lambda 関数によって処理されずに DynamoDB Streams 上に長時間座っている場合にアラートを生成する必要があります。これは、Lambda 関数に欠陥がある (未処理の例外など) か、イベントを十分に速く処理できないためにキューが深くなる Lambda 関数の証拠である可能性があります。システムが最適化され、適切に実行されると、DynamoDB Streams イベントが表示されて数秒以内に処理されます。次のテーブルは、Lambda メトリクスと、DynamoDB Streams イベントからトリガーされる各 Lambda 関数の推奨アラーム設定をまとめたものです。

説明	メトリクス	アラーム設定	注意
DynamoDB Streams イベントの経過時間の上昇	`IteratorAge`	> 30,000 ミリ秒 (30 秒)	箱から出してすぐ

次のコードは、上記のメトリクスの AWS CloudFormation テンプレートの例です。このアラームは、Lambda 関数名 (DynamoDBStreamLambdaFunctionName パラメータで参照) に基づいています。

  DynamoStreamLambdaIteratorAgeAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoStreamLambdaIteratorAgeAlarm'
      AlarmDescription: 'Alarm when lambda iterator age exceeds 30 seconds (30k ms)'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Namespace: 'AWS/Lambda'
      MetricName: 'IteratorAge'
      Dimensions:
        - Name: 'Function'
          Value: !Ref DynamoDBStreamLambdaFunctionName
        - Name: 'Resource'
          Value: !Ref DynamoDBStreamLambdaFunctionName
      Statistic: 'Average'
      Threshold: 30000
      ComparisonOperator: 'GreaterThanThreshold'
      Period: 60
      EvaluationPeriods: 2

まとめ

アラートをモニタリングおよび受信できるメトリクスは他にもたくさんありますが、この記事は DynamoDB を運用するための出発点として役立ちます。

Amazon DynamoDB のハウツーコンテンツ、ニュース、機能の最新情報を入手したい方は Twitter でフォローしてください。

著者について

Chad Tindel はニューヨーク勤務の DynamoDB スペシャリストソリューションアーキテクトです。Chad は大企業のお客様と連携して DynamoDB ベースのソリューションの評価、設計、およびデプロイメントを行っています。Amazon に入社する前は、Red Hat、Cloudera、MongoDB、および Elastic で同じような役割を担っていました。

Pete Naylor は、シアトル勤務の DynamoDB スペシャリストソリューションアーキテクトです。それ以前は、AWS の顧客として Amazon をサポートするテクニカルアカウントマネージャーで、データベースの移行と大規模な運用の卓越性に重点を置いていました。彼の職務のバックグラウンドは、地理的に多様なティア 1 ワークロードでの高可用性のためのシステムエンジニアリングです。

Pratik Agarwal は Amazon DynamoDB のソフトウェア開発エンジニアで、リソースガバナンスチームで働いています。主に、DynamoDB の Auto Scaling、適応能力、オンデマンドキャパシティモードなどの IOPS 管理に焦点を当てています。

Ankur Kasliwal は、Amazon DynamoDB のテクニカルプログラムマネージャーです。彼は、革新、プロジェクト開発構造の簡素化を支援し、お客様へ効果的かつ効率的な結果を提供する手助けをしています。それに加えて、Amazon DynamoDB を使用したソリューションに重点を置いて、AWS のサービスのアーキテクチャガイダンスを内部および外部のお客様に提供しています。

Amazon Web Services ブログ