Mackerel APM導入ガイド ― コスト・データ量の見極め

APMの価値は短期検証による可視化分析で実感できました。パフォーマンスのボトルネックが一目でわかる、エラーの原因を素早く特定できる。APMがあれば運用が大きく変わることは理解できたはずです。

しかし、本番導入に踏み切るには、コストの見通しが欠かせません。「本番環境に導入したらデータ量はどのくらいになるのか」「月額コストがどの程度になるか、稟議を通すための数字が欲しい」「コストが高すぎたらどうしよう」といった不安は当然のものです。

この章では、検証で集めたデータを使って本番運用のコストを概算する方法を解説します。精緻な数字を出すのではなく、「桁感」を掴むことが目的です。コストが想定を超えた場合の最適化手段も紹介しますので、導入判断に必要な材料を一通り揃えられます。

APMのコスト構造を理解する

コストは何で決まるのか

Mackerel APMの利用コストは、送信されるスパン数に基づいて決まります。

スタンダードプランの場合、月間5M（500万）スパンまでが無料枠に含まれ、超過分は1M（100万）スパンあたり330円（税込）が課金されます。つまり、コストを見積もるには「本番環境で月間どのくらいのスパンが発生するか」を把握すればよいということです。

なお、トライアル期間中は1億スパンまで無償で利用できます。上限に達するとスパンの受け付けが停止されるため、意図せずコストが発生する心配はありません。検証段階ではコストを気にせずデータを収集し、本番導入前にこの章の手順で見積もりを行ってください。

スパン数が増える要因

スパン数は主に以下の要因で増減します。

  • トラフィック量：リクエストが多ければスパンも多くなります。これが最も大きな要因です
  • 計装の深さ：ゼロコード計装で自動的に生成されるスパンの数は、使用しているフレームワークやライブラリの種類と数に依存します
  • サービス数：計装対象のサービスが増えればスパン総数も増えます
  • 分散トレーシング：1つのリクエストが複数のサービスをまたぐと、サービスごとにスパンが生成されます

「1リクエストあたりのスパン数」という考え方

コスト見積もりの出発点は、「自分たちのシステムでは1リクエストあたり平均何スパン生成されるか」を把握することです。

同じリクエストでも、経由するサービスやライブラリの数によってスパン数は異なります。シンプルなAPIなら1リクエストあたり3〜5スパン程度かもしれませんし、複数のデータベースや外部APIを呼び出す複雑な処理なら数十〜数百スパンになることもあります。

この数字は検証データから確認できます。APMのトレースタブでトレース一覧からトレースをクリックして詳細を開くと、スパンツリーの右側にサービス名とそのスパン数が表示されます。いくつかのトレースを確認して、1リクエストあたりのスパン数の目安を掴んでおきましょう。

トレースのスパン数

検証データからスパン数を確認する

スパン数の確認方法

検証期間中に送信されたスパン数は、以下の3つの方法で確認できます。用途に応じて使い分けてください。

方法1：オーガニゼーションの利用状況タブで日次推移を見る

Mackerelのオーガニゼーション概要画面にある利用状況タブを開きます。APMの画面ではなく、オーガニゼーション全体の利用状況のページです。

  • トレースのスパン数（日次利用量）：日ごとのスパン数が表示されます。検証した日にどのくらいのスパンが送信されたかを把握できます
  • トレースのスパン数（総利用量推移）：蓄積推移のグラフで、無料枠（5Mスパン）の線も表示されます。月間の利用ペースが無料枠に収まりそうかを視覚的に判断できます

利用状況タブ

コスト見積もりの出発点として、まずこの画面で1日あたりのスパン数を確認するのがおすすめです。

方法2：メトリックエクスプローラーで分単位の投稿量を見る

より細かい粒度でスパン数を確認したい場合は、Mackerelのメトリックエクスプローラーを使います。

  1. Mackerelのサイドバーから「エクスプローラー」をクリックし、メトリックエクスプローラーを開く
  2. service.name に __mackerelio.system を指定する
  3. 「検索」をクリックする

