はじめまして、技術部の西岡です。

普段の業務では社内システムやサービス開発をメインに行っています。

今年の6月に入社して以来、ひたすら何かを作っているのですが、クックパッドでは自分のやりたいことをベースに業務を決めることができるので、日々、楽しい開発ライフを送れています。

さて、クックパッドには様々な社内システムがあるのですが、その内の１つに全社員の目標を管理できるシステムがあります。このシステムでは、目標と共に顔写真や得意なことを設定する仕組みになっているため、普段あまり関わりのない人が、どのような業務を行っているのかをざっくり知ることが出来ます。

このシステムは私が開発したのですが、開発する際に少し余裕があったことと、個人的に興味があったことから、iPhoneのSafariからも閲覧できるようにしてみました。

残念ながら肝心のシステム内部の話はあまり紹介できないのですが、対応する際に調査したSafariの仕様などについての資料をアップしました。

最後の方にネイティブアプリについての言及があるのですが、先日リリースさせて頂いたクックパッドアプリではUIWebViewは利用せずに全てObjective-Cで開発しています。ここら辺の話もいずれ公開できればと思います。

クックパッドではクライアントアプリからサーバーアプリまで、816万人のユーザの期待を背負ったサービスを開発したいエンジニアを募集しています！

[技術部] webシステムエンジニア
[技術部] サーバシステムエンジニア

はじめまして。インフラチームの菅原といいます。

今年の7月に入社してから、コンソールとにらめっこする毎日を過ごしています。クックパッドのようにアクセスの多いサイトのサーバを扱うことが今まで無かったので、いろいろと勉強になることが多いです。

さて、インフラチームではサーバの状況をモニタリングして、サーバに問題がないかを常に把握するようにしています。そのため日常的にtailでログを追いかけているのですが、そんなときはAWKが非常に便利なことに気付き、最近はかなりAWKにハマっています。

今回は絶賛マイブーム中のAWKの活用例をご紹介したいと思います。

なぜAWKなのか？

残念ながらAWKの知名度はあまり高くないようで、社内でも「なぜRubyでやらないのか？」と聞かれることがありました。僕も入社するまではcutの代わりぐらいにしか使っていなかったのですが、あるときログ出力の整形に使って以来、AWKのおもしろさにすっかりハマってしまいました。

AWKの魅力はいろいろとあるのですが、ひとつあげるとすれば「ワンライナーの書きやすさ」です。もちろんRubyでもPerlでもワンライナーは書けるのですが、AWKはさらにワンライナーが書きやすい言語です。

仕事での活用例

普段、僕が仕事で使っているAWKスクリプトをいくつかご紹介します。AWKの文法についてはGNU Awk User’s Guideなどを参照してください。

Railsの500msec以上かかっている処理を追いかける

後からRailsのログを集計してもよいのですが、その場で状況を知りたいときは tail -f と AWK の組み合わせが強力です。次の簡単なAWKスクリプトは、遅くなっている処理をさくっと把握したいときに使っています。

$ tail -f log/production.log | ¥
 awk '/^Completed/{if($3 > 0.5) print }'
Completed in 0.56046 (1 reqs/sec) | Rendering: 0.23351 (41%) ...
Completed in 0.59227 (1 reqs/sec) | Rendering: 0.00010 (0%) ...
Completed in 1.90438 (0 reqs/sec) | Rendering: 1.87990 (98%) ...
...

Apacheの平均応答時間を追いかける

アクセスが多くなると tail -f でaccess_logを追いかけようとしても、流れが速すぎて状況を把握できません。そこでAWKで100リクエストごとの平均応答時間を計算して、現在の応答時間がどのくらいなのかを把握しています。

$ tail -f access_log | awk '
{i++; t+=$4}
i > 100 {
  print strftime("%H:%M:%S"), "|", t / i / 1000, "ms"
  i=t=0
}'
18:58:34 | 97.1538 ms
18:58:38 | 80.6553 ms
18:58:42 | 75.4794 ms

ちなみにクックパッドのaccess_logは以下のようなフォーマットで出力されます。

