- はじめに
- Workloadsとは?
- 結論：「カスタムダッシュボード」と「Workloads」の使い分け
- Workloads活用：アラートとService Levelsの併用運用
- 実践的調査フロー
- まとめ
- 宣伝
はじめに
こんにちは。 マネージドサービス部の福田です。
New Relicを運用していると、「Workloads」と「Dashboards」の使い分けに迷うことはありませんか？
「どう使い分けるのが正解なのか」と悩んでいる方も多いのではないでしょうか。
というよりも、実は私自身がそうです。
そこで今回は、ある程度自分の中で整理できたので個人的に考えているWorkloadsとカスタムダッシュボードの「使い分け」について書いていこうと思います。
もし「もっといい活用方法があるよ！」という方がいれば、ぜひ教えていただけると嬉しいです。
Workloadsとは?
Workloadsは、APMやHosts、Browserなど、New Relic上の各種リソースを、「決済システム」や「検索機能」といったビジネスやシステムの単位でまとめて管理・可視化する機能です。
通常、New Relicのメニューは「APM」「Infrastructure」のように機能ごとに分かれています。しかし、実際の本番環境では、Webサーバー、DB、フロントエンドなどが連携して初めて「1つのサービス」として機能します。
Workloadsを使うことで、これらの関連エンティティをひとまとめにできます。
「サーバー単体」の状態だけでなく、「サービス全体」として正常に稼働しているかを一目で把握できるのが最大のメリットです。
各ワークロードのヘルスステータスは以下のように色で表示されます。
- Critical (赤)：クリティカルアラートが発生中
- Warning (黄) ：Warningアラートが発生中
- Healthy (緑)：アラートは発生しておらず正常
- Unknown (灰) ：アラート設定なし、またはデータ未収集
主要画面
Summary情報
サービス全体のステータス、発生中のインシデントなどが集約されています。
Errors情報
Workloads内のリソースで発生したアラートやエラー情報を時系列で確認できます。
個別のAPM画面へ行かなくても、ここでスタックトレースなどの詳細情報までドリルダウン可能です。
Activity情報
Workloads内のリソースのパフォーマンス情報（ゴールデンメトリクス）やイベント情報の把握が可能です。
カスタムダッシュボードの関連付けも可能になります。
Map情報
リソース間の通信経路や依存関係をマップ化します。
複雑な分散システムにおいても、どのサービスがどのDBに依存しているか、障害の影響範囲はどこまでか、どこがボトルネックになっているかを視覚的に特定できます。
※New Relic新UIでの表示例
Service Levels情報
システムの稼働状況だけでなく、「ユーザーに対するサービスの品質目標（SLO）」を管理できます。
- SLI (指標)
- 成功率や応答時間など、サービスの健全性を測るメトリクス。
- SLO (目標)
- 「可用性 99.9%」などのターゲット値。
- Error Budget (エラーバジェット)
- あとどれくらいエラーが許容されるかが可視化されます。
Workloads画面上でSLOを確認することで、「システムは動いているが、ユーザー体験が悪化していないか（バジェットが急激に減っていないか）」という、よりビジネスに近い視点での運用が可能になります。
New Relicでは代表的なSLOは自動で作成することが可能です。
SLO設定方法については、以下の弊社ブログも併せてご覧ください。
結論：「カスタムダッシュボード」と「Workloads」の使い分け
運用における両者の役割は、以下のように定義するとスムーズかなと思います。
- Workloads（検知・全体把握）
- アラート状態やService Levels（SLO）の達成状況をシステム全体的に把握する
- Custom Dashboards（分析・深掘り）
- Workloadsのデータより詳細な障害発生時の原因分析や、中長期的なパフォーマンス傾向を把握するための詳細分析に活用する
※DashboardsはBasic User（Core User）でも利用できますが、Workloadsの機能はFull Platform User向けの機能であるため、今回はFull Platform Userを想定した話になります
Workloads活用：アラートとService Levelsの併用運用
結論で「Workloadsは検知・全体把握」と書きましたが、具体的にどう活用すればいいのか。
ポイントは「アラート」と「Service Levels」の2つを組み合わせることです。
アラートによる状態把握
基本となるのはアラートとの関連付けです。CPU使用率やメモリ枯渇など、設定したアラートが発生するとWorkloadsのステータスが「Critical」に変わり、どのリソースで障害が起きているかを把握できるようになります。
逆に言えば、アラート設定が紐づいていないと、いくらサーバーの状態が悪くてもWorkloadsのステータスは「Unknown (灰)」のままです。
まずはアラート設定をWorkloadsに紐づけるのが第一歩になります。
Service Levelsによるパフォーマンス把握
Service Levels（SLO）を設定すれば、個別のリソース監視だけでは見えないサービス全体の異常を検知できます。
まだ本格的なSLO運用が難しくても、Workloadsを使うことで「発生中のアラートが、実際にサービスへ悪影響を与えているか」を判断できます。
例えば、「アラートは頻発しているが、SLOには全く影響していない」ということが分かれば、それは対応不要なノイズである可能性が高く、アラート設定の削除や見直しのきっかけになります。（アラート設定はせずにカスタムダッシュボードでの表示のみとするなど）
このように、日々の障害対応の優先度判断だけでなく、アラートの精査や棚卸しにも活用できるのが大きな強みです。
上記画面では以下のような指標を設定しています。
- デモシステム - 外形監視
- Synthetic Monitorによる外部からのアクセス成功率
- デモシステム - レスポンス時間
- 500ms以内に完了したリクエストの割合
- デモシステム - 決済処理成功率
- 決済関連トランザクションが正常に完了した割合
- デモシステム - アプリ可用性
- アプリケーション全体の可用性（システム起因のエラー（5xx）を除いた、正常に応答できた割合）
これらをWorkloadsに関連付けることで、「サーバーは落ちていない（アラートは緑）けど、レスポンスが悪化している（SLO未達）」といったユーザー影響に気づけるようになります。
アラートだけでは拾いきれない「品質の低下」に気づけるのが、Service Levelsを組み合わせるメリットです。
実践的調査フロー
では、実際に異常を検知した際、どう調査を進めればよいのか。
私がイメージしているフローは以下の通りです。（画像はGeminiにより生成しております）
詳細は以下になります。
- 検知（Workloads）
- Workloadsのステータスが赤くなっていたり、Service Levelsが目標値を下回っているのを確認します。
- Map（マップ）を見て、どのサービス間で問題が発生しているか、影響範囲を把握します。
- 詳細調査（Workloads Errors）
- Workloadsメニュー内の「Errors」をクリックします。
- どのサービスでエラーが起きているかが集約されており、クリックすればスタックトレース（エラー発生箇所の詳細）まで確認できます。
- 独自視点での分析（Custom Dashboards）
- WorkloadsのActivity画面やエラー画面だけでは把握しきれない、より詳細な分析が必要な場合にカスタムダッシュボードを活用します。
- 例えば、Activity画面のGolden metrics以外のメトリクスや、カスタム属性（店舗IDなど）をキーにした集計など、WorkloadsのUI上で確認できない内容を調査します。
まとめ
今回の内容をまとめます。
- Workloadsとは
- バラバラのリソースを「サービス単位」でまとめる機能。
- 使い分け
- Workloads：アラートとSLOで「異常を把握・検知する」
- Custom Dashboards：Workloadsでは把握できない部分を「詳細分析する」
この2つを組み合わせることで、検知から原因特定までの時間を大幅に短縮できると思います。
New Relicでは代表的なSLOは自動で作成が可能なので、まずはWorkloadsを作成し、主要なService Levelsを設定することから始めてみてはいかがでしょうか。
この記事がNew Relic運用の参考になれば幸いです。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのNew Relic導入支援サービスのページよりお問合せ頂けましたら幸いでございます。
・福田 圭(記事一覧)
・マネージドサービス部 所属・X（Twitter）：@soundsoon25
2023 New Relic Partner Trailblazer。New Relic Trailblazer of the Year 2025受賞。New Relic User Group運営。
