Mackerel APM導入ガイド ― Mackerel APM の基礎理解

Webサービスやアプリケーションを運用していると、「なんだか遅い」「エラーが増えた気がする」といった問題に直面することがあります。サーバーのCPUやメモリには余裕があるのに、ユーザーからは「ページの表示が遅い」と報告される。障害が起きたとき、どのサービスのどの処理が原因なのか、特定に何時間もかかってしまう。

こうした「アプリケーション内部で何が起きているかが見えない」という課題を解決するのが、APM（Application Performance Monitoring） です。Mackerel APMは、業界標準規格であるOpenTelemetry形式に対応したAPMサービスで、アプリケーションのパフォーマンスをリアルタイムに可視化・分析できます。

この章では、APMの基本概念とMackerel APMの特徴を合わせて解説します。

APMとは何か

APM（Application Performance Monitoring） は、アプリケーションの動作状況やパフォーマンスをリアルタイムに監視・分析する仕組みです。日本語では「アプリケーション性能監視」とも呼ばれます。

インフラ監視との違い

サーバーの監視というと、CPU使用率やメモリ消費量、ディスクI/Oといったリソースの状態を見るインフラ監視を思い浮かべる方が多いかもしれません。インフラ監視はシステムの土台を支える重要な仕組みですが、「アプリケーションの中で何が起きているか」まではわかりません。

たとえるなら、インフラ監視が「建物の電気・水道の状態を見る」ことだとすれば、APMは「建物の中で人がスムーズに移動できているかを見る」ことに相当します。電気が正常でも、エレベーターが渋滞していれば利用者は困ります。APMは、アプリケーション内部の処理時間やエラー率、リクエストの流れなど、「アプリケーションが実際に何をしているか」を可視化します。

すでにMackerelでサーバー監視をしている方にとっては、Mackerel APMを導入することで、インフラ監視とアプリケーションの可視化を同じMackerelの中で利用できるようになります（ただし、従来のホストメトリック・サービスメトリックとAPMのトレースデータは仕組みが異なるため、それぞれの画面で確認する形になります）。

観点 インフラ監視 APM
監視対象 サーバーリソース（CPU、メモリ、ディスク） アプリケーションの処理（リクエスト、クエリ）
わかること リソースの使用状況、枯渇の兆候 処理時間、エラー率、リクエストの流れ
得意な問い 「サーバーは正常か？」 「アプリは期待どおり動いているか？」
問題特定の粒度 ホスト・プロセス単位 リクエスト・処理ステップ単位

APMが扱うデータの種類

APMが扱うデータは、大きく3種類に分けられます。

  • トレース： 1つのリクエストがシステム内をどのように流れたかの記録です。トレースはスパンと呼ばれる処理の単位で構成されています。たとえば「Webサーバーでリクエストを受け付ける」「APIサーバーに転送する」「データベースへクエリを発行する」といった個々の処理がそれぞれ1つのスパンになり、これらが親子関係で連なったものがトレースです。各スパンには処理名や所要時間が記録されるため、どのステップにどれだけ時間がかかったかを可視化でき、ボトルネックの特定に欠かせないデータです。Mackerel APMはこのトレースを中心としたサービスで、利用料金もスパンの数に基づいて計算されます。

  • メトリック： 数値で表せるデータです。リクエスト数、エラー率、応答時間（レイテンシー）など、システム全体の傾向を素早く把握するのに向いています。「いつもより応答が遅くなっている」「エラー率が急上昇した」といった異変をいち早くキャッチできます。Mackerel APMでは、トレースデータから導出したREDメトリック（後述）のグラフを確認できます。OpenTelemetry形式のメトリックは、Mackerelのメトリックエクスプローラーで別途確認する形になります。

  • ログ： アプリケーションが出力するテキスト形式の記録です。エラーメッセージや処理の詳細な経緯を確認できます。Mackerelのログ機能やCloudWatch Logsの検索に紐付けることができます。

以下は、1つのHTTPリクエストがトレースとしてどのように記録されるかを示した例です。各処理がスパンとして記録され、親子関係で階層構造を形成します。

トレースを構成するスパン

Mackerel APMの特徴

Mackerel APMは、アプリケーションのパフォーマンス監視に必要な機能を備えたAPMサービスです。ここでは、Mackerel APMの主な特徴を紹介します。

OpenTelemetry標準規格への対応

Mackerel APMは、OpenTelemetry（オープンテレメトリー）形式でメトリック、ログ、トレースを扱います。OpenTelemetryは、テレメトリーデータを収集・送信するための業界標準規格で、オープンソースプロジェクトとして開発されています（https://opentelemetry.io/ja/）。

