食べログ×クックパッド合同勉強会 に行ってきた #tabepad

はじめて白金台の駅で降りた。なんだこのおしゃれな感じは…。昔は毎日こんなところを通過していのか。
電車を降りててくてく歩いて行くと、そのなかでも目を引くかっこいいビルがあって、そこの5階がクックパッドのオフィス。エレベーターを降りてちょっと曲がるとすぐに広いキッチンがあって、みんなでなにかを作っている。すごく美味しそうな匂いがして、炒めもののいい音が聞こえるする。
19時ちょっと前のお腹の減った僕には辛いくらい。


前置きが長くなったけど、食べログ×クックパッド合同勉強会に行ってきた。30人の狭き門で、抽選に当たって嬉しかった。

発表のタイトルはこんな感じ。

togetter のまとめはこちら。

ustの録画はこちら。

いかにしてユーザ体験を保証するか

  • Status Code : 502 Bad Gateway
    • 例えば蛇口をひねったけど、水がでない
    • 期待したことができていない
  • サーバがエラーを返したり、重かったりする
    • 嫌な体験は簡単に与えられる
  • 守る
  • 進む
  • 備える
守る
  • 明確な目標を持つ
    • 200 msec/req でサーバから返す
    • ユーザのことを考えて目標を設定する
    • 目標が明確だと意思決定がしやすくなる
  • すみずみまで監視する
    • リアルタイム監視
    • どのくらいのアクセス数があるか
    • どれくらいの速度で返却しているか
  • モニタリング数を多くし過ぎると見なくなる
    • 毎日見るものは少なくする
  • 障害時は迅速に対応する
    • ユーザ体験を優先する
    • 問題解決よりも、復旧させることが大事
  • 迅速に対応できるように工夫する
    • エラーログを追いやすくする
    • スピードには価値がある
  • 障害から学ぶ
    • 再発防止策を行うまでが障害対応
    • 障害はredmineのチケットに登録
進む
  • 変化に強い体質
  • 継続的にデプロイする
    • 1日に10回くらいデプロイしている
    • すぐにフィードバックがある
    • 変更が少しづつになる
      • 問題が起きても原因がわかりやすい
  • デプロイルール
    • デプロイは 09:30-19:00
    • インフラサポート待機
    • デプロイしたひとはデプロイ後1時間待機
      • 障害が発生してもすぐ対応ができる
  • 設定も履歴管理する
  • サポートチーム(ユーザと接しているひとたち)と連携する
    • 大きな変更をしたときは、変更内容を伝えておく
備える
  • キャパシティを計測する
    • 実際のリクエストで、サーバ種類ごとに pv/sec
  • スケーラビリティを確保する
    • スケールするか
    • クラウド移行
      • 必要な時だけスケール
まとめ
  • インターネットの向こうにはユーザがいる
  • ユーザ体験を守り、変化に強い体質を作り、将来に備えよう

Jenkins + Selenium + Python on 検索システム

  • 自己紹介
    • カカクコムの検索システムを担当
    • いろんなサービスに対して検索システムを提供している
    • 価格.com / 食べログ / yoyaq など
  • 検索システムでのJenkinsジョブ構成
  • ビルドジョブ
  • デプロイジョブ
  • Seleniumジョブ
ビルドジョブ
  • トリガは svn commit
  • svn update
  • virtual env で python環境を分ける(like rvm)
  • nosetestでテスト
  • Junit形式で出力でJenkinsが勝手にグラフ化
  • pep8で静的ソース解析
  • 全部通ったら tarball
デプロイジョブ
  • トリガは環境により異なる
  • ssh scp で tarball 配布
  • 本番の場合L7ロードバランサから切り離してデプロイして繋げ直す(今後やりたい)
Seleniumジョブ
  • 検索機能が使われている箇所はたくさんある
    • 画面を含めて全体を検証したい
    • 早く検知したい
  • 定時実行
    • 検索API、Webサイトそのものを検証
    • 検索結果件数にしきい値を設定して検証
  • Jenkinsプラグインを使っている
  • テストケースの作り方
    • 100パターン弱
    • SeleniumIDEで作った
    • Web Driver は使っていない
      • 運用者でも使うのでSeleniumIDEのほうがメンテナンスしやすい
    • テストが落ちたらメールで通知
  • テストのメンテナンスは正直面倒
  • Seleniumの工夫
  • Linuxで動かしている
    • ブラウザの差(見た目の差)を気にしない 検索結果の検証が目的なので
    • xvfbで仮想フレームバッファを作ってFirefoxで検証
    • ジョブを同時実行すると落ちてしまう
    • XMLの検証 nsが独自なのでちょっとハック
    • JSONはevalして検証
Jenkins自身の構築、運用、注意
  • インストールなどは特に問題なし
    • JenkinsはAPサーバの実行ユーザで動作する
    • JenkinsのHOMEをwarのディレクトリと別にする
      • アップデートしたら、いろいろごっそり消えてしまったりしたので
  • 更新が早くてついていくのが大変
    • LTSを使おうかな
    • Jenkinsの認証を使っている
    • 通常はユーザ登録はできないようにしている
  • 案件が複数走るとtag/trunk/branchの管理が大変
  • gitで解決できるかな?
