Cookpad Summer Internship 2022 を開催します!

cookpad summer intern 2022

こんにちは、ボイスサービス部の ymd (@y_am_a_da) です。今年は新卒採用エンジニアリーダーもやっています。

今年もクックパッドはサマーインターンシップを開催します!本記事ではエンジニアコースについてご紹介いたします。

以下のサイトからご応募頂けます。

internship.cookpad.jp

今年は、 15-day Tech Course と 3-day Tech Course の 2 種類をご用意しております。

15-day Tech Course

こちらのコースでは、前半の5日間でクックパッドが日々のプロダクトづくりに活用しているサービス開発の手法論や、Rubyによるサーバーサイド開発とSwiftによるモバイルアプリケーションの開発についての講義を実施します。 そして後半の10日間では、 OJT として前半の講義で得た知識を用いてメンターと共に実際に現場で業務を行って頂きます。

15日間という短い期間ですが、実務を通してメンターからレビューやフィードバックを受けることで、グッと一回り大きく成長できる内容となっております!

今年は以下の日程で開催されます。

  • 8月15日(月)〜9月2日(金)

昨年の様子については、以下の記事をご覧ください。

techlife.cookpad.com

3-day Tech Course

このインターンシップでは、ユーザーに価値を届けるプロダクトづくりのノウハウの講義・実践、そしてフィードバックを3日間に詰め込んだサービス開発スキルをグッと向上させることができるコースです。

まずは、クックパッドがプロダクトをつくる上で大切にしている考え方やサービス開発で活用しているフレームワークを中心に講義を実施します。そして、実際にユーザーとコミュニケーションを取りながら価値仮説を検証し、課題解決のためのプロダクトづくりに取り組んでいただきます。

サービス開発に日々注力している社員のサポートを受けつつ、アウトプットに対して実際のユーザーからレビューやフィードバックを受けることができる短い期間ながら実践的な内容となっております!

こちらの開催日や詳細については別途、後日に公開を予定しております。

最後に

参加してくださる皆さまのため、サマーインターンシップには毎年会社を挙げて取り組んでいます。 クックパッドのエンジニアになった「未来の自分」を体験できた、と参加して頂く皆様に実感してもらえることを目指して準備を進めていきます。

また、長期の就業型インターンシップも通年で募集しています。 興味のある方は、以下のページからご応募ください。

internship.cookpad.jp

皆様のご応募お待ちしております!

internship.cookpad.jp

工学的知見と実際の観測データに基づいて物理世界にサービスを展開しています

こんにちは.研究開発部の鈴本 (@_meltingrabbit) です.

クックパッドの研究開発部 では,「毎日の料理を楽しみにする」というミッションを実現するために,様々な野心的なチャレンジをしています.一方で,我々研究開発部のメンバーには,自分のもてる技術を用いて,部署内外の課題を発見し,解決するという使命もあるのです.

今回はクックパッドの生鮮 EC プラットフォームサービスであるクックパッドマートで食品流通のために展開している冷蔵庫の温度管理についてご紹介します.クックパッドマートで使用されてる冷蔵庫は,サービスの安定稼働のため,次のように工学的知見と実際の観測データに基づき運用されています.

マートステーションに設置されている冷蔵庫の課題

クックパッドマートでは,ユーザーの皆さまが食品を受け取る場所をマートステーションと呼んでおり,そこには下図のような冷蔵庫が設置されています.

f:id:meltingrabbit:20220222223237j:plain
マートステーション

そして,この冷蔵庫の冷却設定は,「より安全側になるように,少し強めに冷却する」というような設定で運用しています.しかしながら,冷蔵庫というハードウェアを実環境に展開している以上,どうしても目標の温度に対して多少上がりすぎてしまったり,冷えすぎてしまったりするという課題がありました.

クックパッドマートでは,すべての冷蔵庫に温度計を設置し,リアルタイムで庫内温度をモニタリングしています.それによって,社内規定の温度ポリシーを逸脱し食品が危険にさらされた場合や,葉物野菜等が低温障害によって品質が損なわれた場合に,直ちに適切な対応がとれるようになっています.

冷蔵庫の温度設定を見直すことで,弊社にとっては返品ロスの削減,ユーザーの皆さまにとっては注文した商品が高い品質で届くというサービスクオリティの向上が図れるのではないか,という考えに至りました.ただし,「温度設定を見直し,場合によっては設定温度を上げる」という施策は,心理的ハードルが高く,なかなか実行に踏み切れていませんでした.

