こんにちは。クックパッドでイベント運営を担当しているスミです。

去る12/17、食べログさんと共催で勉強会を行いました。食べログさん、クックパッドのエンジニアがそれぞれ3名ずつ、お集まり頂いた約30名のエンジニアの皆さまの前でプレゼンを行いました。

インフラのお話をテーマにした今回。会場の皆さまからたくさんのご質問を頂き、とても熱い時間を過ごさせて頂きました。ご来場頂いた皆さま、どうもありがとうございました。

クックパッドのエンジニアが使用した資料を公開いたしますので、是非ご覧くださいませ！

・クックパッドのスケーリング（高田悟史）

・800万人の”食べたい”をHadoopで分散処理（佐々木達也）

・サーバー・クライアントのボトルネック調査と高速化（菅原元気）

クックパッドでは、今後も継続的にイベントを開催してまいりますのでご興味のある方は是非ご参加ください。

※詳細は決まり次第こちらのブログで紹介いたします。

スミ

8月に入社した佐々木です。こんにちわ！

入社してからはHadoopを使うことが多く、日々、大規模データと格闘しています。大変ではありますが、個人ではなかなか触ることが出来ないような大規模データを触れるのは楽しいです。

さて、Hadoopは最近色々なところで使われ始めてきていると思うんですが、実際に利用してみて困った事やtipsなど、実践的な情報はまだあまり公開されていません。その辺の情報をみんな求めているはず…！！

そこで、僕が実際に触ってみて困った事やHadoopを使う上でポイントだと思ったことなどを社内勉強会で発表したので公開してみます。Hadoopを使っている（使いたいと思っている）方の参考になれば幸いです。

Hadoopの利用はまだまだ試行錯誤の連続ですが、何とか使えるレベルになってきました。これからも処理に時間の掛かる部分にHadoopを利用して、より良いサービスを迅速に提供できるような仕組みを作りたいと考えています。

—

クックパッドではHadoopなどを使った大規模データ解析に興味があるエンジニアを募集しています。

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

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

去年、約80名のエンジニアにご参加頂き、大好評を頂いたこの勉強会。
満を持して第2回を開催することになりました。

楽しい忘年会シーズンを支える食べログ。バレンタインの恋する乙女を支えるクックパッド。
大規模トラフィックを支えるそれぞれのサイトのインフラ戦略、運用テクニックを
現場のエンジニアが発表いたします！

実施内容

■プレゼンテーション

「クックパッドのスケーリング」by高田/クックパッド

「食べログで動いている自作ライブラリのお話」by大石/食べログ

「800万人の”食べたい”をHadoopで分散処理」by佐々木/クックパッド

「PCI-Express型SSDをMySQLで試してみた」by葛西/食べログ

「サーバー・クライアントのボトルネック調査と高速化」by菅原/クックパッド

「ボトルネック特定の為のログ解析・監視設定」by京和/食べログ

■質疑応答
会場の皆さまから、どんどんご質問をお受けいたします。

■懇親会
プレゼンテーション、質疑応答の後に懇親会を予定しております。
今回は、プロのシェフがクリスマスにちなんだ素敵なメニューをご用意いたします。

当日の詳細

■日時
12/17（木）
19:00-20:30　プレゼンテーション＆質疑応答
20:30-          懇親会

■会場
クックパッドオフィス（東京都港区白金台5-12-7 ＭＧ白金台ビル5Ｆ）

http://info.cookpad.com/location

■費用
無料

■募集人数
30名（抽選）

■募集締め切り
12/14（月）18:00 　　当選された方には、12/15（火）にご連絡いたします。

申込方法
以下の内容をご記入の上、メールでお申し込みください。

【件名】
勉強会参加希望＠クックパッド

【本文】
・お名前
・ご年齢
・勉強会に期待すること
・今はまっていること
・ご自身で作成したサイトURL（あれば）

皆さまのご応募を心よりお待ちしております。

※公式ハッシュタグ⇒　#tabepad2

実行委員会一同

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

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

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

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

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

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

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

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

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

こんにちは。クックパッド・イベント担当のスミです。

