AWS SQS FIFO + Lambda による Prepare-Challenge パターン実装ガイド

1. 概要

非同期処理を確実に完了させるPrepare-Challengeパターンを、AWS SQS FIFO（First-In-First-Out）キューとLambdaを使って実装するためのガイドです。

1.1 パターンの目的

外部システムとの非同期処理を確実に完了
処理の順序性を保証
システム負荷の制御
処理状態の追跡容易性

1.2 AWS サービスの選定理由

SQS FIFO
- メッセージの厳密な順序保証
- 重複排除機能
- メッセージグループによる並列処理の制御
- デッドレターキュー（DLQ）によるエラー処理
Lambda
- サーバーレスでの柔軟なスケーリング
- SQSとの統合が容易
- コスト効率の良い実行環境
- 監視・ログ収集の容易さ

2. キュー設計パターン

2.1 優先度別キューの構成

高優先度キュー

const highPriorityQueue = new sqs.Queue(this, 'HighPriorityQueue', {
  fifo: true,
  contentBasedDeduplication: true,
  retentionPeriod: Duration.minutes(15),
  visibilityTimeout: Duration.seconds(30)
});

即時処理が必要な重要な業務処理用
短い保持期間と可視性タイムアウト
1メッセージずつの即時処理

標準優先度キュー

const standardPriorityQueue = new sqs.Queue(this, 'StandardPriorityQueue', {
  fifo: true,
  contentBasedDeduplication: true,
  retentionPeriod: Duration.hours(1),
  visibilityTimeout: Duration.seconds(30)
});

通常の業務処理用
適度な保持期間
バッチサイズによる効率的な処理

低優先度キュー

const lowPriorityQueue = new sqs.Queue(this, 'LowPriorityQueue', {
  fifo: true,
  contentBasedDeduplication: true,
  retentionPeriod: Duration.hours(2),
  visibilityTimeout: Duration.seconds(60)
});

バッチ処理など、時間的余裕のある処理用
長めの保持期間と可視性タイムアウト
大きめのバッチサイズでの処理

2.2 共通の設定ポイント

コンテンツベースの重複排除
- contentBasedDeduplication: true
- メッセージ本体に基づく自動的な重複排除
- 5分間の重複排除ウィンドウ
デッドレターキュー（DLQ）
```
deadLetterQueue: {
  queue: dlqQueue,
  maxReceiveCount: 3
}
```
- 失敗メッセージの分離
- 再処理ポリシーの設定
- 長期の保持期間設定
メッセージグループID
- 同一処理グループ内での順序保証
- 業務単位での並列処理制御

3. Lambda Trigger設定

3.1 基本設定

const eventSource = new lambdaEventSources.SqsEventSource(queue, {
  batchSize: 10,
  maxBatchingWindow: Duration.seconds(5),
  reportBatchItemFailures: true
});

3.2 優先度別の設定例

高優先度キューのトリガー

{
  batchSize: 1,
  maxBatchingWindow: Duration.seconds(0),
  reportBatchItemFailures: true
}

標準優先度キューのトリガー

{
  batchSize: 5,
  maxBatchingWindow: Duration.seconds(5),
  reportBatchItemFailures: true
}

低優先度キューのトリガー

{
  batchSize: 10,
  maxBatchingWindow: Duration.seconds(10),
  reportBatchItemFailures: true
}

4. メッセージ送信パターン

4.1 基本的なメッセージ構造

interface PrepareChallengeMessage {
  processType: string;
  priority: 'HIGH' | 'STANDARD' | 'LOW';
  requestId: string;
  timestamp: string;
  payload: {
    [key: string]: any;
  };
  metadata?: {
    retryCount?: number;
    originalTimestamp?: string;
  };
}

4.2 送信パラメーター例

const sendParams = {
  QueueUrl: queueUrl,
  MessageBody: JSON.stringify(message),
  MessageGroupId: groupId,
  MessageDeduplicationId: deduplicationId
};

4.3 メッセージグループIDの設定パターン

注文処理の場合
```
MessageGroupId: `ORDER_${orderId}`
```
- 同一注文の順序性保証
顧客単位の処理の場合
```
MessageGroupId: `CUSTOMER_${customerId}`
```
- 同一顧客の処理順序保証
バッチ処理の場合
```
MessageGroupId: `BATCH_${batchType}`
```
- 同種バッチの順序性保証

5. エラーハンドリング

5.1 Lambda側の実装

export const handler = async (event: SQSEvent) => {
  const batchItemFailures: { itemIdentifier: string }[] = [];

  for (const record of event.Records) {
    try {
      const success = await processMessage(record);
      if (!success) {
        batchItemFailures.push({ 
          itemIdentifier: record.messageId 
        });
      }
    } catch (error) {
      batchItemFailures.push({ 
        itemIdentifier: record.messageId 
      });
    }
  }

  return { batchItemFailures };
};

5.2 再処理戦略

Prepare Phase失敗時
- 同一キューの後方に再エンキュー
- バックオフ時間の設定
- 最大再試行回数の管理
Challenge Phase失敗時
- DLQへの移動
- アラート通知
- 手動再処理の検討

6. モニタリングと運用

6.1 CloudWatchメトリクス

キューの深さ
処理遅延時間
エラー率
DLQメッセージ数

6.2 アラート設定

new cloudwatch.Alarm(this, 'DLQAlarm', {
  metric: dlqQueue.metricApproximateNumberOfMessagesVisible(),
  threshold: 1,
  evaluationPeriods: 1,
  alarmDescription: 'Messages in DLQ detected'
});

6.3 運用上の注意点

キャパシティ管理
- FIFOキューの制限（1秒あたり300メッセージ）
- Lambda同時実行数の制限
- メモリ使用量の監視
コスト最適化
- バッチサイズの適切な設定
- Lambda実行時間の最適化
- 保持期間の適切な設定
メンテナンス性
- ログレベルの適切な設定
- エラーメッセージの明確化
- デバッグ情報の充実

7. ベストプラクティス

設計原則
- 単一責任の原則を守る
- 疎結合な設計を心がける
- 監視可能性を確保する
実装のポイント
- メッセージの冪等性確保
- タイムアウト値の適切な設定
- エラーハンドリングの徹底
運用面での推奨事項
- 定期的なDLQの確認
- パフォーマンスメトリクスの監視
- キャパシティプランニングの実施