AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴 - Qiita
著者: 伊藤 雅博, 株式会社日立製作所 はじめに AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスのうち、ストリームデータを扱う際によく活用されている下記サービスの特徴を紹介します。 Amazon Kinesis Data Streams (KDS) Amazon Managed Streaming for Apache Kafka (MSK) Amazon Simple Queue Service (SQS) なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照
Sidekiq で最大回数リトライ後に失敗した場合出すログに例外のバックトレースを含める - Qiita
この記事では Sidekiq 5 系を対象にしていますが、4 系でも変わらない内容です。 Sidekiq Worker を利用する利点の一つに、 リトライ処理 を Sidekiq に任せられる点があります。 リトライを安全に実行するために、Sidekiq Worker の処理を冪等にしておくことは Sidekiq の Best Practice にも触れられています。以下は引用です。 2. Make your job idempotent and transactional Idempotency means that your job can safely execute multiple times. For instance, with the error retry functionality, your job might be half-processed, throw an
Shoryuken を導入しようとして諦めた話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Rails で非同期処理といえば、 Sidekiq, Resque, DelayedJob あたりが有名かと思います。 DelayedJob は RDS をジョブキューとして利用できる1ため、インフラの準備が不要で比較的ライトに導入できますが、数万件のジョブを登録しようと思うと RDS にかなりの負荷がかかりますし、Insert もそれほど早くないため、ジョブキューとしてはあまり適しているとは言えません。 Redis などのインメモリーデータベースを用いれば、RDS に負荷をかけず、Insert の高速化も見込めますが、万が一 Redi
RSpec でキューイングした ActiveJob を同期実行する - Qiita
ジョブの実行をテストしたいとき、キューに入ったことをテストしたいだけのときと、その実行結果まで含めてテストしたいとき（つまり同期実行したいとき）がある。 前者であればRails.application.config.active_job.queue_adapter = :testで足りるが、後者を実現するためにはどうすればよいだろう。 方法はいくつかあって、まずはRails.application.config.active_job.queue_adapter = :inlineとする方法。 これは簡単に同期実行は実現できるが、こんどはキューに入ったことが確認できなくなってしまうし、他の非同期のままにしておきたいところまで影響がでてしまう。 またSidekiqを使っているのであればSidekiq::Testing.inline!やSidekiq::Testing.fake! で制御すること
ActiveJobでリトライ制御 - Qiita
ActiveJob はまだまだリトライ制御機能が弱く、retry_job での単純な再実行位しか機能がありません1。 そこで、公式ドキュメントで公開されている API のみを活用し、ある程度の制御が行えるモジュールを作成しました。 成功するまでリトライ まず retry_job を使ったシンプルな例です。 StandardError が発生すると、rescue_fromで補足され、5分後に再実行するようにスケジューリングされます。 ただし、これでは成功するまで無限にリトライが行われてしまいます。リトライ回数の制限を行おうと思っても、現状 ActiveJob ではその制御機構がありません。 当然 Gems もいくつか既に提供されていますが、まだまだ「これが間違いない」と思える gem が出てきてないように思います。 おそらく一番 Github でスターが多いのが ActiveJob::Ret
Sidekiqで非業の死を遂げたキューを知る方法 - Qiita
前置き：Rubyのキューイングシステム Rails（Ruby）で非同期にキューイングしてくれるライブラリといえばSidekiqですよねっていうくらいSidekiqが好きなんですが、世の中のシェア的にはResqueなのかな。でも、Sidekiqの方が安定的に動かせているので僕は好きです（delayed_jobは知らない）。 ShoryukenというAWS SQSを使ったキューイングシステムもあり、RedisじゃなくてSQS使いたいっていう場合は、これも良いのかもしれないですね。まぁ、ローカルの場合面倒そうな感じもありますけど。 phstc/shoryuken まぁともかくSidekiqを導入してキューイングするっていうのは、もう超絶簡単にできるわけです。できるんですけど、実際にラフに運用していくと、キューがいつの間にかこけて処理待ちで埋まってたり、レアなケースで例外投げて死んでたりするわけで
Elixirを使ってSidekiqを操作する - Qiita
はじめに これは 【その1】ドリコム Advent Calendar 2015 の19日目の記事です。 18日目はYさんの記事でした。 【その2】ドリコム Advent Calendar 2015の18日目はwasbi01さんの記事でした。 寺社自社で開発/運用している、Elixirを利用した広告配信システムについて紹介したいと思います。 自己紹介 @ohrdev 普段は写経(仏教的な意味で)や仏像彫り、寺社仏閣巡りをしています。 空いた時間はドリコムという会社で広告周りのシステムの開発をしています。 好きなbehaviourはgen_eventです。 Elixirについて ElixirはErlangのVM上で動作する比較的新しいプログラミング言語です。 Erlangで実装されている為、分散、耐障害性、ソフトリアルタイムといった(Erlangの)特徴を兼ね備え、Elixir独自の、マクロ、
heroku schedulerの使い方(Rails,sinatra) - Qiita
herokuで定期的な処理を行いたい場合、大体はaddonのheroku Schedulerを使うことになると思うので、簡単にまとめてみる。 特徴など タスクは複数登録可能 タスクの起動間隔は10分おき、1時間おき、1日おきで選べる。 heroku schedulerはベストエフォート型のサービスなので、実行開始時間は多少の遅延したり、スキップされることがあるので注意する 無償でできるのはプロセスの利用時間は1Dynos (= 750時間(/1ヶ月)) WebのDynosを1つ利用していた場合、（1ヶ月が31日の場合） 24h * 31日 = 744hなので、残りの6h分のプロセスのみスケジュールタスクとしての処理時間として利用できます。 それ以降は1時間あたり$0.05かかる（1ヶ月フル使用で$37.2) 利用状況は https://dashboard.heroku.com/accoun
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shoryukenの諸動作 - Qiita
純粋関数型データ構造（８）〜Banker's Queue〜
ruby on railsでShoryukenを使うときにGod(神様)を使って監視をする - Qiita
[Elixir] Task QueueのExqをPhoenixで使う - Qiita![[Elixir] Task QueueのExqをPhoenixで使う - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/00e1ec89ec5a4430e2df1eca818e79c20d8127b5/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGNTY0NCUyRnByb2ZpbGUtaW1hZ2VzJTJGMTQ3MzY4MjE2MT9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz01YjRjNmNlYzdlMzQ2Njg1OWI3NGVmYjZmMjc4NWJlMg%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D1875469e12d646b293317dcd5ed54352%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCRWxpeGlyJTVEJTIwVGFzayUyMFF1ZXVlJUUzJTgxJUFFRXhxJUUzJTgyJTkyUGhvZW5peCVFMyU4MSVBNyVFNCVCRCVCRiVFMyU4MSU4NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTkxYjIwOGI1ZWEyMzg3MDQ3NDI0ZDVhZjM5MTdjZWQ5%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBGTDRUTGlOMyZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWRiM2I4MDM2NmNmY2ZiMzQ0YzE0OTc1MjIyMmMxZWQ1%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Dfcf883422b9daf169084e8a39627075f)