# ステータス, 時間, 処理時間(マイクロ秒), リクエストuri, パラメータ...
LogFormat "%>s\t%{%Y-%m-%d %H:%M:%S}t\t%D\t%U\t%q..."

上記のスクリプトを少し修正して、単位時間あたりのリクエスト数を出力するようにすると、サービスへどのくらいアクセスがあるのかを把握できるようになります。

[...]$ tail -f access_log | awk '
BEGIN{st=systime()}
{i++}
i > 200 {
  et=systime()
  printf("%s | %.1f req/sec\n",
    strftime("%H:%M:%S"),  i / (et - st))
  i=0; st=et
}'
19:10:45 | 16.8 req/sec
19:10:55 | 20.1 req/sec
19:11:06 | 18.3 req/sec

slow-query.logを追いかける

mysqldumpslowというスロークエリログ用のツールがありますが、その場で状況を知りたいときには tail -f で追いかけるのが手軽です。しかし、そのままでは少々見にくいので、次のようなAWKスクリプトで整形します。

[...]$ tail -f slow-query.log | awk '
/^# Time/ {
  q=substr(q,0,64)
  printf("%s %s %-17s %2d %s\n", d, t, h, s, q)
  d=$3; t=$4
}
/User/ {h=$5}
/Query_time/ {s=$3}
/^[^ ]/ {q=$0}'
091010 17:46:45 [192.168.xxx.xxx]   2 SELECT foo, bar, zoo FROM...
091010 17:55:29 [192.168.xxx.xxx]   3 SELECT foo FROM...
091010 17:56:08 [192.168.xxx.xxx]   3 SELECT foo FROM...

ANSIエスケープシーケンスを使えば、10秒以上かかったクエリだけ赤く表示することもできます。

awk '
/^# Time/ {
  if (s > 9) {
    printf("33[0;31m")
  } else {
    q=substr(q,0,64)
  }
  printf("%s %s %-17s %2d %s\n", d, t, h, s, q)
  printf("33[0m")
  d=$3; t=$4
}
/User/ {h=$5}
/Query_time/ {s=$3}
/^[^ ]/ {q=$0}'

まとめ

今回は、仕事で使っているAWKスクリプトをいくつかご紹介させていただきました。僕もまだAWK初心者なのでお世辞にも洗練されたコードとはいえませんが、それでも非常に役に立っています。
ちなみに、AWKのワンライナーには何か癖になるものがあり、最近はワンライナーばかり書いているので、historyがスクリプトの保存先と化しつつあります。

みなさんもAWKで一行野郎を使いこなしましょう！

おまけ

GNU Awkはソケットが使えるので、カレントディレクトリをDocumentRootとするWebサーバを、ワンライナーで書いてみました。

awk 'BEGIN{s="/inet/tcp/80/0/0";"pwd" |& getline;r=$0;while((s |& getline) >; 0){gsub(/[\r\n]/,"");if($0 ~ /^\s*$/){c="cat " r path;printf "HTTP/1.0 200 OK\r\n\r\n" |& s;while((c |& getline) > 0){print |& s}close(c);close(s)}else if($0 ~ /HTTP/){print;path=$2}}}'

きちんと改行をいれるとこんな感じになります。

awk '
BEGIN {
  s = "/inet/tcp/80/0/0"
  "pwd" |& getline
  r = $0

  while ((s |& getline) > 0) {
    gsub(/[\r\n]/, "")

    if ($0 ~ /^\s*$/) {
      c = "cat " r path
      printf "HTTP/1.0 200 OK\r\n\r\n" |& s

      while ((c |& getline) > 0) {
        print |& s
      }

      close(c)
      close(s)
    } else if ($0 ~ /HTTP/){
      print
      path = $2
    }
  }
}'

AWKを使ったことがなくても、わかりやすいコードではないでしょうか？

GNU Awkのネットワーク機能はとても面白いです。AWKを始めた人には、ネットワーク機能のマニュアルを一読することをお薦めします。

はじめまして。今年の5月に入社した勝間@さがすチームです。

入社してからは、なかなか大変なことも多いですが、最近はお酒好きが集まって月曜から飲み合う 「勝間会」なるものも発足して、仕事面でも仕事以外の面でも密度の高い毎日を過ごしています！

