BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

はじめてのNew Relic - 社内オンボーディングを開催いただきました

NewRelic

はじめに

CTOの川口 (id:dmnlk) です。
BASEは現在140万ショップを超え、サービスの安定性・信頼性を維持することは非常に重要になっています。
その中で去年、New Relicを本格的に導入しました。
https://newrelic.com/jp/press-release/20201217

しかしNew Relicを導入しただけで安定性が獲得できるわけではありません。得られるのは可観測性のための武器であり、その使い方を適切に学ばなければ無駄になってしまいます。 今回、New Relic社のご提案もあり社内メンバー向けにオンボーディング会を開いていただけることになりました。 オンボーディングを行うことでまずNew Relic Oneのオブザーバビリティプラットフォーム で何が出来るのか、どのように使うことでBASEシステムの可観測性を得ていくことが出来るのかを開発チームが体系的に学べることを狙うこととしました。

オンボーディングに参加して

SREチームのngswです。 当日の参加者は最終的には50名近くとなりました。プロダクトに直接関わるフロントエンド、サーバサイド開発陣のほかにCSE(Corporate Solutions Engineering)チームも参加する形で、大変にぎやかな会になりました。

14:00〜17:00という長丁場の中で、個人的に特に盛り上がったなと感じたところである以下を中心に当日の雰囲気をお伝えできればと思います。

  • 「New Relicに期待することはなにか」
  • New Relic でできることについて
  • NRQL / Query builder について

「New Relicに期待することはなんですか？」

オンボーディング中の風景01
期待に胸を躍らせる面々

オンボーディング開始の直前まで、Slack上ではNew Relic社のSenior Solutions Consultant 1 の清水毅様と調整を行っておりました。 清水さんにはBASEを強くサポートいただいており、 その中でご提案いただいたのが「各開発チームの代表者を1名ずつ決めて、それぞれに『New Relicに期待すること』をそれぞれ教えていただきたい」というものでした。

当日発表内容は以下になりました。

所属チーム New Relicまたは今日のオンボーディングで期待すること
ペイメント New Relic Browserを組込中。
ユーザがどのような形で <BASE> を利用しているか、解明していきたいと考えていて、
他の機能もさわっていきたい
CSE 内部統制を効率的かつ有効に進めていけそうな機能を、このオンボーディングの中で見つけていきたい
ショップ1 (New Relicを用いることで)開発側でも監視/モニタリングを積極的に行える土壌ができることを期待している
フロントエンド1 パフォーマンス改善の足がかりとしてNew Relicを活用していきたい
安定運用を自チームを含めた全開発陣でやっていくことを
ショップ2 リリースした機能/APIが期待通りのパフォーマンスがでているか、ある時点から劣化していないかということを追跡したい
フロントエンド2 JavaScriptのエラートラッキングや、追いきれていないパフォーマンスのボトルネックの発見を行うためのツールとして期待しており、このオンボーディングで学んでいきたい
基盤 今、アプリから呼び出されるAPIのパフォーマンス改善を行っているところで、ログ追跡がより便利に、かつ簡便になることを期待している
SRE インフラ側(たとえばSRE)と開発陣での共通の話題が、たとえばNew Relicのダッシュボードを中心になっていくようなことを期待している
ネイティブアプリケーション モバイルアプリから呼んでいるAPIの負荷/ボトルネックなどの、問題の発見と追跡を行いたい
BASE BANK社開発陣 マイクロサービス化していく中で、3〜4サービスまたいでログを確認しなければいけないなど、運用に苦しんでいるところがある
SLOなどの設定を考えていく中で、そもそものメトリクスをどうとるか(そして投げ入れるか)などのヒントをこのオンボーディングで学んでいきたい
DS New Relicをチーム内でどの様に活用できていけるのか、その下地になる知識を仕入れていきたい

よかったなと感じたのは、CSEチームの「内部統制に活用したい」というものでした。 この発想を自身は持ち得なかったので、共有いただけたのは個人的な収穫のひとつでありました。 もうひとつ感じたことは「開発陣はパフォーマンスに関心がないわけではなくて、関心はあるのだけれど、追跡に必要な情報へアクセスしづらいがために、結果的に後回しになってしまっている現状がありそう」というものです。これはわれわれSREチームの至っていない点であるなと反省した次第です。

このあと清水さんより New Relic の概要説明がありときには補足も入りながら、New Relicの目指すところはなにかという内容へと進んでいきました。 紙幅の都合もありますし、より正確な内容をご自身の目と耳でご確認いただきたいと考えますので、興味を持たれた方には以下のウェビナーへの参加や過去動画の閲覧をおすすめいたします。

セミナー・ウェブセミナー | New Relic（ニューレリック）

  • Q 内部統制でどういったところにつかえるでしょうか、たとえばDB操作の監視であるとか……
    • A ログベースの検知であったり、そのキーワード監視ができます。加えていうとリリースプロセスが内部統制の制約をうけるので、モニタリングをQAと連携させることもひとつの重要な観点になります
  • Q バックエンドで稼働するバッチ処理の成功可否など、きちんと検知する仕組みはできるでしょうか
    • A Webフレームワークの機能を利用しているものであれば、組み込むことは難しくないです 補足をするとバッチ処理などは実行と終了だけでなく、処理内容とその出力成果物の整合性など、バッチ処理の価値そのものを追っていくことも大事なことなので、いくつかの観点で複合的に考える必要がでてくるかもしれません

