type
status
date
slug
summary
tags
category
icon
password
 

理論

1. 可視性タイムアウト

可視性タイムアウトは、メッセージが処理中であるときに他のコンシューマーに再び配信されないようにするための設定です。処理中のメッセージが再処理されることを防ぎますが、処理がタイムアウトすると、他のメッセージがブロックされる原因にもなり得ます。

2. デッドレターキュー (DLQ)

デッドレターキューは、処理に失敗したメッセージを隔離するために使用されます。これにより、故障したメッセージがシステム全体の処理を妨げることなく、後で分析して修正できます。デッドレターキューは標準キューかFIFOキューを設定できますが、通常は標準キューが推奨されます。

3. バックエンド処理とキュー設定の整合性

バックエンド処理タイムアウトと可視性タイムアウトが適切に調整されていないと、処理がタイムアウトし、メッセージが再度キューに戻され、再度エラーを引き起こす可能性があります。バックエンドの処理が終了する前にメッセージが再度キューに戻ることを防ぐために、可視性タイムアウトを適切に設定することが重要です。 バックエンド処理が完了するまでの時間が可視性タイムアウトより短くなるように設定することが重要です。これにより、メッセージの再処理を防ぎ、正常に処理が終了するまで他のコンシューマーがそのメッセージにアクセスしないようにできます。

4. FIFOキュー vs 標準キュー

FIFOキューはメッセージの順序を保証しますが、順序が重要でない場合やスループットが重視される場合には標準キューが適しています。標準キューは順序を保証しないため、より高いスループットを提供し、特にデッドレターキューとして使用する場合に適切です。
要点:
  • 可視性タイムアウトバックエンド処理タイムアウトの整合性を保つことが重要。
  • デッドレターキューを設定して、処理に失敗したメッセージを隔離し、後で分析・修正できるようにする。
  • 標準キューをデッドレターキューとして使用するのが最適。
これらの知識は、SQSを利用するシステムの健全性を保つために不可欠です。

実践

一問道場

質問 #276
トピック 1
ある会社がイベント駆動型アーキテクチャを使用して注文システムを実装しました。最初のテスト中にシステムが注文処理を停止しました。
さらにログ解析を行った結果、Amazon Simple Queue Service(Amazon SQS)の標準キューにある1件の注文メッセージがバックエンドでエラーを引き起こし、その後のすべての注文メッセージをブロックしていることが判明しました。
キューの可視性タイムアウトは30秒に設定されており、バックエンド処理タイムアウトは10秒に設定されています。ソリューションアーキテクトは、故障した注文メッセージを分析し、システムが後続のメッセージを処理し続けることを確実にする必要があります。
ソリューションアーキテクトがこの要件を満たすために取るべきステップはどれですか?
A. バックエンド処理タイムアウトを30秒に増やして可視性タイムアウトと一致させる。
B. キューの可視性タイムアウトを短くして、故障したメッセージを自動的に削除する。
C. 新しいSQS FIFOキューをデッドレターキューとして設定して、故障したメッセージを隔離する。
D. 新しいSQS標準キューをデッドレターキューとして設定して、故障したメッセージを隔離する。

解説

この問題では、Amazon SQSを使って注文システムが構築されており、1つの故障した注文メッセージが原因でシステム全体が停止してしまう状況です。目標は、故障したメッセージを分析しつつ、後続のメッセージが正常に処理されるようにすることです。
それぞれの選択肢を見ていきましょう。

A. バックエンド処理タイムアウトを30秒に増やして可視性タイムアウトと一致させる。

  • 誤り: バックエンド処理タイムアウトを可視性タイムアウトと一致させても、故障したメッセージが後続の処理に影響を与える原因を解決するわけではありません。可視性タイムアウトはメッセージが再処理されるまでの時間を制御するものであり、システム全体の停止を防ぐためには、エラー処理の方法を改善することが重要です。

B. キューの可視性タイムアウトを短くして、故障したメッセージを自動的に削除する。

  • 誤り: 可視性タイムアウトを短くしても、故障したメッセージの処理は早く終わらない可能性があり、結果的にメッセージの再処理が頻繁に行われ、システムが無限ループに陥る恐れがあります。故障したメッセージを自動的に削除する方法としては適切ではありません。

C. 新しいSQS FIFOキューをデッドレターキューとして設定して、故障したメッセージを隔離する。

  • 誤り: FIFOキューはメッセージの順序を厳密に保証しますが、このシナリオではメッセージの順序を厳守する必要はありません。デッドレターキューとしてFIFOキューを使用するのはオーバーエンジニアリングであり、標準キューの方が適切です。

D. 新しいSQS標準キューをデッドレターキューとして設定して、故障したメッセージを隔離する。

  • 正解: 標準キューをデッドレターキューとして設定することが最適です。デッドレターキューは、処理に失敗したメッセージを隔離するために使用され、これにより故障したメッセージが後続のメッセージ処理をブロックすることを防げます。標準キューは順序に依存しないため、後続のメッセージが正常に処理されることを確保できます。
結論: 正しい回答は D です。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
277-AWS SAP AWS 「理論・実践・一問道場」AWS Step Functions275-AWS SAP AWS 「理論・実践・一問道場」(AWS SCT)
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签