SRE 兼よろず屋の id:sora_h です。最近は本社移転プロジェクトをやっています。趣味は Web *1 です。 さて、クックパッドでは 2020 年 12 月に TLS 1.0 および TLS 1.1 (以後 "Legacy TLS") を廃止しました。 Legacy TLS は RFC 7457 でまとめられているような既知の脆弱性の存在などから、Chrome, Firefox といった主要ブラウザを含め各所でのサポートが打ち切られつつあります。また、現在では IETF においても Legacy TLS は deprecated と RFC 8996 にて宣言されました。 クックパッドでもセキュリティ対策およびレガシーな技術と向き合う一環で廃止を進めました。我々は歴史の長いサービスも提供しているため、古い Android や Internet Explorer などからのアクセス

技術部 SRE グループの鈴木 (id:eagletmt) です。 クックパッドでは Amazon ECS をオーケストレータとして Docker を利用しています。Docker 自体は2014年末から本番環境にも導入を始めていましたが当時はまだ ECS が GA になっておらず、別のしくみを作って運用していました。2015年4月に GA となった ECS の検討と準備を始め、2016年より本格導入へと至りました。クックパッドでは当初から Hako というツールを用いて ECS を利用しており、Hako の最初のコミットは2015年9月でした。 https://github.com/eagletmt/hako/commit/7f95497505ef78491f3f68e9d648204c7c9bb5e2 当時は ECS に機能が足りずに自前で工夫していた部分も多かったのですが、ECS やそ

