インフラ担当がNew Relicで実現した3つの貢献
次に、New Relicを用いて村山氏が実際に不具合の解消、引越しシーズンのアクセス負荷過多をスムーズに乗り切ることに貢献した3つの例を見ていこう。
1つ目は、New Relicの「APM（Application Performance Monitoring）機能から付与されたTraceIDによるエラーログ調査」だ。New Relicのダッシュボードを開き、エラーが発生したアプリ名や発生したエラーのメッセージを入力して絞り込み、該当する条件のTraceIDを見つける。そのTraceIDをキーにして、再びログを検索することで、エラーに関連する一連のログを抽出することができる。これにより、エラーの調査効率が上がり、アプリ開発の担当者からは「5倍は速くなった」との声が上がったほか、アプリの実装をわかっていないインフラエンジニアでも、エラーの前後でいつ何が起きたのかある程度理解することができ、切り分けに役立てることができたという。「簡単なクエリを書くだけなので、すぐに始められる。New Relicの導入直後から効果を感じられたところだ」（村山氏）
2つ目は、「遅延テーブルや問題クエリの特定」だ。New RelicのAPMでは、アプリから外部APIを呼び出した回数や、データベースに対するクエリの実行状況も詳細に観測できるようになる。たとえばデータベースであれば、「どのテーブルに、何回クエリが発行され、どれくらい時間がかかっているか」といった情報をテーブル単位で出力することができる。実際、処理遅延が発生した際に、APMのデータをもとに疑わしいテーブルを特定し、そこで使われているクエリを抽出して、アプリ開発の担当者に相談。該当クエリについて改善してもらったところ、データベースのアクセスの平均時間が激減したケースもあった。「パフォーマンスが改善されると、コスト削減にもつなげられる。インフラしかやってこなかった自分にもこのような貢献ができるのは、新鮮な経験だった」（村山氏）
3つ目は「ピーク時に向けた適切な対応」である。ガス・電気の受付システムは、引越しが集中する3〜4月に5〜9倍にまで負荷が増える。公共性の高い東京ガスでは、万一、障害によって受付が停止するような事態になると、経済産業省への報告や是正措置が必要になる。このような大惨事を避けるため、「止まるくらいなら増やせ」というのが定石だった。しかし、New Relicの観測データを活用することで、ピークを見極めたうえで根拠を持ちながら処理能力を拡張し、ピーク後にはスムーズに縮小することができた。「サービスの停止が許されない状況で、データなしにサイズ調整をするのは極めて困難。New Relicがあったからこそ、過度に怯えることなく、最適化を図ることができた」（村山氏）
New Relic導入後のインフラチームの変化について、村山氏は以下のようにまとめた。
「今回のプロジェクトで学んだことを受け、現在は東京ガスグループ全体にNew Relicの活用を広げようと奮闘している」と明かす村山氏。「オブザーバビリティツールは自分たちから見える範囲を、より広く・深くしてくれるもの。関係者間での共通認識を増やし、協力し合いながら課題を解決するための土台となる。データをもとに組織全体の意識・行動・文化を変えられるよう、インフラチームから働きかけていきたい」と語り、セッションを締め括った。
