2022-11-22 NEWT Tech Talk vol. 2 ~ Backend/TypeScript/GraphQL ~ Shumpei IINUMA ( 株式会社令和トラベル) Monitoring GraphQL API on Cloud Run 

Shumpei IINUMA 令和トラベルでバックエンドエンジニアをしています 新しい旅行を体現するアプリ「NEWT 」と、それを提供 するための旅行管理システムの開発 ~ 2015 大学院で自然言語処理を学ぶ 2016 ~ 2017 リクルートでサイト内検索ロジックの開発 2017 ~ 2021 SaaS プロダクトの開発 2022 ~ 令和トラベルにジョイン 主な仕事内容 略歴 @iinm_stderr @iinm 

No content

No content

本日の発表内容 前提 GraphQL のAPI をCloud Run 上で動作 実装にはApollo GraphQL を利用 GraphQL をいわゆるAPI アグリゲーションの層として使っているわ けではなく、単体で機能するもの NEWT の安定稼働のために、API をどのようにモニタリングして いるか？ 良かったところ・課題があり後に改善したこと 話す内容 

Cloud Run の基本的なメトリック取得・アラート 

Cloud Monitoring 例 外形監視 レイテンシー インスタンス数 CPU 使用率 Memory 使用率 ... 一般的にとるべき指標はCloud Monitoring で可視化・アラートを設定 （GraphQL は関係ないので詳細は省略） 

重要イベントの捕捉 

前提：NEWT のAPI ログの種類とレベル Application log : Error : 人による対応が必要なレベルのエラー（ハンドリング漏れなど） Warn : 対応は不要だが異常なイベント（カスタマーの入力エラーもこれ; 基本的には問題ないが、数が多い場合、例えばUI が分かりづらい など、別の問題が見つかる可能性があるので記録している） Customer Event log : ツアーの一覧閲覧から予約完了まで、カスタマーの行動分析に必要なイ ベント 

ログの種類と転送先 - 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 へ 

実装：エラーの振り分け - Apollo Server Plugin ApolloServerPlugin を利用してエ ラーを捕捉 リクエスト内容（operation やク ライアントの情報）と紐付けて ログ出力 

実装：カスタマーのアクションの捕捉 - Middleware (TypeGraphQL) リクエスト内容をログ出力するMid dleware を実装 イベントとして記録したいResolver にUseMiddleware で設定（この例は 、ツアーの詳細閲覧イベント） Middleware を使うことで、業務処 理とは関係のないログ出力のコード を分けてスッキリ書ける 

Operation レベルのパフォーマンス 

知りたいこと：機能単位のパフォーマンス 例：ツアーの検索結果や詳細を返すのにどれくらい掛かっているか？ 

Apollo Studio Query,Mutation ごとのレイテンシやフィールドレベルのトレース 他にもスキーマのChangelog 自動生成、破壊的変更の検知、非推奨フィ ールドの利用状況確認ができたり、運用上便利な機能が豊富 機能 導入までの経緯 NEWT リリース時点（2022 年4 月）では、料金プランが異なり開発者1 人 あたり数十ドルと、ちょっと高めだったため導入を見送った 10 月4 日のプラン改定でリクエスト数に応じた従量課金に変更＆無料枠 も設定された 🎉 → ちょうどOperation 単位のパフォーマンスが見られず困っていたため導入 

Operation Metrics 

Trace field レベルでどこに時間が掛か っているかがぱっと見で分かる ボトルネック特定に有効 

事例：ある画面の描画が遅い原因を調査 Android: 50p = 3.3s iOS: 50p = 2.3s Web: 50p = 1.4s 画面で利用しているQuery のパ フォーマンスを確認 表示内容は同じなのに、クライ アント間でパフォーマンスに差 があった Fragment の使い回しによる典 型的なオーバーフェッチを発見 （一覧と詳細でFragment を共 通化した結果、一覧で不要なフ ィールドを取得） 

パフォーマンスのボトルネック検出 

Cloud Trace 

Cloud Trace 導入経緯：リリース前の負荷試験で致命的なボトルネックがないことを 確認するために導入 GraphQL のField レベルでのTrace にはLogging で紹介したApollo Server Plugin ( ライフサイクル内に処理を差し込める仕組み) を利用 ⚠️Field レベルでのSpan が多すぎてCloudTrace の画面が重くなりChrome がカクカクする＆ノイズが多くなる→ 現状、NEWT のモニタリングにお いてはCloudTrace ではDB アクセスと外部通信のみを見ている DB アクセス部分はgoogleapis/cloud-​ trace-​ nodejs にplugin のサンプルを参考に必要な情報のみを出力するよう調整 

まとめ：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