タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
p2: https://speakerdeck.com/morihirok/ruby-on-rails-nole-simifang p4: https://speakerdeck.com/moro/dynamic?slide=41 p44: https://github.com/sidekiq/si…
kaigi on rails 2024の発表資料です https://kaigionrails.org/2024/talks/willnet/
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に！ ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン！ Pub/Sub との比較検討もしましたが今回は
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Use Sidekiq Directly, Not Through Active Job - Andy Croll 原文公開日: 2021/10/04 著者: Andy Croll 参考: 週刊Railsウォッチ20211018: SidekiqをActive Job経由ではなく直接使う 参考: Active Job の基礎 - Railsガイド Webアプリケーションを構築する場合は、ユーザーごとのレスポンスに要する時間を最小限に留めるべきです。Webサイトが速ければ速いほど、その分ユーザーも幸せになれます。 そのための方法の1つは、重くなる可能性のある処理（実行に長時間かかる、パラレル化可能な処理）を、イミディエイトなWebリクエストの外で非同期実行することです。メール送信、計画的なクリーンアップ、長時間かかる計算、外部API
2024.10.25 Fri Kaigi on Rails 2024@有明セントラルタワーホール & カンファレンス（東京）
Kaigi on Rails 2024 に参加しました こんにちは、クラウドハウス採用でエンジニアインターンをしている Higashiji です。 10 月の 25・26 日、Ruby on Rails についてのカンファレンス、 Kaigi on Rails 2024 が開催されました。 弊社からは新卒エンジニアの @izumitomo が「デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ～俺のやらかしを越えてゆけ～ 」というセッションで登壇しました。 スライドがアップロードされているので、興味を持っていただけた方はぜひご覧になってください。 私はこれまでカンファレンスに参加したことがなかったのですが、カンファレンス参加費補助制度を使って初めて参加させていただきました。 本記事では、Shinichi Maeshima (@willnet) さんによるセッション Sid
はじめに こんにちは、プロダクト開発部の勝間田です。 先日、サービスのパフォーマンス向上のため、ECSで稼働しているSidekiqコンテナのvCPUをスケールアップしました。増やしたCPUリソースを最大限に活用すべく、Sidekiqのconcurrencyも引き上げたのですが、CPU使用率が期待通りに上がらず、オートスケールが機能しないという事態に陥りました。 この出来事をきっかけに、CPU、プロセス、スレッド(concurrency)、そしてRubyのGVL（Global VM Lock）について自分の理解が不十分だと気づきましたので、これらについて調査・検証を行いました。 きっかけ：予期せぬCPU使用率の低下 私たちのサービスでは、バックグラウンドジョブの実行にSidekiqを利用しています。CPU使用率に基づいたオートスケールを設定しており、1vCPU 8GBの環境で処理していました
This post was endorsed by Mike Perham, the creator of Sidekiq, after its publication. Sidekiq is one of the most ubiquitous1 Ruby background job processors out there. To anybody who has worked with Ruby on and off Rails, it needs no introduction. Sidekiq has a 10+ year track record of being an efficient, battle-tested and simple-to-use solution for offloading the execution of application logic int
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: How we migrated from Sidekiq to Solid Queue - BigBinary Blog 原文公開日: 2024/03/05 原著者: Chirag Shah 日本語タイトルは内容に即したものにしました。 私たちBigBinaryは、neetoでさまざまなプロダクトを構築しています。現在22のプロダクトを開発中で、それらはいずれもSidekiqを利用しています。Solid Queueが公開された後で、私たちのneetoFormで使われているSidekiqをSolid Queueに移行する決定を下しました。 なお、現時点のSolid Queueはcronスタイルのジョブや定期的に繰り返されるジョブ実行をサポートしておらず、これに関するプルリク#155がオープンされています。そういうわけで、Solid
初めまして、株式会社Techouseでバックエンドエンジニアをしている本澤(mottei)と申します。本日は私の携わっているプロダクトであるクラウドハウス労務で利用されている分散プログラミングの技術について紹介します。 クラウドハウス労務について 分散プログラミングについて紹介する前に、私が開発しているクラウドハウス労務について、なぜ分散プログラミングが必要かの説明も兼ねて紹介します。 クラウドハウス労務は労務業務の電子化を推進するためのクラウドサービスです。人事労務担当と従業員との手続き機能・年末調整などの法定業務など様々な機能を持っており、企業の人事労務担当者と従業員とのやりとりを簡単に行うことができます。 これらのたくさんの手続きによって集められた大量の従業員データは、クラウドハウス労務のデータベースに格納されています。クラウドハウス労務は大企業が持つ基幹システムなどの別システムとの
2025-03-10 After six months of hard work, I’m thrilled to announce the general availability of Sidekiq 8.0! 🥳🎉 Status Sidekiq is used by thousands of Ruby applications around the world to scale job processing up to billions of jobs/day. Current Sidekiq Enterprise customers are reporting a grand total of 1,806,671,058,604 jobs processed, almost two trillion, with my largest customer executing up
はじめに Ruby on Rails (以下Rails) でバックグラウンドジョブを実行する際に一番よく使われているのGemである、Sidekiqのバージョン7.0（以下Sidekiq 7）が2022年10月にリリースされました。 このバージョンでは、管理画面へのメトリクスの追加、Pumaなどのプロセスへの埋め込み、キュー毎の同時実行数を制限するカプセルなど、以前よりも大きな機能追加が行われています。 本記事では、Sidekiqの公式サイトの記事や、GitHubの公式プロジェクトの内容を元に、Sidekiq 7の新機能や変更点の解説を行います。 注意点 本記事で取り扱うエディション 本記事ではGitHubで公開しているOSS版のSidekiqについて記述しています。Pro / Enterprise版を使用している場合は、公式サイト（英語）を参考にしてください。 サポートされるRails /
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
概要 ECS環境にRubyのジョブ管理ライブラリSidekiqを導入する際にやったことをまとめてみました 背景 メール送信のように時間がかかる処理や、重たい処理を分割して並列実行したいときに非同期ジョブを使いたくなることがありますよね。 RailsにはActiveJobというジョブ管理のAPIが用意されていますので、これを使わない手はないです。 Railsガイドのジョブを実行するに書かれている通り、本番環境で使うには何らかのキューイングバックエンドが必要です。 production環境でのジョブのキュー登録と実行では、キューイングのバックエンドを用意しておく必要があります。具体的には、Railsで使うべきサードパーティのキューイングライブラリを決める必要があります。 Rails自身が提供するのは、ジョブをメモリに保持するインプロセスのキューイングシステムだけです。 プロセスがクラッシュした
2024-02-04 This article was originally published on DanSvetlov.me and is republished here with permission of the author. This article is relevant to Sidekiq v7. Sidekiq is one of the most ubiquitous1 Ruby background job processors out there. To anybody who has worked with Ruby on and off Rails, it needs no introduction. Sidekiq has a 10+ year track record of being an efficient, battle-tested and s
はじめに こんにちは。 SREグループの佐々木と申します。 Amazon ECS（以下、ECS）を使っていて、ローリングアップデート時に、コンテナ上のSidekiqで実行中のジョブに影響が無いのか、気になったことはありませんか？ この記事では、ローリングアップデート時のECSとSidekiqの挙動、ローリングアップデート時に気をつけるポイントを紹介します。 背景 最近、「Sidekiq::Shutdown」のエラーメッセージと共に落ちたジョブがいました。 リリースの際に発生していたので、ECSのローリングアップデート起因で、Sidekiqのジョブが強制終了してしまい、ジョブが落ちたのだろう。と想定していました。 とはいえ、あくまで想定です。 また、ジョブが落ちたことによる影響の有無が分かりませんでした。 そこで、エラーメッセージの原因を調査するために、ECSとSidekiqの挙動を追いま
2022-01-17 It’s hard for me to believe these words but I pushed Sidekiq’s first commit on Jan 16th, 2012. Ten years ago. The public announcement. One month later. One quarter later. Some context for those new to this blog: Sidekiq is the most popular background job system for the Ruby programming language. Every application has tasks which are important: send an email, charge a credit card, reserv
はじめに こんにちは、プロダクト開発部の勝間田です。 非同期処理は、即時の応答が不要な処理をバックグラウンドで並行処理することでユーザー体験を向上させるものであり、私たちのサービス TUNAG（ツナグ）では主にSidekiqを利用しております。 即時の応答が不要な処理とはいえ、そこで大きな遅延（Latency）が発生してしまえば、ユーザー体験を損ねることにつながってしまいます。 Sidekiqの設定でキューの重みづけを行い、ユーザーへのインパクトが大きいジョブが優先的に処理されるよう工夫はしていましたが、優先度の低いキューとはいえ、その遅延が大きくなることがありUXに少なからず影響が出始めていました。 これまでスケーリングについてはECSタスクのCPU使用率ベースのオートスケーリングに任せていました。 それとは別で定期実行によりSidekiqのキューが一定数以上滞留してしまった場合はSla
SidekiqでのSentry通知/リトライの設定方法の話と、「普段は無視するけどリトライが全て失敗した時だけSentry通知したい」といった設定の方法の話をします。 はじめに Sidekiqは6.2 Rails(だけどActiveJobは使わない) sentryのgemはsentry-ruby の前提です。 (なお、Sidekiqはwikiがとっても充実しているので、たいていのことはそこを見ればわかります。 とくに今回のエントリはwikiのエラーハンドリング の内容が参考になります。) 1. Sentryに通知し、リトライもしたい場合 このケースでは、rescueせずに、単に例外を投げっぱなしにすれば良いです。 class FooWorker include Sidekiq::Worker sidekiq_options retry: 5 # 設定しないとデフォルトは25。 class
表題の通り、発表してきました。 Sidekiq vs Solid Queue | Kaigi on Rails 2024 スライドはこちら。 発表に至るまでの道のり イベントの懇親会などでエンジニアの人と話しているときに「最近気になっているgemあります？」のような質問に「Solid Queueですかねえ」と返すと「なんですかそれ？」と聞かれたりする イベントの懇親会などでSidekiqを使っている会社さんの中の人にProやEnterpriseつかってます？と聞くと「なんですかそれ？」と聞かれたりする 新しいRailsで標準になったが、既存のRailsアプリケーションには影響がないもの(例: importmaps)に対して「Railsアップグレードするならこれ対応しないといけないですか？」と聞かれたりする SidekiqとSolid Queueをお題にして話せばこの手の疑問を一気に解決でき
ウォンテッドリーでバックエンドエンジニアをしている冨永(@kou_tominaga)です。本記事では、「ジョブが途中で止まり、ログにも例外が残らない」問題を原因特定から対策比較、実装まで順に解説します。一見まれな事象に見えますが、実際にはミドルウェアの設定値、デプロイやスケールインのタイミングなど、特定の運用条件が重なると再現しやすい問題でした。本記事ではその仕組みを明らかにし、同様の問題を防ぐための知見をまとめています。 目次前提 背景・問題の発見 解決策の検討 実装の詳細 1.SIGTERM を検知できるようにする 2.自己再エンキューによる再実行 結果と効果 まとめ 前提ウォンテッドリーでは、任意のタイミングでデプロイを実行できる オンデマンドデプロイ を採用しています。アプリケーションは Kubernetes 上で稼働しており、本記事はその環境で発生したジョブ中断の事象について解説
Railsでアプリケーションを作っていると非同期処理でSidekiqを使用することが多いと思います。今回はSidekiqを使用する際の注意点について記載していきます。 具体的には リトライサーバプロセスが落ちると、jobのデータは失われるメモリ肥大化する問題並列実行数制御について記載します。 Sidekiqを正しく理解して安全に使おう！という記事になります。 まずはSidekiqとは？について記載していきます。 Sidekiqとは Railsで非同期処理を行うためのgemです。複数の非同期処理を同時に実行することができ、サーバリソースを有効活用できます。 以下、処理イメージです。 Rails WEBサーバがリクエストを受け付けるRails WEBサーバは非同期でしたい処理をRedisにjobとして格納するSidekiqが動いているサーバがRedisからjobを取得するSidekiqはjob
After Kaigi on Rails LT Night で登壇しました https://smartbank.connpass.com/event/299631
背景と目的 Rails8.0 ではActive Jobの機能が拡充されたことに加え、これまでの Sidekiq や Resque などに加えて、新たに Solid Queue という選択肢が提示されました。しかしながら、Sidekiq の公式ドキュメントでは以下のような性能差が示唆されています： Active Job 経由と Sidekiq ネイティブ使用で 約1.2倍の差 Solid Queue と比較すると 最大15倍の差 果たしてこれらの差は現実にどの程度再現されるのか？ また、Solid Queue を使う場合に Sidekiq に並ぶ性能を発揮するにはどのような設定が必要なのか？ OSS ライセンスの範囲内で各方式の性能を定量的に検証しました。 実験環境 実験環境としては筆者のPCにてDocker Desktopのコンテナを利用しました。 Ruby: 3.3.5 Rails: 8
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails: 先週の改修（Rails公式ニュースより） 公式更新情報: Ruby on Rails — Enhanced assert_broadcast
【アドカレ2023】Sidekiqのredis-namespace gemからの脱却 これは 株式会社TimeTree Advent Calendar 2023 の12日目の記事です。 11日目は @gonsee の カレンダー開発の怖い話: 週番号 の記事 でした。 こんにちは。今年の4月からTimeTreeに入社し、プロダクトDivというチームに所属しています。 社内では Dashというニックネームで働いています。 この記事では、 redis-namespacegemからの脱却までに行なった手法などを紹介していこうと思います。 ※この記事に使用しているバージョンはそれぞれ下記の通りです。 Ruby on Rails：7.0.8 ElasticCache for Redis：7.0.7 Sidekiq Pro：5.5.8 redisgem：4.8.1 redis-namespacegem
Sidekiqのエラーハンドリング 最終更新 2019/07/20 編集者 Scott E. Knight このことについて言及したくはないのですが、ワーカーはジョブの実行中に例外を起こすことがあります。これは避けることのできない事実です。 Sidekiqはすべてのタイプのエラーを処理するための数多くの機能を持っています。 ベストプラクティス エラー集約サービスを使用する。 Honeybadger、Airbrake、Rollbar、BugSnag、Sentry、Exceptiontrap、Raygunなど。これらはすべて機能セットと価格が似ています。いずれかを選択してください。エラー集約サービスは、ジョブに例外が発生するたびにメールを送信します（Honeybadgerなどのよりスマートなものは、1番目、3番目、および10番目の同一エラーで電子メールを送信するため、1000個のジョブが失敗し
![Sidekiqのエラーハンドリング [翻訳] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/12161c42fa66788754fa2989ed2994ea29a00976/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%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%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMzMwMTElMkZwcm9maWxlLWltYWdlcyUyRjE0NzM2ODYwMjg_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmJnPUZGRkZGRiZmbT1wbmczMiZzPTI5NDgwZjk5MzJhYTJlOWJmNjY4MmE3MDhmNTVhMzI5%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D7e85cc9bb73e3bb7d53bcf49a761834e%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9U2lkZWtpcSVFMyU4MSVBRSVFMyU4MiVBOCVFMyU4MyVBOSVFMyU4MyVCQyVFMyU4MyU4RiVFMyU4MyVCMyVFMyU4MyU4OSVFMyU4MyVBQSVFMyU4MyVCMyVFMyU4MiVCMCUyMCU1QiVFNyVCRiVCQiVFOCVBOCVCMyU1RCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTg1Y2I1OTFmNzgyNWM0ZDZhZTliZTk4MDVhZDgyY2E3%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDB0cy0zMTU2JnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9NjVkNzA2NWZhZmFiZDY2ODAyYjc3OGFhNWFjMmUzZjk%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Da0d2bb32e265d367db4d0d6880ebf384)
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails: 先週の改修（Rails公式ニュースより） 今回は以下の更新情報から見繕いました。 更新情報: Perform destroy_all in
こんにちは。サーバーサイドグループの山田です。 最近クロスバイクを買って自転車で走ることにはまっています。 弊社ではRailsアプリケーションの非同期処理やバッチ処理でSidekiq/Sidekiq Enterpriseを使用しています。 tech.studyplus.co.jp Sidekiq Enterpirseには便利な機能が多くありますが、今回は Rate limiting の Concurrent について書いていきます。 なぜConcurrentかというと、先日この設定内容が原因で想定外に大量の待機ジョブを発生させてしまったためです。 その失敗を交えて紹介していきます。 TL;DR Rate LimitingのConcurrentを使う場合 ジョブの処理時間に合わせたlock_timeoutを設定する ジョブの処理を修正する場合はlock_timeoutも見直す Sidekiq
kaigi on rails 2024の発表資料です https://kaigionrails.org/2024/talks/willnet/
1. 概要 sidekiqプロセスのメモリ使用率が元に戻らない悩みを解消するためのイチ手段として、 gem「sidekiq-worker-killer」を使う がある。 残念ながら、上記GitHubのReadmeのみでは、その詳細な挙動を知ることは難しい。 そこで本記事では、sidekiq-worker-killerのソースコード(ver.1.0.0)、およびその他関連情報を調査し、sidekiq-worker-killerの設定項目・挙動について全体的にまとめた。 sidekiq-worker-killerの設定の意味・設定方法 sidekiq-worker-killerの処理開始タイミング sidekiq-worker-killerの処理開始後の挙動 2. sidekiq-worker-killerの設定の意味・設定方法 sidekiq-worker-killerのオプション設定につい
2022-10-27 I’m proud to announce, after nearly a year of work, Sidekiq 7.0 is now available. Sidekiq is the most popular background job system for Ruby, used by thousands of companies around the world. This release is our biggest, most splendiforous release ever! What’s New? Metrics One thing I know: everybody loves big beautiful graphs! Sidekiq 7.0 has a major new feature for tracking and visuali
はじめにSidekiq は主にRuby on Rails用に広く使われているジョブキューです。 Sidekiqは通常Ruby on Railsのアプリケーションコードから呼び出される形で使われますが、障害対応などのために管理画面やRuby APIからの操作が必要になることもあります。本稿ではSidekiqのRuby APIを使うときのTipsをまとめました。 公式の資料API - mperham/sidekiq Wiki (日本語訳)rubydocいつAPIが必要か溜まりすぎたジョブを削除したり、失敗しすぎて停止してしまったジョブの調査・再実行をしたりといった作業が必要になることがあります。 こういった調査と操作は管理画面からでもできますが、ある程度の自動化 (特定条件を満たすジョブを全てドロップするなど) が必要なときにはAPIが有用です。そのため本稿ではジョブ操作APIに特化して説明し
最近 Rails アプリケーションにSidekiqを導入したので、 そのときに考慮したポイントと参考になった記事をまとめておく。 考慮したポイント ログ リトライ ActiveJob/ActionMailer との連携 concurrency の設定 Redis/ElastiCache テスト デプロイ shoryuken その他知見 ログ Sidekiq のロギングに Rails logger を利用する - Qiita 通常だとconfig/sidekiq.ymlに設定したログファイルに Sidekiq のログは出力される。 別の出力先にしたいときはSidekiq::Logging.loggerを置き換えると良いとのこと。 Sidekiq で最大回数リトライ後に失敗した場合出すログに例外のバックトレースを含める - Qiita Sidekiq はデフォルトで失敗したジョブのリトライをや
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
FargateでRailsコンテナと別にSidekiqを動かしたかったので試してみました。 その手順を書いていきます。 なお、RailsにSidekiqを導入するやり方については、本記事では紹介しません。 前提 RailsアプリをFargateで動かすまでにやり方については以下の記事に書いております。 Sidekiqの設定確認 Sidekiq.configure_server do |config| config.redis = { url: "redis://#{ENV.fetch("REDIS_URL", "localhost:6379")}", namespace: "sidekiq" } end Sidekiq.configure_client do |config| config.redis = { url: "redis://#{ENV.fetch("REDIS_URL", "
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: “Fair” multi-tenant prioritization of Sidekiq jobs—and our gem for it!—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2024/02/14 原著者: Andrey Novikov（バックエンドエンジニア）、Travis Turner（技術記事編集者） サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。 はじめに 多くのバックエンドアプリケーションのマルチテナ
こんにちは。スタディプラスのSREグループの水口です。 2022年5月に入社してからStudyplus Engineering Podcastには何度か出演しておりましたが、テックブログは今回初めて書きます。 この記事では、SidekiqをKubernetes(Amazon EKS)で動作させる際、Graceful Shutdownさせるために必要な前提知識を整理します。 背景 Sidekiqプロセスの停止 SIGTERM + timeout オプション Kubernets Podの停止 Deploymentのマニフェストについて terminationGracePeriodSecondsについて Kubernetes Nodeの停止 Cluster Autoscaler について Amazon EC2 スポットインスタンス について 【参考】既存実装について おわりに 【宣伝】Podca
みなさん、こんにちは。まどぎわです。 rubyで非同期処理やるときのデファクトスタンダード的なgemsidekiqのコードを読んで、概要が割とつかめた気がしてきたので、どういう感じで動いてるか自分の理解の範囲でメモしてみました🙇 github.com sidekiqの機能としては大きく分けて、 Redisへのqueueのpush Redisからqueueのpopとjobの実行 だと思ったので、それについてsidekiqのコードと合わせて概要を整理してみました。 ※記載しているコードについては、読みやすいコードを削除しているので全文が読みたい方は、それぞれのリンク先で確認いただけますと🙏 前提 今回調べたsidekiqのversionは、2019/04/28現在のmasterである、6.0.0.pre1です。 # frozen_string_literal: true module Si
1. Active Jobとは バックグラウンドで実行するジョブをRailsアプリケーションで動かすための共通インターフェイスです。 例えばメール送信やCSVアップロード等の時間がかかる重い処理はバックグラウンドで実行することが多いです。 Rails 4.2で導入された機能で、非同期処理を実装する際にまず検討する事が多いかと思います。 2. 共通インターフェイスって？ Active Jobが導入される以前のRailsバージョンの場合、非同期処理を実装するGemを使用していました。 代表的なものではDelayed JobやSidekiq、Resqueがあります。 当然それぞれのGemで記述や機能が異なっていましたが、Active Jobはそうした違いを気にせずジョブを扱うことができるインフラ機能です。 Railsガイド Active Jobの目的によると、Active Jobには下記のような
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[みんなのケータイ]いつの間にか便利になっていたスマホアプリ版「NotebookLM」](https://cdn-ak-scissors.b.st-hatena.com/image/square/5c29d951f2848519d8dc4b845662d028327bbf07/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fk-tai.watch.impress.co.jp%2Fimg%2Fktw%2Flist%2F2062%2F435%2F1.jpg)
