技術部の青木峰郎です。 去年までは主にデータ分析システムの構築を担当していましたが、 最近はなぜかレシピサービスのサービス開発をやっています。 今日は、そのサービス開発をする過程で導入したBFF（Backends for Frontends）であるOrchaについて、 導入の動機と実装の詳細をお話しします。 Orcha導入にいたる経緯 まずはOrcha導入までの経緯、動機からお話ししましょう。 最初のきっかけは、わたしが去年から参加しているブックマークのようなサービスの開発プロジェクトでした。 このプロジェクトの実装のために新しいmicroserviceを追加することになったのですが、 そのときにいくつかの要望（制約）がありました。 1つめは、撤退するとなったときに、すぐに、きれいに撤退できること。 2つめが、スマホアプリからのAPI呼び出し回数はできるだけ増やしたくない、という要望です。

こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 先日のiOSDCは大盛況でしたね。とても楽しく、実りあるカンファレンスでした。この記事で僕は ididblog! ということにしようと思っています 😋 クックパッドからは @giginet と僕の二人が登壇しました。発表を聞きに来ていただいた方はありがとうございました。 @giginet の 詳解Fastfile という発表中でさらっと話された、”毎週自動的にリリースされる”という言葉が気になった方はいるのではないでしょうか。実はこのリリースフローについての話もプロポーザルに出していたのです(もっともっと細かくリリースをしてユーザーに最速で価値を届けるためのリリースフロー)。 この記事ではこのリリースフローについての話をしたいと思います。 クックパッドアプリの開発体制 クックパッドアプリの開発体制は人数の変動はあ

こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開

研究開発部の伊尾木です。 研究開発部では、Alexaのスキルを公開しています（Google Assistantも公開していますよ！）。 今回はAlexaスキルのテストを便利にするKuchimaneというツールを公開したので紹介したいと思います。 E2Eテストが難しい 音声UIの開発はまだまだ新しい分野で知見やツールがそろっているわけではありません。 特に E2E (End To End) テスト、RSpecでいうところの Feature spec に相当するようなテストを行うことがとても困難でした。 AlexaでのE2Eテスト 以下のような一連の会話があったとします。 あなた「クックパッドを開いて」 Alexa「クックパッドへようこそ」 あなた「大根のレシピを教えて」 Alexa「大根ですね。サラダ、ナムル、スープのどのレシピがいいですか」 あなた「スープ」 Alexa「大根のスープですね

こんにちは、技術部の長（@s_osa_）です。 先日、新卒の総合職・デザイナー向けに技術基礎研修を行ないました。 そこで研修をするにあたってどのようなことを考えて何をしたか、担当者の視点から書いてみようと思います。 なぜやるのか 研修を担当することになったとき、はじめに「なぜやるのか」「この研修の目的は何なのか」を考え直してみました。 ぼんやりとした「技術についても少しは知っておいてほしい」という気持ちはありましたが、研修内容を考えるにあたって目的を明確にする必要がありました。 研修を受けてもらうのは総合職・デザイナーの人たちです。 エンジニアに対して技術研修があるのは自然ですが、技術職ではない人たちに技術研修を受けてもらうのには然るべき理由があるはずです。 理由の言語化を試みたところ、「研修を受ける人たちは技術職ではないが、テクノロジーカンパニーの一員であることに変わりはない」というとこ

こんにちは、開発基盤の Taiki です。今回は、マイクロサービスで必須のコンポーネントとなりつつあるサービスメッシュについて、クックパッドで構築・運用して得られた知見についてご紹介できればと思います。 サービスメッシュそのものについては以下の記事や発表、チュートリアルで全体感をつかめると思います: https://speakerdeck.com/taiki45/observability-service-mesh-and-microservices https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://istio.io/

インフラストラクチャー部セキュリティグループの水谷(@m_mizutani)です。 クックパッドでは現在セキュリティ監視の高度化に取り組んでおり、その一環としてセキュリティ関連のログ収集およびその分析に力を入れています。ログ収集の部分では可用性などの観点からAWSのオブジェクトストレージサービスであるS3に一部のサービスやサーバのログをまず保存し、後から保存されたファイルを読み込んで分析などに利用しています。分析のためにS3に保存したファイルを前処理する方法としてAWS Glueなどを用いたバッチ処理がありますが、到着したログをなるべくストリームデータのように扱いたい場合もあります。特にセキュリティ関連のログでは以下のようなユースケースで利用しています。 アラートの検出: ログを検査してその中から危険度の高いと考えられるログを探し出し、アラートとして発報します。アラートの具体的な例としては