さて、僕は「さがす」チーム所属ということで、普段はレシピを「さがす」ユーザの満足度を上げるために、 クックパッドの検索まわりについて、いろいろな開発を行っています。 一方で、ユーザの「さがす欲求」について深く知るために、大規模なデータ解析を行い、欲求の分析を行う機会も増えてきました。

ところが、クックパッドのログは膨大な数があるので、一口のデータ解析と言っても通常のバッチ処理だと間に合わないため、 分散処理環境の必要性が高まってきました。 そこで、まずは手軽に試せる分散処理の王道ということで、最近ではHadoopを使ったデータ解析環境を整備しています。

そんな中、ちょうどtech lunchで発表の順番が僕に回ってきたので、いい機会なので 「そもそもHadoopって何？」ということや「Map & Reduceを行っているとき、各プロセスは何をしているの？」な話をデモを含めながら発表してみました。 今回は、そのときの内容の資料と質疑応答の内容を共有したいと思います。

発表資料はこのようなものを利用しました。

その後は、このような質疑応答が行われました。

HDFSのNameNodeがボトルネックにはなりえないのか？

NameNodeは障害が起こると、HDFSのクラスタ全体が利用不能になるので、SPOFという観点で考えると、構成上どうしてもボトルネックになり得ます。
ただし、NameNodeが扱うメタデータを保護できれば、NameNodeに障害が起きても復旧できるため、次のような方法が提唱されています。

• メタデータについては、RAIDを組んで多重にディスクに書き込む。
• または、NFSマウントされた領域にメタデータを書き込む。
• SecondaryNameNodeはNameNodeのメタデータのバックアップを定期的にとっているため、NameNodeとSecondaryNameNodeを物理的に別ノードに分けて運用する。

また、NagiosやGangliaでモニタリングを行うことも可能で、ここから障害を検知することも可能です。

Hadoop MapReduceの処理コードはmasterにだけ置いておけば配布されるのか？

処理コードはMap&Reduce実行時にmasterからslaveに配布することができます。もちろんあらかじめrsyncなどで配布しておく方法も取ることが出来ます。

HDFSの安定性は？

レプリケーションの数を増やすことで安定稼働されます。 バックアップ失敗を想定して、レプリケーション数は3以上が推奨されています。また、HDFSに対してファイルシステムチェックを行うことも可能です。

Hadoop MapReduceとHDFSを分けた方がリソースを効率的に使えるのでは？

そういう発想もありかと思いますが、Hadoop開発陣の方針として、基本的には標準的な設定の使用を推奨しているようです。
標準的な設定は、YahooやFacebookなど大規模に利用されているケースをベースにして設定されたものなので、これに習うのが結果的に一番安定して動作するのでしょう。

Taskを割り振るのに優先度が付けられるのか？

複数Jobを与えるときに、優先度を付けることができます。

UU測定のサンプルコードで、複数プロセス存在するはずのReduceがハッシュマップのようなオブジェクトをどうして持てるの？

ハッシュマップのようなキーごとに処理を行うオブジェクトを持つためには、Reducerはキーごとに同じノードが処理を行っている必要があります。このとき、Mapの出力を同じキーごとに同じグループに属するように分割できれば、Reduceは分割可能となります。

ここでの、「Mapの出力を、ソートし、Reduceに渡す」フェーズは「Shuffle」、「Reduceへの入力をキーに基づいてグループ化してまとめる」フェーズを「Sort」フェーズと呼びます。 HadoopではShuffleやSortは完全に隠蔽されているので開発者がこれらのコードを書くケースはありません。

つまり、今回のようなMapの出力がkeyごとに分割されている場合は、Shuffle, SortによってMapの出力を分割、グループ化してReduceが処理できるようになるのでうまく扱うことができます。

HDFSを画像サーバなどに利用できるのか？

HDFSからのレスポンスは特に速いわけではなく、転送速度がボトルネックになるので、画像サーバには向いていません。HDFSは、データの行き来がそれほど起こらない、ログデータのようなものの保存が最も適していると思います。 画像サーバを分散ストレージで検討する場合は、他のプロダクトを利用したほうがよさそうです。