冷蔵庫の温度をより適切にするには?

最適化したい対象が目の前にあるとき,まず最初にしなければならないことは,対象の正しい理解です.

はじめに,使用している冷蔵庫を “理想環境” で稼働させたときの特性を見てみます.理想環境とは,外乱の少なく,安定した,想定した環境,さらには,製造誤差なども無視できる状況下,つまり冷蔵庫でいえば,外気温・湿度が一定でかつ,その他の外的要因がない環境,です.

この下図が,その時の温度グラフです.一番上の紫線が室温(恒温槽)の気温で,下方の3線が3台の冷蔵庫の庫内温度です.冷蔵庫は基本的には,「庫内がある温度を超えたら冷却ON,ある温度を下回ったら冷却OFF」というように2状態で制御されています(いわゆるバンバン制御,ないしはオンオフ制御). つまり,

  • 庫内温度が上昇し,ある基準温度を上回ったら冷却を開始.
  • 冷却に伴い庫内温度が下降.ある別の基準温度を下回ったら冷却を停止.
  • 停止に伴い庫内温度が上昇.(以下繰り返し)

というような挙動を示します.このようにして,ここでは庫内温度がおよそ0〜4度に制御されています*1

f:id:meltingrabbit:20220222224526p:plain
使用している冷蔵庫の理想環境での庫内温度(スペックシートより)

理想環境での挙動がわかったら,今度は “実環境” でどうなるか,です.ソフトウェアでも,デプロイしてみたら,想定外の時間に想定以上のアクセスがあった,とか,想定外のデータが飛んできた,とかありますよね.ハードウェアを実世界に展開したときでももちろん,似たような想定外や外的要因が発生するものです.

次の画像が(故障や異常な冷蔵庫を除いて)無作為に抽出したある冷蔵庫 60台の温度ログです.ハードウェアを扱う以上,現実世界は理想状態からは程遠く,そこまで単純ではありません.

f:id:meltingrabbit:20220222231125p:plain
冷蔵庫 60台分の温度時系列ログ

ひと目見ただけでも,次のようなことが理想環境下とは異なることがわかります *2

  1. グラフの形状が異なる(理想環境ではきれいな一次遅れ系だが,実環境では異なる).
  2. 振幅が異なる(理想環境では0〜4度の4度ほどだが,実環境では3度以下のものもちらほら).
  3. 実現される温度帯がばらついている(理想環境では0〜4度の範囲に入るとされているが,ステーション実測では個体ごとにばらつき,全体として-2〜6度の範囲に).

1, 2は,理想環境下では無負荷(庫内が空)で気流がきれいに流れている一方,実環境下の冷蔵庫では庫内に食品が入っているため,空気の循環が異なることなどが原因として考えられます.3は製造公差,環境外乱などが原因でしょう.この冷蔵庫の温度制御回路はアナログ回路です.つまり回路定数などに誤差が発生しますし,冷風の温度計測にもバイアスがのります.また,冷蔵庫はコンビニの店内といった空調の効いた環境からマンションのエントランスといった半屋外など,環境の異なる場所に設置されています.そういったことを考慮に入れると,このばらつきも納得できます.

さらに,庫内というのは実は3次元的な空間であり,大きさを持っています.つまり,冷蔵庫上段奥と,冷蔵庫下段手前では,その温度は異なります.実際にたくさんの計測機器を冷蔵庫に設置し,実験を繰り返すことで,このような庫内温度分布といった特性を理解していき,そしてその特性が食品に与える影響を考えていくのです.

本記事では詳細は省略しますが,理想環境では食品をおおむね0〜4度(2±2度)で保存できると思いきや,実環境では,

  • 庫内温度のバンバン制御により±2度
  • 公差,外乱などにより±2度
  • 庫内温度分布などの影響により±1.5度

などの誤差が累積し,同じ型番の冷蔵庫を展開したとしても,食品が体感する可能性がある温度帯はレアケースも含め-3.5〜7.5度(2±5.5度)に分布すると推定されました.

工学的知見と観測データに基づく解析から,エビデンスをもって施策決定を行う

さて,本題です.

