Amazon SQSのDead Letter Queueを可視化してみよう

aws, sqs コメントを残す

Amazon SQSのDead Letter Queueを可視化して運用監視を強化する方法

はじめに

こんにちは。ディーネットの牛尾です。

SAPの勉強をしていたときにSQSのDLQについて、イメージがつきませんでした...。
そこで今回はAIに聞きながら、DLQの動作やアラート発報のタイミングについて可視化する検証をやってみました。

注意: 本記事は環境構築から動作確認まで含む実践的なハンズオン記事です。

  • 記事を読むだけ: 約30分
  • 実際に構築する場合: 約1-2時間
  • お急ぎの方は「本記事で学べること」と「まとめ」をご覧ください。

本記事で学べること

  • DLQの基本概念と重要性
  • CloudWatchメトリクスを使ったDLQの可視化
  • アラームによる障害の自動検知
  • 実際の動作確認とテスト方法
  • 運用時の注意点とポイント

Dead Letter Queue (DLQ) とは

Dead Letter Queue（DLQ）は、メッセージ処理が繰り返し失敗した際に、そのメッセージを隔離するための特別なキューです。

動作の仕組み

メインキューからメッセージを受信して処理に失敗すると、メッセージは再度キューに戻ります。この失敗が設定回数（maxReceiveCount）に達すると、メッセージは自動的にDLQへ移動します。

例: maxReceiveCount=3 の場合、3回失敗したらDLQへ

[メインキュー] --処理失敗×3回--> [DLQ]
     ↓
  [正常処理]

DLQを使うメリット

失敗メッセージの隔離
問題のあるメッセージがメインキューを詰まらせず、正常なメッセージの処理を継続できます。

障害分析が可能
失敗したメッセージを保存するため、原因調査や再処理ができます。

データロストの防止
メッセージが消失せず、システムの健全性とデータ整合性を保てます。

DLQを使わない場合のリスク

DLQを設定しないと、処理に失敗したメッセージは永久に失われ、障害に気づかないまま放置される可能性があります。これにより原因調査が困難になり、ビジネスへの影響が拡大するリスクがあります。

なぜDLQの可視化が重要なのか

DLQに気づかない問題

SQSのDLQは、デフォルトでは以下の問題があります。

  • 通知がない: メッセージがDLQに入っても自動通知されない
  • 見えない: AWSコンソールを開かないと状況が分からない
  • 気づきにくい: 定期的にチェックしないと見逃す

つまり、障害が発生していても気づかないまま放置してしまう可能性があるのです。

可視化によって得られる効果

障害の早期発見
DLQにメッセージが入った瞬間に通知されるため、深夜や休日でも検知できます。

迅速な対応
リアルタイムで状況を把握し、影響範囲を早期に特定できます。

システムの信頼性向上
データロストを防ぎ、SLA達成率の向上につながります。

前提条件・準備

必要なAWSサービス

  • Amazon SQS: メインキューとDLQ
  • Amazon CloudWatch: メトリクス、アラーム、ダッシュボード
  • Amazon SNS: アラート通知用（オプション）

必要な権限

以下のAWSサービスへのアクセス権限が必要です

  • Amazon SQS: キューの作成、設定、メッセージ送受信
  • Amazon CloudWatch: メトリクス参照、アラーム作成、ダッシュボード作成
  • Amazon SNS: トピック作成、サブスクリプション作成（通知設定時）

具体的には、以下のマネージドポリシーまたは同等の権限が必要です

  • AmazonSQSFullAccess
  • CloudWatchFullAccess
  • AmazonSNSFullAccess（通知設定時）

検証環境の構築

Step 1: DLQの作成

まず、Dead Letter Queue用のキューを作成します。

  1. SQSコンソールを開く

    • AWSマネジメントコンソールで「SQS」を検索して選択

  2. キューを作成

    • 「キューを作成」をクリック

  3. 基本設定

    • タイプ: 「標準」を選択
    • 名前: blog-test-dlq と入力

  4. 詳細設定

    • メッセージ保持期間: デフォルト（4日）のまま
      • 重要: DLQの保持期間は、メインキューより長く設定することが推奨されます
      • 本番環境では14日（最大値）を推奨（メインキューのデフォルト4日より長い）

  5. キューを作成

    • その他の設定はデフォルトのまま
    • 画面下部の「キューを作成」をクリック