はじめに サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。 背景 現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。 メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置さ

こんにちは、技術部開発基盤グループの小室 (id:hogelog) です。 最近エンジニアが全員集まる Slack のチャンネルからデプロイ通知等の機械的な通知を排除したらエンジニア同士のコミュニケーションがほぼ毎日発生するようになり満足しています。自分のような無名なペーペーエンジニアも業界に名を馳せる著名エンジニアもフラットに属しているチャンネルが通知で埋まっていて人間の会話がまったく発生しないなんてもったいないですからね。Slack のチャンネルをどう運用するか会社によって文化の違いがあると思いますが、良い運用は参考にしたいので各社どんどん発信してほしいのでよろしくおねがいします。 さてそんな話で終わっても良いのですが、ここは開発者ブログだしせっかくなので最近開発した Slack 関連のアプリケーションを紹介します。 tokite で GitHub から Slack への通知をカスタマ

こんにちは。牧本 (@makimoto) です。最近はバックエンドシステムの設計をやったりしています。 今回は複数のサービスが存在するとき、その間でどのようにデータ連携を実現するかついて述べていきます。 背景と問題定義 cookpad.com は世界有数の規模の Ruby on Rails で作られたウェブアプリケーションです。 巨大な Rails アプリケーションは単純に起動やデプロイ、テストが遅いという問題以上に、自分の変更が与える影響範囲を予測するのが困難という大きな問題があります。cookpad のメインレポジトリ (cookpad_all と呼ばれる) には1つの mountable engine を共有する Rails アプリケーションは7つがあり、困難さに拍車をかけています。cookpad_all を触る開発者は新しい機能を追加する、既存の機能に手を入れる、不用な機能を消すな

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

技術部開発基盤グループの @moro です。 クックパッドでは、昨年に引き続き今年も、夏の技術職インターンシップを実施しました。 クックパッドのインターンシップは前後半に分けた構成になっていました。まず前半はWebサービス開発に必要な技術の中から6つの分野に関する講義や実習を行いました。さらに後半は、前半の座学に合格した方を対象に、メンターとなる社員と一緒に実際の開発現場に入り、具体的な問題解決に取り組んでもらいました。 その中で、前半の講義に使った資料を公開します。 1日目 Git (@moro) 昨年に引き続き、講義初日はGit, TDD, Railsを1営業日で一巡りするという、忙しい構成でした。 Git編では、すでにGitを使っているエンジニアも多いだろうと想定して各コマンドの紹介などは最小限に済ませました。代わりに、Gitの内部構造を説明し「コミットを覚えておけばなんとかなる」感

こんにちは。デザイナーの池田（id:tikeda）です。6月末までユーザーファースト推進室というデザイナーを中心としたユーザー体験について横断的に責任をもっている室の室長を勤めていました。7月からこのユーザーファースト推進室をなくし役割を各部室に分散させる体制変更を行いました。 ユーザーファースト推進室については、過去のインタビューやブログのエントリーをご覧ください。 はじめに サービス開発では、デザイナー・エンジニアといった職種毎に部を構成し各プロジェクトに派遣するようなスタイル（A）、ディレクター・デザイナー・エンジニアといった役割の異なる職種で部を構成するスタイル（B）、またこの2つを組み合わせたハイブリットのような組織が存在しており、弊社だけでなく開発の現場ではよりよい開発が行われるよう試行錯誤が行われていると感じています。 クックパッドではここ数年、アプリケーションエンジニアは各

インフラ部の荒井（@ryot_a_rai）です。 今年の4月、弊社には11名の新卒エンジニアが入社しました。そして現在、3ヶ月間の研修を受けています。ビジネスマナーから技術研修まで幅広く行われていますが、その中で5月下旬におこなったインフラ研修とその後の社内ISUCONについてご紹介します。 インフラ研修（講義） インフラ研修はインフラ部に配属されるエンジニアに限らず、全新卒エンジニアが参加する研修です。日常業務でコードを書いてサービスを開発していくうえで知っておいてほしい、インフラに関する基礎知識や共通言語を獲得することを目的としています。合計3日間をインフラ部の@kani_bと分担して講義しました。研修内容の内容はざっくりと以下のようなものです。 1日目 インターネットとは ブラウザでウェブサイトを閲覧する際になにが起きているのか IPからHTTPまでざっくりと Webインフラアーキテ

こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で

舘野 (id:secondlife / @hotchpotch) です。 クックパッドでは会社の中心にキッチンがあり、社員同士でランチやお菓子を作ったり、イベントを開いたりと社内のコミュニケーション用途で広く使われています。そんなキッチンで作られている様々な料理や、楽しそうなコミニュケーションをその場に居ない人にも伝えたいなー、どうにか伝える方法は無いのかな〜と思っていました。 そんな中、より良い組織を作るために の中でも触れられているコミニュケーション改善の話をしている最中、社内に共用のカメラが置いてあって、撮った写真が何もせずとも自動で社員が見れる場にアップロードするだけの仕組みを提供するだけでうまく行くかも、と思ったので2014年末に作ってみました。 サービスのコンセプト 作るときに盛り込んだコンセプトは以下の二点です。 運用コストがゼロ アップロードコストがゼロ 運用コストがゼロ

会員事業部の小椋(@littlestarling)です。 会員事業部では会員向けサービス全般、中でもプレミアムサービスの価値向上を継続すべく、日々サービス開発を行っています。 クックパッドのプレミアムサービスの柱のひとつは人気順検索機能です。 今年、私はその人気順検索でカバーしきれない課題を見つけ、その課題を解決する新たな価値を生み出すことをミッションとして与えられました。 当社ではサービス開発はディレクターとエンジニアのチームによって進められています。 ディレクターの方に既に明確なビジョンがある場合はその壁当て相手として質問を繰り返して煮詰める作業に徹することが出来ますが、今回はお互いゼロからのスタートとなったため、一緒に"What"と"Why"を探っていくことになりました。 本稿では、このようにエンジニアがディレクターと企画を一緒に考えていったことについて書きたいと思います。 検討のた

技術部開発基盤グループの id:gfx と申します。 Google I/O 2014で発表されたGoogle Play Developer API (Android Publisher)を調べてみました。 Android PublisherはPlayのアプリケーション情報やAPKバイナリの操作を行うAPIで、これがあればリリースエンジニアリングの自動化(Release Engineering as Code)や、アプリの説明文や更新情報のgit管理などができるようになります。リリースエンジニアリングは属人化しがちなので、その作業をコードに落としこむという点で大きな意味を持つAPIだと言えるでしょう。AndroidアプリケーションにおけるRelease Engineering as Codeの実現に一歩近づくことができます。 本エントリでは、Android Publisher API（以下、

こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 たまにネットやイベントなどで「たかがレシピサイトになんでこんな技術力が必要なのか」と言われることがあるので今日はそれに真正面から答えてみようと思います。 例えばどういうところで技術使ってるか 他の人の話はこのブログの他のエントリを見てもらえればわかると思うので、僕の所属しているクックパッド編集室での取り組みの中から今回は料理動画を例に説明します。 Adaptive bitrate streaming での配信 クックパッドで配信している動画は基本的に「料理動画を支える技術」でも触れられている配信プラットフォームを利用しています。 ここでは裏で動画を「低画質」「普通」「高画質」の 3 パターンでエンコードして、回線状況に応じて最適な画質の動画を HTTP Live Streaming (HLS) で配信してい

こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 主に "セキュリティ" や "AWS" といったタグのつきそうなこと全般を担当しています。 Fluentd などのデータコレクタ、Kibana やその他 SaaS による可視化、Kafka, Kinesis, Spark などのストリーム処理といった様々な分野で「ログの処理」がホットですが、アプリケーションのログ (行動ログなど) に関する話題が多くを占めています。 そうしたログの他に重要なのが OS や各種ミドルウェアのシステムログです。これらはトラブルシューティングであったり、セキュリティ上の問題を見つけたり、といったことに使われますが、最低限 syslog でどこかに集約しているだけ、といった例をよく見かけます。 これらのログをきちんと検索可能にし、分析することで、今まで気づかなかったような問