HadoopはHDFSに特化してるのか？

Hadoopを利用する場合は、必ずしもHDFSしか使えないわけではないです。他にもAmazon S3, CloudStoreなんかの選択肢があります。実際は、HDFSが一番ポピュラーで標準的に利用されているので、今回はこれを試してみました。

Hiveたのしそうですね

試してみましたが、なかなかたのしいです。 RDBと親和性高く、Joinなんかもできるのは魅力的なので、導入を検討しています。

クックパッドではHadoopはどのように使われるの？

直近では、様々な条件下でのログ解析や、バックエンドのDB更新などに利用される予定です。

まとめ

クックパッドにおいてデータ解析の需要が高まってきたことで、Hadoopへの取り組みをまとめてみました。今後、本格導入していく際にはまた改めてエントリを上げたいと思います。

また、このような分散環境におけるデータ解析についてご興味ある方を、クックパッドでは募集しています！

• [技術部] Webシステムエンジニア
• [技術部] サーバシステムエンジニア

こんにちはみなさん、とんかつってうまいですし目黒のとんきは哲学ですよね、8/1付けで商品部エンジニアになったnegipoです。すてきな上司とかわいい同僚に囲まれてとても幸せです！

さて、今回はクックパッドのバックエンドで動いているバッチシステムの紹介スライドを共有します。

大事なことは全部かいてあるので読んで下さい。
けっこう大胆な修正が入っていますが、なんとか趣旨をよみとってもらえるとうれしいです。

という訳で、クックパッドでは2週間に1度みんなでお昼ごはんを食べながら一人のエンジニアが何かをしゃべる、”tech lunch”というものを開始しました。技術部はもちろん、商品部や編集部のディレクターなど多岐にわたる人たちがクックパッドがどうやって動いているか、将来どうなっていくのかという話にふむふむと頷いています。
今後このtech lunchで共有された技術的な内容は、順次この開発者ブログに掲載していく予定です。皆様のお役に立つ情報がどんどん集まればよいなと思います。
今後ともクックパッド開発者ブログをよろしくお願いします。

こんにちは。クックパッドのインフラを担当している高田悟史です。入社してもう少しで1年になりますが、とても密度の濃い毎日をすごしています。

今回は、クックパッドで1年を通してアクセス数が1番多いバレンタインデーを無事のりきったお話をします。

1年を通してクックパッドのアクセス数(PC版)を見ると、日々順調に増えている中でもクリスマス前後とバレンタインデー前後が、特に多くなっています。例えば去年度では、2007年のピークが12/24の8,110,082PV、年をあけた2008年のピークが2/13の14,906,776PVだったので、バレンタインデーのピークはクリスマスのピークの1.8倍のアクセスがありました。

バレンタインデーにアクセスしてくれたユーザーに、いかに快適に使ってもらうかはとても重要となるので、インフラチームでは、去年の7月にリニューアルを終えてからずっと、バレンタインデーを意識した仕事をしていました。もはや「バレンタインデー」=「アクセスが多い日」と認識してしまっていて、直前になってそういえばチョコレートを贈る日だったんだ！と思い出したほどです。

さて、バレンタインデーのアクセス対策ですが、年があけてからはインフラチーム4人が、オフィスの奥にある和室部屋にこもり、システムのボトルネックの調査をし、キャッシュの実装、サーバーの増設、去年のクリスマスをもとにした負荷テスト、などをしていました。

その結果、無事バレンタインデーのアクセスをさばくことができたので、先週、技術部ではバレンタインのりきりを祝う会を開きました。当日は、ちょうどクックパッドのモバイル版「モバれぴ」が、docomo・au・SoftBankの3キャリア公式化を終えた日でもあったので、一緒に祝いました。

女子社員がこっそり作ってくれたケーキです。どうもありがとうございました。

技術部の集合写真。

バレンタインデーのアクセス対策については、また改めて書こうと思います。

こんにちは、はじめまして。
クックパッドで社内システムの運営をしています、えいしょうです。
今日は、クックパッドの開発からは少し話題がそれますが、
弊社の社内システム、その中でも特に「Salesforce」というシステムについて、ちょっとお話しさせて頂こうかと思います。