検索結果に複数のメトリックが表示されます。コスト見積もりには、スパン投稿量を示す __mackerelio.estimated_usage.monthly_spans のグラフを確認してください。1分単位での積み上げグラフで表示されます。

スパン投稿量のグラフ（積み上げ）

差分値表示に切り替えれば、その1分間に投稿されたスパン数がわかります。

スパン投稿量のグラフ（差分）

この方法で取得できるメトリックは通常のMackerelメトリックとして扱えるため、監視ルールを設定してアラートを発報させることも可能です。たとえば「スパン投稿量が一定値を超えたら通知する」といった設定ができ、本番運用でのコスト管理に活用できます。

アラートは監視ルールの「クエリによる監視」で設定します。以下は当月の累積投稿スパン数を求めるクエリです。

sum(__mackerelio.estimated_usage.monthly_spans{service.name="__mackerelio.system"})

これをたとえば50000000（50M）でWarning、95000000（95M）でCriticalのアラートを出すように設定した例が以下です。

累積投稿スパン数でアラートをかける設定

詳細についてはMackerelのヘルプページ「概算使用量メトリック」（https://mackerel.io/ja/docs/entry/advanced/estimated-usage-metrics）を参照してください。

方法3：APMのトレースタブでスパン数の推移を見る

APMのトレースタブでも、期間ごとのスパン数を確認できます。

  1. トレースタブの「フィルター」ボタンをクリックし、検索モードを「スパン」に切り替える
  2. グラフ上部の「スパン数」をクリックする

トレースタブ内でのスパン数表示

表示モードに応じた粒度でスパン数の推移が表示されます。

表示モード 粒度
30分〜1時間 1分
6時間 5分
1日以上 60分

トレースタブの絞り込み条件と組み合わせることで、「特定のサービスだけのスパン数」「特定のエンドポイントだけのスパン数」といった分析も可能です。

確認のポイント

以下の数値を記録しておきましょう。見積もりに必要な材料になります。

  • 検証期間：何時間（または何日）検証を行ったか
  • スパン総数：検証期間中に送信されたスパンの合計数
  • リクエスト数：検証期間中に処理されたリクエストの合計数（わかる場合）
  • 時間帯ごとのスパン数の推移：ピーク時間帯とオフピーク時間帯の差があるか

リクエスト数がわかれば、1リクエストあたりの平均スパン数を概算できます。

1リクエストあたりの平均スパン数 = スパン総数 ÷ リクエスト数

本番規模のコストを見積もる

検証データを「ミニチュア」として、本番環境のスケールに拡大して見積もります。精緻な予測ではなく「桁感」を掴むことが目的なので、概算で十分です。

図：本番規模のコストの見積り概算

ステップ1：1時間あたりのスパン数を算出する

まず、検証データから1時間あたりのスパン数を算出します。

1時間あたりのスパン数 = 検証期間のスパン総数 ÷ 検証時間（時間）

たとえば、4時間の検証で20万スパンが生成されていた場合、1時間あたり5万スパンです。

ステップ2：本番トラフィック比率で補正する

検証環境と本番環境のトラフィック量の差を反映します。

本番での1時間あたりスパン数 = 検証の1時間あたりスパン数 × トラフィック倍率

たとえば、検証環境では1時間に100リクエスト、本番では1時間に10,000リクエストを処理している場合、トラフィック倍率は100倍です。検証の1時間あたり5万スパン × 100倍 = 本番では1時間あたり500万スパンという計算になります。

ステップ3：対象サービス数を合算する

検証では1サービスだけに計装した場合、本番で複数サービスに導入する際は各サービスのスパン数を合算します。サービスによってリクエスト量やスパン数の特性は大きく異なるため、可能であればサービスごとにステップ1〜2の見積もりを行い、合計してください。

すべてのサービスで個別に見積もるのが難しい場合は、検証済みのサービスのスパン数をベースに、他のサービスも同程度と仮定して概算する方法もあります。精度は下がりますが、大まかな桁感を掴むには十分です。

ステップ4：月間スパン数を概算する

月間スパン数 = 1時間あたりスパン数 × 1日の稼働時間 × 30日