Step 2: メインキューの作成とDLQ関連付け

次に、メインキューを作成し、DLQを関連付けます。

  1. キューを作成

    • SQSコンソールで「キューを作成」をクリック

  2. 基本設定

    • タイプ: 「標準」を選択
    • 名前: blog-test-main-queue と入力

  3. Dead-letter queue の設定（重要）

    • 「有効」を選択
    • Dead-letter queue を選択: blog-test-dlq を選択
    • 最大受信数: 3 と入力
      • 3回処理に失敗したらDLQへ移動

  4. キューを作成

    • その他の設定はデフォルトのまま
    • 画面下部の「キューを作成」をクリック

Step 3: 設定の確認

  1. メインキューの詳細を確認
    • blog-test-main-queue をクリック
    • 「Dead-letter queue」タブで設定を確認
      • Dead-letter queue: blog-test-dlq
      • 最大受信数: 3

確認ポイント:

  • ✓ Redrive Policyが正しく設定されている
  • ✓ DLQのARNが正しい
  • ✓ maxReceiveCountが3に設定されている

DLQの可視化手順

Step 1: CloudWatchメトリクスの確認

SQSは自動的にCloudWatchメトリクスを送信します。
DLQ監視で重要なメトリクスは以下の3つです。

主要メトリクス

  1. ApproximateNumberOfMessagesVisible

    • DLQ内の取得可能なメッセージ数
    • 0より大きい = 処理失敗メッセージあり
    • 最重要メトリクス（DLQ監視に最適）

  2. NumberOfMessagesSent

    • DLQへ手動で送信されたメッセージ数
    • 注意: maxReceiveCountを超えて自動的にDLQへ移動したメッセージはカウントされません
    • 今回のテストでは、メッセージは自動移動するため、このメトリクスは増加しません

  3. ApproximateAgeOfOldestMessage

    • 最も古いメッセージの滞留時間（秒）
    • 長時間滞留 = 処理漏れの可能性
    • 1時間以上は要注意

メトリクスの確認方法:

  1. CloudWatchコンソールを開く

    • CloudWatchコンソールの「メトリクス」→「すべてのメトリクス」を選択

  2. SQSメトリクスを表示

    • 「SQS」→「キューメトリクス」を選択
    • 検索ボックスに blog-test-dlq と入力
    • 以下の3つのメトリクスにチェックを入れる：
      • ApproximateNumberOfMessagesVisible (DLQ内のメッセージ数)
      • NumberOfMessagesSent (DLQへ送信されたメッセージ数)
      • ApproximateAgeOfOldestMessage (一番古いメッセージがDLQに入ってからの経過時間)

  3. グラフ化したメトリクスの設定

    • 「グラフ化したメトリクス」タブに移動
    • 統計: 「平均」を選択
    • 期間: 「5分」を選択

      注意: リソースを作成したばかりの段階では、DLQにメッセージが存在しないため、グラフには何も表示されません（すべて0）。これは正常な状態です。

Step 2: CloudWatchアラームの設定

メトリクスを監視するだけでは不十分です。アラームを設定して、異常時に自動通知されるようにします。

2-1. SNSトピックの作成（通知先）

  1. SNSコンソールを開く

    • AWSマネジメントコンソールで「SNS」を検索して選択

  2. トピックを作成

    • 左側のメニューから「トピック」を選択
    • 「トピックの作成」をクリック

  3. トピックの設定

    • タイプ: 「スタンダード」を選択
    • 名前: sqs-dlq-alerts と入力
    • 「トピックの作成」をクリック

  4. サブスクリプションの作成

    • 「サブスクリプションの作成」をクリック
    • プロトコル: 「Eメール」を選択
    • エンドポイント: 通知を受け取るメールアドレスを入力
    • 「サブスクリプションの作成」をクリック

  5. メールの確認と承認

    登録したメールアドレスに確認メール（件名: AWS Notification - Subscription Confirmation）が届きます。

    注意: 確認メールには「Confirm subscription」と「Unsubscribe」の2つのリンクが含まれています。誤って「Unsubscribe」をクリックすると通知が解除されてしまうため、以下の方法で安全に承認することを推奨します。

    推奨方法: SNSコンソールから承認

    1. 確認メールを開く（件名: AWS Notification - Subscription Confirmation）
    2. 「Confirm subscription」リンクを右クリック（左クリックしない）
    3. 「リンクのアドレスをコピー」を選択
    4. SNSコンソールに戻り、トピック（sqs-dlq-alerts）を選択
    5. 「サブスクリプションの確認」をクリック
    6. コピーしたURLを貼り付けて「サブスクリプションの確認」をクリック

    承認後、トピックの「サブスクリプション」タブでステータスが「確認済み」になっていることを確認します。


