179-AWS SAP AWS 「理論・実践・一問道場」エラーハンドリング SQS

type

status

date

slug

summary

理論

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

イベント駆動型アーキテクチャでは、システムは「イベント」に反応して動作します。イベントは例えばユーザーのアクションや外部システムからの通知などです。これにより、システムは非同期で動作し、イベントが発生するたびに適切な処理が行われます。

SNS (Simple Notification Service) は、イベントを発行するためのメッセージングサービスです。SNS は、複数のサブスクライバー（例えば Lambda 関数）にメッセージを一斉に通知します。

Lambda はサーバーレスコンピューティングで、SNS からのイベントを受けて自動的に処理を行います。

2. 自動スケーリング

システムは、受信するリクエストやイベントの量に基づいてリソースを自動的に増減させる能力を持つべきです。これにより、システムは効率的にリソースを使用し、過負荷になることを防ぎます。

Lambda は、イベントの量に応じて処理能力を自動的にスケールイン・スケールアウトできます。これにより、大量のイベントが来ても自動で処理能力が増えます。

EC2 Auto Scaling は、EC2 インスタンスを動的にスケールするための機能で、リソースの需要に応じてインスタンス数を増減させます。

3. エラーハンドリング

エラーハンドリングは、処理中のイベントが失敗した場合に重要です。失敗したイベントは、後でレビューや再処理できるように、別のキューに移動する必要があります。

SQS (Simple Queue Service) は、メッセージを保存し、失敗したメッセージをデッドレターキューに移動させることでエラーハンドリングを行います。

まとめ

この問題は、SNS や Lambda を使用したイベント駆動型アーキテクチャの設計に関連しており、自動スケーリングやエラーハンドリングがどのように実装されるかに焦点を当てています。

実践

略

一問道場

問題 #179

トピック 1

ソリューションアーキテクトがイベントを処理するソリューションを設計しています。このソリューションは、受信するイベントの数に基づいてスケールインおよびスケールアウトする能力を持つ必要があります。処理エラーが発生した場合、イベントはレビューのために別のキューに移動する必要があります。

どのソリューションがこれらの要件を満たしますか？

A. イベントの詳細を Amazon Simple Notification Service (Amazon SNS) トピックに送信します。AWS Lambda 関数を SNS トピックのサブスクライバーとして設定し、イベントを処理します。関数に失敗時の宛先を追加します。Amazon Simple Queue Service (Amazon SQS) キューをターゲットとして設定します。

B. イベントを Amazon Simple Queue Service (Amazon SQS) キューに公開します。Amazon EC2 Auto Scaling グループを作成します。Auto Scaling グループを設定し、キューの ApproximateAgeOfOldestMessage メトリックに基づいてスケールインおよびスケールアウトを行います。アプリケーションを設定して、失敗したメッセージをデッドレターキューに書き込みます。

C. イベントを Amazon DynamoDB テーブルに書き込みます。テーブルに対して DynamoDB ストリームを設定します。ストリームを設定して AWS Lambda 関数を呼び出し、Lambda 関数でイベントを処理します。

D. イベントを Amazon EventBridge イベントバスに公開します。Amazon EC2 インスタンス上でアプリケーションを作成し、Auto Scaling グループで実行します。アプリケーションロードバランサー (ALB) の背後に配置します。ALB をイベントバスのターゲットとして設定します。イベントバスを設定してイベントをリトライします。アプリケーションがメッセージを処理できない場合、デッドレターキューにメッセージを書き込みます。

解説

この問題は、イベントを処理するための 自動スケーリング と エラーハンドリング の要件を満たすソリューションを選択する内容です。解説を以下にまとめます。

問題の要件

スケールインおよびスケールアウト: システムは受信するイベント数に基づいて自動的に処理能力を増減させる必要があります。

エラーハンドリング: 処理中にエラーが発生した場合、イベントは別のキューに移動してレビューする必要があります。

各選択肢の解説

A. SNS + Lambda + SQS

SNS (Simple Notification Service): SNSは、イベントを発行するサービスで、イベントが発生すると、SNSにサブスクライブしている Lambda 関数 に通知されます。

Lambda: Lambdaは、SNSから受け取ったイベントを自動的に処理します。Lambdaは並列実行により自動的にスケールし、イベント数の増加に対応できます。例えば、イベント数が増えればLambdaのインスタンス数が増加します。

SQS (Simple Queue Service): もしLambdaでイベント処理が失敗した場合、Lambdaは失敗時に指定されたSQSキューにエラーイベントを移動できます。これにより、失敗したイベントは後で確認でき、処理漏れを防げます。

この選択肢は、イベント数のスケーリングに関して非常に効果的で、エラーハンドリングの仕組みも適切です。

B. SQS + EC2 Auto Scaling

SQS: イベントが SQS キュー に送られ、キューにメッセージが蓄積されます。処理能力が不足している場合は EC2 Auto Scaling を使ってEC2インスタンスを増加させます。

EC2 Auto Scaling: メッセージ数に基づき、EC2インスタンスの数が増減します。負荷が高ければインスタンス数を増やし、低ければ減らします。

デッドレターキュー: 処理に失敗したメッセージは、SQSのデッドレターキュー（DLQ）に送られ、後で確認できるようになります。

この選択肢は、イベント処理のスケーリングにおいて EC2 Auto Scaling を使用しており、柔軟ですが、EC2インスタンスの管理 が必要で、他の選択肢よりも運用がやや複雑になります。

C. DynamoDB + Lambda

DynamoDB: イベントをDynamoDBに書き込むと、DynamoDB Streamsを使って変更をトリガーできます。

Lambda: DynamoDB StreamsからLambda関数がトリガーされ、Lambdaがイベントを処理します。

このアーキテクチャでは、自動スケーリングに関しては Lambda による処理のスケーリングはありますが、DynamoDB自体にはイベント数に基づくスケーリングの仕組みがないため、スケールイン・スケールアウトが必ずしも最適に行われるわけではありません。また、エラーハンドリングの詳細が不足しており、失敗したメッセージの処理が不明確です。