自己紹介
はじめまして、株式会社アイスタイルで@cosmeの開発マネージャーをやっております、土屋です。
本日はNew Relic Advent Calendar 2021の22日目ということで、わたしの方からアイスタイルで導入したNew Relicの導入背景や参考事例をお伝えできればと思います。
本題に入る前にご紹介をさせてください。New Relicのアドベントカレンダーとは別にでもアイスタイル Advent Calendar 2021をやっておりますので、ぜひこちらよりわたしを含むアイスタイルのエンジニアの記事をお読みいただけますと幸いです。
導入背景
現在アイスタイルで運営中のアットコスメですが2021年で22年目となります。この年数が分かる通り裏側の基盤システムが古くなっているものが有り現在その環境（主にインフラ）を一新するべくRebornプロジェクトが動いており大掛かりな負債解消のプロジェクトが動いております。こちらに関して詳しくは
・技術的負債を解消する
・システムRebornプロジェクト
などの弊社noteをご覧ください。
大掛かりな改善を行うとともに社内でも少しずつ改善は行ってきましたが、その際に用いられたものとしてはxprof（しかもステージングのみ）やzabbixによるリソースの空き状況などからの仮説構築・修正、Logファイルの分析など、どれも旧来の方法で解析をしていることが多く正直効率的な状態とは言えませんでした。
また情報の蓄積もできておらず、リリースの際のパフォーマンスとの因果関係を追うことも気づくことができない状態になっており、結果としてパフォーマンスの劣化に気づくことが困難な状態になっていました。
上記の理由により、アイスタイルではNew Relicを導入するということを決定し導入を進めてきました。
活用事例
導入初期フェーズでの活用
弊社では主に改善用途に使用しました。フェーズの最初の方に導入したのは主にフロントのサーバーへの導入をし、シンプルに読み込み速度だけをダッシュボード化したものを作成しました。
クエリとしては
SELECT percentile(duration, 95) * 1000 FROM Transaction WHERE appName IN (‘hogehoge') TIMESERIES max FACET `appName` LIMIT 20 SINCE 1 month ago EXTRAPOLATE
という感じで基本は95%タイルをトラッキングし、比較的遅いデータのトラッキングを行いました。平均を分析の指標として採用しなかった理由としては、当時はネットワーク（データセンター側）の帯域が頭打ちになる場合があるのではないか、という仮説があったことや、現在の95%タイルの指標がそもそも現行のパフォーマンス値としてあまり良い結果ではなかったことによるためです。これが改善されていくにつれて指標を平均か99%タイルなどより厳しい指標を使用するのは有りかなと考えております。
また導入初期の改善については
サーバを移転するだけで@cosmeサイト全体のレスポンスタイムが30％も改善した、という話
こちらの事例も合わせてご確認いただければと思います。
Core Web Vitals改善での活用
Core Web Vitalsの改善では以下のようなダッシュボードを作成しました。
こちらはとあるトップページを切り出したダッシュボードとなります。
上のグラフは主にページに対するレスポンス速度のグラフで、下のグラフはCore Web Vitalsの3指標（LCP,FID,CLS）のグラフとなっています。
Core Web Vitalsの改善ではLCPをメインの改善にすればよいのでは、と思うことはありますが、正直弊社では全体的に読み込み速度が遅い状態と仮定し、LCP＝読み込み速度として捉え改善の指標としました。
またCore Web Vitalsに関しては
SELECT percentage(count(*), WHERE largestContentfulPaint < 2.5) AS '~2500ms', percentage(count(*), WHERE largestContentfulPaint > 2.5 AND largestContentfulPaint < 4) AS '2500ms~4000ms', percentage(count(*), WHERE largestContentfulPaint > 4) AS '4000ms~' FROM PageViewTiming WHERE 中略 TIMESERIES MAX SINCE 1 day ago
このような指標を作成し、ChatTypeをAreaにすることにより、LCPの遅い割合がどのくらいなのか、ということを可視化しています。
現地点・作業地点であきらめたこと
現地点であきらめたことも何点かありその点も解説できればと思います。
あきらめたことにより正直導入までスピードアップできたこともあるので、参考になればと思います。
全サーバー・アプリケーションへの導入
弊社で動いているアプリケーションで、New Relicに対応していないフレームワークなどが動いているので、そこは主要なサービスのみ手動で対応させ、非対応のアプリケーションはアプリケーション本体側をアップデートする方向にしました。
全社員へのアカウントの配布
導入当時は全社員へフルユーザーの発行を検討していましたが、現在は一部のメンバーのみにしております。
理由としては料金が一番大きいですが、もともとNew Relic見てプロジェクトで改善をする、というのがまだ定常的に業務として紐付いていないので、まずはNew Relicを見るという習慣を啓蒙することが重要かなと考えております。
なお基本ユーザーに関しては、無料で発行できるので全社員に配布をしています。
これからやること
これからやることに関しては、かなり文章がここまでで長くなってしまったので、箇条書き程度に収めていきたいと思います。
– マイクロサービスとの関連性の可視化
– アプリケーション外の可視化
– エラーバジェットの可視化
– エラー通知をzabbixから変更
– E2Eテストの構築
今後クラウド化する上でまたNew Relicの活用方法も変わってくると思いますので、そこは合わせて考えていくべきことかなと思います。
最後に
ここまでかなり長文ですが、お読みいただきましてありがとうございます。
弊社でもエンジニアを募集しておりますので、ぜひこちらから土屋の記事を見て、とか書いてくれると土屋にちょっとぐらいお小遣いが入るのかもしれません、入るという気持ちで書いております。
弊社でのNew Relicの使い方が皆様の改善のお役に立てればと思います。