2-2. DLQメッセージ検知アラーム

DLQにメッセージが1件でも入ったら即座に通知するアラームです。

  1. CloudWatchコンソールでアラームを作成

    • CloudWatchコンソールの「アラーム」→「すべてのアラーム」を選択
    • 「アラームの作成」をクリック

  2. メトリクスの選択

    • 「メトリクスの選択」をクリック
    • 「SQS」→「キューメトリクス」を選択
    • blog-test-dlq の ApproximateNumberOfMessagesVisible を選択

  3. 条件の設定

    • 統計: 「平均」を選択
    • 期間: 「1分」を選択
    • しきい値: 1 と入力（1件以上で発火）
    • 「次へ」をクリック

  4. アクションの設定

    • SNSトピック: sqs-dlq-alerts を選択
    • 「次へ」をクリック

  5. 名前と説明

    • アラーム名: blog-test-dlq-messages-detected
    • 説明: DLQにメッセージが検知されました
    • 「アラームの作成」をクリック

設定のポイント:

  • しきい値: 1（1件以上で発火）
  • 期間: 1分（即座にチェック）
  • 評価期間: 1（即座に通知）

2-3. DLQメッセージ滞留アラーム

メッセージが長時間DLQに滞留している場合に通知するアラームです。

  1. 2つ目のアラームを作成

    • CloudWatchコンソールで「アラームの作成」をクリック

  2. メトリクスの選択

    • 「SQS」→「キューメトリクス」を選択
    • blog-test-dlq の ApproximateAgeOfOldestMessage を選択

  3. 条件の設定

    • 統計: 「最大」を選択
    • 期間: 「5分」を選択
    • しきい値: 600 と入力（10分 = 600秒）
    • 「次へ」をクリック

  4. アクションの設定

    • SNSトピック: sqs-dlq-alerts を選択
    • 「次へ」をクリック

  5. 名前と説明

    • アラーム名: blog-test-dlq-message-age-high
    • 説明: DLQのメッセージが10分以上滞留しています
    • 「アラームの作成」をクリック

設定のポイント:

  • しきい値: 600秒（10分）
  • 期間: 5分間隔
  • 統計: 最大値を監視

アラーム作成後、アラーム一覧に blog-test-dlq-messages-detected が表示されていることを確認してください。

Step 3: CloudWatchダッシュボードの作成

複数のメトリクスを一元管理するため、ダッシュボードを作成します。

ダッシュボードの構成:

  1. DLQメッセージ数の時系列グラフ（DLQ内のメッセージ数）
  2. DLQへの送信レートグラフ（DLQへ送信されたメッセージ数）
  3. 最も古いメッセージの滞留時間グラフ（メッセージの滞留時間）
  4. メインキューとDLQの比較グラフ（メインキューとDLQのメッセージ数比較）

