Monitoring GraphQL API on Cloud Run

NEWT Tech Talk vol.2 〜Backend/TypeScript/GraphQL〜 でのLTの資料です。
https://reiwatravel.connpass.com/event/264018/

Transcript

1. 2022-11-22 NEWT Tech Talk vol. 2 ~ Backend/TypeScript/GraphQL ~ Shumpei IINUMA ( 株式会社令和トラベル) Monitoring GraphQL API on Cloud Run
2. Shumpei IINUMA 令和トラベルでバックエンドエンジニアをしています 新しい旅行を体現するアプリ「NEWT 」と、それを提供 するための旅行管理システムの開発 ~ 2015 大学院で自然言語処理を学ぶ 2016 ~ 2017 リクルートでサイト内検索ロジックの開発 2017 ~ 2021 SaaS プロダクトの開発 2022 ~ 令和トラベルにジョイン 主な仕事内容 略歴 @iinm_stderr @iinm
5. 本日の発表内容 前提 GraphQL のAPI をCloud Run 上で動作 実装にはApollo GraphQL を利用 GraphQL をいわゆるAPI アグリゲーションの層として使っているわ けではなく、単体で機能するもの NEWT の安定稼働のために、API をどのようにモニタリングして いるか？ 良かったところ・課題があり後に改善したこと 話す内容
6. Cloud Run の基本的なメトリック取得・アラート
7. Cloud Monitoring 例 外形監視 レイテンシー インスタンス数 CPU 使用率 Memory 使用率 ... 一般的にとるべき指標はCloud Monitoring で可視化・アラートを設定 （GraphQL は関係ないので詳細は省略）
8. 重要イベントの捕捉
9. 前提：NEWT のAPI ログの種類とレベル Application log : Error : 人による対応が必要なレベルのエラー（ハンドリング漏れなど） Warn : 対応は不要だが異常なイベント（カスタマーの入力エラーもこれ; 基本的には問題ないが、数が多い場合、例えばUI が分かりづらい など、別の問題が見つかる可能性があるので記録している） Customer Event log : ツアーの一覧閲覧から予約完了まで、カスタマーの行動分析に必要なイ ベント
10. ログの種類と転送先 - Cloud Logging, Sentry, BigQuery Application log : Error : Cloud Logging & Sentry Warn : Cloud Logging Customer Event log : Cloud Logging & BigQuery 経緯 最初はApplication_log のみで、全てSentry に送っていた（アラートのセ ットアップが容易で、ログも見やすかったため） Warn ログを利用する頻度は低いため、Cloud Logging のみへ その他、行動分析に使いたいログはCloud Logging からBig Query へ
11. 実装：エラーの振り分け - Apollo Server Plugin ApolloServerPlugin を利用してエ ラーを捕捉 リクエスト内容（operation やク ライアントの情報）と紐付けて ログ出力
12. 実装：カスタマーのアクションの捕捉 - Middleware (TypeGraphQL) リクエスト内容をログ出力するMid dleware を実装 イベントとして記録したいResolver にUseMiddleware で設定（この例は 、ツアーの詳細閲覧イベント） Middleware を使うことで、業務処 理とは関係のないログ出力のコード を分けてスッキリ書ける
13. Operation レベルのパフォーマンス
14. 知りたいこと：機能単位のパフォーマンス 例：ツアーの検索結果や詳細を返すのにどれくらい掛かっているか？
15. Apollo Studio Query,Mutation ごとのレイテンシやフィールドレベルのトレース 他にもスキーマのChangelog 自動生成、破壊的変更の検知、非推奨フィ ールドの利用状況確認ができたり、運用上便利な機能が豊富 機能 導入までの経緯 NEWT リリース時点（2022 年4 月）では、料金プランが異なり開発者1 人 あたり数十ドルと、ちょっと高めだったため導入を見送った 10 月4 日のプラン改定でリクエスト数に応じた従量課金に変更＆無料枠 も設定された 🎉 → ちょうどOperation 単位のパフォーマンスが見られず困っていたため導入
16. Operation Metrics
17. Trace field レベルでどこに時間が掛か っているかがぱっと見で分かる ボトルネック特定に有効
18. 事例：ある画面の描画が遅い原因を調査 Android: 50p = 3.3s iOS: 50p = 2.3s Web: 50p = 1.4s 画面で利用しているQuery のパ フォーマンスを確認 表示内容は同じなのに、クライ アント間でパフォーマンスに差 があった Fragment の使い回しによる典 型的なオーバーフェッチを発見 （一覧と詳細でFragment を共 通化した結果、一覧で不要なフ ィールドを取得）
19. パフォーマンスのボトルネック検出
20. Cloud Trace
21. Cloud Trace 導入経緯：リリース前の負荷試験で致命的なボトルネックがないことを 確認するために導入 GraphQL のField レベルでのTrace にはLogging で紹介したApollo Server Plugin ( ライフサイクル内に処理を差し込める仕組み) を利用 ⚠️Field レベルでのSpan が多すぎてCloudTrace の画面が重くなりChrome がカクカクする＆ノイズが多くなる→ 現状、NEWT のモニタリングにお いてはCloudTrace ではDB アクセスと外部通信のみを見ている DB アクセス部分はgoogleapis/cloud-​ trace-​ nodejs にplugin のサンプルを参考に必要な情報のみを出力するよう調整
22. まとめ：NEWT の安定稼働のためのGraphQL API のモニタリング 基本的なメトリック取得・アラート：Cloud Monitoring でCloud Run の基本的なメトリックを押さえる 重要イベントの捕捉： Application Log ：Cloud Logging 、重大なエラーはSentry へ Customer Event Log ：Cloud Logging 、分析のためBigQuery へ パフォーマンスモニタリング： Operation, Field レベル：Apollo Studio 外部へのHTTP Request やDB アクセス、N+1 検出：Cloud Trace