工学的知見と実験等によるデータから,マートステーションで使われている冷蔵庫の実環境における特性を理解することができました.あとは,多数の実環境データを用いた統計的解析により,冷蔵庫の最適な温度設定を探っていきます.

はじめに,運が悪く最悪ケース級の外れ値を引き当ててしまった冷蔵庫や,そもそも不具合を抱えている冷蔵庫といった,社内規定である温度ポリシーを違反しうる可能性の高い冷蔵庫を洗い出します.

冒頭でお見せしたように,冷蔵庫の温度はバンバン制御しており,周期的に上昇と下降を繰り返しています.さらに扉の開閉などによっても温度は変化します.このように,瞬時的な温度ですべての異常を検知するのは困難であるため,以下のような可視化と解析を行いました.

  1. 扉の開閉やその他の影響が少ないと思われる,深夜0時~早朝6時までのデータを収集
  2. 周期的に振動する時系列データから,外れ値などの影響を取り除くため,下図赤線のような上側温度と下側温度を求める(算出方法の詳細は割愛)
  3. 下側温度を横軸,上側温度を縦軸にとった散布図を描く

f:id:meltingrabbit:20220222231627p:plain
青線:温度履歴,赤線:算出される上側温度と下側温度

結果は下図(見やすさのため極端な外れ値は除いてます)の紫点のようになります,赤枠は,これまでにわかっている冷蔵庫の特性と解析方法から予想される温度域(を大雑把に直線で描画したもの)で,概ねそこに収まっていることがわかります.

f:id:meltingrabbit:20220222232741p:plain
異常冷蔵庫検出結果

一方で,この赤枠からおおきく外れているものは何かがおかしく,詳細に見ていくと,

  • マートステーションが稼働する前のデータの混入
  • 冷蔵庫本体の故障
  • 半ドアや施工ミス(冷蔵庫の設定ミスや,そもそもの設置方法のミス)などの冷蔵庫が不適切な状態
  • データ欠損などのデータが不完全によるもの
  • その他(いろいろな誤差が悪い方へ重なり範囲を逸脱したもの.どうしてもハードウェアは外れ値を出すものはある.)

に分類でき,最初のスクリーニングとしては十分な威力を発揮してくれました.

このようにして検出された潜在的に温度ポリシー違反となりうる可能性の高い冷蔵庫は順次是正していくことにします.そうすると,「庫内の設定温度を少し上げても,食品の危険性はそこまで増加せず,むしろ低温障害などの影響が低減できる」ということがわかってきました.また,管理コストの問題から,冷えすぎている冷蔵庫のみではなく,展開しているすべての冷蔵庫の温度設定を一括で変更したいと考えました.一方で,冒頭に記したとおり,安全側に寄せるために強めにしている冷却を弱める,というのは心理的ハードルがつきまといます.

この心理的ハードルを乗り越えるために,「庫内の温度の設定値を上げること」がどの程度効果があり,そして現実的に可能であることを検証していきます.そのためには実験あるのみです.数十台の冷蔵庫の温度設定を変更した時のデータを取得し,解析します.そうして得られた工学的知見に基づくエビデンスをもとに,「マートステーションの冷蔵庫の設定温度を一括で上げること」,「温度設定の変更は,冷却モードを1段引き下げるのが最適であること」を提案しました.

提案文章内のエビデンスの概要は,だいたい次のようなものを用意しました.

f:id:meltingrabbit:20220223002921p:plain

  • 左図が冷蔵庫の温度が低い時間帯の温度(下側温度)分布
    • 青色で示した箇所が,今回の施策で氷点下を脱する可能性が十分ある冷蔵庫
    • 赤色で示した箇所が,今回の施策で氷点下を脱することができない見込みの冷蔵庫.とはいえ,これは下側温度であり,常に氷点下に陥っているわけではないことに注意すること.
  • 右図が冷蔵庫の温度が高い時間帯の温度(上側温度)分布
    • 青色で示した箇所が,今回の施策で一時的にでも10度を超えうる冷蔵庫だが,そもそもここに現れているのは何らかの異常を抱えているものであるので(サービスでの利用が停止されている),強く意識する必要はない(別の方法で是正していくべきもの)
  • 平均温度は全体的に0.5~1.0度ほど上昇するが,幸運なことに上側温度に対して下側温度の方が温度上昇幅が大きいことが事前実験の解析から予想される
    • したがってリスクは小さい
  • 冷却モードを1段(およそ1度程度)引き下げるのが,ちょうどよい
    • 1段ではまだまだ冷えすぎてしまう冷蔵庫もあるが,全体分布としては1段が最適
    • 今回救えなかったものは,個別に適当な処置を施すのがよい

こうして社内の合意形成を得た施策を実施した結果は,ほぼぼぼ予想通りでした. このようにして,様々な検討事項に対してエビデンスを示し,施策提案を行うことで,クックパッドマートのサービスクオリティを向上させることができました.

終わりに

このように,クックパッドでは,しっかりと事前解析を行いエビデンスを示すことで,生鮮食品流通といった場でも,重要な施策の意思決定が実現されています.そのエビデンスの裏では,工学的な知見や実験データ,運用データに基づく解析が行われています.ここでは紹介しきれませんでしたが,クックパッドマートではサービスクオリティを向上させるために,下図のような実際の食品をつかった実験や,実際に冷蔵庫を恒温槽で動作させ,様々なデータを取得する実験等も行っています.こういったデータを収集することで,工学的・物理的な現象理解がすすみ,適切な運用ができるようになると考えています.

f:id:meltingrabbit:20220223003924j:plain
実際の食品を用いて冷蔵庫庫内だけではなく,食品内部・表面等の温度特性を測定している

f:id:meltingrabbit:20220223004031j:plain
冷蔵庫の恒温槽試験の様子

*1:この図から,実験設備(恒温槽)の空調もバンバン制御されてることがわかっておもしろいですね.

*2:時々温度が急上昇しているのは,長時間,または断続的に扉が開けられていることによるもの

3/12 (土) 開催!「6社合同SRE勉強会」のクックパッドのセッションを紹介します

6社合同SRE勉強会について

クックパッド技術部 SRE チームの @eagletmt@mozamimy が、以下の Connpass で告知・募集されている「6社合同SRE勉強会」に登壇します。

https://line.connpass.com/event/236497/

6社合同SRE勉強会は、IT 企業 6 社 (LINE/メルカリ/クックパッド/ディー・エヌ・エー/サイバーエージェント/リクルート) が合同で開催する、Site Reliability Engineering (SRE) 領域の勉強会です。各社が特徴的な事例を共有し、各セッションのAsk the Speakerでは違う会社の登壇者がモデレーター兼聞き手を務めて、知見共有&深堀りを行なっていきます。

多様なバックグラウンドを持つ各社の SRE が取り組んでいる課題について、技術的な面から組織的な面までを絡めた、魅力的な内容のセッションが盛りだくさんとなっています。

以下、クックパッド SRE によるセッションの概要をご紹介します。現在、鋭意資料の準備中ですので、本番では細かい内容が変更になる可能性がありますがご容赦ください。

Track B 13:30-14:15: 少人数でも運用できるインフラ作り

技術部 SRE グループの鈴木 (id:eagletmt) です。このセッションではクックパッドにおけるインフラ構成の変遷を概観しつつ、その変遷の根底にあったマネージドサービス化やセルフサービス化について話そうと思っています。

私がクックパッドに入社した2014年当時、社内の多くのエンジニアはレシピサービス (cookpad.com) の開発にかかわっており、モノリシックな Rails アプリケーションが Amazon EC2 上にデプロイされてレシピサービスが実現されていました。SRE *1 の仕事もレシピサービスに関することが中心でした。一方でみんなのカフェや料理教室といったサービスをレシピサービスとは独立したアプリケーションで提供しており、API での連携の基礎ができてきたりマイクロサービス化が始まりつつありました https://techlife.cookpad.com/entry/2014/09/08/093000 。レシピサービスのマイクロサービス化についてはお台場プロジェクト https://techlife.cookpad.com/entry/2018-odaiba-strategy へと続いていき、このお台場プロジェクトによって大きく進みました。現在のレシピサービスは Web フロントエンドの一部を Next.js で提供するようになったり https://techlife.cookpad.com/entry/2020/12/01/093000 、スマートフォンアプリ向け API の一部は Java で実装された BFF を利用していたり https://techlife.cookpad.com/entry/2019-orcha-bff 、Go で実装された広告配信サーバがあったり https://techlife.cookpad.com/entry/dynamodb-accelerator-usecase-adserver 、実装言語も異なる様々なアプリケーションから成り立っています。そして事業面でもレシピサービスだけでなくクックパッドマートにも力を入れていて、多くのサーバーサイドエンジニアがレシピサービスの Rails アプリ開発に従事していた頃とは大きく状況が変わっています。

このようなアプリケーションの変化に合わせて、インフラ構成や SRE の役割も変化していく必要があります。新規事業や新しいマイクロサービスがどんどん増えていく状況では、10人にも満たない SRE チームがアプリケーションに合わせて EC2 インスタンスや MySQL を用意して運用していてはそれだけで手一杯になってしまいます。そこでサービス開発において SRE がボトルネックとならないようにするため、可能な限り AWS のマネージドサービスを利用するようにして SRE にとっても運用負荷を軽減しつつ、事業部のエンジニアへと運用を委譲しやすくしました。さらに、新規のアプリケーションを本番環境で動かすために必要な作業を自動化したり、インフラ操作の権限を委譲していくことで、できるだけ SRE の手作業無しでも新規リリースやミドルウェアの変更を行えるようにセルフサービス化を進めてきました。このセルフサービス化の考え方について話しつつ、とくに自分が中心的に関わっていた ECS 関連や Terraform 移行について一例として触れようと思っています。

また、SRE の運用負担について話す上でオンコール対応は切っても切れない話題でしょう。マイクロサービス化に合わせてインフラが複雑化する中、アラーティングの基準やオンコール体制をどう変化させたかについても触れようと思っています。

関連記事

Track A 15:15-16:00: AWS コストを可視化して「説明」できるようにするための取り組み

技術部 SRE グループの mozamimy です。本セッションでは、クックパッドにおける、AWS のコストを可視化・管理し、最適化までカバーする取り組みについて話す予定です。AWS コストを、と銘打っていますが、その根本的な考え方や各テクニックの本質的な部分は GCP や Azure といった他のパブリッククラウドでも役に立つでしょう。

会社のミッションを達成するための原動力として、お金は有限のリソースであり適切に管理するべきです。サービスを提供するためのインフラはそれ自体が利益を生むことはできません。したがって、ユーザ向けに同じクオリティのサービスや、社内の開発者向けに同じ開発効率を提供できるのであれば、インフラコストを下げて、事業に直接関係する投資などの有意義なお金の使い方をするほうがよいでしょう。

AWS のコスト管理・最適化の枝葉のテクニックはいろいろありますが、「コストを説明できる」というところに集約できるとわたしは考えています。クックパッドではこの考え方をベースにして、年次の AWS の予算案の作成、月次の経営層をまじえてのコストの振り返り、週次の SRE 定例ミーティングなどを中心とした、コスト管理の業務プロセスを実践しています。

本セッションでは、まず「コストを説明できる」というのはどういうことかを説明したのち、過去 (2019 年頃) のクックパッドにおける AWS コスト管理の課題を振り返り、どのような流れで現在の業務プロセスになったのかを説明します。

次に、その業務プロセスを支える技術について、以下の仕組みについてそれぞれ説明します。

  • RI / Savings Plans を管理するための仕組み
  • コスト配分タグを管理と月次レポートの半自動生成機能を中心とした、スタッフ向けのウェブツール
  • 開発向けサンドボックス AWS アカウントのリソースを定期的に掃除する仕組み

これらの仕組みは AWS のマネージドサービス (Cost Explorer や CloudWatch カスタムメトリクスなど) をうまく利用しつつ、足りない部分を内製で補うようになっています。

さいごに、これらの仕組みを整えたことによりメリットがあったと実感できた事例や、社内のプロダクト開発チームに与えた影響、これからの展望についても述べます。

本セッションは本ブログの以下の記事をベースにしつつ、内容をより整理した形で、最新のアップデートとともにお届けする予定です。

まとめ

3/12 (土) に開催される6社合同SRE勉強会のイベント概要と、クックパッドの登壇情報をお伝えしました。各社興味深い発表が目白押しですので、以下の各社のブログへのリンクからセッション内容をチェックしつつ、ぜひご参加ください。

事前質問について

クックパッドのセッションも事前質問を受付中です。以下のリンクからお気軽にどうぞ!

*1:正確には当時の名前は技術部およびインフラ部