作成方法:

  1. CloudWatchコンソールを開く

    • CloudWatchコンソールの左側メニューから「ダッシュボード」を選択
    • 「ダッシュボードの作成」をクリック

  2. ダッシュボード名の入力

    • ダッシュボード名: SQS-DLQ-Monitoring と入力
    • 「ダッシュボードの作成」をクリック

  3. ウィジェット1: DLQメッセージ数グラフを追加

    • 「ウィジェットの追加」ダイアログで「線」を選択
    • 「次へ」をクリック
    • 「メトリクス」タブで「SQS」→「キューメトリクス」を選択
    • 検索ボックスに blog-test-dlq と入力
    • ApproximateNumberOfMessagesVisible にチェック
    • 「グラフ化されたメトリクス」タブで設定：
      • ラベル列: DLQ Message Count と入力
      • 統計と期間はデフォルトのまま（平均、5分）
    • 「ウィジェットの作成」をクリック


  1. ウィジェット2: DLQ送信レートグラフを追加
    • 「+」をクリック
    • 「線」を選択→「次へ」
    • 「SQS」→「キューメトリクス」を選択
    • blog-test-dlq の NumberOfMessagesSent にチェック
    • 「グラフ化されたメトリクス」タブで設定：
      • ラベル列: Messages Sent to DLQ と入力
      • 統計列: 「合計」を選択
    • 「ウィジェットの作成」をクリック
  2. ウィジェット3: 最も古いメッセージの滞留時間グラフを追加
    • 「+」をクリック
    • 「線」を選択→「次へ」
    • 「SQS」→「キューメトリクス」を選択
    • blog-test-dlq の ApproximateAgeOfOldestMessage にチェック
    • 「グラフ化されたメトリクス」タブで設定：
      • ラベル列: DLQ Oldest Message Age と入力
      • 統計列: 「最大」を選択
    • 「オプション」タブで設定：
      • 水平注釈/しきい値:
      • ラベル: 10 Minutes と入力
      • 値: 600 と入力（10分 = 600秒）
      • 塗り: 「なし」を選択
    • 「ウィジェットの作成」をクリック

  3. ウィジェット4: メインキューとDLQの比較グラフを追加
    • 「+」をクリック
    • 「線」を選択→「次へ」
    • 「SQS」→「キューメトリクス」を選択
    • blog-test-main-queue の ApproximateNumberOfMessagesVisible にチェック
    • blog-test-dlq の ApproximateNumberOfMessagesVisible にチェック
    • 「グラフ化されたメトリクス」タブで設定：
      • メインキューのラベル列: Main Queue と入力
      • DLQのラベル列: DLQ と入力
    • 「ウィジェットの作成」をクリック

  1. ダッシュボードの保存とレイアウト調整
    • ウィジェットの端をドラッグして、見やすいサイズに調整
    • ウィジェットをドラッグ＆ドロップして配置を変更
    • 画面右上の「変更を保存」をクリック

ウィジェットは後から自由にサイズ変更や配置変更ができます。
推奨レイアウトは2×2のグリッド配置です。

実際の動作確認

テスト1: 正常系（メッセージが正常に処理される）

AWSマネジメントコンソールから以下の手順で確認します：

  1. SQSコンソールでメインキューを開く

    • blog-test-main-queue を選択

  2. メッセージを送信

    • 「メッセージを送受信」をクリック
    • メッセージ本文: Test message - Normal processing
    • 「メッセージを送信」をクリック



  1. メッセージを受信して削除
    • 「メッセージをポーリング」をクリック
    • 受信したメッセージを選択
    • 「削除」をクリック

結果: DLQにメッセージは移動しない

このテストでは、メッセージを受信して削除することで正常処理をシミュレートしています。
DLQへの移動条件については、次のテスト2で詳しく確認します。

テスト2: 異常系（メッセージがDLQに移動）

このPythonスクリプトは、メッセージ処理の失敗をシミュレートしてDLQへの移動を確認します。

動作の仕組み:

メインキューからメッセージを受信後、以下の流れでDLQへ移動します

  1. メッセージを意図的に削除せずに放置
  2. VisibilityTimeout（5秒）が経過してメッセージが再度キューに戻る
  3. この動作を4回繰り返す（maxReceiveCount=3を超過）
  4. 4回目の受信失敗後、メッセージが自動的にDLQへ移動

重要: メッセージがDLQに移動する条件は、「受信したが削除せず、VisibilityTimeoutが切れて再度キューに戻る」動作をmaxReceiveCount回（今回は3回）繰り返した場合のみです。
テスト1で実施した「受信して削除」は正常処理のため、DLQには移動しません。

事前準備:

  • AWS認証情報が設定されていること（AWS CLIの設定など）
  • Python 3.x と boto3 がインストールされていること

処理失敗をシミュレートするPythonスクリプト:

import boto3
import time

# 設定（実際のキューURLに置き換えてください）
QUEUE_URL = 'https://sqs.[利用するリージョン].amazonaws.com/[ACCOUNT_ID]/blog-test-main-queue'
REGION = '[利用するリージョン]'

sqs = boto3.client('sqs', region_name=REGION)

# テストメッセージを送信
print("Sending test message to main queue...")
sqs.send_message(
    QueueUrl=QUEUE_URL,
    MessageBody="Test message for DLQ - This will fail processing"
)
print("✓ Message sent successfully\n")

