ジモティーを支える技術

Hashです。ミームの人と呼ばれていた時期が俺にもありました。現在、株式会社ジモティーでエンジニアをやってます。公私ともにidで呼ばれ、本名を忘れがちなのが最近の悩みですが、別に悩んでいません。

ジモティーのエンジニアは5人で、基本的にまんべんなく仕事をやるもののある程度得意不得意があって、僕はインフラというかサーバの世話をすることが多いです(諸般の事情により名刺にはインターフェイスエンジニアと記載されているのですが…)。

そこで今回は「ジモティーを支える技術」と題して、ジモティーの使っている技術をざっくり紹介したいと思います。まぁタイトル使いたかっただけじゃね感あります。





Rails3

Ruby on Rails 3でWebアプリケーションを開発しています。
ウェブサービスとして見たときジモティーはいわば今風の「掲示板」で、トリッキーな作りは少ないためRailsとの相性は良いのではないかと思っています。ただやっぱりRailsはなんというか重武装なので、個人プロジェクトで今後新しく何か作る時はPadrinoを使ってみようと思っています。

ちなみに余談ですが弊社にはhtmlに留まらずhamlを直接記述し、ローカルにRails実行環境を持ち、作業時はgitブランチを切ってoriginにpushしてくれるスーパーデザイナがいます。

そんなデザイナさんのヘルパーを絶賛募集中。詳細はこちら





MongoDB

mongodb

データベースとして、ドキュメント指向のMongoDBを利用しています。Mongoたんとの付き合いは山あり谷ありでこれだけでエントリが何個も書けそう。最近は、負荷の高いバッチ更新処理を別インスタンスのMongoDBに分離することで安定性が増したところです。

もっとMongoたんと仲良くなりたいものです(かつてWeb上でMongoについて盛んに議論していた先輩エンジニアたちが最近はArangoDB に興味を移しているのを横目に眺めながら)。





GitLab

複数人数開発にgitを使っています。GitLabを中央レポジトリにして、機能開発時はブランチを切って、レビュー後メインブランチへmergeするフローで開発を行っています。gitかわいい。
ただGitLabそのものに関して、使っているバージョンは古いわ、僕がいろいろ未熟な時に立てたので非コア機能が一部壊れてるわで、できれば最新版に入れ替えて、Pull Request driven な開発を導入してみたいねとエンジニア間で話しています。gitかわいい。

参考: 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ – 肉とご飯と甘いもの @ sotarok





Jenkins CI

Jenkinsおじさんを導入、メインブランチにcommitして中央レポジトリにpushしたらテスト(RSpec)を実行させています。
使いこなせばJenkinsの可能性はかなり広いそうですが、弊社のJenkinsには自動テストしかやらせていないので、CTO (Chief Taida Officer) としては大いに改善の余地があるポイントだと思っています。自動化といえば、HUBOTも、私気になります。



完璧なTDDなどといったものは存在しない。完璧な絶望が存在しないようにね。


これは個人の見解なのですが、TDD(テスト駆動開発)はみんなが「いいよね」と認めることで方向を決めたり判断の指針になる理想論の一種だと理解しています。

理想から現実に至る無限のグラデーションの中、少しでも理想へ近づけるための戦略として、弊社には反省Specという文化があります(あります)(あります)。

これは、テスト不足でバグを出してしまったとき、コードを書いた人が同じバグを防止するRSpecも同時に書いて反省の心を込めてcommitするというもので「同じ過ちを繰り返さない」という原則に基づいているような意識の高い雰囲気を醸し出します。

反省Specは「いろいろな制約と優先順位付けの問題から完璧なTDDは実現できないけど理想は共有している」少人数チームと相性がいいのではないでしょうか。ジャストアイディアですが。





NewRelic

パフォーマンス測定、サーバーリソース監視に一時期ZABBIXを使っていたりしましたが、現在はNew Relic : Web Application Performance Management (APM)の有償版に落ち着いています。エンジニアじゃなくてもサーバーやアプリケーションの状態を確認でき、把握しやすいのもいいなあと思う点です。

人数が少ないと特にそうですが「同じものを見ている」という状態は大切っぽいです。





AWS (Amazon Web Service)

AWSはスバラシイ。
入社当時は愚かにも「えーAWS? Linuxそのものの運用スキル上げた方がよくね?」と思ったものですが、信頼性、運用のハードルの低さなど、1年やってきてこれほど頼りになるものはないと確信しています(もちろんすべてにおいて完璧ではありませんが)。ジモティーでは、EC2をはじめELB, Route53, S3, CloudFront, SES, AutoScalingなどなど活用しており、サーバをAPIでプログラム的に操作できる便利さはたまらないものがあります。ガチインフラの人がいなくてもサーバを”そこそこ”管理でき、少人数でもアプリケーション開発に注力することができるのはAWSのおかげでしょう。



それでもAutoScalingならなんとかしてくれる


個人的に導入してよかったと思うものの筆頭はAutoScalingです。Webサーバの負荷が高くなるとインスタンスを追加し、落ち着くと戻ります。安心感が違う。

ただし、AMIからEC2インスタンスを起動し、gitレポジトリから最新のソースを取得してRails起動、health checkを通過してELBに接続されるまで5-10分。 このように検知から稼働までオーバーヘッドがあることから急激な負荷増には効果が薄いとされるため過信は禁物、とも付け加えておきます。

