はてなブックマーク

この記事では 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

class CreateSuppliers < ActiveRecord::Migration[5.0] def change create_table :suppliers do |t| t.string :name t.timestamps end create_table :accounts do |t| t.belongs_to :supplier, index: true t.string :account_number t.timestamps end end end [2] pry(main)> Supplier.create(name: 'dan') (0.1ms) BEGIN SQL (27.8ms) INSERT INTO "suppliers" ("name", "created_at", "updated_at") VALUES ($1, $2, $3) RETUR

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Sidekiq の Server プロセス内でバックグラウンド処理をするとは Sidekiq は Client Side (Worker#perform_asyn を呼び出す方） と Server Side (スレッドベースで動作し Worker#perform を実行する方) の 2 つで構成されています。 Server Side の方はそれ自身がプロセスとして動作しており、そのプロセス内でさらにバックグラウンド処理を行っている拡張がいくつか存在します。 私が知るものの多くは「定期実行」と「cron のようなスケジュール」に関するものです。 ここでは、それらの拡張を見ていきながら、どういう手法でバックグラウンド処理を実施しているのかを見ていきます。 cron 処理に関するもの Sidekiq 本家としては Ent Periodic Jobs - sidekiq wiki 上記の Ente

Sidekiq 5 の変更点 Change.md - mperham/sidekiq 5.0-Upgrade.md - mperham/sidekiq 上記のどちらでも、Job Logging と Job Retry の変更点について真っ先に触れられています。 この変更点だけで言えば、おそらく直接的に影響があるのは、Job Logging と Job Retry が Sidekiq middleware として挿し込まれていたという前提で書かれているようなプラグイン系であり、普通に使っている分にはそれ程大きな影響は無いと思われます。 私自身も仕事で幾つかのプラグインと共に利用していますが、特に影響は出ていません。 この変更点の要因になっている内容が、この記事で触れることの大半です。 Sidekiq の PR から関連する変更点を見ていく もちろん全てではありません、一連の流れが分かりそうな

動機 Sidekiq は Sidekiq::Logging.logger に設定された Logger を利用し、デフォルトでは普通の Logger となっています。 加えて、デフォルトでは STDOUT への出力ですが、-L オプションや設定ファイルに指定することでファイルへの書き出しも可能です。 Logging - mperham/sidekiq Sidekiq を Rails と一緒に使っている場合は、Rails.logger と同じものを使いたいケース Fluentd を使っていたり、特殊なフォーマットを使っている場合に、Rails.logger に設定された logger はなんらか設定が反映された Logger である事もあると思います。 そういう場合に Sidekiq の Logger も設定を同じにできれば、Sidekiq 自身が出力するログもその設定通りになります。 あくま

mysql> use utf8mb4_sample_development; mysql> show variables like "chara%"; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesyste

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

チームメンバー毎でも書き方が違う時があるので、どういうやり方がありそうで、どういう時にそれを適用したら良さそうかを考えたメモです。 Faraday Ruby 製の HTTP Client です。Ruby Tool Box の HTTP Client カテゴリでは 2 位なので結構使われているライブラリなのではないかと思います。 lostisland/faraday - Github 本家の README を見てもらうと分かる通り、いくつかの adapter を選択できるようになっています。 また faraday_middleware を代表とした middleware といった形で拡張可能なのも特徴の一つのようです。 Qiita 内でもたくさん見つかりますね Qiita を faraday で検索 まずエラーもリトライも考慮しない書き方 response を受け取るまでは faraday

遭遇した状況 今回は中でも ElastiCache プライマリクラスターのみで障害が発生した場合 の話しです。 ドキュメントにもあるように、マルチAZ 環境での自動フェイルオーバーでの今回の状況においては 書き込みは、昇格プロセスが完了するとすぐに (通常は数分) 再開できます。ElastiCache が昇格したレプリカの DNS を反映させるため、書き込みのためのエンドポイントを変更する必要はありません。 となっています。 ポイントは、「DNS を反映させるため、書き込みのためのエンドポイントを変更する必要がありません」というところです。 発生した課題 自動フェイルオーバーが発生した際に、運用している Rails アプリから上記のエラーが止まらないと言う状況になりました。 最終的には、Web アプリ、ワーカーアプリともに、再起動することで状況は改善しました。 このエラーメッセージから分か

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

reset_session Ruby on Rails Security Guide では Session Fixation - Countermeasures の項目で紹介されています。 Ruby On Rails Security Guideの訳 : 2.Sessions 2.8 - FLATz Railsのセキュリティ セッション固定化の対策 - Ruby STUDIO 調べながら気になった記事 Rails アプリのセキュリティ対策入門 - Rubyist Magazine またセッション ID はログイン後に reset_session でリセットすることが望ましいそうです。 認証後にリセットする方法のサンプル そもそも認証が最初の画面なのであれば（ログイン画面が最初とか） SessionController#create の before で reset_session してしま