# メッセージを受信して削除せずに繰り返す（処理失敗をシミュレート）
print("Simulating failed processing (maxReceiveCount=3)...\n")

for i in range(4):
    print(f"Attempt {i+1}:")
    response = sqs.receive_message(
        QueueUrl=QUEUE_URL,
        MaxNumberOfMessages=1,
        VisibilityTimeout=5,
        WaitTimeSeconds=2,
        AttributeNames=['ApproximateReceiveCount']
    )

    if 'Messages' in response:
        message = response['Messages'][0]
        receive_count = message['Attributes'].get('ApproximateReceiveCount', 'N/A')
        print(f"  ✓ Received message (Receive count: {receive_count})")
        print(f"  ✗ Not deleting (simulating processing failure)")
        print(f"  ⏳ Waiting for visibility timeout...\n")
        time.sleep(6)  # VisibilityTimeoutより長く待つ
    else:
        print(f"  ℹ No messages available (moved to DLQ)\n")
        break

print("=" * 60)
print("✓ Test completed!")
print("Message should now be in DLQ.")
print("Check CloudWatch metrics and alarms in 1-5 minutes.")
print("=" * 60)

実行:

python test_sqs_dlq.py

実行結果:

Sending test message to main queue...
✓ Message sent successfully

Simulating failed processing (maxReceiveCount=3)...

Attempt 1:
  ✓ Received message (Receive count: 1)
  ✗ Not deleting (simulating processing failure)
  ⏳ Waiting for visibility timeout...

Attempt 2:
  ✓ Received message (Receive count: 2)
  ✗ Not deleting (simulating processing failure)
  ⏳ Waiting for visibility timeout...

Attempt 3:
  ✓ Received message (Receive count: 3)
  ✗ Not deleting (simulating processing failure)
  ⏳ Waiting for visibility timeout...

Attempt 4:
  ℹ No messages available (moved to DLQ)

============================================================
✓ Test completed!
Message should now be in DLQ.
Check CloudWatch metrics and alarms in 1-5 minutes.
============================================================

エラーが出る場合は、必要なPythonモジュールが不足している可能性があります。
以下のコマンドでインストールしてください。

pip install boto3
pip install "botocore[crt]"

テスト3: CloudWatchの確認

重要: CloudWatchメトリクスは1-5分の遅延があります。テスト実行後、5分程度待ってから確認してください。

3-1. SQSコンソールでDLQメッセージを確認

まず、メッセージが実際にDLQに移動したことを確認します。

  1. DLQキューを開く

    • SQSコンソールで blog-test-dlq を選択

  2. メッセージをポーリング

    • 「メッセージを送信および受信」をクリック
    • 「メッセージをポーリング」をクリック
    • テストで送信したメッセージが表示されることを確認


  3. メッセージの詳細を確認

    • メッセージをクリックして詳細を表示
    • 以下の情報を確認：
      • メッセージ本文: テストメッセージの内容
      • 受信数（ApproximateReceiveCount）: 3以上
      • 送信済（SentTimestamp）: メッセージが送信された時刻

確認ポイント:

  • ✓ DLQにメッセージが1件存在する
  • ✓ 受信数が3以上（maxReceiveCountを超過）

3-2. CloudWatchダッシュボードで可視化を確認

作成したダッシュボードでメトリクスを確認します。

  1. ダッシュボードを開く

    • CloudWatchコンソールの「ダッシュボード」を選択
    • SQS-DLQ-Monitoring をクリック

  2. 各ウィジェットを確認

各グラフの見方:

  • DLQ Message Count（左上）:

    • グラフが右肩上がり = DLQにメッセージが蓄積されている
    • 値が1以上 = 処理失敗メッセージが存在

  • DLQ Oldest Message Age（右上）:

    • グラフが右肩上がり = メッセージが滞留し続けている
    • 赤い水平線（600秒）を超える = 10分以上滞留（要対応）

  • Messages Sent to DLQ（左下）:

    • 0のまま = 正常（自動移動したメッセージはカウントされない）

  • Main Queue vs DLQ（右下）:

    • オレンジ線（DLQ）が上昇 = 失敗メッセージがDLQへ移動
    • 青線（Main Queue）が0または低い値 = メインキューのメッセージは処理済み
  1. 時間範囲の調整
    • 画面上部の時間範囲を「1時間」に設定
    • メッセージがDLQに移動したタイミングが確認できる