今や企業には、実に様々なシステムがあります。
弊社のような業種の場合、システムがなければ何も仕事できないと言っても、過言ではありません。

ですが、どの企業でも、こと「営業」に関しては
比較的アナログが多いのではないでしょうか。
何故か？おそらく、一人一人の「経験」や「勘」に頼るところが多く、
機械的なプロセス分析やパフォーマンスチェックが、難しいからだと思います。

しかし、経験や勘に頼っていては、いつまで経っても生産性の向上は望めませんし、
人数が増えるほど情報が錯綜し、却ってパフォーマンスが下がってしまいます。

そこで登場するのが「Salesforce」です。
今やSaaS（Software as a Service）の急先鋒と言われて様々なことができるシステムですが、
その機能のキモは、読んで字のごとく「営業の力」、つまり営業をサポートし、売上を上げるところにあります。

具体的には何をしているのか？
大きく分けると、以下の5つになるかと思います。

(1)受注情報の一元管理

誰がいつ、どこの企業から、何の商品をいくらで受注したか。
これが把握できなければ会社は成り立ちませんので、どの企業でも管理している情報でしょう。経理が主導して管理している企業が多いかと思います。

(2)ヨミ（売上見込み）情報の一元管理

(1)はすでに売上が確定した情報ですが、それだけでは会社としての見通しが立ちません。また、営業としても、何をどう頑張ったらいいのか分かりません。
これも、どの企業でもおおよそは把握しているでしょう。
営業事務やマネージャが主導になり、エクセルを使って管理している企業が多いんじゃないでしょうか。

(3)顧客情報の一元管理

ここからは、できていない企業も多いんじゃないでしょうか。
連絡先、業種、担当者の名前といったハードデータだけでなく、
(1)(2)の紐付けによる受注データやヨミデータ、
また、誰がいつ何をして（ex．訪問した・電話した）、その結果がどうだったか、といった行動データまで、すべてを一元管理します。
このような詳細な顧客情報を共有することで、以下2つのメリットを享受できます。
・引き継ぎがとても楽になります。
　　営業活動の中でもかなり厄介な、顧客の引き継ぎ。
　　ところが、これらの情報が共有されていれば、「よろしく」の一言で片付きます。
・既存顧客に対する適切な営業が可能になります。
　　商材にもよりますが、リピートの提案には、適切なタイミングと確かな履歴情報が
　　必要です。今までのお付き合いが詳細に把握でき、いいタイミングでアラートが
　　上がってくれば、チャンスを逃さずにリピートの売上につなげることができます。

(4)営業マンのパフォーマンスの把握

ここまで来ると、たいていのシステムじゃあ難しいんじゃないでしょうか。Salesforceの真骨頂です。
（2）ヨミデータや(3)で出てきた行動データを、営業マンごとに集計すれば、
さまざまな切り口からの営業マンのパフォーマンスを知ることができます。
たとえば、1週間の行動量、受注率や失注率、案件の発生ペース、などなど。
ここで肝心なのは、『会社として重視すべき指標（KPI）を設定し、ぶれないこと』です。
見れるのであればと欲張って、いろんな指標を知りたくなるものですが、余りにたくさんあると大事なものを見失ってしまいます。
指標はシンプルにすること。これには、マネージャーや経営陣の協力が不可欠です。

(5)フレキシブルなデータの分析

以上の登録されたデータを、さまざまな切り口から分析できます。
たとえば、商材別の売上、販路別のヨミ、販売代理店のパフォーマンス、など。
この場合、「スピーディーさ」がとても重要になります。
さまざまな分析が柔軟にできることで、信憑性や価値が増し、よりアイディアを広げることができます。一つ分析するのに何日もかかっていたのでは、動きの速い営業の世界では役に立ちません。

ここまで書いていて、弊社はまだまだだなぁと、我ながら痛感してしまいました。。。
これらが全て活用された時、本来の価値が発揮され、売上への貢献という目的が達成するのだろうと思います。
そこで初めて導入プロジェクト（の”第1段階(！)” ）が達成。道のりは長いです。

閑話休題。
ではなぜ「Salesforce」を選んだのか？

