スマートレストランでGraphQL を採用した話

スマートレストランでGraphQL を採用した話

1. 1. 株式会社ウェリコ 会社紹介
2. 2. 自由なレストランで、自由な体験を ITと金融 力で めちゃめちゃイケてる 飲食店を作る
3. 3. 全体 流れ お客様 来店 着席 注文 食事 会計 退店 ホール ②QRコードを読み取る ①来店登録、QRコー ドを発行してお客様に わたす ③iPadでオーダーを確 認し、調理する キッチン ④調理が完了したら、 通知を受取って配膳す る ⑤カードで会計をする ⑥会計が完了したら、お 見送りをする
4. 4. レストラン スマート化 可能性 ホールキッチン ✔ 空席確認 ✔ 予約確認 ✔ アレルギー、好み 把握 来店後来店時来店前 ✔ 納品受け取り ✔ 仕込み ✔ おすすめメニュー 考案 ✔ メニュー表 更新 ✔ 予約確認・座席案内 ✔ 商品説明・レコメンド ✔ 配膳・バッシング ✔ お会計 ✔ 調理タイミング 管理 ✔ レシピ 共有 ✔ スキル 可視化 ✔ 満足度 把握 ✔ 在庫棚卸 ✔ 発注 お客様 ✔ 予約 ✔ 席 指定 ✔ 料理・ドリンク 注文 ✔ 会計 ✔ 二次会 検索 ✔ レビュー投稿 ✔ PL管理 ✔ マーケティング ✔ 採用 飲食店 運営業務 多岐に渡っており、それぞれが複雑に絡み合っている SaaS ベンダーになる で なく、プレイヤーとして業務改善を図る ✔ シフト管理 ✔ 立地戦略 ✔ 顧客管理 ✔ 人材教育（キッチン、サービス） ✔ メニュー開発
5. 5. 飲食店 楽しいよ - ご んが美味しい - まかない、社割あり - メニュー 試食 3店舗でスタッフ100人 MAU3万 - 人・人・人 - ユーザーが自分 目 前でアプリを使っている - 店舗スタッフ→ 30人が10時間/日 * 365日 - ユーザー→1セッション2時間 * 来店者数 - ITによる自動化 ⇔ エモさ - リアル x IT フロンティア - レガシーな領域な で、課題だらけ - 巨大なマーケット（デリバリー、生産） - IoT/画像認識/ハードウェア、全部できます、お がいします - 圧倒的なデータ量
6. 6. スマートレストランでGraphQL を採用した話 @wawoon_jp
7. 7. Netlify 技術構成 GCP GAE go112 Cloud SQL APIサーバー GCS 画像アップロード Imgix Pusher リアルタイムイ ベント通知 注文アプリ 店舗アプリ Firebase Auth 認証/認可 画像配信 GitHub Push ビルド/配信 通信（Relay Modern） GraphQL
8. 8. Netlify 技術構成（実際） GCP GAE go112 Cloud SQL APIサーバー StackDriver 監視 GCS 画像アップロード Imgix Sentry エラー通知 Pusher イベント通知 注文アプリ 店舗アプリ Firebase Auth 認証/認可 画像配信 GitHub CircleCI Push 自動テスト ビルド/配信 Segment イベント収集 BigQuery ログ収集/分析 通信（Relay Modern） +あといくつか SaaS
9. 9. Why GraphQL - やってみないとわからない（不確実性へ 対処） - 特にフロントエンド - とにかく実地でPDCA - フロントエンド 何度でも作りなおす - GraphQLなら、どんな画面やクエリ 仕方にも対応できる - システムが落ちたらレストラン 営業がとまる - API通信にも型がほしい - GraphQLなら、型がある - サーバーとフロント 型が合わないなら、ビルドでコケる
10. 10. GraphQL採用してよかったこと - リリース前: 開発スピード そんなに落ちない - REST APIサーバー作るとき 時間 x 1.5くらいしかかからない - 遅い？でもメリット たくさん - スキーマ駆動開発しよう（ golang, gqlgen, sqlboilerいいぞ） - サーバー用意できないとき モックサーバーを立てる - GraphQL 型ファイルから自動的に作成 - リリース後: ほとんど 変更 フロントエンドで対応 - 新機能 ときだけサーバーサイドに変更 - フロントエンド 欲しいデータだけ、欲しい形式で取得
11. 11. 大変だったこと - API 設計 - REST APIとぜんぜん違う→GitHub APIを真似る - パフォーマンス対策 - GraphQL クエリが巨大→クライアント側を直す、ロギング - DBアクセス、N+1クエリ問題→SQLをバッチ化 - 並行処理でDBアクセス→コネクションプーリング事前に確保 - 実装むずい - Relayでコネクションというリスト取得 仕様がある - 振る舞い 仕様 あるけど、実装 決まってない - → 自作テンプレートでORMをラップしたモデルから自動生成（ go generate） - ロギング - とにかく分散トレーシングだ！ → StackDriver Tracingいれた。簡単。
12. 12. We are hiring - 正社員、業務委託で エンジニアを募集しています - 技術的に たぶん面白いことをやる ずです - 過去 経験技術（使用言語など） 問わないです - 小さなチームで大きな裁量をもって開発できる or チャレンジしたい人 - 年内にエンジニアを5人くらい採用したい - Webフロントエンド - サーバー - インフラ - IoT - 興味がある人 、ブースで声をかけてください - 自分（@wawoon_jp）、また 社長（@reI_araki）に@かDM
13. 13. Appendix: 難しい点詳細 - サーバー編（１） - N+1クエリ問題 - 事前にどんなクエリが来る かわからない - eager loadingとかpreloadとかできない - 発行されたも ベースで対応する必要がある - SQLへ アクセスがあるときバッチ化する - 2msなど、短い時間 sleep - そ 間に同じクエリが発行されたらそれをバッチ化 - イメージ - 0ms: goroutine1「select * from products where id = 1; 」発行したい - 1ms後: goroutine2 「select * from products where id = 2; 」発行したい - → まとめて、select * from products where id in (1, 2); で発行 - → 返り値をそれぞれ、goroutine1, goroutine2に返す - ライブラリ - https://github.com/vektah/dataloaden
14. 14. Appendix: 難しい点詳細 - サーバー編（２） - N+1を直してもDB刺さる問題 - GraphQL 1リクエストでも普通 HTTP通信 5-10個分くらい DB処理をする - リゾルバがgoroutineで並行処理されているため - DBコネクションがリゾルバ 並列数分使われる - コネクションプーリング ボトルネックをどう直すか - コネクションをApp Engine インスタンス 限界まで事前に用意（ 100コネクション） - リクエストがたくさんきたら、インスタンス数を増やす - 並行処理そもそもむずい - sync.Mutex使うべし - バグ事例 - DBアクセスしたデータを構造体 中にキャッシュ化 - 排他処理していなかった で、 goroutine 実行順によりランダムでレスポンスに失敗
15. 15. Appendix: 難しい点詳細 - サーバー編（３） - GraphQLリクエストがそもそもデカイと困る - や いクエリ 例 - 100件ある商品 - 商品ごとに100件 オーダーを取得 - オーダーごとに、支払い 一覧 - 支払いしたユーザー ...etc - 上記 場合だと、 100 x 100 x …. ような巨大クエリができあがる - →今 制限かけてない でレビューで防ぐ - Relay Specificationへ 対応 - offsetベースだと、新しいデータが入ってきたときに位置がずれる で以下から計算 - first, last: 何個ほしい か - after, before: 基準となるノード ID - go ジェネレーターでモデルから静的にコード生成して対応。
16. 16. Appendix: 難しい点 - クライアント編 - とくに辛いこと ない - Relay いいぞ - GraphQLでつらい がキャッシュ管理だが Apolloより良くできている - mutation周り, 特に削除処理 - mutation 直後など、ノードを消せ それで終わり - query周り、データ 更新 - データ 再取得をするだけで、内部 キャッシュが更新 - 変更があったentityを参照している箇所、すべてで画面表示が更新される - API ちょっとだけ難しい - ドキュメントを読もう - 特にコネクション キャッシュを変更するところが難しい