OpenTelemetry以前は、APMツールごとに独自のデータ収集方法が必要でした。ツールを変更すると、データ収集の仕組みも作り直す必要があり、ベンダーロックインの原因になっていました。Mackerel APMはOpenTelemetry標準規格に準拠しているため、特定のツールに依存しない形でデータ収集の仕組みを構築できます。

Mackerelのサーバー監視との関係

すでにMackerelでサーバー監視をしている場合は、同じMackerelアカウント上でAPMも利用できます。

（ただし、従来のホストメトリック・サービスメトリックによるサーバー監視と、APMは別々の仕組みで動いており、それぞれ異なる画面で確認します。「サーバー側のリソース状況はホストの詳細画面で、アプリケーション内部の処理フローはAPMの画面で」というように、用途に応じて使い分ける形になります。）

分散トレーシング

分散トレーシングの説明に入る前に、「サービス」という概念を押さえておきましょう。ここでのサービスとは、特定の機能を担うアプリケーションやプロセスの単位を指します。たとえば「認証サービス」「商品サービス」「決済サービス」のように、役割ごとに分かれたアプリケーションがそれぞれ1つのサービスです。モノリスなアプリケーションであっても1つのサービスとして扱われます。この「サービス」はOpenTelemetryやKubernetesなどで広く使われている概念で、OpenTelemetryでは service.name というリソース属性でサービスを識別します。

なお、Mackerelを従来からお使いの方への補足ですが、ここでの「サービス」は従来のMackerelのサービス（ホストやメトリックをグルーピングする単位）とは異なる概念です。Mackerel APMではOpenTelemetryの service.name に基づいてサービスが管理され、APM専用の画面で確認します。

分散トレーシングは、複数のサービスにまたがるリクエストの流れを1つの「トレース」として追跡する仕組みです。マイクロサービス環境では、1つのユーザーリクエストが認証サービス、商品サービス、在庫サービス、決済サービスと、いくつものサービスを経由して処理されます。

Mackerel APMの分散トレーシングは、こうしたサービス間の依存関係や、各サービスでの処理時間を可視化します。「どのサービスがボトルネックになっているか」「エラーがどのサービスで発生しているか」を正確に把握するために不可欠な機能です。

複数のサービスを分散トレーシングで可視化

図：マイクロサービス環境における分散トレーシングとボトルネックの検出

REDメトリック

REDメトリックは、アプリケーションの健全性を素早く判断するための3つの基本指標です。Mackerel APMでは、収集したトレースデータからこれらの指標を自動的に算出し、グラフとして表示します。

  • Rate（リクエスト数）: 単位時間あたりのリクエスト数
  • Error（エラー率）: エラーが発生したリクエストの割合
  • Duration（処理時間、レイテンシー）: リクエストの処理にかかった時間

この3つの指標を監視するだけで、サービスの状態を大まかに把握できます。Rateの急増はトラフィックの異常を、Errorの上昇はアプリケーションの不具合を、Durationの悪化はパフォーマンスの劣化を示唆します。

サービスマップ

サービスマップは、サービス間の呼び出し関係を図として可視化する機能です。どのサービスがどのサービスに依存しているか、各サービス間の通信量やエラー率はどの程度かが一目でわかります。システム全体のアーキテクチャを把握し、影響範囲の分析に活用できます。

なぜ今APMが必要なのか

Mackerel APMのようなAPMツールが求められる背景には、いくつかの変化があります。

システムの複雑化

かつては1つの大きなアプリケーション（モノリス）として構築されていたシステムも、近年はマイクロサービスアーキテクチャへの移行が進んでいます。1つのリクエストが複数のサービスをまたいで処理されるようになると、「どのサービスのどの処理が遅いのか」を従来のインフラ監視だけで特定するのは困難です。

サービス間の呼び出しが複雑に絡み合うほど、問題の切り分けには時間がかかります。APMの分散トレーシングは、リクエストがサービス間をどのように流れているかを可視化し、ボトルネックを迅速に特定する手段を提供します。

ユーザー体験への要求の高まり

ページの表示が数秒遅れるだけでユーザーが離脱する時代です。パフォーマンスの問題は、売上やユーザー満足度に直結します。「体感で遅い気がする」ではなく、データに基づいてパフォーマンスを把握し、改善の優先度を判断できる仕組みが求められています。

障害対応の迅速化

障害が発生したとき、復旧までにかかる時間（MTTR: Mean Time To Recovery）をいかに短縮するかは、運用チームにとって大きな課題です。APMがあれば、「何が起きているか」を素早く把握し、勘や経験だけに頼らず、データに基づいた原因特定が可能になります。

Mackerel APMで解決できる具体的な課題

APMの必要性を理解したところで、次はMackerel APMで具体的にどのような課題を解決できるのかを見ていきましょう。

「どこが遅いかわからない」問題