・・・かなり長くなってしまったので、続きはまた次回にさせて頂きます。
次回も長くなってしまうような気がしますが・・・お付き合いくださいませ。

こんにちは、はじめまして。クックパッド株式会社エンジニアのnegipoです。
業務では主に広告系のシステムを担当しています。クックパッドには新卒で入社し1年半ぐらいの業務歴ですが、エンジニア職ではCTOに次ぐ古株だったりして上から下までいろいろやってます。今後ともよろしくお願いします！

さて、今回のエントリーでは、10/26に弊社にて開催された「小さな会社の優秀な技術者の採り方　第0回」と言うイベントについてレポートしたいと思います。
このイベントかなりヤらしいタイトルですが、第0回である今回は基本的に知り合いベースで集まって、今後の方向性などを模索する感じで企画を行いました。弊社の採用担当である鷲見に’技術者の価値観をいろんな会社にいる人たちから感じ取ってもらう’ことを主眼に置いたものとなっています。大きめのメーカから従業員2人のweb企業まで、いろんな業種のエンジニア職の方が20人弱集まった会となりました。
タイムテーブルとしては

1. 1) あらかじめ用意した2枚のスライドを発表してもらう
2. 2) 会社のキッチンでみんなで料理！
3. 3) 食べる！
4. 4) まとめる

と言う感じです。エンジニアが20人集まって料理できる会社はクックパッドだけ！

あらかじめ用意してもらったスライドについて

参加者のみなさんに現在あるいは過去の所属企業について

• ・入社しようと思った理由
• ・入社してヤバいと思った理由

をそれぞれ一枚ずつスライドとして準備してもらいました。で、ここで得られる情報というのがすごく重要で、要は

• ・優秀なエンジニアを見つけてきて、採用する
• ・優秀なエンジニアを自社内に囲い込む

ためのエッセンスが様々なタイプの企業におけるノウハウとしてプレゼンに詰まっているんですね。
例示はかなりアレなのでできませんが、印象を丸めてツリーに落とすと以下の様になります。

その会社に入社しようと思った理由

• やりたいことができる
  • 好き勝手やってよい文化がある
  • 経験が生きる
  • キャリアパス上重要なことが学べる
• 環境がいい
  • 優秀な同僚
  • 海外の事業所がある
  • 女の子かわいい
• 会社の将来性が感じられる
  • 世界で唯一のチャレンジを行っている
  • 目的がはっきりしている
• 感じが良い
  • 採用プロセス上 で会ったのがとても良い人
  • 社長が面白い
• 縁があった
  • 友達とか先輩とかが居た
  • バイトしてた

その会社に入社してヤバいと思った理由

• 組織的にヤバい
  • 部門間対立深くてロスがすごい
  • 大企業的思想がひどい
  • 歯車感がある
  • 特定コミュニティ出身者が多い
• 環境が悪い
  • 給料安い
  • 帰れない
  • 尊敬できる人が少ない
  • 僕がしくったら会社ヤバいというプレッシャー
• 開発体制的にヤバい
  • 人が少なすぎる
  • システムが前時代的
  • 特定の人がいなくなった時にシステム止まりそう
• 会社のビジョンが無い
  • エンジニアが好き勝手してる感がある

ここで補足しておきたい点として、入社前に企業に対して抱いた好感には企業の規模による差が殆どなかったのに対して、入社後の悪い印象は規模の大きい企業に関しては主に組織体制、規模の小さい企業に対しては主に労働環境に対するものであったことが挙げられます。

各社の技術職の採用を担当されている方にとっては、採用広報などの業務において参考になる意見集ではないでしょうか。

僕個人としては、入社時に感じた「目的がはっきりしている」「社長が面白い」「女の子かわいい」といった点は裏切られていないため、些細な問題はあっても、依然クックパッドは魅力的な会社です。別の方の意見として出た、「キャリアパス上重要なことが学べる」や「世界で唯一のチャレンジを行っている」といった意見についても日々実感しています。Joel先生の本とか読みつつこれを参考に採用活動にコミットできればなと思っています。

てな訳で、お料理お料理

クックパッドエプロン

