システムの重要性や期待値が高まる今、ビジネス≒システムとなりつつあります。システムのトラブルがビジネスに大きな影響を及ぼすこともあるため、問題の発生にいち早く気づき、誰もが原因を特定できる必要が出てきました。このとき重要なのが、必要なデータを取得して関連付けることでシステムの状態を把握可能とする「オブザーバビリティ（可観測性）」です。
2024年4月24日、Qiita株式会社はデジタルビジネスのあらゆる重要指標を観測可能にするオブザーバビリティプラットフォーム「New Relic」を提供するNew Relic株式会社と、オブザーバビリティをテーマにしたオンライントークイベントを共同開催しました。記事投稿イベント「Qiita Advent Calendar 2023」の受賞者3名と、New Relic株式会社の大森 俊秀氏をお招きし、オブザーバビリティの基礎知識からNew Relicのユースケースまでご紹介しています。本レポートでは、当日の様子をダイジェストでお届けします。
オブザーバビリティを実践するメリット
目次
登壇者情報
オブザーバビリティがビジネスの成否を分ける時代
システムの重要性や期待値が高まる今、ビジネス≒システムとなっているケースがあるのではないでしょうか？システムが使えなくなるとビジネスに大きな影響を及ぼし、システムへの期待値が高ければ高いほど、それだけ責任が生まれると言えるのではないかと思います。こうした中で、スキルや在籍年数にかかわらずすべてのエンジニアがシステムを支えていくことが重要ですし、みんなで神輿のようにシステムを担いでいく意識がビジネスの成功につながっていくと考えています。
とはいえ、ユーザーや社内外の方から「このシステム、遅いよ」「正常処理できていないときがあるよ」のように言われるまで気づくことができず、さらにはトラブルの原因がすぐには分からないこともあるでしょう。そうなると、当然問題解決も遅れます。このようなケースでは、最終的にはシニアのエンジニアが独自の方法で情報を集めて原因を特定することになりがちですが、問題に気づいてから解決までに時間がかかってしまうため、システムの評判が落ちることにもなりかねません。
こうしたシステムの問題を解決する際には、大きく分けると3ステップあると思います。まず問題の発生にいち早く気づくことです。そして問題の原因を特定し、その原因を取り除くこと。ただ先ほどユーザーから指摘されて気づく例を挙げたように、自分たちで気づけない場合があります。また問題に気づいても原因をすぐに特定できなかったり、解決までに時間がかかったりします。オブザーバビリティをシステムが備えていると、問題に早く気づけますし、問題を誰でも特定できるようになります。
オブザーバビリティ実践の4ステップ
オブザーバビリティの効果を、具体的なケースで考えてみましょう。システムにオブザーバビリティが備わっていない状態では、ユーザーが障害を体験したタイミングでクレームが発生します。この時点で予兆の発生から数日間が経ってしまっていることもしばしばです。
クレームを受けてはじめてトラブルに気づき、そこから原因を特定して復旧作業を進めていきます。原因の特定には大量のログ調査をしなければなりませんが、ログがない場合は関係者を集めてヒアリングを行い、再現作業をしていく必要が出てきます。膨大な時間がかかりますし、みなさん忙しい中、関係者を集めて認識合わせをする必要もあります。
システムがオブザーバビリティを備えていれば、予兆が発生したタイミングで、自分たちでトラブルに気づくことができます。さらに情報がすでに集まっている状態から原因特定をスタートできるため、時間が大幅に短縮できます。オブザーバビリティを実践することで、原因特定にかかる時間を平均83%削減できたというデータもあります。
トラブルシューティングを特定の担当者に依存しないため、シニアのエンジニアがいなくても、問題を特定する事ができます。また、エンジニアが本来やりたい業務に集中できるという効果も得られます。
オブザーバビリティを実践するためにまず必要なのは、データの収集です。ホストのCPUやメモリなどを含めたシステムやインフラに関する情報や、アプリケーションのレスポンスなどブラウザ上・モバイル上におけるユーザー体験に関する情報、ビジネスに関する情報などを収集して、それらを相互に関連づいた状態で保管します。そのデータを可視化して、さらに原因の詳細を深堀りしていくことで原因を特定することができます。これを実践できるとシステムの問題にすぐに気がつくこともできますし、素早く原因にたどり着くことができます。
ただ、オブザーバビリティを急に一番高いレベルで実践するのは現実的ではありません。そのためNew Relicでは、次のような4段階を設定しています。
これはシステムの課題に限らないことですが、測定できない問題は改善できません。まずは焦らずにデータを収集し、問題発生の予兆にいち早く気づくためのベースを作りましょう。その上でオブザーバビリティのツールなどを使って原因特定を早めたり、誰でも原因特定をできるようにしたりするのが良いと思います。
New Relicでオブザーバビリティの実践が簡単に
オブザーバビリティツールの導入には、どのようなメリットがあるのでしょうか。ユーザーがブラウザやモバイルからアクセスしてWebアプリケーションを通してAPIやデータベースを呼び出し、サービスを使うといったシステムを思い浮かべてみてください。このときNew Relicを使えば、クラウド・オンプレミスを問わずインフラの状況を計測し、システム全体の処理連携プロセスを可視化できます。
トラブル発生時にもソースコードやデータベースクエリのレベルまで、即座にボトルネックを特定できます。また収集したデータがしっかり関連付けられているため、トランザクションをつなげて複数のアプリケーションを追跡できます。もちろんブラウザやモバイルのユーザー体験の計測や、外形監視のような形でサービスの動作を常時シミュレートすることも可能です。
New Relicは「オールインワン オブザーバビリティプラットフォーム」と銘打っています。その中でデータを収集し、関連付けた形で集約したものを、ユーザー体験、アプリケーション、クラウド、インフラといった全スタックを一気通貫で可視化します。そのデータからインサイトを得て、改善アクションを実行できるプラットフォームになっています。New Relicの機能はたくさんあります。まずは、先ほどのオブザーバビリティの成熟度に合わせて、自分のシステムに関連するスタックの情報を収集できるようにします。その後、自分たちで問題を発見できるようにして、問題が発生したら、このツールを使って深堀りしていただくのが良いと思います。
New Relicは、開発ライフサイクルの様々な場面で活用できます。エラーやバグの発見、問題の特定はもちろんのこと、リリースのタイミングでサービスの品質を計測しておけば、心理的安全性の担保にも役立ちます。さらにユーザーの利用状況やシステムの稼働情報を見ながら「次はどのような開発計画を立てようか」というプランニングにも活用いただけます。
New Relicでかなうオブザーバビリティの実践
「オールインワン オブザーバビリティプラットフォーム」としての特徴と多彩な機能を活かして、New Relicは多くの企業で活用されています。今回は、Qiita Advent Calendar 2023のNew Relicカレンダーにて特別な賞を受賞された3名のQiitaユーザーの方々に、導入のきっかけや活用シーン、導入の効果などをご紹介いただきました。
はじめてのパフォーマンス改善 with New Relicで年間2,520時間を生み出した話／株式会社エアークローゼット
登壇者情報
株式会社エアークローゼット / プロダクトグループ テクニカルエンジニアリングチーム SRE
今回のLTでは、New Relicを初めて使ってみた感想と、エアークローゼットにおける活用事例と成果についてご紹介します。
エアークローゼットは国内最大級のファッションレンタルのプラットフォームです。洋服のサイズや好みを登録すると、スタイリストが選んだ洋服のコーディネートが自宅に届きます。ファッションを楽しんだあとはクリーニング不要でご返却いただけるというサービスです。
エアークローゼットには、オンライン上でスタイリストが洋服を選んでくれるサービスを実現する「スタイリング提供システム」があります。このスタイリング提供システムにはローディングに時間がかかるという課題があり、スタイリストから「もっとサクサク動くようにしてほしい」という要望も寄せられていましたが、優先度の関係でなかなか着手できていませんでした。そしてNew Relicを導入してすぐパフォーマンス改善プロジェクトを開始しました（Qiita記事「はじめてのパフォーマンス改善 with New Relicで年間2520時間を生み出した話」参照）。
まず着手したのは、原因の特定です。ローディングが長いと言われるけれど、具体的にどの部分の応答が遅いのかを探っていきました。調べていくと、データベースに問題がありそうだということが分かりました。中でもSQLログの転送設定がされていなかったため、設定のチューニングから進めていきました。公式ドキュメント通りに実装していけばSQLのログが取れるようになりましたので、それほど手間取ることもありませんでした。
またDurationが長いログをEXPLAINしてみたところ、インデックスが貼られていなかっただけと分かりました。原因は単純でしたが、インデックスを貼ることで一気にパフォーマンスが改善しました。
改善の結果、スタイリストが1回洋服をお選びする流れを1選定としたとき、お客さま1人あたり18.15秒の所要時間削減に成功しました。エアークローゼットでは年間で約50万回以上選定が行われているので、実質2,520時間以上の削減ができたということになります。スタイリスト管理者からも「サクサク動くようになった」「全社で共有しましょう！」といった喜びの声が上がり、New Relic導入後初のパフォーマンス改善は最高の結果に終わりました。
New Relicを上手く活用できたのは、組織としてやりたいことや仮説が明確だったからだと思っています。当社ではインフラのリソース状況やRDBのログ、アプリケーションなどがそれぞれ別のツールで管理されており、それらが調査効率低下の一因になっていました。New Relicを導入すればそれらを一元管理でき、調査効率が良くなるのではないかという仮説があったのです。こうした仮説の明確さが、改善プロジェクトを成功に導いてくれたと思っています。また狙い通り一元管理に成功し、効率的な調査環境を構築することができました。
エアークローゼットはサービスサイト、アプリともにまだまだパフォーマンス改善の余地があります。また、新しいプロダクトや機能も続々とリリース予定です。New Relicを活用して引き続き改善に取り組み、より良いサービスを提供していきたいと思っています。
レガシーシステム にNew Relicを入れて改善を頑張った話／ディップ株式会社
登壇者情報
ディップ株式会社 / 商品開発本部 システム統括部 バイトルエンジニアリング部 テックリード
私は求人サービス「バイトル」の開発者やスクラムマスターを経て、現在は同システムのテックリードを務めています。最近Full Stack Observability認定試験に受かりました。これ結構New Relicさんの難しい試験ですので、受かってとても嬉しいです。
まずはバイトルがNew Relicを導入するまでについてお話しします。ガンガン作れる200人体制として、開発の内製化を進めたいというのがありました。バイトルでは開発の内製化を進める中で、多角的なシステムを「見える化」したい、そして監視からオブザーバビリティへ進化させていきたいというところから、New Relicの導入が始まっています。数年前から各プロダクトで導入がはじまり、私が担当している求職者向けサイトでも導入して2年弱が経っています。
バイトルにNew Relicを導入してから2年半、そこには長い長いレガシーシステムとの戦いの歴史がありました（参照記事「レガシーシステムにNew Relicを入れて改善を頑張った話」）。ただこれはNew Relicさんが悪いというわけではなく全部自分たちのせいであって、基本的には導入するだけで十分に効果を得られるサービスです。なので本日の話は、基本笑い話として受け取っていただければ幸いです。
New Relicではデプロイメント機能でリリース前後のパフォーマンスを比較したり、サービスレベル機能でSLIやSLOを設定したりできるようになりました。一方で、バイトルへの導入にあたっては課題もいくつかありました。バイトルのシステムは20周年を迎えるかなりレガシーめなシステムだったので、エラーを捕捉できない、ログが見づらい、必要性の低いアラートが次々と上がるなど、いくつかの課題がありました。ただ視点を変えて考えてみると、こうした課題はいずれ改善しなければならないものです。それなら今取り組むべきだと思い、New Relic導入をきっかけに改善していくことを決めました。
本日は、それらの中でも苦労した、ログの構造化をピックアップしてお話しします。New Relicにはmonologというライブラリのシステムがあって、それを使えば自動的にAPMがログファイルを転送してくれます。しかし、当時のバイトルのシステムでは、PHPのバージョンが古かったり、ライブラリの管理体制が行き届いていなかったりして、New Relicの転送システムを使うのは難しい状況にありました。そのため、ログの検索に膨大な時間がかかっていました。
こうした場合、各所に協力を求めてひとつひとつ攻略していくことが、遠いように見えて1番の近道かなと思いました。まずは「ライブラリ管理をデファクトスタンダードなものに変えよう」という話を開発チームに持っていったり、ログライブラリのツールは自分から変えていこうと積極的に押し進めたりといったところからはじめました。 PHPのバージョンについては、他のメンバーとも協力してバージョンアップを実施しました。その結果、ビギナーのエンジニアにもログの調査を任せられるくらい、ログ検索の利便性が向上しました。
ログの構造化に取り組む中で、社内にシステム改善への意識が根付いてきていることに気づきました。New Relicでは担当外のシステムに関するデータも閲覧できるため、システム全体のパフォーマンス改善に関心が向くようになったのだと思います。
ログの構造化がひと段落した頃、「New Relicをさらにどう活用していくか」という話題に切り替わっていきました。中でもNew Relicを使ってエンジニアのパフォーマンスを可視化できるようになったのは、大きな変化です。
またそれまで別のツールで管理していたビジネスサイドのダッシュボードもNew Relicに移行しました。これによって、同じプラットフォームの中にエンジニア向けとビジネスサイド向けのダッシュボードが共存する状況を作り出すことができました。エンジニアとビジネスサイドのメンバーがお互いのダッシュボードを覗くなどして、仕事に関心を寄せるきっかけになったと思っています。
現在取り組んでいるのは、New Relicを活用したリリースによるKPIの計測です。リリースのデータとKPIのデータを組み合わせてダッシュボードに表示することで、KPIへの貢献度を可視化できるのではないかと考えています。これができるとエンジニアのビジネスへの貢献度が可視化され、かなり大きな成果になるのではないかと、今頑張っています。レガシーシステムのマイナスを0にまで持ち上げ、さらにプラスに変えていけるポテンシャルをNew Relicに感じています。これからもさらに活用していきたいです。
New Relicを使ったPING監視の実情／株式会社サーバーワークス
登壇者情報
株式会社サーバーワークス / マネージドサービス部
サーバーワークスはAWS専業のクラウドインテグレーターです。AWS請求代行サービスを基本として、導入支援保守自動化といったサービスを提供しています。私は保守運用のカテゴリーを担当し、AWSの技術やAWS運用代行監視サービス、AWSの運用最適化サービスなどを提供しています。その中でお客さまから「ネットワーク機器のPing監視をしたい」というご要望があり、New Relicを活用して調査・検証を行いました（参照記事「New Relicを使ったPING監視の実情」）。
New Relicを使ったPing監視には、大きく3つあります。1つめがSyntheticsを使ったPing監視、2つめがFlexを使ったPing監視、3つめがktranslateを使ったPing監視です。順にご説明していきます。
Syntheticsを使ったPing監視では、New Relic株式会社が管理するSynthetics監視システム（パブリックミニオン）から監視を行います。Syntheticsの機能に含まれるScripted APIという機能を使って監視を行うという仕様になっていますが、監視対象が多かったりポーリング時間が短い場合は、コストが高くなる可能性もあるので少し注意が必要かなと思います。
監視対象について、インターネット環境の場合は標準で準備されているパブリックミニオンからおこなえますが、プライベート環境の場合はパブリックサブネットにプライベートミニオンを立ち上げ、そこからURL監視の機能の一部としてICMP監視を行う流れになります。
Flexを使ったPing監視は、基本的には公式ドキュメントにないトリッキーな方法です。infrastructureエージェントの機能の中に含まれる、Flexという機能を使ってホスト内からコマンドを実行し、その実行結果をNew Relicのサーバーに送信するといった手法になります。コマンドの結果にもよりますが、Ping監視以外の詳細な情報を確認できないという点に注意が必要です。
続いて、Ktranslateを使ったPing監視は、New Relic推奨の監視設定です。動作環境としては仮想環境の観点で少しスペックが高いリソースが求められますが、遅延情報など細かいメトリクスなども取れるので、より解像度の高い監視ができるようになったと思っています。監視設定についてはDockerコンテナ内に配置してあるsnmp-base.yamlのDevice設定の中でping_only属性をTrueにすることで実現できます。このあたりは公式ドキュメントでは情報が少ない部分ですので、設定や編集の難易度は少し高くなるかもしれません。
ここからは、監視基盤の使用上の課題についてご紹介します。私の所属部署では標準的な監視メニューに基づいた監視サービスを提供しています。その中に今回のテーマであるPing監視についてはNew Relicの動作特性上、標準的な監視に含めていないという実情がありました。
ここで、当社の監視基盤をご紹介します。まずNew Relic環境の場合は、監視対象のリソースからNew Relicに対して通信を行う仕様です。これに対してZabbix環境の場合は、ZabbixサーバーからZabbixプロキシを返して、監視対象のリソースに向けて通信を行う仕様です。この場合、Zabbixのプロキシから監視対象に対して通信を行えるので、エージェント間の通信やICMPとしてのネットワーク機器の監視が容易に行えます。
一般的な企業では、社内にZabbixサーバーを構築するケースも多いと考えていまして、その場合は社内のネットワーク通信という形になりますので、監視対象リソースやネットワーク機器に容易に通信できる環境だと認識しています。それに対してNew Relicの場合、監視対象のリソースからNew Relicのサーバーに対して通信を行うため、間に立てた中継サーバーからPing監視を行い、その結果をNew Relicに返すという構成になります。
中継サーバーを構築しない場合、Ping監視を実現するのは基本的に困難な状況かなと考えています。New Relicの要件を考慮すると、基本的に監視対象のリソースにNew Relicがインストールされていてインターネットにつながっていれば、New Relicに対して通信を行うことができます。そのため、あえて中継サーバーを立てる理由がありません。当社としては管理コストのかかるリソースを作成しない代わりに、Ping監視を標準使用の対象外としています。
Ping監視の導入にはまだまだ課題もありますが、New Relicの導入によって監視設定の標準化が実現でき、横展開しやすくなりました。また、情報の一元化によって複数の管理画面を開くことがなくなり、管理が非常に楽になりました。こうした管理面の負担軽減が、少なからずコストの削減につながっているのではないかと思います。
導入企業が語るオブザーバビリティ実践のコツ
続いて、LTでお話しいただいた3名に、New Relic株式会社の大森氏とQiita株式会社の清野氏が加わり、パネルディスカッションを行いました。そちらの様子もお届けします。
パネルディスカッション登壇者紹介
導入当時の状況と解決したかった課題
清野：本日は登壇いただきありがとうございます。今日は僕も、オブザーバビリティについてしっかりとキャッチアップしていきたいなと思っていますので、どうぞよろしくお願いいたします。それではNew Relic導入当時の社内状況や、導入によって解決したかった課題を教えてください。
小森谷：シニアのエンジニアを除いて、障害の対応方法やシステムの仕様を詳しく把握できていないという点を改善したいという想いがありました。障害対応が属人化していると、対応できる人がいない状況になった場合、ビジネスにも直結してインパクトを与えてしまう恐れがありました。こうした状況を打開し、みんながシステムの仕様を理解して障害に対応できるようにしたいと思い、New Relicの導入を進めることになりました。
塩野：監視基盤をZabbixからNew Relicに移行してオブザーバビリティに取り組んでいこうという機運は、もともと社内にありました。取り組みの中で、お客さまから「Ping監視をサービスのメニューに組み込んでほしい」というご要望があったことが、直接的な導入のきっかけです。複数の監視基盤を併用するよりは、情報をNew Relicに集約して横断的に見られるようにしたほうが便利ですし、より深い分析ができると考えました。
工藤：導入の課題感で言いますと、監視ツールが5つものサービスに分散していたため、トラブル時などに「どこに何を見に行けばいいのかわからない」という状況になってしまっていました。これを1つのサービスに集約して、必要なデータを迷わずに見つけられるようにしたいと思ったことが、New Relic導入のきっかけになりました。
清野：大森さんの感触では、どのようなきっかけでNew Relicの導入を検討する企業さんが多いのでしょうか？
大森：オブザーバビリティとひと口に言っても、その段階は企業によって様々です。監視自体がまだできていないというケースもあれば、すでにオブザーバビリティを実践しているけれどもさらにいろいろな場面で活用したいというケースもあります。そのため一概には言えないのですが、オンプレミスからクラウドへという流れの中でこれまでの監視ツールが使えなくなり、それをきっかけにご検討いただくケースは比較的多いですね。
データは「集めるだけ」では意味がない
清野：ログ監視の仕組みは自由度が高いので、少し状況が変わるだけで今までうまくいっていたものがいかなくなるというケースはよくありそうですね。New Relicの導入を決めてからは、どのように導入を進めていったのでしょうか。苦労した点について、それぞれ教えていただきたいです。
小森谷：自社のOSが非常に古かったため、インフラのリソース監視やデータ収集を行う「インフラストラクチャー」というツールを入れるのにかなり苦労しました。New Relicではガイド付きでツールを簡単にインストールできる方法がありますが、レガシーシステムゆえにそれが使えず、無理やりソースをインストールしました。それによって使えない機能も多々出てきました。システム自体を改善しないとNew Relicを完全に活用することが難しかったので、そこをどう寄せていくかをかなり頑張りました。
塩野：infrastructureエージェントに関しては公式ドキュメントが充実していた一方で、Syntheticsを使ったPing監視については公式ドキュメントが少なく、検索してもほとんど情報が見つからない状況でした。こうした情報を求めるユーザーは少ないのかもしれません。Ping監視を実現できる方法を見つけ、さらにそれをNew Relicの推奨する方法で実現するにはどのような設定をすればいいのかを深掘りをしていく作業には、非常に骨が折れました。
小森谷：いくらデータを集めても、それを活かせなければ意味がありません。New Relicで膨大なデータを集めたあと、これをもとに何をどう分析したらユーザーのためになるのか、事業ビジネスの価値につながるのかを考えるのには、かなり苦労しましたね。私は求職者向けのサービスを担当しているので、求人情報が一覧表示されるページや求人応募の入力フォームなど、ビジネス的な価値の高いページや機能をピックアップして、関連データを見ることからはじめました。そこから「このデータにはどのような価値があるのか」「こんな場面で役に立ちそうだ」というように考えながら取捨選択し、徐々にデータを活用できるようになりました。
大森：システムによって特性や構成が異なる中で、自社のシステムにおいてビジネス的な価値に直結するページや機能を見極めていく作業は非常に重要だと思います。その点、New Relicは私のようなソリューションコンサルタントが伴走します。設定の方法や情報をどう活用していくかを相談したり、レガシーシステムのマイナスを0に上げていく過程の苦労も共有できます。お客さまと密にコミュニケーションをとりながら伴走していける点が、New Relicのソリューションコンサルタントとしてのやりがいでもあると感じています。
New Relicを導入して得られた効果
清野：New Relicを活用して得られた効果や成果についても、改めて教えてください。
小森谷：みんながシステムを見られるようになったのが一番の成果ですね。簡単な障害調査やパフォーマンス調査に関しては新卒のメンバーでも対応できるくらい、システムに関するデータが一目瞭然になったということは非常に大きいと思います。ジュニアのメンバーってスキルを伸ばしたいけれどどうすれば良いのか分からないとか、自分でできるか不安だということが多いと思うんです。New Relicであれば簡単にデータが見られるので、そのデータを使って根拠を持った改善提案ができます。それがジュニアメンバーの自信や周囲からの信頼につながり、任せられる仕事の範囲が広がりました。
清野：オブザーバビリティのような領域は、ジュニアのエンジニアにはとっつきにくさや心理的距離感があるかもしれませんが、データにアクセスしやすい状態にすれば興味を持ってくれるメンバーも増えそうですね。組織文化にも変化が生まれてくるかもしれません。
工藤：定量的な効果では先ほどお伝えした2,520時間の削減をはじめ、別のプロジェクトでも月100万円ほどの削減を達成し、New Relicの導入効果が続々と出ているのを感じています。定性的にも、以前は「あのデータ、どこにありましたっけ」と聞かれることが多かったのですが、「どのようなデータもNew Relicを見ればある」という認識が広がってきてからは、こうした質問自体が減ったような気がします。
オブザーバビリティは「システム」と「ビジネス」をつなぐもの
清野：オブザーバビリティプラットフォームを導入したあと、継続的に改善の取り組みを続けるのも難しいことです。New Relicを活用するという機運を醸成するために、どのような工夫をされましたか？
小森谷：そうですね。定期的にオブザーバビリティを意識する機会を設けないと、モチベーションを保つのは難しいと思います。私のチームではスクラムを組んで開発をしていますが、レトロスペクティブやプランニングの中で、サービスの現状を眺めながら次のアクションにつなげることを目的とした「データや数値を見る会」を設定しています。これによってオブザーバビリティへの関心が継続して、データや数値を意識する文化が根付いてきたと思います。
清野：データや数値を意識する文化を作るために、行った取り組みなどはありますか？
小森谷：個人の関心事を把握し、それに合わせてNew Relicの機能を紹介しています。開発者によって関心事は様々です。例えばパフォーマンスを改善したり、ロジックを考えるのが好きな人にはパフォーマンスの変化をデータで見てもらうことで、New Relicの便利さを伝えています。一方でビジネス的な数値を見るのが好きな人には、機能のリリース前後のメトリックスやKPIの変化を見てもらっています。
塩野：お客さまによって運用状況やワークロードは異なり、「正しい状態」を定義するのは難しいと感じています。その中でAWSなどのクラウドベンダーやNew Relicが推奨しているプラクティスをお勧めするものの、「システム側の対応が難しいから今のままの運用でいい」と言われてしまうこともあります。しかし、それはお客さまにとってのベストプラクティスではありません。こうした場合、どのように運用すべきかは悩ましいところです。
工藤：エアークローゼットでは開発エンジニアがオペレーションも交代で担当しているので、基本的に全員がNew Relicに触ったことがあるという状況になっています。もともとあった文化のおかげで、オブザーバビリティの浸透が早かったのは良かったですね。一方でチューニングを担当できるメンバーは多くないので、その点は改善が必要だと感じています。
大森：せっかくツールを導入をいただいてもツールを使っていただかないとオブザーバビリティは浸透していきません。定例会の中でデータを見る時間を設けるなど、習慣化する仕組みが大切だと思います。また、オブザーバビリティを意識する文化の醸成には、段階を踏んで取り組むことをおすすめします。1つのシステムで成果をつくったあと、徐々に横展開していくという流れが良いと思います。そして最も重要なのが、大きなトラブルが起きる前にオブザーバビリティを実践しておくことです。トラブルが起きてから取り組みをはじめようとしても、データが蓄積・整理されていない状態ではすぐに原因を特定できません。致命的な事故が起きる前からデータを継続的にチェックし、システムの問題をいち早く発見できる体制を整えておくことが大切です。
清野：トラブルの予兆にいち早く気づいて原因を特定できるだけでなく、トラブルシューティングを民主化し、開発組織の価値を向上させてくれる。それがオブザーバビリティの価値なんですね。New Relicを活用することでオブザーバビリティを簡単に実践でき、アプリの担当者もインフラの担当者も、エンジニアもビジネスサイドのメンバーもデータを見られるようになるので、New Relicはシステムとビジネスについてみんなで話し合える基盤プラットフォームとも言えるのだと感じました。
編集後記
あらゆる業界でDX化が進む今、企業はシステムのトラブルと無縁ではいられません。ビジネスのリスクを最小限に抑えるためにも、オブザーバビリティへの強い意識が求められます。今回登壇された3社の事例をお聞きして、あらためてそう感じました。一見敷居の高いオブザーバビリティを誰もがわかりやすい形で実践できるNew Relicは、これからの時代を生き抜く企業の必須ツールになるでしょう。
文／株式会社Tokyo Edit