(例えば、所謂「WBS砲」をはじめとする爆発的アクセスに対しては、AutoScalingの対応可能速度を超えた負荷によって落とされたりするようです)



あと、ELBも我々の安眠を確保してくれる大切な機能です。初期のジモティーではnginxのリバースプロキシがすべてのアクセスを捌いていたのですが、さすがにシングルポイントになっててまずかろうということでELBに切り替えたのが今年の春ごろでした。





Solrによる全文検索

ジモティーをオープンした後、初期は全文検索を「タイトルと本文を正規表現でひっかけ」るだけの実装で実現していたのですが、バッチによる大量更新が本格化してくるとすぐに破綻したため今年の夏前にSolrを導入しました。
Sphinxなどの他の全文検索エンジンもいくつか調べてはみましたが、Railsフレンドリーなライブラリが存在していること、身近に(他社ですが)Solrをがっつりやっている方がいたので困ったら聞けるかもという期待もありSolrに決めました。

Solrは僕にとって最もおもしろかった仕事のひとつです。





Resque (on Redis)

つい先週導入したのがResqueです。Railsを使わない人には馴染みがないかもしれませんが、Resqueは、KVSのひとつRedisを基盤にした、GitHub謹製のバックグラウンド処理システムです。素のforkを使うだけに比べ、サーバーのメモリが爆発しないように調整してくれます。

いざ稼働させてみて、以下の特徴から実はResqueは期待していたよりもかなり使える子なのでは? と思っています。

* バックグラウンドJobの「実行」と「Job登録」が分離され、コードが綺麗になる
* バックグランドJobが失敗した場合、管理画面から確認できる。JobはRedisに永続化されてるので、問題を修正してworker再起動して再度実行させられる。
* workerの数を増やすことで容易にScaleできる(できそう)。

以上により、重い処理を追加する時に「じゃあバックグラウンドに放り込むか」という選択肢がかなり有力なものとなりました。





Deploy w/ Capistrano

デプロイはCapistranoを使い、コマンド一発で完了するようにしてます。

当初、Capistranoによるデプロイは10分くらいかかっていましたが、Deployment Script Spring Cleaning を参考に高速化したところ2,3分でコードの更新まで完了するようになり、デプロイ後のRailsプロセス再起動の方が遅く感じるようになりました。

正直、クセというかcap世界のルールになれるまで大変なのですが、コツがわかれば(中身はRubyなので)柔軟にカスタマイズできるのが魅力です。手で行う作業はすべてcap化できると信じ、もっとラクをするためなら努力を惜しまないつもりです。






nginx w/ Passenger


Passenger →→ Unicorn →→ Passenger と出戻りして今に至ります。
Unicornのダウンタイムなしデプロイが魅力で意気揚々とUnicornに切り替えたはいいが、じゃじゃ馬すぎて乗りこなせませんでした。Passenger安定してていい。ひょっとしたらMRI使ってるから苦労してて、REEならもう少しおとなしいのかな?(しかしMRI 1.9.2からREEに変更する時の影響範囲が読めない)





Monit


一時期、神ことGod – A Process Monitoring Framework in Rubyも使ってみたのですが、Monitの方がLinuxフレンドリーで扱いやすいという結論になりました。DSLも言うほどクセがなくて、こんな感じです。

[javascript]
check process nginx with pidfile /opt/nginx/logs/nginx.pid
start program = "/opt/nginx/sbin/nginx"
stop  program = "/opt/nginx/sbin/nginx -s stop"
[/javascript]

プロセスが突然落ちた時、エンジニアには【突然の死メール】を配信して恐怖を煽りつつ、ちゃんと再起動しておいてくれる出来る子です。

_人人 人人_

>突然の死 <

 ̄Y^Y^Y^Y ̄





memcached (View Cache)


レンダリングがヘビィなRailsは、アプリケーション規模が大きくなるとviewキャッシュなしでは重すぎて話にならない、と風の噂に聞いた。
ジモティーではトップページなどよく参照される箇所をフラグメントキャッシュでmemvachedインスタンスに保存して使い回してる。データ更新後のキャッシュ再生成は、上述のResqueにjobを投げている。

いまのところEC2インスタンスで対応できてるけど、将来的には Amazon ElastiCache も選択肢に入るかもしれません。





ログと解析(未)


RailsやMongoDBのログを、syslog-ng経由で一箇所にだばだば流し込んで保存している。調査のとき解凍してgrepするとか、流れるログをオフィスのインテリアにするくらいしか使ってないけど、このログたちを解析して活用できないかなーとぼんやり夢見てはいる。Treasure Dataのサービス、

Hadoop-based Cloud Data Warehouse | Treasure Data

↑も気になるけど、まあ流行ってるからやるんじゃなくてジモティーでログ解析すると一体何が嬉しいのよ、というあたりを明確にするのが先かなあと思ってます。






いじょ


記事にも所々書いたように、ジモティーをリリースしてから徐々に弱点を埋めて改良してきて今に至ります。そうしたサイト/システムの成長に伴ってエンジニア陣のスキルも上がり、次のレベルに到達して調子に乗ってたらさらなる強敵が現れたりと、RPGをやってるような感覚になりますね。

久しぶりにがっつり日本語を書いて、なんだか個人ブログも更新したくなってきたところでお開きと致します。そんじゃーね。

投稿者: ジモティー | 2012年09月14日 | スタッフブログ - 最新の記事: オフィスがぎゅうぎゅう... 記事一覧ページTopへ