CBR250R(MC41 2011年式)に乗って8ヶ月ほどたった
気がつけばそんくらい経っていた
プロの洗車でリフレッシュしたCBRさんのドヤ顔
実際乗った感じ
当たり前なんだけど教習車のCB400SFよりパワーがない。初日はそのあたりの感覚がわからず、発進でエンストしまくった記憶。4000回転くらいまでぶん回してやればまずエンストしないのだが、教習車の発進では2000くらいでやってたので感覚をつかむまではちゃんと回せなかった。
そして軽い。ごてごてバンパーの付いた教習仕様CB400SFより圧倒的に軽い。軽さに救われてる局面がちょいちょいあった。箱根に行ったときに坂道で立ちごけしてもおかしくない程度にバランスを崩したものの、軽さのおかげでなんとか持ち直した。重いバイクだと持ち直せなかったと思う。
困ったこと
メーターパネルの時計のあたりのバックライトがつかなくなってしまった。
スピード表示は暗闇でも全く問題なく確認できるので、特に実害はないのだが(これで時計が見づらいから整備不良だと言われることは流石にないと思う)、夜走っててパネルが一部暗いと心細くなるので直したさ。
調べると、どうもちょいちょいMC41前期で出てる症状っぽく、直すならメーター交換か、そういう修理やってる業者(こことか)に送って直してもらうことになるよう。交換なら数万、修理なら1万円ほどで、値段的にもこれまでの記録を消したくない意味でも修理がいいかな、と思うのだが、自分でメーター付け外しする場所も工具もないので、バイク屋まで行って外して業者に送って戻ってきたらまたつけて、とかめんどい注文をしないといけなくて、なかなか億劫である。やろうやろうと思ってすでに4ヶ月くらい経ってしまった。
あと最初にアクセサリー電源につけたUSB電源がどうにも安定せず、iphoneの充電が追いつかないことが多々あって困った。ちゃんとできるときはちゃんと2.1A流れてるっぽくて、かなり早く充電できるのだが…バッテリー直につけるタイプでかつバイクの電源に連動して通電が切れてくれるちょっといいやつもあるので、そっちに変えたいけど、交換費用考えるとモバイルバッテリーフル活用したほうが安上がりなのでこれも二の足を踏んでいる。
どこかのタイミングで重い腰をあげてえいやと色々手を入れたい気持ちはある。
行ったところ
奥多摩にいったり、伊豆にいったり、秩父に行ったり。あと房総半島へも行った。そういえばあまり写真を取っていない。
嫌なことがあると、ふらりと夜の海ほたるに行ったりもした。
深夜のアクアラインのトンネルは、誰もいないし風もまったくないし、ひたすら真っすぐでストレスフリー。トンネルを抜けたら海ほたるの食堂でノンアルコールビールと蕎麦を食って帰ったり。ETCなら600円で行けるので、たまに長めに夜の散歩をするにはとてもいい。
行きたいところ
そういえば割りと近場なのに江ノ島に行っていない。とはいえ主に走る目的だともっと遠いほうがいいかなという気持ちもある。北海道には確かに行きたいが、現実問題遠すぎるし日数もいるしなかなか厳しい。あとはいろは坂とか、伊豆へ泊りがけで行ってみたい。
他に乗ってみたいバイク
NC750X(大型免許もってない)とかセローとか結局乗らなかったNinja250とか、CB400SBとか。
まあなんだかんだでCBRが気に入ってるしまだ乗り換え欲が高いわけではに。Ninja250は一回くらいレンタルなり試乗すれば気が済みそう。
そんな感じで、まだ無事故でどうにかやれています。
Resque(perl ver)を触っていた
message queueとして長らくQudoのお世話になっていたのだが、もろもろきっかけがありjobの仕組みを考え直すことになった
Qudoを使っていて感じたペインポイントをまとめてみる
Qudoの運用でぱっと思い出せるペインポイント
雑な前提として、自分がここ一年ほど運用していたプロジェクトではかなり多量のjobを投げていた
- enqueueやdequeueのクエリが遅い場合がある
- slow queryにがんがん流れてきていた
- qudoのmysqlをアプリのデータを持つmysqlから独立させていなかったのだが、qudoのクエリでサーバ負荷がかなり高まっていた
- qudoのmysqlを別サーバに分離させたところ劇的にサーバ負荷が改善された
- mysqlのスケールアウトが割りと面倒
だいたいmysqlで運用しなければならないことに起因していて苦労を背負っていたようなきがする。オンプレだったので余計に、ということもあるけど、AWSなどでもEC2を増やすのに比べてRDSのインスタンスを増やすのは比較的ことが大きのではないかと思う。なるべくbackendの部分は台数増やさなくてもスケールしてほしいし、アプリ側からはチューニングの余地がほぼないのでenqueueとdequeueは高速に動いてほしい
そんなわけで、SaaSに寄せないパターンを採択するならRedisを使う系のものを試してみたいなあと考えていたのと、preforkするWorkerの実装が比較的楽そうなもの、ということでResqueに行き着いた。RubyならばSidkiqなどの選択肢もありそうだが、PerlのプロジェクトだったのでPerl実装のあるResqueをとりあえず試している
github.com
基本的な使い方はSYNOPSISとかadvent calendarにあるので省く
起動スクリプトの周りの話
systemdから起動スクリプト叩いて、そこからpreforkしたworkerを立ち上げて使いたい。まじめにやるとシグナルの取り回しなどそこそこ面倒くさい*1*2のだけど、Resque::Workerに最初からそのあたりのことが実装されているので、preforkする側ではシグナルをtrapするだけで済んでくれている。実装読みつつ書いた結果、だいたい以下のような起動スクリプトで行けそう
#!/usr/bin/env perl use strict; use warnings; use utf8; use Resque; use Parallel::Prefork; my $pm = Parallel::Prefork->new(+{ max_workers => 3, trap_signals => +{ TERM => 'TERM', INT => 'INT', QUIT => 'QUIT', HUP => 'QUIT', USR1 => 'USR1', USR2 => 'USR2', CONT => 'CONT', }, }); $pm->start(sub { my $resque = Resque->new(redis => 'localhost'); my $worker = $resque->worker; $worker->add_queue('hoge-queue'); $worker->work; }); $pm->wait_all_children;
Resqueのシグナルのハンドリングはこのあたり
ResqueのWorkerは実際にjobを実行するとき、自身で行うのではなく、一度forkして子プロセスに行わせる仕様になっている。TERMやINITを受け取ると、実際に処理を行うプロセスを容赦なくSIGKILLして自身も終了する。QUITの場合は子プロセスを無理やり殺すことはない。restartの際はsystemdからHUPを送りつけたいので、QUITに直して渡してやる
前述の通り、forkしてから使い捨ての子プロセスで実際の処理が行われるので、max_reqs_per_child的なことは考える必要がなさそう
足りなさそうなこと
retryやjobのtimeoutなどがほしければ、jobの実装の方で別途用意する必要がありそう