こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

こんにちは。インフラストラクチャー部の加藤(@EugeneK)です。 今回はWebサービスを運用する上で欠かせない、モニタリングをクックパッドでどうしているかという話をします。 死活監視と性能監視 Webサービスを運用している以上、そのサービスを稼働しているサーバがあり、サーバには故障やトラブルが発生します。 また、どれくらいのパフォーマンスが出ているか、リソースをどのくらい消費しているかなどのトレンドを把握することは、成長するサービスを支えていく上で欠かせません。 故障やトラブルにいち早く気づくための仕組みを死活監視と言います。 また、サーバリソースの時系列での推移を知るために、グラフとしてトレンドを可視化する仕組みを性能監視と言います。 ポーリング監視の限界とZabbixのアクティブ監視 クックパッドでは死活監視にNagios、性能監視にMuninを使用してきましたが、サーバ台数の増加

クックパッドで広告領域の企画や実装などを担当している大野です。 2015年期から広告領域ががふたつの事業部に分かれ、私は「新規広告開発部」に所属しています。この事業部は、新しい顧客や販路から収益を上げることと、既存を含む広告の配信を技術的に最適化して収益効率を向上させること、のふたつの目的から新設されました。 事業部に所属するメンバーは、営業やエンジニアといった職種に関わらず、それぞれ収益に対してコミットしています。そして、収益源やビジネスモデルはそれぞれ異なっています。 今回は、特にエンジニアがこうした環境において、やることおよびその優先度をどのように議論して決定しているかを紹介します。やりたいことやアイディアをどう出していくかについては本稿では議論しません。 ちょうど25日に公開された成田による議論 が参考になります。 優先度 = 回収可能額 * 必要投資規模 いきなり結論めいた話です

こんにちは。ユーザーファースト推進室の元山です。 みなさんはスマートフォンアプリケーションやWebサービスの開発・改善をするときにどのようなプロセスで行っているでしょうか？アジャイルやリーンなどの最近では一般的なよくある開発プロセスの中で、今やプロトタイピングは当たり前に行うものとなっていると思います。プロトタイピングを支援するアプリやWebサービスも数多くありますが、ただ闇雲にプロトタイプを作ればいいわけではありませんし、プロトタイプモックを作ること自体が目的化されては意味がありません。 クックパッドでもプロトタイピングを取り入れた開発プロセスを行っていますが、開発のフェーズであったり、または目的によってどのようなアウトプットとしてプロトタイピングするのかは変わってくると思います。今回はクックパッドで実際に行っているプロトタイピングについてフェーズや目的ごとにご紹介しようと思います。 コ

ユーザーファースト室のhidaka（@kaa）です。 クックパッドアプリ内では元々同じレシピの画像を画面、環境によって様々なサイズで表示しています。 レシピの検索結果でのサムネイルや、レシピ詳細画面、写真の拡大表示時などなど。 その際、端末の解像度にあわせ無駄のないよう、表示領域にあわせて画像をリクエストしていました。 *画像配信にはtofuという配信システムが稼働しています http://www.slideshare.net/mirakui/ss-8150494 これでそれぞれの端末にあわせた画像を配信していましたが、今年あたりからさらに最適化が必要になってきました。 問題1 画面密度の上昇 端末のスペックが上がることにより、１インチあたりのピクセル数が増加しました。 retinaと言われていたiPhone 5で326dpiだったのが去年あたりからの高解像度端末の幅1440pxの機種(a

技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ

こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ

自己紹介 会員事業部*1 森田です。昨年はプレミアムサービス(以下PS)*2の訴求改善を担当しました。その中で抜きん出て効果の高かった施策を紹介します。具体的な数値を書くことは出来ないものの、この施策一つで前期に私がおこなった他の施策効果の合計を上回ります。 施策内容 紹介する施策は検索結果に関係するものです。今までは検索結果の下に控えめに表示していた人気順検索*3以外のPSコンテンツの訴求を、検索結果の間に追加しました。 殿堂入りレシピ*4 (人気順検索以外のPSコンテンツ)の訴求 予期せぬ効果 実はこの施策は会員事業部によるものではなく、別部署による検索ページへの大きなデザイン変更施策*5の一部として行われました。そのため検索結果の間でPSコンテンツを紹介することも私が考えたわけではなく、効果も深く考えていませんでした。当時私が気にしていた事は、今までも存在していた人気順検索の訴求効果

こんにちは。新規広告開発部所属エンジニアのレオ（@lchin）です。 ここ2年ほどは、大きな事業部のなかの小規模なエンジニアチームのリーダーを務めてきました。エンジニアリーダーとしては、1人のエンジニアとしてソフトウェア開発をしつつ、チームのメンバーの力をまとめて、事業部のゴールを推進しました。事業部のマネージャほど、マネジメント業務が中心になるわけではありませんが、多くのエンジニアが苦手な人間関係スキルはエンジニアリーダーにも必要です。 メンバーは何か大きな不安を抱えていないのか？ポテンシャルを発揮できていないメンバーにどうフィードバックするのか？メンバー間に何かトラブルはないのか？見えないところで仕事の妨げはないか？チームでソフトウェア開発を行う上のよくある悩みだと思いますが、皆さんはどう解決していますか？私は、個人面談はこういった悩みを解消するための大変有効な手段だと思います。 なぜ

こんにちは。投稿推進部の清水(@pachirel)です。 2009年にクックパッドに入社してから、インフラ周り、クックパッドの人事周り（採用・評価）や広告周りのシステム開発を担当していました。 2014年4月頃から、2〜3名の小さなチームで新規サービスのプロトタイピングをいくつか行っています。 企画の詳細は省きますが、私がこの10ヶ月ほどで学んだことをまとめました。アジャイル開発やLean startupの考えに共感しているので、そこから得た内容に私の体験を付け加えたものになっています。 今回はプログラミングに関する技術的な内容は含まれていません。 なぜ作るか スタートアップが失敗する原因で一番多いのは「人が必要としていないものを作ってしまった」というものです。 The Top 20 Reasons Startups Fail 社内の新規サービス開発でも同じ傾向があるのではないでしょうか。