去る11/20（金）、クックパッドオフィスにて第一回techlifeライトニングトークを開催いたしました。

当日の模様をyoutubeにて公開いたしましたので、ぜひご覧くださいませ。

最初は、クックパッドの佐々木

続いて、ＧＲＥＥのkajidaiさん

3番手は、ＰＦＩの太田さん

4番手は、シリウステクノロジーの藤川さん

そしてトリは、浜本階生さん

5名の方のプレゼンに続き、キッチンで懇親会も行いました。

懇親会の途中から、弊社の代表も混ぜて頂き

あちこちで熱～いトークが繰り広げられていました。

お忙しい中ご参加頂いた皆様、本当にありがとうございました！

今後もtechlifeライトニングトークは、テーマを替えて行ってまいります。

次回のテーマは「puppet」　12/3（木）19:00～です。

ご応募を心からおまちしております！

お申し込みはこちらから↓

http://techlife.cookpad.com/2009/10/24/techlife_introduction/

これからもどうぞよろしくお願いいたします。

スミ

techlifeライトニングトークは、実践的な技術交流のためのイベントです。

毎回テーマを決めて、それについてプレゼンをして頂きます。

・1人5分、参加者全員発表

・LTの内容は動画で公開予定

・あなたのtechlife（技術のある楽しい生活）に役立った内容のみ発表可能

・申し込み人数が10名を超える場合は、抽選とさせて頂きます。

techlifeライトニングトークは、平日19時から！

12/11　 Hive

1/7       iPhone

-申込方法

下記項目をご記載の上、までメールをお送りください。

〆切は開催2日前。ご参加頂く方には、詳細のメールを差し上げます。

—————————————————

■タイトル（例えば分散処理の会なら）

「分散処理参加希望」

■本文

・お名前

・ご年齢

・ライトニングトークのおおまかな内容

—————————————————

twitterはじめました！ライトニングトークのテーマ募集中☆

＠techlifecookpad

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

今年の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で共有された技術的な内容は、順次この開発者ブログに掲載していく予定です。皆様のお役に立つ情報がどんどん集まればよいなと思います。
今後ともクックパッド開発者ブログをよろしくお願いします。

こんにちは、高田悟史です。クラウドとかスケールとかそういうインフラよりのセッションを選んで参加しています。

今回は、Ilya Grigorik氏によるセッションArt of the Ruby Proxy for Scale, Performance, and Monitoringのレポートです。

スライドは下記のアドレスで参照できます。
http://www.slideshare.net/igrigorik/ruby-proxies-for-scale-
performance-and-monitoring-gogaruco-igvitacom-1396734

本セッションは、プロキシラブという同氏によるプロキシのすすめともいうべき発表でした。静的ページのキャッシュという本来の機能だけではなく、ロードバランサーとして使うということはありますが、もう少し踏み込んだ使い方をしてみようというお話です。

例えば、一つのリクエストをproductionとstagingの両方にプロキシして(もちろん返すのはproductionのレスポンスだけ)、stagingのベンチマークをしたりだとか、ログを採集してリアルタイムに監視したり、あるいはデータそのものをダイナミックに書き換えたり、などになります。採集したログを元に、パフォーマンステストを行うためにautoperfというツールも紹介されていました。

そして、ポイントは、このようなことが、同氏作のEM-Proxyというライブラリを使うことで簡単に実装可能だということでした。このライブラリはRuby製なので、やはりパフォーマンスが気になるところですが、EventMachineを使ってイベント駆動になっているので、ほとんど影響はないとのことでした。

同氏のブログエントリRuby Proxies for Scale and Monitoringも参考にして下さい。

プロキシをミドルウェアとして機能を持たせるというのはおもしろいし、それを慣れ親しんだRubyで実装できるというのはかなり魅力的だと思います。ただ、やっぱりパフォーマンスに関しては実際に試してみないと気になります。プロキシに持たせる機能のアイデアとパフォーマンス等のデメリット(メンテナンスコストが上がるなど)の天秤だとは思いますが、今後は、発生した問題の解決策として「プロキシサーバーに実装してしまおう」という選択肢が増えたのは良いですね。