emahiro/b.log

Drastically Repeat Yourself !!!!

トップ > techcon > Cookpad TechConf2018に行ってきた！

Cookpad TechConf2018に行ってきた！

techcon

こちらに参加してきました

techconf.cookpad.com

基調講演

遅れて参加したので聞いてません。

クックパッドの “体系的” サービス開発

BMLループ

buildの失敗

  • 手戻り？

mesureの失敗

  • ログの取り忘れ

learnの失敗

  • 数字は動いた
  • しかしイマイチ効果がわからない
  • 数字は得られたが学びがない
  • 属人的

Buildの前に行っておくこと

  • BMLループを前から順に行わない
    • 手戻り防止
    • 逐次にやろうとすると結構大きな手戻りが起こる
    • 最初にサイクル全体を設計する
  • 効率的な学び
    • 施策結果に対する予想
      • 現実の理解
      • サービスに対する理解
      • 想定との良し悪し->なんで？？
    • どういう結果が出そうなのか？
      • mesureやlearnのフェーズで考える内容を考えておく

Mesureの前にしておくこと

  • 計測結果の選定
  • KPI設定
    • 指標やKPIはそれ単体で存在することは珍しい
    • 通常は別の指標とバッティングする
    • 事前にバッティングする箇所を予想しておく
  • ログの確認、SQLの実行

Learn前にしておくこと

  • 指標解釈の整理
  • 結果の想定
  • 👉成功のイメージを共有する
    • その施策が成功した時に、ユーザーはどういう体験をしているのか？

社内ツール

  • Build
    • 価値仮説シート
    • Chanko
    • EasyAB
  • Mesure
    • 社内ツールがある
  • Learn
    • Report.md
      • 施策の分析レポートをMarkdownで作成し、PRベースで管理していく
      • Report.mdを先に作ってサイクルを決める

まとめ

  • 仮説の実行から学びを得るサイクルを先に設計する
  • 前から逐次体に行わない

クックパッドクリエイティブワークフロー

Cookpadは1サービスを作るのに140人のエンジニアがいる

  • ユーザーのシーンごとにGroup分けしている。

料理きろくのアプリ版チーム

  • Missionオーナー
  • デザイナー
  • エンジニア ✕ 2
  • エンジニアとデザイナーがお互いを補完する

目的と仮説を明確に

  • 常になんのためにしているのか意識する

Github issueでのアイデア発散

デザインレビュー

  • 目的・背景・コンテキストを明確化
  • 職種関係なく、横串でデザインを評価する
  • 品質向上

数値は全員が見れる場所に

テスト

  • 考慮漏れ・見つめ直す
    • TsuyoiUI・・・社内のチェックツール
      • issue作ったら、issueテンプレートに自動的に反映する

リリース・分析

  • あの時誰かがしてたな？？？(゜゜)問題
    • チーム内外の共有をすぐしたい
  • Report.mdの誕生
    • 見たい時にすぐ見れるレポートの管理

デザイナの役割

  • デザインリリースマネージャ
    • リリース単位で体験やUIの変更箇所を把握、デザイン周りを一貫してみる役割

What/How to design test automation for mobile

テスト自動化について

  • 開発サイクルの効率化？
  • 自動化がモチベーション？

テストで話が噛み合わないところのコミュニケーションの方法

SPLIT がキーワード

-よくわからないものを分割していく

Scope

  • どこをテストの対象範囲とするか？
    • モバイルアプリを使っているユーザー
    • どこまで踏み込んでいってテストをするのか？

Phase

  • 開発中？orリリース後？
    • in Production
      • 世に出したあとのテスト
        • A/Bテスト
        • カオスエンジニアリング

Level

  • なにをテストするのか？
  • どこを自動化するのか？

sIze

  • テストの種別

    • UnitTest
    • IntegrationTest
    • ...

  • テストサイズを分割する

  • どういう形に落とし込んでいくのか？

Type

  • テストを目的別に区分

範囲、時間的なもの、どこまでするのか、どこまで自動化するのか？にどんどん分割していく。

Cookpad Android for Globalでの事例

  • 事前のコミュニケーションが大事
    • 理想的なプロダクトのラインを決める
  • Scope事例
    • ユーザーが実際に使う状態に近しい環境
    • ネットワークが関係する環境のテスト
  • Phase
    • in developent
      • 開発中だった
      • sizeを再定義 3つから4つ
        • UnitTest
        • IntegrationTest
        • UI Components based
        • User Senario based

iOSはパフォーマンスをテスト自動化しようとしている

  • 以前似たような状況にあって、パフォーマンスが劣化した例があった。

Rubyの会社でRustを書くということ

CookpadはRubyの会社

  • 多くのサービスがRuby on Rails
  • 但し全てのサービスがrubyで書かれているわけではない
    • Middlewareなどはjava、Goで書かれてたりする
  • CookpadはRubyの会社だけではあるが、Rubyだけの会社ではない。

