らいむぎばたけ

つかまえなくてだいじょうぶ

家はまぐり塩ラーメン

幻のタンポポ 宝登山参道本店 / Twitter で活蛤カマンベール塩そばを食べた。もう一度食べたいな〜と考えていたタイミングで、はまぐりを入手する機会があったので、とりあえず自分ではまぐり塩ラーメン1作ることにした。はじめて作ったため、作り方や調味料、分量は勘です。

はまぐり出汁

まずは昆布で出汁をとる。沸騰直前で昆布を取り出す。

水の状態でいれる

昆布を取り出したあと、長ネギ・生姜・はまぐり (砂抜き済み) を鍋に入れる。ちょうど家庭菜園でとれた長ネギがあったので、それを使った。

鍋に入る前のみなさん

鍋に入ったみなさん

はまぐり出汁が白いことがわかった。この時点でうまい。家二郎 (凛) ほどは煮ず、たぶん 20 分くらい。

これがはまぐり出汁

出汁をとったあとのはまぐりは別のことに使うことを急遽思いついたので、貝殻からはがした。

無心ではがした

カレイとイサキの出汁

家にちょうどカレイとイサキのアラがあったのでついでに一緒に出汁をとった。このときまではかえしに混ぜようと思っていたが、試しにはまぐり出汁と混ぜたらうまかったので、はまぐり単体とはまぐり・魚ミックスの二種類のラーメンを作ることに変更。

アクはちゃんと取る

はまぐり出汁と違って、魚でとるとほんのり黄色い。これもこの時点でうまい。

ちょっとこずみがある

かえし

塩・白コショウ・砂糖・酒・みりん・味の素・長ネギ・しょうがを入れて軽くチンした。そのあとカレイとイサキの出汁を少量追加。

そのままなめるとしょっぱい

左がはまぐり魚ミックスにかえしを合わせたもの、右がはまぐり単体にかえしを合わせたもの。

出汁二種

スチームでチンした小松菜としめじを用意した。

完成

はまぐり単体のほうはカマンベールのせ。カマンベールにちょこんとのっているしめじがかわいい。

はまぐり単体

はまぐり・魚ミックスはカマンベールなし。

はまぐり・魚ミックス

どっちもおいしかった。はまぐり塩にはカマンベールがやっぱ合う......

次の日

はまぐり・魚ミックスのほうにもカマンベールが入っていたほうがよかったのでは、という話になった。いや、そもそもカマンベールじゃないにしても油分が必要なのでは?ということで検証するために鶏皮を買ってきて鶏油を作り、はまぐり・魚ミックス出汁と鶏油をあわせてみた。おいしい。油か、塩ラーメンにも油が重要なんだ。

おまけのゆで卵

おまけ

出汁がらの昆布とはまぐりで、炊き込みご飯をつくった。これにお茶漬けみたいにラーメンスープをかけて食べたら悪魔の味がした。

🍚


  1. ここではラーメンとそばは同じものとします

🐟ISUCON12 の予選に参加した🌼

ISUCON12 にうなすけとやままの 3 人で「たんぽぽの上の刺身」で参加した。おととしの 🐟ISUCON10 の予選に参加した🌼 - らいむぎばたけ が初参加で、ISUCON11 にも出たので 3 回目の参加になった。去年は終了数分前になにかをマージした結果、ベンチが落ちて 0 点になり無力感がすごくて何も書けなかった。

気を取り直して ISUCON12 の結果は、スコア 3765 でリーダーボードの結果によると328 位だった。

やままの記事はこちら ISUCON12 の予選に参加した - きりきりやま

やったこと

  • select * になっているところを必要なものだけをとってきたり
    • 点数上がった気がするけど誤差
  • 不要な SQL 叩いているところを消したり
    • そもそもそんなに叩かれている箇所では無かったので点数伸びず
  • N+1 修正で bulk insert にしたり
    • 思いの外伸びなかった
  • 大会終了後に訪問した人をそもそも SQL でとってこないようにしたり
    • これが一番伸びた

どれもこれも 500 点くらいしか上がらないようなことしかできなかった。無力。

今年もお疲れ様でした。来年もがんばります。

ひとつの Rails アプリから 複数の Sidekiq プロセスを扱う

ひとつの Rails アプリで Sidekiq worker によって使う Redis を分けたい。

Sidekiq のプロセスはひとつの Redis と接続することを前提としているので、複数の Redis と接続する場合には Redis の数に合わせて Sidekiq のプロセスが必要になる。

ここではふたつの Sidekiq プロセスを扱い、接続先の Redis の URL は全て環境変数に入れるものとして書く。

config/initializers/sidekiq.rb

Sidekiq.configure_server do |config|
  config.redis = { url: ENV['REDIS_URL'] }
end

Sidekiq.configure_client do |config|
  config.redis = { url: ENV['REDIS_1_URL'] }
end

ざっくりと、 server は dequeue するほう (Sidekiq プロセス)、client は enqueue するほう (Rails アプリ) 。

client 側の設定は、とりあえずメインで接続するほうの Redis を設定しておけば良い。

Rails アプリの環境変数

  • REDIS_1_URL=redis://redis_1:6379
  • REDIS_2_URL=redis://redis_2:6379

Rails アプリ側では Redis の数だけ環境変数を用意する。

worker ひとつめ

ひとつめの worker はメインで接続するほうの Redis を使っているので普通に何も気にせず書いたら良い。

class Worker1
  include Sidekiq::Worker

  def perform(*args)
  end
end

Worker1.perform_async()

Sidekiq プロセスの環境変数

  • REDIS_URL=redis://redis_1:6379

worker ふたつめ

ふたつめの worker は、呼び出し側で接続先が違うことを書かないといけない。 詳しくはここにかいてある。 Sharding · mperham/sidekiq Wiki

class Worker2
  include Sidekiq::Worker

  def perform(*args)
  end
end

redis_2 = ConnectionPool.new { Redis.new(url: ENV['REDIS_2_URL']) }
Sidekiq::Client.via(redis_2) { Worker2.perform_async() }

Sidekiq プロセスの環境変数

  • REDIS_URL=redis://redis_2:6379

さいごに

ここまで書いたあとに worker にオプションとして渡す方法を知った。Conection Pool を都度生成するのはやめたいし、呼び出し側じゃなくて worker 側に書いてあるほうがわかりやすいのでこっちのほうが良さそうと思った。

class Worker2
  include Sidekiq::Worker
  sidekiq_options pool: ConnectionPool.new { Redis.new(url: ENV['REDIS_2_URL']) }
end

とはいえ、Sharding 自体はおすすめはされていなさそう。

Part of the reason I don't document sharding well is because it is supposed to be painful/last resort. It's better to start breaking your monolith into smaller services if you've reached the point of saturating a Redis instance. Questions about Sharding usage · Issue #3605 · mperham/sidekiq