こんにちは。クックパッドでエンジニアをしている @morishin です。Bdash Server というデータ分析 SQL を共有するアプリケーションを作って社内で使い始めたのでその紹介をします。 クックパッドのサービス開発は「仮説を立てる」→「作ってリリース」→「効果検証」の繰り返しで進んでいます。ここで言う効果検証というのは作ったサービスが狙い通りの使われ方をし、ユーザーに価値を提供できているかどうかの確認のことです。その手段は複数あり、実際に使っていただいたユーザーさんにインタビューをさせていただく場合もあればアプリケーションから送信されたアクセスログ等を分析することで評価する場合もあります。この記事では後者の定量分析を効率化するためのツールを作った話をします。 アプリの概要 まずはアプリの機能を紹介します。Bdash Server は、Bdash という同僚 (@hokaccha

技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが

技術部クックパッドサービス基盤グループの id:koba789 です。 昨年まではデータ基盤グループというところで 最新のログもすぐクエリできる速くて容量無限の最強ログ基盤 を作ったりしていました。 今年はちょっとチームを移動しまして、検索システムをいじっていました。今回はそのお話です。 なお、クックパッドには様々な検索システムがありますが、この記事では説明を簡単にするためにレシピの検索のみに焦点をあてています。 クックパッドの検索システムにあった課題 クックパッドにはレシピを検索できる機能があります。 プレミアム会員限定の人気順検索もこの機能の一部です。 しかし、この重要な機能を支える検索システムにはいくつもの課題がありました。 Solr が古すぎる クックパッドでは、レシピ検索を含む多くの検索機能にSolrを用いています。 今年の始めに私がこの課題に取り組み始めた時点では、その Sol

こんにちは。PlayStation 5が一向に買えない@giginetです。普段はモバイル基盤部というところでiOSの基盤開発をしています。 皆さん、行動していますか？我々は日々Webサービス上で様々な行動をしています。サービス開発において、改善に活かすための効率的な行動ログの収集方法はしばしば課題になります。 今回は、サービス開発者がモバイルアプリ上で簡単にログを定義し、分析を行えるログ基盤を導入した事例について紹介します。 行動ログとは何か モバイルアプリの行動ログとは、ユーザーのアプリ上の操作や利用状況を取得、集積するためのものです。 例えば、特定の画面を表示したり、特定のボタンをタップしたり、といったユーザー操作を起点として送信されています。 集められたログは、サービス開発のための分析や実態把握に役立てられます。 最近はFirebase Analyticsなど、PaaSの形態で提供

最近はZX-25Rが気になっている菅原です。4気筒250ccといえば、以前バリオス2に乗っていたんですが、あれもよく回るよいバイクでした。足つきの良さが懐かしいです。 この記事では、クエリログを使ったAurora MySQLの負荷テストの話を書きます。 MySQLの負荷テスト サービスに使われているデータベースは、Webサーバと比べて自動的なスケールアップ・スケールアウトが簡単ではないためキャパシティプランニングは非常に重要です。サービスへのアクセス増による負荷増大の結果、急激に性能が低下するためなるべく事前にキャパシティを把握しておきたいところです。 クックパッドではサービスのデータベースとして主にAurora MySQLを利用しているのですが、キャパシティを把握するための負荷テストには以前から苦労してきました。 1. シナリオを書くのが大変 サービスで使われているデータベースの負荷テス

こんにちは、技術部SRグループの菅原です。 最近、Ninja650からNinja1000に乗り換えました。パワーがあるせいで３速発進・４速発進が平気でできてしまい、シフトワークがどんどん下手になっています。精進したいものです。 この記事では、Amazon RDS/Auroraをクローンするシステムを作った話を書きます。 Amazon RDS/Auroraをクローンするシステム サービス開発を行っていると、調査や検証でプロダクション環境で使われているデータベースが必要になることがあります。開発環境やステージング環境にもデータベースは存在するのですが、プロダクション環境のデータでしか再現しないバグの調査や、プロダクション環境のデータ量でのスキーマ変更の負荷の検証など、開発環境やステージング環境のデータベースではできない作業も多いです。しかし、オペレーションミスや個人情報へのアクセスを考えると、

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

こんにちは、事業開発部でプロジェクトマネージャー兼エンジニアをやっている新井(@SpicyCoffee)です。10 万円の申請書を書く前に 20 万円のパソコンを買いました。 クックパッドでは、毎日の料理を楽しみにするべく日々サービス開発がおこなわれています。本稿では、サービス開発の中でも重要かつ難解な「KPI の設定」について、私がプロジェクトマネージャーとして普段考えていることや注意している点を紹介します。 KPI を決めるのは難しい サービス開発において KPI を設定し、それを改善するような施策や検証を繰り返していくことは基本中の基本です。しかしながら、現実には「KPI を設定する」という行為自体の難易度が非常に高く、日夜頭を悩ませている開発者のみなさんも多いのではないでしょうか。 以下では、その要因の一つである「KPI は複数の要件を満たす必要がある」ことについて考えます。 満た

こんにちは、@morishin127 です。クックパッドの在宅勤務環境 - クックパッド開発者ブログ でも書かれていた通り、クックパッドは2月18日から現在に至るまで全従業員が原則在宅勤務となっています。突然の在宅勤務体制の中でも社員がなるべくいつも通りの生産性を発揮できるように様々な取り組みを行っています。このような状況になる以前から Slack や Zoom、GitHub Issue などのコミュニケーションツールが職種を問わず日常的に利用されていたため、比較的物理的な制約を受けないコミュニケーションができていたと感じていますが、それでもやはり全員が在宅勤務になると色々な課題が生じました。従業員に向けたアンケートでは次のような課題が挙がっていました。 仕事とプライベートの切り替えが難しい 同僚や上司との気軽なコミュニケーションがしにくい いちいち Zoom をつなぐのはハードルが高い

技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて

技術部 SRE グループの鈴木 (id:eagletmt) です。クックパッドでは Codenize.tools を用いて様々なリソースをコードで管理してきましたが、現在では大部分が Terraform へと移行しています。Terraform の使い方等については既に沢山のドキュメントや紹介記事があるので本エントリでは触れず、なぜ Terraform へと移行しているのか、どのように Terraform を利用しているのかについて書いていきます。 Terraform 移行の理由 クックパッドでは自分と同じく SRE グループに所属している菅原 (id:winebarrel) によって開発された Codenize.tools のツール群を利用して IAM、Route 53、CloudWatch Alarm、CloudWatch Events 等をコードで管理し、いわゆる GitOps を実践

技術部の笹田（ko1）と遠藤（mame）です。クックパッドで Ruby (MRI: Matz Ruby Implementation、いわゆる ruby コマンド) の開発をしています。お金をもらって Ruby を開発しているのでプロの Ruby コミッタです。 去年の記事「プロと読み解く Ruby 2.6 NEWS ファイル」に続き、今年も本日 12/25 リリース予定の Ruby 2.7 の NEWS ファイルの解説をしてみようと思います。NEWS ファイルとは何か、というのは去年の記事を見て下さい。 実は最近、NEWS ファイルを読みやすくしよう、と例を入れたりしていて、以前のものに比べて読みやすくはなっています（英語だけど）。記事中のコードも、NEWS ファイルから引用しているものがあります。本記事では、変更の解説に加え、執筆者らが開発に携わっているということを活かして、「なぜ変更

技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいるため、今回はそれについてご紹介します。 前半では、そもそもの話として「なぜコスト最適化が重要なのか」「何が難しいのか」「何をすべきなのか」といったことを述べます。これは、当たり前すぎて逆に陽に語られることが少ない (とわたしは感じています) トピックで、一度しっかり言語化しておいてもいいかなと考えたからです。内容のほとんどはわたしの脳内ダンプで、クックパッドという会社のコンテキストや組織としてのステージが前提になっているため、大多数の組織について当てはまる内容とは限りません。 後半では、コスト最適化の一例として、リザーブドインスタンス (以下 RI と略記) を維持管理するためのフローと、それを支えるモニタリング

技術部 SRE グループの id:itkq です。2019 夏アニメで一番好きな作品は Re:ステージ！ドリームデイズ♪ です。この記事では SRE が運用している退職処理の自動化について説明します。 退職処理とは 入社後に業務のための様々なアカウントを作成するのと反対に、退職時にはそれらのアカウントを無効化する必要があります。これを退職処理と呼んでいます。SRE が管轄している典型的な例では、SSO に対応していない SaaS のログインアカウント・AWS の IAM User・データベースの個人ログインユーザなどが該当します。これらのアカウントは社員によって要否が異なったり必要な権限が異なるため、入社時に一括で用意せず必要に応じて申請してもらう形をとっています。一方で退職時にはそれらのアカウントをすべて無効化する必要があります。 退職処理は繰り返され、自動化の余地のあるタスクです。また

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

技術部のフルタイムRubyコミッタの遠藤（@mametter）です。昨日の Hackarade #04 の開催報告に続き、2日連続で記事を投稿します。 今回は、ある条件下でのRubyの実行速度を高速化した話を紹介します。この改善はすでにMRIの先端にコミットされていて*1、年末リリース予定のRuby 2.6に含まれる予定です。 ひとことで言うと、「簡潔ビットベクトルを索引に使うことで、プログラムカウンタから行番号を計算するアルゴリズムをO(log N)からO(1)に改善した。これにより、TracePoint有効時やコードカバレッジ測定下で、長さ N のメソッドの実行が O(N log N) から O(N) に高速化される」ということです。順に説明します。 背景：Rubyのバイトコードの構造 この最適化を理解するにはまず、Rubyのバイトコードのある特徴を知る必要があります。 たとえば x

こんにちは！広報部のとくなり餃子大好き（ id:tokunarigyozadaisuki ）です。 クックパッドのSlackには無数のオープンチャンネルが存在していますが、最近盛り上がりを見せているのが「#keyboards」というチャンネル。先週末コミックマーケットが開催されていたためここ最近はその話でもちきりの様子でしたが、普段から大事な仕事道具であるキーボードにこだわりを持った社員が日々情報交換をしています。興味本位で社員のキーボードをのぞいでみると、ピカピカ光るものから、カチカチッと音がなるもの、アルファベットも数字も書いていないもの……その多彩さにびっくりします。 そこで、クックパッドエンジニアの最近のキーボード事情を調査してみました！ なお、HHKBやRealforceはクックパッドでは当たり前だったので、紹介は割愛いたします。 クックパッドエンジニアのキーボード @takai

こんにちは。研究開発部の @vanhuyz です。機械学習・自然言語処理を中心に研究開発しています。 今回は機械学習を活用してユーザーからのご意見を 81 のカテゴリーに自動分類し、ユーザーサポートスタッフによる手動分類の工数を半分にできた話を紹介したいと思います。 背景 クックパッドは現在約 5,500 万人の国内月間ユーザーがあり、日々ユーザーからたくさんのご意見やご要望を頂いています。創業してからユーザーの声を大事に扱う文化があり、どのご意見も一度目を通すようにユーザーサポートスタッフが努力しています。ご意見はスタッフによってさらに分類され、必要に応じてディレクターやエンジニアに振り分けられています。 例えば、こんな感じのご意見が来ています。「このレシピは簡単なので、子供とやってみました。楽しかったです」や「機種変更して、ログイン出来ません」や「もっと具体的な内容でも検索できるように