確認ポイント:

  • ✓ すべてのウィジェットでデータが表示されている
  • ✓ DLQメッセージ数が1以上になっている
  • ✓ グラフでメッセージ移動のタイミングが確認できる
  • ✓ 4つのグラフを見比べることで、DLQの状態を多角的に把握できる

3-3. CloudWatchアラームの発火を確認

アラームが正常に動作していることを確認します。

  1. アラーム一覧を開く

    • CloudWatchコンソールの「アラーム」→「すべてのアラーム」を選択

  2. アラームの状態を確認

    • blog-test-dlq-messages-detected の状態を確認
    • 状態が「アラーム状態」（赤色）になっていることを確認

  3. アラームの詳細を確認

    • アラーム名をクリックして詳細を表示
    • 「履歴」タブで状態変化の履歴を確認
    • 「OK」→「アラーム状態」に変化したことを確認

  4. 通知メールの確認

    登録したメールアドレスの受信トレイを確認します。

    メール1: DLQメッセージ検知アラート

    • 件名: ALARM: "blog-test-dlq-messages-detected" in [リージョン名]

    メール本文の重要な情報:

    • State Change: OK -> ALARM（正常状態からアラーム状態へ変化）
    • Reason for State Change: しきい値を超えたことを示す
      • 例: 1.0 (06/03/26 10:50:00)] was greater than or equal to the threshold (1.0)
      • 意味: DLQのメッセージ数が1.0件になり、しきい値1.0以上を満たした
    • MetricName: ApproximateNumberOfMessagesVisible（監視対象メトリクス）
    • Dimensions: [QueueName = blog-test-dlq]（監視対象キュー）

    メール2: DLQメッセージ滞留アラート（テスト実行から約10分後）

    • 件名: ALARM: "blog-test-dlq-message-age-high" in [リージョン名]

    メール本文の重要な情報:

    • State Change: OK -> ALARM
    • Reason for State Change:
      • 例: 628.0 (06/03/26 10:56:00)] was greater than or equal to the threshold (600.0)
      • 意味: メッセージの滞留時間が628秒（約10.5分）になり、しきい値600秒（10分）を超えた
    • MetricName: ApproximateAgeOfOldestMessage（監視対象メトリクス）
    • Statistic: Maximum（最大値を監視）

確認ポイント:

  • ✓ アラームが「アラーム状態」になっている
  • ✓ アラーム履歴で状態変化が確認できる
  • ✓ SNS経由でメール通知が届いている
  • ✓ メール本文から、どのメトリクスがどの値でしきい値を超えたかが分かる
  • ✓ 2つのアラームが異なるタイミングで発火している（メッセージ検知→滞留検知）

3-4. CloudWatchメトリクスでDLQへの移動を確認

テスト実行後、CloudWatchメトリクスでDLQにメッセージが入ったことを詳細に確認します。

  1. CloudWatchコンソールを開く

    • CloudWatchコンソールの「メトリクス」→「すべてのメトリクス」を選択

  2. DLQのメトリクスを選択

    • 「SQS」→「キューメトリクス」を選択
    • 検索ボックスに blog-test-dlq と入力
    • ApproximateNumberOfMessagesVisible にチェックを入れる

  3. グラフの設定

    • 「グラフ化したメトリクス」タブで設定：
      • 統計: 平均、最小、最大の3つを選択（メトリクスの変化を詳細に確認するため）
      • 期間: 5分
    • 時間範囲を適切に調整（テスト実行時刻の前後30分程度）

  4. グラフの確認

    • グラフが右肩上がりになっている = DLQにメッセージが入った証拠
    • 平均、最小、最大の3本の線が表示される
    • テスト実行のタイミングでグラフが上昇していることを確認

グラフの見方:

  • 3本の線（平均、最小、最大）が重なっている = メッセージ数が安定している
  • グラフが0から1に上昇したタイミング = メッセージがDLQに移動した瞬間
  • その後横ばい = メッセージがDLQに残り続けている

確認ポイント:

  • ✓ グラフが右肩上がりになっている（DLQにメッセージが蓄積）
  • ✓ テスト実行時刻付近でグラフが上昇している
  • ✓ 平均、最小、最大の値が一致または近い値（メッセージ数が安定している証拠）

