JMDC TECH BLOG

JMDCのエンジニアブログです

GraphQL RubyのSentryTraceを使ってみました!

こんにちは。@dtaniwakiこと谷脇です。

github.com

私は現在は産業保健向けのサービス「 Pep Up for WORK」の開発に携わっています。
Pep Up for WORKは社員1人1人を元気にし、活気ある組織作りを実現することを目的としたサービスです。

lp.pepup.work

さて突然ですが、みなさんトレース使ってますか?
ご存知の方も多いと思いますが、トレースはObservability(可観測性)の構成要素の一つで、他にはメトリクスやログとともにサービスを運用する上で非常に重要な技術です。

Pep Up for WORKでももちろん使っていて、集約・可視化にはSentryを使っています。
Pep Up for WORKはRailsアプリケーションなので、sentry-rubyのgemを入れていればActiveRecordなどRails関係の処理は自動でspanを作成してくれるため、ボトルネック調査時に非常に重宝しています。

しかし、Backend APIはgraphql-rubyを使ってGraphQLで開発しているため、全てのリクエストが同じActionControllerのspanで計測されてしまい意味をなしていませんでした。

SentryTrace導入前

どのSQLクエリでどのくらい時間がかかっていたかわかるのは良いのですが、それぞれのSQLクエリのコンテキストがわからず修正時にエスパーする必要がありました。

なんとかならないかと調べたところ、graphql-rubyにはtracing用の拡張がありました!が、残念ながらSentryには対応していませんでした。
実装して本家にPRでも出すか・・・と思いながらなかなか時間が取れずにそのままになっていたのですが、ふと気づくとなんとv2.2.6でSentryTraceがサポートされていました!

早速使ってみたところ、感動的な出来だったので共有します。

 

まず導入は簡単で、

class MySchema < GraphQL::Schema
  trace_with GraphQL::Tracing::SentryTrace
end

スキーマに1文追加するだけです。

すると、あら不思議!

SentryTrace導入後

このようにGraphQLのクエリーやフィールド単位でspanが作られるようになりました。
これで重いSQLクエリやN+1問題の発生しているフィールドを簡単に特定できるようになり、ボトルネック調査の効率が劇的に上がりました!

JMDCでは質の高いサービスを顧客に提供し事業を成長させるため、常に開発プロセスの改善に取り組んでいます。エンジニア採用も積極的に行なっているので、一緒に取り組んでいただける方がいましたらぜひ応募お願いします。
まずは面談だけという方も歓迎です。

hrmos.co

hrmos.co