24時間稼働のサービスなら、1時間あたり500万スパン × 24時間 × 30日 = 月間36億スパンです。

見積もり結果から月額コストを算出する

算出した月間スパン数をMackerel APMの料金体系にあてはめます。

月間スパン数 無料枠（5M）超過分 月額コスト（税込）
500万 なし 0円
1,000万 500万 1,650円
1億 9,500万 31,350円
10億 約10億 約33万円

この段階の見積もりには幅があるため、上限と下限のレンジで示すのがおすすめです。また、この数字は最適化前の「生のまま全データを送った場合」の見積もりです。次のセクションで紹介する最適化手段を適用すれば、コストを大幅に削減できます。

コストが想定を超えたら ― 最適化の選択肢

見積もったコストが想定より高く見えても、心配する必要はありません。最適化の手段があり、見積もった数字がそのまま最終コストになるわけではないからです。

フィルタリング ― 不要なトレースの除外

フィルタリングは、特定の条件に合致するトレースをまるごと除外する手法です。

  • ヘルスチェック（/healthz、/readyz）のトレースは、大量に発生しますがパフォーマンス分析の観点では価値が低いケースがほとんどです
  • 静的ファイルの配信（CSS、JavaScript、画像ファイル）も、分析対象外となることが多いリクエストです

これらを除外するだけで、スパン数が数十%削減できることも珍しくありません。

サンプリング ― データの間引き

サンプリングは、全リクエストではなく一部のみを記録してデータ量を抑制する手法です。

  • 正常なリクエストは10%だけ記録し、エラーが発生したリクエストは100%記録する、といった条件付きの制御も可能です
  • トラフィック量が多い環境では特に効果が大きく、90%削減も実現できます

最適化後のコスト見込みを概算する

最適化の効果を概算してみましょう。

たとえば、月間1億スパンと見積もった場合に、フィルタリングで20%削減し、さらにサンプリングで正常トレースの90%を間引くと仮定すると、

フィルタリング後: 1億 × 0.8 = 8,000万スパン
サンプリング後: 8,000万 × 0.1（正常）+ エラートレース分 ≒ 1,000万〜1,500万スパン程度

月額コストは最適化前の約31,350円から、3,300円〜5,000円程度まで削減できる見込みになります。

フィルタリングとサンプリングの具体的な設定方法は、フィルタリングとサンプリングによるデータ量・コストの最適化で解説しています。

導入判断の整理 ― チームで共有するために

コスト見積もりが揃ったら、導入判断に必要な情報を整理しましょう。

検証結果をまとめる観点

  • 可視化の価値：短期検証による可視化分析で確認できた情報と、それによって解決できそうな課題
  • コスト見積もり：本番規模での月間推定コスト（最適化前と最適化後のレンジ）
  • 導入による期待効果：障害対応時間の短縮、パフォーマンス改善の効率化、チーム間の認識合わせの改善など

関係者ごとの関心事に応える情報整理

チーム内で導入を提案する際には、関係者ごとの関心事に応じた情報を準備すると効果的です。

  • 開発チーム：ボトルネック特定がどの程度容易になるか、デバッグ効率の向上
  • 運用チーム：障害検知・原因特定の迅速化（MTTR短縮）、運用負荷の変化
  • マネージャー・CTO：投資対効果（ROI）、チーム生産性への影響、技術選定としてのOpenTelemetry標準への準拠

段階的な導入の提案

いきなり全サービスに導入する必要はありません。以下のような段階的なアプローチがおすすめです。

  1. まずは1〜2サービスから始める
  2. 効果を確認しながら、対象サービスを段階的に広げていく
  3. コスト最適化（フィルタリング・サンプリング）を並行して進め、スケールしてもコストを管理可能にする

コストは最初から完璧に最適化する必要はありません。まずは導入して価値を実感しながら、段階的に調整していくのが現実的です。

次のステップへ

ここまでの手順で、以下のことが達成できました。

  • 検証データから本番運用のスパン数とコスト感を概算できた
  • 最適化の選択肢と、最適化後のコスト見込みを把握した
  • 導入判断に必要な情報を整理できた

次は、コスト最適化を実践してみましょう。