3-5. メインキューとDLQの比較

メインキューとDLQのメッセージ数を並べて表示し、メッセージの流れを視覚的に確認します。

  1. CloudWatchコンソールを開く

    • CloudWatchコンソールの「メトリクス」→「すべてのメトリクス」を選択

  2. 2つのキューのメトリクスを選択

    • 「SQS」→「キューメトリクス」を選択
    • 以下の2つにチェックを入れる：
      • blog-test-dlq の ApproximateNumberOfMessagesVisible
      • blog-test-main-queue の ApproximateNumberOfMessagesVisible

  3. グラフの設定

    • 「グラフ化したメトリクス」タブで設定：
      • 統計: 合計
      • 期間: 1分
    • 時間範囲を適切に調整（テスト実行時刻の前後15分程度）

  4. メッセージの流れを確認

    • 青線（blog-test-dlq）: DLQのメッセージ数
    • オレンジ線（blog-test-main-queue）: メインキューのメッセージ数
    • テスト実行後、DLQにメッセージが入り、メインキューは空のままであることを確認

グラフの見方:

  • 青線が上昇 = DLQにメッセージが移動した
  • オレンジ線が0のまま = メインキューにメッセージが残っていない（正常処理またはDLQへ移動済み）
  • 2つの線を比較することで、システム全体のメッセージフローが把握できる

3-4と3-5の違い:

  • 3-4（DLQ単体の詳細分析）:

    • 目的: DLQのメッセージ数の変化を詳細に追跡
    • 見るもの: 平均、最小、最大の3つの統計
    • 使い方: メッセージが増減しているか、安定しているかを確認

  • 3-5（メインキューとDLQの比較）:

    • 目的: システム全体のメッセージフローを把握
    • 見るもの: 2つのキューのメッセージ数を並べて表示
    • 使い方: メッセージがどこからどこへ流れたかを視覚的に確認

どちらを使うか:

  • 3-4: DLQの状態を詳しく知りたいとき
  • 3-5: メインキューとDLQの関係を理解したいとき

確認ポイント:

  • ✓ DLQ（青線）にメッセージが存在している
  • ✓ メインキュー（オレンジ線）は0のまま（メッセージが処理済みまたはDLQへ移動）
  • ✓ 2つのキューの状態を一目で比較できる
  • ✓ システム全体のメッセージフローが視覚的に理解できる

注意点・運用のポイント

1. コストについて

以下のAWSサービスに料金が発生します:

  • Amazon SQS: メッセージのリクエスト数に応じて課金
  • CloudWatch: アラーム、ダッシュボード、メトリクス保存
  • SNS: 通知の送信数に応じて課金

詳細は以下の料金ページで確認してください:

注意: 本記事の検証環境は無料利用枠内で実施できますが、本番環境では利用量に応じて料金が発生します。

2. 運用上の注意点

DLQメッセージの管理:

  • DLQ内のメッセージは自動削除されません
  • 定期的に確認して処理してください（保持期間: 最大14日）
  • 推奨フロー: アラート受信 → 原因調査 → 問題修正 → メッセージ再処理または削除

アラーム設定:

  • 過去のデータを参考に適切な閾値を設定する
  • 頻繁に発火する場合は閾値を見直す

セキュリティ:

  • DLQ内に機密情報が含まれる可能性があります
  • アクセス権限を適切に管理してください
  • 必要に応じてKMS暗号化を検討してください

まとめ

本記事では、Amazon SQSのDead Letter Queueを可視化し、CloudWatchを活用した運用監視の方法を実践的に解説しました。

SQSは触る機会が少ないのと初めての検証で楽しい反面めちゃくちゃ疲れました。
一番はこのブログを書くために構成を考えるのが大変でした。

本記事で学んだこと

  • DLQの基本概念と仕組み
  • DLQ可視化の重要性
  • SQSキューとDLQの構築方法
  • CloudWatchメトリクスによる監視
  • CloudWatchアラームの設定方法
  • CloudWatchダッシュボードでの一元管理
  • 実際の動作確認とテスト方法
  • 運用時の注意点とポイント

DLQ可視化によって得られる効果

  • メッセージ処理失敗の早期発見
  • 障害への迅速な対応
  • データロストの防止
  • システムの信頼性向上
  • 運用負荷の軽減

参考リンク

返信を残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA