radioc@?

レディオキャットハテナ

【勉強会メモ】【京都開催 feat.はてな】Cookpad Tech Kitchen #11

cookpad.connpass.com

日時:2017/09/28(木) 19:00 〜 21:00

場所:株式会社はてな 京都オフィス(本社)

Cookpadさんの勉強会に関西で参加できる機会はなかなか無いので京都まで行ってきた。@cockscomb さんのSPAの話も興味があったけど時間的に間に合わず。。残念。

ScalaPerlでMicroservices in production

発表者:中澤 亮太さん/株式会社はてな

決済システムの見直しにあたり、マイクロサービス化を検討。Scala関西Summit 2016の資料 をベースにその後の稼働状況などから現在の評価を加えた内容。

旧システムの状態

  • Webアプリケーション
    • APIではなくHTMLのフォームがあるのみ
  • Perlの共通のモジュールを周辺システムが呼び合う仕組み
    • Perl以外のシステムで使うのは不可能

新決済システム

マイクロサービスアーキテクチャオライリー

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

  • 1章から3章がおすすめ
  • 「優れたサービスとは?」について述べられている

疎結合と高凝集性

  • スコープを小さく明瞭に
  • 分割統治する

本番投入しての採点

  • ガバナンス:○
    • チームはモノリシック
  • 疎結合:○
  • 高凝集性:△
    • UI層とAPI層のデプロイタイミングを揃えるのが難しい

⇒採点は70点

マイクロサービスはアリ?

  • 新決済システムでの採用は正解
  • チームまでマイクロに分割する必要はない
    • きちんと帽子をかぶり直す必要がある(メンバーがモノリシックも担当しているので)

機械学習でサービスの常識を破壊する(料理きろくと機械学習

発表者:杉本 風斗さん/クックパッド株式会社

機械学習に関わる理由

便利なものを作りたい

今後3〜5年は 機械学習ヒューリスティクス

  • UIは透明化していく
    • 自動化によって入力UIの存在が希薄化する

例)

  • レコメンデーションで検索しなくなる
  • 自動運転

料理きろく

  • 料理の写真を自動で記録
  • 料理を楽しく振り返る
  • 累計1,000万枚の料理写真が登録されている
  • 積極的に機械学習を採用

  • 写真が料理かどうかを判定する

    • 例)犬とパンの写真
  • 閲覧したレシピを実際に調理したかを判定
    • 取った写真からその日に見たレシピの画面を紐付ける
  • 魅力度の推定
    • 1〜5点の推定
    • 料理のきれいさ
      • きれいな写真をpush通知で「つくれぽしませんか?」と通知
  • 料理写真の分類
    • 料理の分類(野菜炒めとかオムライスとか)を軸にふりかえる機能

現実世界での課題

モデルのデプロイ(リアルタイム性が必要ない場合)

AWS

Redshift⇒S3⇒ECS⇒S3⇒MySQLRails

  • Redshift
    • データ分析基盤
    • 社内のすべてのログやデータを蓄積
  • Kuroko2
    • ジョブ管理
  • ECS
    • AWSコンテナ実行
      • hako;Docker

補足

  • GPUの仮想化はサポートされていない
  • スクリプトでデータフロー制御
  • Webコンソールから実行

ml-batch

  • 共通処理を簡単化するpythonライブラリ
    • 機械学習は共通する処理が多い
    • 例)tsv⇒処理⇒tsv

メニュー分類での課題

  • インスタンス1台で20日かかる
    • データを並列で扱う
    • 40台で実行すれば0.5日
    • Kuroko2でパラレル制御

巨大アプリにおける新規開発とチームビルディング

勝間 亮さん/クックパッド株式会社

クックパットアプリのサービス上の課題

  • 投稿コミュニテイを活性化したい
  • 大半はレシピを探すユーザー

⇒仕組みを構築

目指す世界:料理の追体験の連鎖が起きる場所

新機能:タイムライン

  • 趣味嗜好が近い人の料理記録
  • 検索では気にしない料理も関心が湧きやすいはず
  • 場が活性化すれば投稿の抵抗の下がるはず

⇒フィード、投稿、リアクション、通知

体制

  • iOS⇒2人
  • Andriod⇒2人
  • バックエンド⇒2人
  • デザイナ⇒3人

⇒普段より大きめの規模

発生した問題

  • 物事が進みにくい
  • チームの雰囲気も悪い

6月のベータ版を断念⇒仕切り直しが必要

巨大アプリの課題

  • 大人数で1アプリ開発
  • 好き勝手にリリースできない
  • 1ヶ月のリリースサイクル

チーム構造の課題

  • 充分な人数のデザイナー⇒プロトタイプが高品質化
  • 検証すべき最小の仮設が考えられなくなる
  • エンジニアはとにかく実現しなきゃという発想になる

チームのリビルド

開発フェーズの再定義

いつどの状態を目指すかを完璧にあわせる

Spotifyが提唱しているモデル(4つのフェーズ)

  1. Think it
  2. Build it
  3. Ship it
  4. Tweak it

lean-trenches.com

検証したい最小の仮説

⇒表示だけで良い(フォローされている人のレシピやつくれぽを流す)

検証

  • 親しい人の料理の情報が流れることの既存ユーザーへの影響
  • 既存サービスに悪い影響が出ていないか

最小サイズをShip itすることに集中

アーキテクチャの決定を早く

  • キャパシティの見極めが早くできた
  • 開発すべきものに集中できる体制の構築
  • やるべきことを絞ってコミュニケーションも活性化

その後

  • 大ふりかえり会実施
  • 1チームから2チームに分割
  • 1ヶ月のリリースを2週間に短縮

現状

  • Teawk itフェーズ⇒やっと仮説が形に
  • 自分たちで意思決定して進められる体制になった

新規開発のポイント

  • 仮説を絞る、検証するものを絞る
  • 大きな構想を立てたときこそ小さく
  • 自分たちの立ち位置と方向性の認識合わせ
  • 最初に解決するものは何かの見極め

問題発生時

  • 状況整理
  • 止めるのも躊躇しない
  • 目線を揃えてやるべきことを集中させることがとにかく重要

まとめ

それぞれ違うテーマではあったが、自社サービスを構築し維持していくためには、その時々において最も重要な事は何かを見極めてコンパクトな仕組みを目指して技術や基盤、体制を選択し乗り越えていくという点では共通しているように感じた(発表は聞けなかったがQAセッションでイカリング2のSPAでReactを採用しているのも思想がわかりやすい点が良いという話だった)。技術にしてもプロセスにしても重要な事に絞ってコンパクトにPDCAを回していくことがサービスの成長につながりやすく、エンジニアにとっても技術力を積み上げやすいのだろうとあらためて感じた。