材料の仕分け

満面の笑み

共同作業

漬け込み中

キッチンドランカー集団

元プロが混じってます

焼けた！

ご飯ご飯

並べたところ

おいしそう


うめー！わーい！

採用担当者によるまとめ

会の終了間際に、鷲見から今回のまとめがありました。

• ・コンセプトを大事にする会社
• ・技術力を活かせる環境がある会社
• ・尊敬できる人がいる会社
• ・技術力が高い会社
• ・健康維持できる体制のある会社

これらの点をクックパッドが企業として目指すと言う宣言です。

今回のイベント開催を通して、とりあえずはエンジニア採用に悩んでいる鷲見さんを助けられて大変良かったです。エンジニアって宇宙人みたいなものですから。
今後の「小さな会社の優秀な技術者の採り方」イベントの開催予定は未定ですが、今回の内容をしっかり噛み砕いて、ゆくゆくは全てのエンジニアが楽しく仕事ができる企業選びを行い、全ての企業がそれに合致した環境提供が可能となるようになれば良いなーと思っています。
今回の開催を企画当初から手伝ってくれたid:yoosuke君と、参加してくれた方々に篤くお礼申し上げます。本当にありがとうございました！

クックパッドエンジニアの高田悟史です。

10月17日(金)にカカクコムさんと共催の勉強会を開催しました。
クックパッド側の発表資料を貼付けておきます。

クックパッドのRailsリニューアル / 橋本健太

cookpad.comの裏側とこれから / 高田悟史

当日は70人くらいの人が集まってくれました。

発表でも触れたとおり、僕はサーバエンジニア歴6ヶ月なので、知らないことだらけなのですが、いろいろなサイトのインフラ系のエンジニアとお話ができて楽しい会でした。特に、今一番気になっているバランサーについて、どういうのを使っているか聞かせてもらいました。だいたいある規模を超えるとハードウェアのバランサーを使うようですね。

参加して下さった皆さん、カカクコムの皆さん、会を盛り上げてくれたクックパッドのスタッフ、おつかれさまでした。

クックパッドのhashikemです。

弊社でも開発者ブログを始めることになりました。よろしくお願いします。
初めての記事なので、軽くクックパッドのシステム構成を説明します。

まず、OSはCentOSを使用しています。いざというときにRedHatに乗り換えられることを重視しましたが、CentOSのままの運用で、無事に現在にいたっています。

フロントのWebサーバはApache2.2です。nginx など、他の可能性も考えたのですが、mod_proxy_balancer, mod_rewriteなどの運用経験から、Apacheを使用しています。

アプリケーションはRails2.0です。以前はColdFusionで独自のフレームワークを作って構築していたのですが、アジャイルさを追求したフレームワークであるというメリットに惹かれてRailsへと移行しました。

各アプリケーションサーバでmongrel_clusterを立ち上げて、フロントのApacheからproxy balancerでバランシングしています。しかしやはり、named_scope使いたい！query_memcachedも使いたい！というわけで、Rails2.1への対応が当面の課題に上がっています。

DBは、MySQL 5.0 で、メインのストレージエンジンはMyISAMを使用しています。最近はInnoDBの使用が主流かと思いますが、実際に両方試してみたところ、弊社のシステムでは、ほとんど違いが見られませんでした。また、DBの一部では、Tritonnを使用して、レシピデータの全文検索を行っています。

サーバについては、ほとんどのサーバをVMWare ESXiで仮想化させており、インフラの運用、調整の負担を減らしています。

この構成で、月間の2億5000万PV、450万人のユニークユーザをさばいています。Railsはパフォーマンスが悪いという話をよくに耳にしますが、それでも、この規模のシステムを運用できるという証明にもなりますね。

現在、クックパッドは世界のRailsサイト中alexaのランキングで7位になっています。また、上位6位までのサイトのPVと比較すると、実はクックパッドよりPVの多いサイトは二つだけになっています。(2008年9月21日時点)(比較1・比較2)

かなりざっくりとですが、弊社のシステム構成についてご理解いただけましたでしょうか。

今後、さらにさまざまな情報を発信していきたいと考えておりますので、よろしくお願いいたします。