New Relic 入門(機能紹介)

オンボーディング中の風景02
「ビジュアル化の重要性を体現的に理解している」と話題になるメンバーのプライベート機

ここからは開発メンバーから代表した数人が、一人ずつZoom画面共有機能を用いてNew Relicに触れていく形になります。「モブプログラミング」でいうドライバー役のようなものを想像いただければ間違い無いかと思います。代表者を含む参加したほとんどのメンバーはNew Relicを今日触るのが初めてと言っていい状態ですから、清水さんがナビゲータ役として位置する形になります。

  • 統合ダッシュボードとしてのNew Relic One

    • Add More Data
      • New Relicにデータを投入するための言語/ツールごとのセットアップ手順がチュートリアルのような形でわかる親切設計です
    • アカウント
      • BASEではサブアカウントを環境ごと(Prd/STG/Dev/……)に対応する形にしました
    • Services
      • BASEではAppNameをリポジトリ名から引用して対応させるようにしました
        • リポジトリAを実行しているEC2は複数台構成で稼働していますが、リポジトリ=AppNameとしているためNew Relicのデータ上ではまとめて表示されるようになっています
    • APM導入後に活用できる各機能
      • Summary
        • サンプルにしたAppNameでは、MySQLのレスポンス時間が高くなっているグラフが目に付きました
      • Databases
        • SummaryでみつけたMySQLのレスポンス時間が高くなっていた部分を調査していきます
          • QueryTimeが長い部分をグラフで視覚的に確認することができます
          • Slowest query time で sort することにより Slow queries を参照することができます
            • MySQL の Queryそのものと、PHPのStack Traceを同時に確認することができます
        • 「EXPLAINだ」「slowlog ã‚’ grep して explain して…みたいなことをここでシュッとできる」というようなコメントがSlack上で見受けられました
      • Workloads
        • アカウント(BASEではサブアカウント)ごとのリソース群の健全性状態を一覧できます
        • 自動的に組み込まれていくので手間いらずで便利そうです

NRQL / Query builder がやってきた

オンボーディング中の風景03
『ある期間内にどのショップがイベントを行ってリクエストが増大したかがひと目でわかる』ことに感心する一同

個人的にもっともエキサイティングな時間がやってきました。 APMで投入されたデータはNew Relic上でNRDBとして格納され、NRQL(New Relic Query Language)を利用してさまざまな解析が可能となります。

今回のオンボーディングでは以下のNRQLを用いた可視化が披露されました。

  • FROM Transaction SELECT avaerage(duration)
    • ここでのduration は属性[応答時間]です
    • このNRQLで本番環境すべてのトランザクション平均時間が得られました
  • FROM Transaction SELECT avaerage(duration) TIMESERIES
    • TIMESERIESのおかげで指定期間単位ごとの集計結果を時系列化したグラフが表示されました
  • FROM Transaction SELECT percentile(duration, 99) TIMESERIES
    • percentile(duration, 99)は duration の99パーセンタイルを意味しています
    • TIMESERIESにより同様に時系列化したグラフを返してくれました
  • FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET name
    • name は属性です
      • ここでは実行されたPHPのファイル名でした
    • FACETはグループ化を行ってくれます
      • 個人的には FACET がとても好きです
  • FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago
  • FROM Transaction SELECT average(duration) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago
    • こちらは先のものを平均時間で置き換えたものです
  • FROM Transaction SELECT average(duration) * count(*) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago
    • 先の平均時間では、各ショップのリクエスト数の多少は考慮されていませんでしたので、average(duration) * count(*) として考慮する形に変わりました
    • この形にかえることで、より戦略的かつ効果的な、費用対効果の向上に直結するパフォーマンス改善のために必要な、実践的なデータが得られるようになりました

ここではNRQLのパワフルさを見せつけられました。 興味を持たれた方は以下をご覧ください。

結びに

New Relicの基本的な機能について学べたオンボーディングでした。 まだ導入当初であって即効的なものを期待したわけではなかったのですが、この記事を書いている2021年03末ごろまでで以下のような成果がありました。

  • 特定ショップのページ表示が遅くなった原因の特定
  • お問い合わせの原因となった不具合がどのリリースと関連するものかの特定

今後は、SRE的観点からダッシュボードを充実させていき、様々な意思決定にNew Relicを利用していきたいと考えています。

サービスの信頼性を獲得することはSREチームだけのミッションではなくバックエンド・フロントエンドエンジニア問わず期待しています。 New Relicを始めとしたツールの支援を受けながら、積極的に改善していくエンジニアを募集しています。

open.talentio.com

open.talentio.com

SREチームは先日求人を見直しました。 devblog.thebase.in

  1. 清水さんのことを心のなかでは 「New Relic アニキ」と呼んでいます↩