GraphQL + Golang でのクエリ最適化

Transcript

1. GraphQL + Golang でのクエ リ最適化 やっさん
2. 当初の予定... GraphQL が知らない人でも興味を持って もらえるようにと心を込めたスライドを SpeakerDeck の方に用意しました！ 興味があればどうぞ！
3. • バックエンド/フロントエンドの共通認識「型」を定義する ◦ 型 → 主に .graphql ファイルなどで表現 • バックエンド/フロントエンドは共通認識の元各々実装を進める ◦ バックエンド/フロントエンドで, コミュニティとか仕様追従が強いのは Apollo とか ▪ フロントエンドの typescript + react なりも楽しいです。またの機会に。 ▪ 型からの自動生成ツールがあったりもして便利。 ざっくり GraphQL Schema Driven を実現するための数ある内の一つの仕様
4. GraphQL サーバーサイド実装を Golang でやった場合のクエリ最適化について 今回は！
5. 今回のサーバーサイド環境 • 言語 ◦ golang 1.13 • （主な）ライブラリ ◦ 99designs/gqlgen ▪ GraphQL schema から golang 中間コードを生成してくれるツール ▪ Resolver という型を返す部分の実装に注視できます ◦ volatiletech/sqlboiler ▪ DB から golang 中間コードを生成してくれる ORM ▪ クエリ生成が直感的 ▪ Voicy 標準になる気運があるらしいと聞いたのでついでにキャッチアップしました ◦ vektah/dataloaden ▪ GraphQL から提供されているユティリティ Dataloader の golang 実装 ▪ この人がクエリ問題を解決してくれる
6. GraphQL のメリットとして • フロントエンドの描画都合によって好きなようにリソースを取得できる ◦ このページでは, 「放送名」「フォロワー数」の一覧が分かれば大丈夫 ◦ こっちのページでは「放送名」「放送詳細」「放送一覧」が欲しい … etc • バックエンド実装では, 特にその辺りのコンテキストを意識することなく型を返す実 装を行えばいい
7. \ 好きなように /
8. Listener と Channel を想定（Listener->Channel） 例えば 分かりやすく単一方向の依存がある型たちを用意します
9. この型を先ほど紹介した gqlgen で自動生成すると problem: struct の slice を持ってしまう
10. どういうことか？
11. これを解決するテーブルを用意したとして ...
12. ベタベタに Resolver 実装すると …… Lister の型が解決されるときに , 毎回全依存関係の解決もあることになっ てしまう。
13. 結果として ... 結果としては, 欲しいリソースが取得できるものの followed 情報の必要可否に関わらず , クエリ発行されてしまう これを解決するために（例えばヘッダーのありなしといった）コンテキスト で解決する？ → 本末転倒
14. 終わりです N+1 問題 スロークエリ サービス品質低下 深夜対応 …… なり響く電話
15. そうしないために（本題） 長かったね ...
16. GraphQL Dataloader Pattern 依存する情報を集めて最後に Fetch して解決するパターン
17. vektah/dataloaden を使った実装フロー（例） 1. db に table を用意する 2. volatiletech/sqlboiler で model を自動生成 3. 生成された model を参照する type を定義 4. vektah/dataloaden によって, 取得した型の DataLoader を自動生成 5. Fetch 実装 6. Resolver 実装 7. 99designs/gqlgen で schema を解決する中間コードを自動生成 大体自動生成で型安全に解決
18. db に table を用意する
19. volatiletech/sqlboiler で model を自動生成 • sqlboiler driver するだけでめっちゃ楽でした • 単一テーブルに対するクエリ生成とマッピングは最強そう • inner join がお察しなのは把握してしまった ...
20. 生成された model を参照する type を定義 @goModel で指定できる もしかしたら client 側も自動生成 ツールを使う場合, 競合することが あるのかも … ??
21. vektah/dataloaden によって, 取得した型の DataLoader を自動生成 • dataloaden ローダー名 キー型 取得対象モデル ◦ e.g. dataloaden ChannelSliceLoader string '*github.com/somen440/graphql-sample/models. Channel' • 取得対象モデルは, single-quotatio で囲わないと, めっ ちゃ怒られた
22. Fetch 実装 • key は, 呼び出し側の pk • 今回は, listener_id -> followed_channel -> channe.channel_id から channel を取得 ◦ なので listener_id • 返り値は, 各 pk に対応した slice グループにして返してあげる
23. Resolver 実装 • Load に対して key となるものを渡すだけ
24. 99designs/gqlgen で schema を解決する中間コードを 自動生成 schema に適するような interface の提供とかも
25. 動作確認！
26. folloed ( フォローしてるチャンネル） Channel への依存あり 依存しているため SQL が発行されてい る
27. folloed ( フォローしてるチャンネル） Channel への依存なし 依存がないためクエリが発行されていな い
28. Where in として SQL が発行されてい て, N+1 問題を解決している
29. 必要な時に必要なだけのクエリが流れた
30. Dataloader を上手く使って GraphQL でも 最適化。本番運用に耐えうる設計を！ そして永眠しましょう 完