APMだけでは守れない時代へ:Runtime-native Observabilityとは何か、なぜ2025年に必要なのか

元記事を読む
キュレーターコメント

「Datadog入れてるから監視はOK」と思っているチームに読んでほしい一本。APMとRuntime-native Observabilityは競合ではなく補完関係というフレーミングが明快で、Kubernetes・コンテナセキュリティを扱うSRE・インフラエンジニアにとって2025年の必読記事です。

概要

「Datadogを入れているから大丈夫」と思っていませんか? Kubernetes・コンテナ・AI/GPUワークロードが当たり前になった今、APM(Application Performance Monitoring)だけでは観測できない領域が急速に拡大しています。本記事では、次世代の可観測性アーキテクチャである Runtime-native Observability の概念と、なぜ今それが求められるのかを整理します。

APMが変えた世界――そして限界

2010年代、クラウド移行とマイクロサービス化が進む中でAPMは「クラウド時代の第1フェーズ」を定義しました。

  • 分散トレーシングにより、リクエストが複数サービスをまたぐ経路を1本の線として可視化
  • SLO(Service Level Objective)文化の定着で「99.9%可用性」がエンジニアとビジネスの共通言語に
  • Datadog / New Relic / Dynatrace などのツールがオンコール対応の質を根本から変えた

APMが収集するデータは主に3種類です。

Metrics  : CPU使用率・レイテンシ・スループット・エラーレートなど数値で示す
Traces   : サービスA→B→Cと流れるリクエスト経路と所要時間の可視化
Logs     : アプリケーションが出力する構造化・非構造化テキスト

これらは現在も絶対に必要なデータです。しかしAPMが観測しているのは「アプリケーション自身が報告できること」だけという構造的な限界があります。SDKを仕込んだトレース、loggerが吐くログ――すべてアプリケーション自身が自発的に報告するものに過ぎません。

なぜ今、Runtime-native Observabilityなのか

この変化は偶然ではありません。3つの構造的変化が重なっています。

1. Kubernetesの当たり前化

従来のインフラKubernetes
IPは固定IPは動的に割り当て
ホストは管理対象ノードは使い捨て
状態(State)を監視変化(Change)を追う
サービスは長期稼働Podはエフェメラル

Podは数秒で生まれ数分で消える。従来のインフラ監視が前提とした「静的な環境」という仮定が崩壊しています。

2. セキュリティの高度化

コンテナ環境を標的とした攻撃が増加しています。クリプトマイニング・サプライチェーン攻撃・コンテナエスケープは、アプリケーション層のログに痕跡を残さないことが多い。MITRE ATT&CK for Containersが定義するように、コンテナ環境特有の攻撃ベクトルはOS・ランタイム層での観測を前提としています。APMの観測範囲では検知が困難です。

3. AI / GPUワークロードの到来

高価なGPUリソースが大量に使われる時代になりました。「GPUが何%使われているか」だけでなく、「誰が・何のために使っているか」 がコスト管理とセキュリティの両面で重要になっています。観測すべき対象が変わったのです。

Runtime-native Observabilityとは何か

APMが「アプリケーション層」を観測するのに対し、Runtime-native ObservabilityはOSとランタイム層から直接観測するアプローチです。

[APM]                   [Runtime-native]
アプリ自己申告           OS/カーネルから直接計測
SDK埋め込み必須          計装不要(eBPF等)
「何を報告するか」依存    「実際に何が起きているか」
アプリ層の可視性          システム全層の可視性

代表的な技術として eBPF(extended Berkeley Packet Filter) があります。カーネルを改変せずにシステムコール・ネットワーク通信・ファイルアクセスをカーネルレベルで観測でき、アプリへの計装が不要です。

# eBPFベースのツールで実際のシステムコールを観測する例(bpftrace)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s\n", str(args->filename)); }'

OSSでは Falco(セキュリティ異常検知)、Cilium(ネットワーク可視性)、Pixie(Kubernetesオートテレメトリ)などがこのアプローチを採用しています。

APMとRuntime-native Observabilityは競合しない

重要なのは、これはAPMの置き換えではなく、観測レイヤーの補完という点です。

  • APM → アプリケーションのビジネスロジック・パフォーマンスを深く観測
  • Runtime-native → システム・ランタイム・セキュリティ層を幅広く観測

「なぜ遅いか」はAPMが得意。「誰がこのプロセスを起動したか」はRuntime-nativeが得意。両者を組み合わせることで、クラウドネイティブ時代の真のオブザーバビリティが実現します。SREチームがこの概念を理解しておくことは、2025年以降のインフラ設計において必須になりつつあります。

まとめ

  • APMはクラウド第1フェーズの標準技術として今も有効だが、観測できないレイヤーが存在する
  • Kubernetes・コンテナセキュリティ・AIワークロードの台頭が新しい観測レイヤーを要求している
  • Runtime-native ObservabilityはOS・ランタイム層からの直接観測により、APMの盲点を補う
  • eBPF・Falco・Pixieなどのツールが実用段階に達しており、今すぐ導入を検討できるフェーズ

元記事(Qiita)では各レイヤーの違いがさらに丁寧に整理されており、SREやDevSecOpsに携わるエンジニアには特に読む価値があります。