Push通知を配信基盤をなんとかする

  • 都度配信

    • イベントごと

  • 一斉配信

    • 特定層に一斉配信

Rustで書き直す前のPush通知配信基盤とは？

  • 殆どの部分をアプリケーションが担っていた。
  • 基盤というにはあまりに機能が少なすぎた

もともとは世界最大のRailsアプリケーション

  • Pushするアプリケーションは１つ以上にある
    • しかし今はマイクロサービス化が進んでいる。
    • １つのときは基盤が貧弱でもなんとかなった
    • 同じロジックが色んなアプリケーションにコピペされている。
      • DBを共有することは避けたい
      • DBに接続することも避けたい

新規版では全てのステップを配信基盤で担う

  • UserId指定
    • 配信先を受信設定に基づいてfilterする
    • Push通知の配信見積もり

厳しい性能要件があるアプリケーションをrubyで書くのはしんどい

  • Rustには色んなメリットがある。
    • 型、安全性、並行性
    • トレイト
    • データ競合のあるロジックはコンパイラが起こってくれる

Rust is not magic

  • Rustで書いたからと行って勝手に高速になるわけではに。
  • 早いソフトウェアを書くのはプログラマの市議と

Facebookのデータローダの考え方を使う

  • クエリをまとめる

OSSを開発

github.com

github.com

※ ここからはさきは説明形式なのとrustなので詳しくわからず

  • ブロッキングな処理をFutureに変換しているとみなせる
    • JSのプロミス的な概念

Rustのいいところ

  • マルチスレッドが安全

    • マルチスレッドとイベントループを混ぜ込むみたいな複雑なアーキテクチャも採用できる。

  • とりあえずロックとかなくなる

  • 安心して高速化
  • 型安全、強力

cookpad storeTV 〜クックパッド初のハードウェア開発〜

StoreTVは三者にメリットがあるサービス

  • スーパー
  • ユーザー
  • 食料品メーカー

ハードウェアでも改善サイクルを回していく - ユーザーにあててサイクルを回す

サイクル

  • 第1サイクル
    • 最小価値影響
      • 売り場で料理動画を探す
        • 料理動画を探す・見れる
        • 300台配布
      • キッティング
        • 1台10分
        • 週ごとに料理動画を作った
    • 価値検証
      • 電話調査
        • 動画見てて楽しい！
        • 自分の作りたい動画探せる！
      • アプリの利用ログ
      • 売上 -> Posデータの提供を受けた
        • StoreTVの採用した売り場は他の売り場の1.3倍の効果アリ
    • その他の問題
      • 動画の数
        • 注力商品のみで良いと思っていた
          • 売り場にあってない
      • 見た目の問題
        • 目立たない
      • キッティング
        • 手作業が手間
      • 端末管理
        • アプリの更新が手作業
  • 第２サイクル
    • スケール
      • なにをやって、なにをやらないか
      • 得意なことは自分たちでやる、不得意なことは誰かに任せる
    • 動画の数
      • 毎月100本
    • 見た目
      • 不得意
      • ケースを作成する
        • 業者に依頼
          • 中国製
          • 中国に行ってきた
            • ロゴがバグってるｗ
      • 不得なことは１人でやらない、でも任せっきりはだめｗ
    • キッティング
      • 不得意
        • 業者に依頼
          • どうしても人力に頼らざる得ない
            • アプリケーションを整えた
    • 端末管理
      • 不得意
        • 自動アップデート
          • MDMによる一元管理(Mobile Device Managiment)
    • 問題点
      • サイネージサイズ
        • 大きすぎる
          • 売り場に置けない
      • 開発新興
        • バグが増え始める
  • 第３サイクル
    • 収益化
      • 広告配信の基盤開発
      • 広告接触者数のカウント
    • サイネージサイズ
    • 開発進行
      • 長時間安定して動画
      • バグの検出
        • 時限製のバグが発覚した
          • コードフリーズ後の長時間再生
      • 顔認識の機能
        • 端末計算リソースを食う
        • エグザイルを利用したｗｗ
          • なお、エグザイルに１台やられたｗｗ

Challenges for Global Service from a Perspective of SRE

クックパッドのグローバル・サービスってなに？

  • 海外向けのレシピサービスを提供している
    • 22言語68カ国で提供
    • イギリスで提供している

2017年のグローバルサービスの成長

  • 対応言語数
    • 15->22言語
      • 7言語の増加について
        • 全言語対応 ≠ 世界対応
        • 去年のスライド見てね

techconf.cookpad.com

