「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に携わるエンジニアには特に読む価値があります。