あるAPIの応答が遅いという報告を受けたとき、APMがなければログを手がかりに原因を推測するしかありません。Mackerel APMのトレース機能を使えば、リクエストの処理経路と各ステップの所要時間を一目で確認できます。

たとえば、あるAPIエンドポイントの応答に5秒かかっている場合、トレースを見ることで「Webサーバーでの処理は10ms、APIサーバーでの処理は50ms、データベースクエリに4,900msかかっていた」と瞬時に判明します。原因の特定に費やす時間を大幅に短縮できます。

「エラーの原因がつかめない」問題

エラーが発生したとき、Mackerel APMはエラー発生時のスタックトレースやリクエスト情報を記録します。どのサービスで、どの処理で、どんな条件のときにエラーが起きたのかを追跡でき、再現性の低い問題の調査にも役立ちます。

「パフォーマンスの傾向が見えない」問題

トレースから導出されるREDメトリックの推移を確認すれば、応答時間やエラー率の変化を継続的に把握できます。デプロイ前後のパフォーマンス比較や、時間帯ごとの傾向分析が可能になり、問題が深刻化する前に対処する手がかりが得られます。

「チーム間の認識がずれる」問題

開発チーム、運用チーム、経営層がそれぞれ異なる情報源を見ていると、パフォーマンスに関する議論が「体感で遅い」「たぶんこのあたりが原因」といった曖昧なものになりがちです。

Mackerel APMの共通の画面があれば、全員が同じデータを見て議論できます。「このエンドポイントの95パーセンタイルレイテンシーが先週から200ms悪化している」という客観的な数値に基づいて、改善の優先度やリソース配分を判断できるようになります。

OpenTelemetryによるデータ収集

Mackerel APMでアプリケーションのデータを収集するには、OpenTelemetryの仕組みを使って計装（けいそう）を行います。計装とは、アプリケーションにテレメトリーデータの収集ポイントを組み込むことです。

計装の方法

OpenTelemetryでの計装には、大きく2つの方法があります。

  • ゼロコード計装： アプリケーションコードを変更せずにデータを自動収集する方法です。ライブラリ計装（インストルメンテーションライブラリ）を使う方式が一般的で、環境変数や設定の追加だけで始められます。さらに、LinuxのeBPF技術を使ってカーネルレベルで観測するOBI（OpenTelemetry eBPF Instrumentation）というアプローチもあり、SDKのインストールすら不要で導入できます（Linux限定となります）。

  • コードベース計装： アプリケーションコードにOpenTelemetry APIの呼び出しを追加して、独自のスパン（処理の単位）やメトリックを記録する方法です。ビジネスロジック固有のデータまで詳細に取得でき、柔軟性が高い反面、導入コストもかかります。

まずはゼロコード計装で全体像を把握し、必要に応じてコードベース計装を追加して深掘りするのが現実的なアプローチです。

Mackerel OpenTelemetryコレクター

Mackerel APMへのデータ送信には、Mackerel OpenTelemetryコレクターの利用を推奨しています。Mackerel OpenTelemetryコレクターは、アプリケーションからテレメトリーデータを受け取り、加工してMackerelのエンドポイントに転送する中継ソフトウェアです。

環境変数 MACKEREL_APIKEY を設定するだけで起動でき、ただ送るだけであれば設定ファイルの準備は不要です。必要であればフィルタリングやサンプリングなど、送信前のデータ加工にも対応しており、検証段階から本番運用まで活用できます。

図：Mackerel OpenTelemetryコレクターのデータフロー

クライアントトークン

Mackerel APMへのトレース送信には通常APIキーを使いますが、ブラウザやモバイルアプリなどフロントエンドから直接トレースを送信したい場合は、クライアントトークンを利用できます。

クライアントトークンは、トレースの投稿だけに権限を限定した専用のトークンです。APIキーと異なり、ほかのAPI操作（ホストの登録や監視ルールの変更など）はできないため、万が一トークンが漏洩しても影響範囲を最小限に抑えられます。フロントエンドのコードに埋め込んでも安全に運用できる設計です。

クライアントトークンは、MackerelのWebコンソールからオーガニゼーションのオーナーまたは管理者権限で作成できます。また、送信時のHTTPヘッダーには、APIキーの Mackerel-Api-Key ではなく X-Mackerel-Client-Token を使用します。詳しくは「クライアントトークンによるトレース投稿」（https://mackerel.io/ja/docs/entry/tracing/guide/client-token）を参照してください。

Mackerel APMを始めてみよう

APMの基礎とMackerel APMの特徴を押さえたところで、次は実際にデータを取得してみましょう。

Mackerel APMは無料トライアルで始められます。まずはゼロコード計装で、自分のアプリケーションでどんなデータが見えるかを体験してみてください。