現状の課題や挑戦

  • 特定の国のユーザー体験が悪い

    • 国ごとに差が出始める。
      • 原因がわからないと改善できない。

  • 世界中のユーザー体験を測定する

    • CatchPointを利用した。
      • CatchPoint Systemsのメトリクスを利用した
    • 原因を調査できるようになった。
    • インドネシアと米国で比較
      • TLS接続
      • Time to First Byteが遅い
      • -> 米国からの距離が遠い。
        • Cookpadのグローバル版は米国リージョンにある。
    • データセンターをユーザーに近い場所に移動
      • マルチリージョン化
        • しかし管理コストがかかってくる
    • CDNの導入
      • Fastlyを導入
      • 米国から遠い国のユーザー体験が改善
  • イベントのバリエーションが多い
    • ex.
      • アルゼンチンは独立記念日にパステリートというお菓子を食べる
      • 日本だとバレンタインの時にユーザーが増える
    • 展開国が増えるとイベントバリエーションが増大する
      • SREは「毎月バレンタイン」
    • 課題改善
      • Amazon Auroraを導入
        • オートスケーリング
      • Dockerアプリ開発環境の提供
        • ECS + hakoでのデプロシステムの導入
        • hako-consoleを使って状態を管理
          • 日本で培った技術をグローバルに応用
  • デプロイのオペレーションコストが高い
    • ネットワークが安定しない、日常的に停電が起きる国とかある。
      • デプロイを他の人に依頼する問題
        • 世界中どこからでもデプロイ出来るようにする
        • 米国にデプロイサーバーを用意
          • デプロイサーバーでのマニュアルオペレーションの課題もある
    • 改善策
      • slackによるbotデプロイ
  • toilが急増する
    • toilとは？
      • 骨の折れる業務
      • アカウント管理業務とか
    • SREの対応する依頼業務が増大
      • toilの割合が増大
      • SREが本来したい業務ができなくなった
    • 世界中に社員がいるからこその課題。
    • アカウント管理
      • nginx + omniauth
      • アカウント管理のセルフ管理化(移譲)
    • SREのマルチリージョン対応
      • 時差の壁を超えたりとか

動き出したクックパッドのCtoCビジネス

  • komercoの発表
    • もので毎日の料理を楽しくするプラットフォーム
      • 料理を盛る器や鍋がいいと、もっと料理が楽しくなる

komercoにはサーバーサイドエンジニアがいない

  • サーバレス
  • Firebaseで開発している

(このあたりやたらFirebaseの宣伝というか、いいこと話してること多かった)

※ Firebase Japan User Group入っておこう。

firebase.asia

OpenSourceにすること

  • 少人数で品質を担保するため
    • Opensourceすると品質が向上する
    • 外部の人がチームのリソースになる
    • 再利用できる
      • 他チームで利用できる

技術一覧はこちら

Pring

  • firebase Model framework

github.com

Orderable

  • Order processing framework

github.com

開発の高速化の先になにがあるのか？

  • 大胆な戦略変更
    • 複数回の仕様変更
    • エンジニアが消耗しない
    • コミュニケーションコストがかからない
    • たくさん試すことができる
  • 事実は我々の中にない、市場に聞くべき
  • たくさん試すべき

Solve "unsolved" image recognition problems in service applications

画像分析のお話

昨今の画像分類問題

  • 理想的な状況下では「解けた」と言われている
    • 適切なラベルの付与
    • 適切なカテゴリの設計
    • closed set
      • 現実世界はopen setである
      • ラーメンの画像分析にケーキの画像がくることなんて容易にある。
  • 私たちが本当にときたい問題はなんなのか？
  • 解くべき問題の多くは「間違っている」
    • 本当に時対問題をtry and errorで探していく

料理きろくの進化と現在

  • 機械学習の観点から見る重要な点
    • クイックスタート
      • 要素技術が成長している
    • モデルの改善と苦手なカテゴリの考慮
      • 間違いやすいやつら
      • 植物はサラダと分類される
      • テストデータの拡充
      • 局所性を取り込むためのpatch化
        • 画像の一部だけに料理が移っていた時
        • ふと、お店で出てきた画像とかどうするんだろう？
          • 自分で作った料理ではなさそう？？？
          • それは分類されてもいいのかな？？？
    • 料理きろくのその先へ
      • 勝利写真のレシピカテゴリに分類
      • 単純な分類に見えて実は非常に難しい
        • openset における予測
    • 類似カテゴリをどう予測するか
    • 類似画像に対する分類

類似モデルは生まれるのか？

  • カテゴリを設定した時にどういう画像が生まれやすいのか？

モバイルへの移植

  • どうサービスに載せるか
  • 次に来そうな領域

Beyond the Boundaries

※ 基調講演

  • 技術を正しく理解し、「ふつうに使う」
  • 技術スタック
    • web
    • mobile
      • Swift
      • Kotlin
      • プロトタイピング
        • React Native
        • Firebase
    • Infra
      • AWS
      • docker
      • Hako
  • 自分たちの道具は自分たちで持続可能にする
    • コミュニティへの還元
  • 「境界」を認識し、乗り越える強い組織へ

まとめ

2年ぶりにCookpad Tech Confに参加してきました。
領域としてはプロダクト作りからグローバルでのサービス展開、機械学習まで幅広い話が聞くことができました。
個人的には、SREの話やPush基盤作りの話が面白いなーと感じましたが、HTTPやCookpadのプラットフォーム作りの話をもう少し聞いてみたかったと思いました。