【読書】乗り越えられないキューバックログの回避
challenge-every-monthの輪読会でAmazon Builders' Libraryの輪読会をやっており、その資料をグラレコで作ったので公開します。
先日東京リージョンでAWS SQSの障害が発生し、AWS LambdaやS3にも影響が及んでいましたが、その理解の一助にもなるかなと思って読んでみました。
グラレコ
感想
AWSソリューションアーキテクトアソシエイトを取得した時は、SQSを用いると可用性・耐久性の高いシステムを構築できるというメリットの方ばかりを意識していたのですが、今回のことでレイテンシーにも気を配るべきであることを学べました。
幾つか資料には含めなかったプラクティスがあったので、SQSを使いたいようなシステム構築の際は見返しておこうと思います。
幾つか資料作成時点では間違って理解しており、輪読会で指摘いただいたこともあります。（ @kdnakt さんありがとうございました！ ）
kdnさんのまとめはこちら。
誤訳箇所
一部明らかな誤訳を見つけてしまったのでPRか改善依頼を投げようかと思ったのですが、窓口が見つからなかったのでここで供養します。
原文：項 "How we measure availability and latency"
>We also get availability measurements from dead-letter queues (DLQ). If a message runs out of retries, it is dropped or put into a DLQ.
誤 :
>また、可用性の観測は、デッドレターキュー (DLQ) を通じても行えます。再試行中に届いたメッセージは、ドロップされるか DLQ 内に置かれます。
正：
また、可用性の観測は、デッドレターキュー (DLQ) を通じても行えます。規定回数以上再試行されたメッセージは、ドロップされるか DLQ 内に置かれます。
開発ガイドやユーザーガイドはOSSとして公開されているみたいなんですがね。
この記事が気に入ったらサポートをしてみませんか？