先月に続きこのブログの状態を振り返ってみた。
まず、RSSのsubscribersがそこそこふえて、メジャーどころのオンラインRSSリーダで100 subscribers(Google Reader + Livedoor Reader系)に到達したようだ。ほぼ50:50くらいというのが面白い。両方に登録している人も結構多いのかな？
初めて1ヶ月半。思ったより早かったかな。過去何度かいくつかの種類のWebサイトをやっていたけど、もう少し遅かった気がする。RSSリーダーのユーザ数の絶対数が増えているというのはあるだろうけど、今回のブログに関して言うとTwitterでの情報の広がりがとても早く感じた。
RTをたくさんされるとやっぱり嬉しい。今まで一番反応が良かったのが、「CouchDBとMongoDBを比較してみた」なんだけど、これは20回近くRTされたみたい。それぞれのRTでそれぞれのFollowerの人が見に来てくれるわけで、これは零細ブログにとっては結構な数になる。Twitter前の世界だと、ブログがアクセスを増やすには有名どころにリンクされるか、炎上する、というのが手っ取り早い方法だった。Twitterによって、少しずつの好意でも情報が広まる、というのを少し実感できた。もう少しターゲットの大きい話題なら、10倍100倍のアクセスを簡単に得ることができそうだ。いい世界になったな、と素直に思う。
後、はてなブックマークも見ているのだけど、その記事が49ブックマークで、このブログのトータルで370くらいらしい。期待(？)していたネガティブなコメントはまだ貰ってない。まあ、技術的なネタに「死んだらいいのに」とか来るとは思えないけど。そもそもコメント付きのブックマークが少ない。ちょっと寂しい。
はてなブックマークは増え方が面白くて、そこそこ頑張って書いたのに！と思っても全然伸びなくてがっかりしてると、それから数日かかって伸びるとかもある。例。まあ、ちょっと狙って書いたのにまったく伸びなくて滑ったな！ってのもある。やっぱり、どんな反応でも、反応があると嬉しい。もちろん数だけではないんだけど。
こんな感じでぼちぼちやっていきます。
cronと比較して
*nix系のシステムだと、伝統的に、何かを定期的に実行したいcronを使うのだけど、アプリケーションからcronを使う場合、いくつかの使いづらい点がある。
- アプリケーション本体から離れた場所でcronの動きを管理しないといけない。通常、/etc/crontab 等をメンテナンスしないといけないのだけど、そこはアプリケーションの外側なので、メンテナンスするときにアプリケーション側で使っている方法を使いづらい(SCMもそうだし、deployとかも別で考えないといけない)。
- cronから起動する場合、起動する環境について考えないといけない。環境変数が代表例。アプリケーションと同じような環境になるように注意しないといけない。
resque-schedulerを使うと、cronでするようなことをアプリケーション内で完結することできる。crontabのようなものをアプリケーション内に置けるので、アプリケーション本体を管理するSCMを使うこともできるし、deployもアプリケーションと常に同じ方法でできるようになる。
ただ、基本的にはcronの動きを踏襲しているので、cronの以下の(場合によっては)負の特徴も引き継いでいる。
- cronと同じように、指定した時間にresque-schedulerが立ち上がってない場合、その処理は行われない。
- cronと同じように、同一のタスクが同時に走ってしまう場合がある。例えば、毎分実行するような設定を書いた場合、その処理に1分以上かかってしまった場合、前の処理が終わる前に次の処理が走ってしまう。それが致命的な場合、自分でロック処理を書く必要がある。
- 複数のresque-schedulerを走らせることが考えられていない。複数のresque-schedulerを実行すると、同じ時刻に同じタスクが複数回走ってしまう。つまり、「冗長化のために、2台のアプリケーションサーバ上でresque-schedulerをそれぞれ動かす」ということができずに、冗長化した構成が取れない。
最後のは、嫌なので、複数のところで走らせても同一のタスクが複数回走らないようなパッチを書いて作者に投げてある。しかし、「冗長化構成が取れるように」ということには賛同を得たのだけど、そのパッチについてはいくつか課題がありそうなので保留になっている。気が向いたらもうちょっと頑張るつもり。
使い方
resque-scheduler を見るのが早いが、crontabで定義するようことをyamlで定義する。そのドキュメントの例を使わせてもらうと、
queue_documents_for_indexing:
cron: "0 0 * * *"
class: QueueDocuments
args:
description: "This job queues all content for indexing in solr"こんな感じになる。この場合、毎日0時0分に、QueueDocumentsというResqueのJobがQueueに入ることになる。ただし、ResqueのQueueに入るだけで、resque-schdulerは実際の実行はしない、ということに注意。Queueを処理するのはResque自体のWorkerの仕事になる。
deployについて
resqueと同じように、resque-scheduler自身には、起動スクリプトみたいなものがついていないので、godやmonitのようなもので管理するのがいいっぽい。
自分はmonitを使って、こんな感じのwrapperを書いて、monitではそのwrapper経由で、起動、停止をしている。
そもそものきっかけは、ここ半年間くらいRuby on Rails(以下RoR)で開発していることにある。
ここ半年弱ほどRoRで開発をして、それなりに満足しているのだけど、ActiveRecordに関しては色々とひっかかるところがあった。
「ActiveRecordがRoRの素晴らしいところそのものだ」と評価している人もいるが、自分の中では逆で、ActiveRecordはRoRの中でもかなりいまいちな部分。
いや、ActiveRecordというよりも、O/Rマッパーの限界なのかな。実際、ActiveRecordはO/Rマッパーの中では、いい方だと思う。今まで、自分用O/Rマッパーを作ったり、それなりの数のO/Rマッパーを見てきたけど、そういうのに比べても、確かにActiveRecordはよくできている。
でも、RoRがよくできたフレームワークなだけに、O/Rマッパー経由RDBMSを使うことに、色々な無駄を感じてしまう。
たとえば、1つのテーブルから同じ条件で検索し、複数のインスタンスを作るために、primary key(id)を検索条件として、何度も検索するとか。「そこはSQL一発で持ってこいよ」と思ってしまう。またそこからlazyに外部キーで他のModel(テーブル)のオブジェクトを持ってこようとすると、またprimary keyでの検索が走る。
一人のユーザが一つの画面を開くだけでSQLを何十回も発行することも普通に起こる。これはどう考えてもSQLの使い方として間違っている。SQLはそういう風に作られていないので、結局(RoR自体を含めた)アプリケーション側の別のレイヤーでインスタンスをCacheしたりと、どんどん複雑になっていく。
そういうのが嫌で、RDBMSとして正しく使おうと、find()で:includeとか:joinsとか使いだすと、今度はどんどんRoR(Ruby)のコードのSQL成分が増していく。全然楽しくない。
つまり、
- SQLっぽく書かずに、Ruby(ActiveRecord)っぽくきれいに書くように頑張る
- でも、ロジック的/パフォーマンス的に頑張るのが限界だった場合に、SQLっぽいコードをRubyに書くことになる
- そうこうしているうちにRubyらしい可読性の高いコードは消えSQLっぽいコードにまみれる
この流れにうんざりする。そもそも1.の段階でも脳内では普通にSQLのことを考えている。だったら最初からSQL書けよ、と思ってしまう。
結局、O/Rマッパーで、きれいに書けるところは、検索した結果でオブジェクトを作る、または、primary *key*指定で持ってきてそれを元にオブジェクトを作る。これだけ書けて、十分な性能が出るなら、RDBMSでなくても、(そこそこの機能を持った) Key Value Storageで十分なんじゃないのかな、とぼんやりと思っていた。
もう一つActiveRecordで嫌いなのが、Modelのコードにカラムの情報を持たない、というとこと。DRYのためだかなんだか知らないが、これはどうみても欠点だと思っている。Modelのコードを見ただけでどういう情報が入っているかわからない。migrationのコードはツギハギだらけで後から見るには向いていない。どういうModelか、ということを知るためには、動いているデータベースにアクセスしてスキーマ情報を見るしかない。かっこ悪い。
ってなことを、漠然と思っていた頃に、タイミングよくNoSQL(KVS)ブームが到来。「ああ、これだ」と思って、ブームに乗っかって、色々なKVSを試している中で、
「これなら最近のWeb開発の多くの部分でRDBMSを捨ててもいけるんじゃないかな」
と感じさせてくれたのがMongoDBだった。
数あるKVSの中でMongoDBの何がよかったのかと言うと、
- RoRのModelにぴったりと合いそう。上にも書いたように、KeyとValueの関係が、そのままModelのIdとInstanceの関係になりそう。
- Valueの部分はスキーマフリー＆ダイナミックに作成可能なので、Ruby側のコード主導でカラムの追加をすることができる。Rubyのコードでのカラムの定義が「正」になる。もちろんDRYも守られたまま。
- SQL-likeなこともできる。where句(のようなもの)を指定したり、maxとかminとかgroup byも使えるし、やろうと思えばストアドプロシージャ(Javascript)のようなこともできる。この辺は、SQL脳の人(チーム)にとっては移行するためのハードルが低そう。
- 上記を踏まえた上で、KVSらしく、RDBMSでは厄介なスケールさせることも考えられていて、Shardみたいなこともデフォルトで用意されている。
とまあ、こんなところ。
つまり、最近のリッチなフレームワークの中では、DB側にそれほどリッチな機能はいらない。RDBMSはそのいらないリッチさがあり、そのせいでスケールさせるのが難しくなったりもしている。だったら、軽量でコンパクト、でもそれなりの機能を持って、そしてスケールしやすいMongoDBで十分なんじゃないのかな、と思った。
もしMongoDB始めてみようって人がいたら、こちらをどうぞ。
追記: CouchDB編もできたみたいです。私は、Railsは好きです。念のため。
RSSリーダで読む