ruby で ElastiCache Redis （クラスターモード有効） 利用でハマった所
概要ruby で ElastiCache Redis （クラスターモード有効）を利用した際にハマったことをまとめます。 まず結論検証終わり、以下のコードにまとめました。 require 'redis' # redis/redis-rb を利用 # 接続先は Configuration Endpoint のみ指定すれば、 cluster でよしなに、 node にアクセスしてくれた♪ # 通信時(in transit), 保管時(in rest) に暗号化する様にすると`rediss://｀を指定する必要がある。 (s が1つ多い) redis = Redis.new(cluster: ["rediss://<elasticache configuration endpoint>:6379"]) redis.set('key1', 'hogehoge') redis.set('key2',
Blue-Green deployments for Sidekiq workers in docker
It’s quite common nowadays to do blue-green deployments. The way they work is quite straightforward. Whenever you need to deploy a new version of your code to production, you go through the following steps: A new version of your production infrastructure is created, with the new code in it, while the old version remains untouched.Once the new infrastructure is up and running, some process checks i
ECS のSidekiqワーカタスクをSidekiqのキュー内の滞留ジョブ数でオートスケールする - インゲージ開発者ブログ
id:kizashi1122 です。お久しぶりです。 前提 弊社では Rails 製のサービスを運用しています。非同期ジョブの処理には Sidekiq を使っています。 そしてそのジョブを処理するワーカは AWS ECS で Fargate で動かしています。 ワーカは役割ごとにいくつかのECSサービスにわけています。そのサービス中には CPU の使用率に応じてスケールするようにしているサービスもあります。 このあたりが参考になります。 docs.aws.amazon.com ECSServiceAverageCPUUtilization というメトリクスをつかって、例えば CPU 使用率が 80% に維持するようにスケールするように設定することができます。 この ECSServiceAverageCPUUtilization というメトリクスは予め定義されているメトリクスとなります。 こ
Rails: SidekiqはActive Jobを経由せずに直接使おう（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 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
Amazon ECSのローリングアップデート開始からSidekiq停止までの流れを追う - Money Forward Developers Blog
はじめに こんにちは。 SREグループの佐々木と申します。 Amazon ECS（以下、ECS）を使っていて、ローリングアップデート時に、コンテナ上のSidekiqで実行中のジョブに影響が無いのか、気になったことはありませんか？ この記事では、ローリングアップデート時のECSとSidekiqの挙動、ローリングアップデート時に気をつけるポイントを紹介します。 背景 最近、「Sidekiq::Shutdown」のエラーメッセージと共に落ちたジョブがいました。 リリースの際に発生していたので、ECSのローリングアップデート起因で、Sidekiqのジョブが強制終了してしまい、ジョブが落ちたのだろう。と想定していました。 とはいえ、あくまで想定です。 また、ジョブが落ちたことによる影響の有無が分かりませんでした。 そこで、エラーメッセージの原因を調査するために、ECSとSidekiqの挙動を追いま
Sidekiq のワーカーノードをオートスケールさせてEC2の稼働コストを60%削減させるまで - Qiita
このストーリーの登場人物は以下の2人です。 依頼人 = アプリケーションエンジニア or マネジメント層（適宜文脈によって読み替えてください） 匠 = インフラエンジニア Before まずは依頼人が抱えるお悩みについて話を聞いてみることにします。 インフラ構成 依頼人のサーバ構成は、 Sidekiq では標準的な構成を採用していました（図1, 2）。 Web ノードでタスクを Redis 登録し、 Worker ノードで Redis からタスクを取り出し実行します。 Web ノードは API として外部に公開されているほか、 Sidekiq の GUI として利用しています。 各ノードは AutoScalingGroup を構成していますが、台数固定で稼働しています。 図1. サービス構成: 図2. AWS構成図: 以下の文章では、便宜的に以下の用語を用います: マスターノード: タスク
次世代バックグラウンドジョブシステム Faktory を試す - リサーチ・アンド・イノベーション 開発者ブログ
リサーチ・アンド・イノベーションの浜田(hamadu)と申します。 いつものお買い物がちょっとお得に、家計簿にもなるポイントアプリ「CODE」のサーバサイド、およびAndroidアプリの開発を担当しています。 序 CODE ではバックグラウンドジョブシステムとして、Sidekiq を採用しています。その作者、Mike Perham 氏が新しい仕組みを作っていました。その名も Faktory。Sidekiq と違いワーカーが言語に依存せず、また本体はGoで書かれているためスケールするのがウリのようです。まだまだ開発中で、プロダクションで使うには厳しい印象を受けますが、今後Sidekiqを置き換えうるプロジェクトになるのではと思います。 本稿では簡単に仕組みの紹介をして、Rubyでジョブを投げるClientと、ジョブを処理するワーカーをそれぞれ実装してみました。 ソースコードは faktory
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
