Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
SQS を使った Python の非同期ワーカーは ndkale しかない - kawasin73のブログ
誰一人見捨てない!!! どうも、かわしんです。Celery は見捨てるんです。 この記事は Pythonその2 Advent Calendar 2019 の 15 日目の記事です。 やや強めのタイトルですが、AWS SQS を使った非同期ワーカーでまともな実装は ndkale しかないという内容です。Celery は論外です。 github.com 前半はディスってばっかりなので、ndkale のことだけを知りたい場合は途中の「大本命 ndkale」から読んでください 前提としての欲しい機能 まず、諸々をディスる前に非同期ワーカーとして欲しい機能をあげておきます。 正しく SQS を使って信頼性のあるタスク実行をする 即時再実行をする 複数のキューを使い分ける。また同じタスクでも動的に利用するキューを切り替えたい Dead Letter Queue も使えると嬉しい まず Celery を
Amazon SQSでFIFOだからってシステム全体が Exactly-Once になると思ったら大間違いだっていう話 - Smoky God Express
TL; DR Amazon SQS で Exactly-Once なキューを使おうとも冪等な処理を書くべき キューが Exactly-Once であるという性質はシステム全体が Exactly-Once になることを保証できない 結局マルチデータソースへの書き込みの問題が残る Designing Data-Intensive Applications (邦訳: データ指向アプリケーションデザイン） が良書でした 邦訳は未読1ですが原著の内容がいいのできっとだいじょうぶでしょう Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 作者: Martin Kleppmann出版社/メーカー: O'Reilly Media発売日: 2017/
AWSでSESと無料のSQSを使って快適なメールマガジン配信システムを構築した話 - ぷれすとぶろぐ
Amazon Web ServiceでSESとSQSを使って、大量に高速に送ることが出来るメールマガジン配信システムを構築してみました。 もともと、別の開発者の人が開発していたものを、引き継いで受託していたサービスが、日々会員数が増えるたびにメールの配信時間が伸びていき、最終的に2万人に配信するのに6時間ほどかかるシステムになっていました。 システム システム構成はシンプルでAWSのEC2のインスタンス上でDBやアプリケーションが動いており、画像などのリソースの保存にS3を、メール送信にSESを使っています。 ちなみにアプリケーションはJavaEEです。最近ではちょっと珍しい？ですね。 問題点 もともとのシステムは、管理画面から登録されたメルマガ情報からメルマガを受診する対象のユーザーを取得し、名前などを埋め込んだスプールを作成する「スプール生成バッチ」と、DBに登録されたスプールを順番に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
