こんにちは、streampack の Tana です。
今回は動画配信サービスに New Relic(APM) を導入したお話になります。

背景

Webアプリケーションを本番運用していくと、リリースの不具合によりエラーが発生したり、またはレコードが増えることでパフォーマンスの低下が顕在化します。一般的にはログを見て原因を調査しますが、膨大なログから原因を特定するのは時間を要します。そこで原因が特定できればいいのですが、再現性がない場合は、一時的な要因と片付けることがあります。がしかし、そのような場合はまた発生します。さらに、そのような事象は開発環境では再現するのが困難です。そこで New Relic の登場です。

New Relic は AWS, Google Cloud, Azure などのクラウドプロパイダーのリソースやアプリケーションを監視してくれるサービスの一つです。APM(Application Performance Monitory)を導入することで、アプリケーションのパフォーマンスからエンドユーザーのエクスペリエンスを可視化されリアルタイムに分析することができます。

導入した経緯は？

アプリケーション(言語)によって多少実装方法は異なりますが、既存のサービスに影響が少なく簡易に導入できることがまず一つです。具体的に必要な実装は、パッケージをインストールし、ライセンスキーをセットすることで適用されます。(一部の言語は必要な箇所に組み込む必要あり)

また、Datadogを使ってクラウド関連の監視も行っておりますが、不十分なケースがあります。何かアラートなどを検知した場合は結局アプリケーション側の調査が必要になり、膨大なログから原因の特定が必要です。APMの導入することによって、エラーのトレースログを出力してくれたり、ボトルネックとなっているリクエストや処理をリストアップしてくれたりと、効率的に調査が可能になります。

導入方法

弊社の streampack は主に Rails と Golang のアプリケーションで構築してますので、そちらの言語での導入について、説明します。

Rails のアプリケーションの導入

他の記事でも多く記載されていますが、Railsの場合の APM の導入は簡単でかつ多くのメトリックス情報を取得することができます。
払い出された config/rewrelic.yml を読み込むことも可能ですが、Dockerを使用してますので、envファイルに必要な情報を定義します。
https://docs.newrelic.com/docs/agents/ruby-agent/configuration/ruby-agent-configuration/#Options

Gemfile


gem 'newrelic_rpm'

開発環境、本番環境とそれぞれ、 NEW_RELIC_APP_NAME を変えることで、環境に応じたAPMとして出力されます。

.env.example

NEW_RELIC_LICENSE_KEY=ライセンスキー
NEW_RELIC_APP_NAME=service-app-env

Railsの場合は以上です。リリースしてアクセスすると、ニアリアルタイムでページに反映されます。

Golang アプリケーションに導入

Goの場合は、必要な箇所の処理前後に入れてあげる必要があります。
gin というフレームワークを使ってますので、middleware として設定することで、最小限のコードでAPIの処理時間の計測が可能になります。 Gorilla のフレームワークも同様に組み込むことも可能です。

.env.example

NEW_RELIC_LICENSE_KEY=ライセンスキー
NEW_RELIC_APP_NAME=service-app-env

main.go


func main() {
    r := gin.Default()
    r.Use(NewrelicMiddleware(os.Getenv("NEW_RELIC_APP_NAME"), os.Getenv("NEW_RELIC_LICENSE_KEY")))
    ...
}

func NewrelicMiddleware(appName string, licenseKey string) gin.HandlerFunc {
    config := newrelic.NewConfig(appName, licenseKey)
    app, _ := newrelic.NewApplication(config)
    return func(c *gin.Context) {
        txn := app.StartTransaction(c.Request.URL.Path, c.Writer, c.Request)
        defer txn.End()
        c.Next()
    }
}

具体的にどのような情報が取れるの？

サマリーページ - Summary

全体的にパフォーマンスに問題ないか、またはエラーが出てないかをサマリーとして確認できます。
通常と異なる傾向であれば、スパイクのようなグラフになったり、Error Rate が上がる傾向があるかと思います。
Apdex Score というのは、アプリケーションパフォーマンスの指標で、
Satisfied / Tolerating / Frustrated の基準があり、スコアが 1 に近ければ近いほど、ユーザーの満足度がいい結果になります。
また、ライブ配信などはピークイベントで急にトラフィックが増えます。その際はこのサマリーページ(Summary)ページで監視できます。

不具合やエラーを特定する - EVENTS(Errors)

下記は Railsのエラーの場合のスタックトレースログです。ぼやかしているので、わかりづらいですが、ログを漁ることなく、原因の特定につながります。

視聴ユーザーの顧客体験可視化する - REPORTS(SLA)

デイリーの SLA(Service Level Agreement) のレポートです。
視聴者(ユーザー)に満足のいくWebのレスポンスが返せているかの指標になります。
もし、クライアント・サーバーサイドのレスポンスが悪いのであれば、Frustratedのパーセンテージが上がり離脱の原因の一つになるでしょう。

遅い処理はどれ？ - Monitor(Transactions / Databases)

何かサービスに影響しそうなリクエストはないかなど、調査確認する際は、Monitor にて確認できます。
下記のように、 Sort by "Showest average response time" で絞り込むことで最も遅い処理がリストされます。

上記の 8.51s は集計系の処理なので、時間がかかるものだと認識済みですが将来的には改善すべき、ということなどがわかります。

外部サービスとの連携 - Service Map

外部との連携しているAPIやサービスの連携部分の可視化などもされます。

まとめ

New Relic の APM を導入することでアプリケーションのパフォーマンスが容易に確認でき、サービスの安定運用、運用の効率化に繋がるのではないかと思ってます。また、クラウド系の監視とインシデント時のアラートを組み合わせをすることでより網羅的に安定運用かつ迅速な対応ができるのではないかと思ってます。