まとめ
  • Jenkinsいい!
    • 毎回やらなければならないことがなくなる
    • Jenkinsが浸透してきた
      • デプロイ作業が精神的に楽に
  • メンテナンスはけっこう大変
  • ジョブが複雑になると大変そう
  • 総じていいプロダクト!

JavaScript継続的インテグレーション

  • 開発基盤グループのお仕事について
  • JavaScriptのテスト事情
    • あまりされてない
    • 実行環境の問題
    • テストしにくい(非同期通信など)
実行環境の問題
  • 今日のメイン
  • JavaScriopt実行環境(railsにおける)
  • ブラウザ
    • 起動が遅い / 不安定
  • JavaScriptエンジン
    • DOM(HTML)がない
  • Selenium
    • 遅い
  • headless
    • GUIのないブラウザ
  • capybara-envjs
    • SpiderMonkey
    • envjs
      • 古いenvjsをフォークしていてマージ不可
  • capybara-zombie
    • v8(node.js)
    • JSDOM
    • 最近出てきたばかりでバグが多い
  • Akephalos
    • Rhino
    • HTMLUnit
    • バグが少ない
    • Seleniumより少しだけ速い→遅い
    • Akephalosとは?
      • エジプトの魔物
      • headlessは首なしなので不吉な名前がおおい
どれもいまいち、そこで
  • capybara-webkit
    • QtWebkitを使って、viewのないブラウザ
    • selenium相当の高精度なエミュレート
    • envjsに近い速度
    • ブラウザなのでやっぱりあんまり安定していない
    • webkitなのでスマートフォン対応もいいかも
  • いい感じかと思ったら
    • マルチバイトが通らない
      • secondlifeさんがパッチ書いてpull request
  • UserAgentを変更できない
    • os0xさんがpullreqで
  • そんなわけでspecが書けるようになった
specを書く
  • そのSpecのゴールはなにか
  • JSCoverage
    • JSファイルの何行目が実行されたかわかる
    • 通っていればいいわけじゃないけど、通っていないところはわかる
    • どうやってる?
      • 各行にカウントアップのコードが入る
  • Jenkinsに渡してカバレッジを表示
    • おとといくらいにできるようになった!
まとめ

大規模環境でRailsと4年間付き合ってきて

TiDD
    • はじめて2年半
    • いまではないと仕事が回らないくらい
  • 2つのカナメ
    • No Ticket, No Commit
    • カスタマイズしたワークフロー
  • 週2回リリース
    • 人数が増えてくるとリリースで問題が頻出
    • いつのまにかリリースされていたり
  • redmineで自作プラグイン
    • リリース範囲のリビジョン、チケットを表示する
    • リリース対象のチケットを一覧化
    • 過去のリリースを簡単にさかのぼって確認できる
    • エンジニア以外の人たちも何がリリースされているか把握できる
  • 継続的インテグレーションしたい
    • gitへの移行
    • デザイナさんの習得コストもあるので、ちょっと難しい
食べログの開発
今回はコードに注目
  • Railsで10万行の世界(テスト抜きで)
    • modelもcontrollerもhelperも、みんな fat なシステム
  • サブシステム化
    • ひとつのrailsアプリだった
      • 開発やデプロイはシンプル
    • 大規模化すると問題発生
      • 障害時の影響範囲が読めない
    • レストラン、お取り寄せ、モバイルなどでサブシステム化
how to
  • テスト→グリーン→修正→グリーン OK
    • これができたらいいけど、仕様や実装コストの問題で諦めた
  • 脱リニューアル症候群
    • 既存のコードは変えない
    • 移動するだけ
  • ソースの静的解析で影響範囲を確認
result
  • サブシステム単位でデプロイ
  • 気軽に変更
  • 大規模案件は新しいサブシステム
  • ただしサブシステムが多くなって複雑化した面もあった
ActiveRecord
  • ModelとORMが同一コンポーネント
  • Controllerにビジネスロジックがはいってしまったり
  • Modelのコードがconfuseになりやすい
  • ActiveRecordとModelを分離させて、サービス層を独自に作った
  • Controllerをとにかく薄く
  • データアクセスをバックエンドに移行
  • HTTPで通信してバックエンドからデータを取ってくる
    • 並列処理ができるようになる
  • Rails3.0 いいね!
    • ActiveModel、Arel など
まとめ
  • railsはシンプルさを優先して1つのコンポーネントが複数の責務を担っている
    • 大規模化→カオス化しやすい
    • もう少しレイヤを増やしたほうがいい
  • Javaのよいところをとりいれていきたい
    • PofEAA

懇親会


タイ料理!パクチー!おいしい!

まとめ

エンジニアだけじゃなく、ほかのひとでも状況を理解できることは大事だなと思った。
たとえばエンジニアだけではなくデザイナも。たとえばインフラエンジニアだけではなく、開発エンジニアも。お互いの領域をある程度理解することで、いろいろなことを加速させることができる。
最近 ruby / rails を使っていたし、Subversion / Jenkins も馴染みがあるし、JavaScript 好きだし、とても勉強になった。こういう取り組みは、一度に全部やろうと思ってもできないし、そうじゃなくても失敗することはよくあると思う。まずは自分たちでできることから取り入れていきたい。確かに上を見上げれば果てしないのだが、すぐに取り組めるものもいっぱいあると思うので。
次回も是非参加したい。抽選に当たることを祈るばかり。
最後においしいご飯を作ってくださった方々にも感謝、ほんとにおいしかった。