380-AWS SAP AWS 「理論・実践・一問道場」

type

status

date

slug

summary

理論

1. メッセージングサービスの活用

Amazon SQS (Simple Queue Service) は、非同期的なメッセージキューイングサービスで、システムの耐障害性を高めるために活用されます。処理が失敗した場合でも、メッセージをキューに保存し、後で処理できるため、データの損失を防ぐことができます。

デッドレターキュー (DLQ) は、失敗したメッセージを保存する専用のキューです。失敗した処理を分析し、手動で再処理できるようにするための重要なツールです。

2. 冗長性とスケーラビリティ

システムの冗長性を確保することで、障害が発生しても別のインスタンスやサービスが処理を引き継げるようになります。例えば、SQSを使うことでメッセージを一時的に保存し、複数の処理ユニット（Lambda関数など）で並行して処理することが可能です。

スケーラビリティの確保も重要です。負荷が高くなるとサービスが過負荷になるため、自動スケーリングや並列処理を使ってシステムの負荷分散を行うことが求められます。

3. リトライと再試行ポリシー

処理が失敗した場合に備えて、リトライポリシーや再試行メカニズムを組み込むことが重要です。失敗したメッセージを一定回数リトライし、最終的に失敗した場合にはデッドレターキューに送る設計が一般的です。

4. イベント駆動型アーキテクチャ

Amazon EventBridge や AWS Lambda は、イベント駆動型のシステムでのエラーハンドリングを効率化します。イベントが失敗した場合でも、他のシステムに影響を与えずに後続処理を行うための柔軟性を提供します。

5. モニタリングとアラート

システムの監視が欠かせません。Amazon CloudWatch を使って、SQSのキューの長さやLambda関数の実行時間、失敗率を監視し、問題が発生する前に通知を受け取れるようにすることで、迅速に対処できます。

このようなアーキテクチャやサービスを活用することで、システムの耐障害性を強化し、予期しない障害に備えることができます。

実践

略

一問道場

ある企業が、数千の気象観測所からの気象データを分析するソリューションを持っています。気象観測所はデータをAmazon API Gateway REST API経由で送信し、そのAPIはAWS Lambda関数と統合されています。Lambda関数は、データの前処理のためにサードパーティサービスを呼び出します。しかし、サードパーティサービスが過負荷になり、前処理が失敗し、データが失われています。

ソリューションアーキテクトは、ソリューションのレジリエンシー（耐障害性）を改善する必要があります。ソリューションアーキテクトは、データが失われることなく、失敗が発生した場合に後でデータを処理できることを確保する必要があります。

この要件を満たすために、ソリューションアーキテクトは何をすべきですか？

A. Amazon Simple Queue Service (Amazon SQS) キューを作成し、そのキューをAPIのデッドレターキューとして設定します。

B. 2つのAmazon Simple Queue Service (Amazon SQS) キューを作成します。1つはプライマリキュー、もう1つはセカンダリキューです。セカンダリキューをプライマリキューのデッドレターキューとして設定します。APIを新しい統合に更新し、プライマリキューを使用します。Lambda関数をプライマリキューの呼び出しターゲットとして設定します。

C. 2つのAmazon EventBridge イベントバスを作成します。1つはプライマリイベントバス、もう1つはセカンダリイベントバスです。APIを新しい統合に更新し、プライマリイベントバスを使用します。プライマリイベントバスのすべてのイベントに反応するEventBridgeルールを設定し、そのルールのターゲットとしてLambda関数を指定します。Lambda関数の失敗先としてセカンダリイベントバスを設定します。

D. カスタムAmazon EventBridgeイベントバスを作成し、Lambda関数の失敗先としてそのイベントバスを設定します。

解説

B. 2つのAmazon Simple Queue Service (Amazon SQS) キューを作成します。1つはプライマリキュー、もう1つはセカンダリキューです。セカンダリキューをプライマリキューのデッドレターキューとして設定します。APIを新しい統合に更新し、プライマリキューを使用します。Lambda関数をプライマリキューの呼び出しターゲットとして設定します。

この選択肢の解説：

プライマリキューとセカンダリキューを使うことで、リクエストが失敗した場合にセカンダリキューにデータを移し、後で処理を再試行できます。これにより、データの損失を防ぎ、後で再処理を行うレジリエンシーを強化できます。

デッドレターキューとしてセカンダリキューを使用することによって、プライマリキューが正常に処理できなかったリクエストを後で処理するためのエラーハンドリングが行われます。この方法では、処理失敗時のメッセージを追跡し、再処理の際に手動で問題を修正できるため、確実にデータを失うことなく処理を行えます。

Bのメリット：

失敗したリクエストをセカンダリキューに保存し、後で再処理を行えるため、データ損失の防止が可能です。

複数のキューを使用することで、処理の優先度を分けることができます（プライマリとセカンダリの使い分け）。

エラーハンドリングの柔軟性を持たせることができ、失敗したリクエストに対して手動で対応できる場面が増えます。

Aとの比較：

Aの選択肢では、SQSをデッドレターキューとして使用する方法が提案されています。こちらも有効ですが、Bの方法では、より高い柔軟性を持って複数のキューを使用することで、失敗時にさらに多くの制御を持たせることができます。

結論：

Bは、データの損失を防ぎつつ、失敗したデータの処理を後で行うために適切なアーキテクチャです。特に、プライマリキューとセカンダリキューを使い分けることで、エラーハンドリングの手法を強化できるため、こちらのアプローチが最適であると言えます。