【要約】Raspberry Pi 5 で New Relic eBPF APM を試す：Go サーバーに負荷をかけると何が見えるのか [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、既存のアプリケーションにAPMを導入する際、コードの改修が必要になるという課題に直面している。従来の方式では、以下の問題が発生する。
- ・アプリケーションへのエージェント組み込みに伴う開発工数の増大。
- ・既存の安定稼働しているコードへの変更リスク。
- ・eBPFなどの最新技術が、ARM64環境でどこまで動作するかという不透明さ。
// Approach
筆者は、アプリケーションを修正せずに観測を行うため、eBPFを用いた非侵入的なアプローチを採用した。検証は以下のステップで実施されている。
- ・Raspberry Pi 5上にUbuntu ServerとGo HTTPサーバーを構築。
- ・New Relic Infrastructure AgentとeBPF Agentを導入。
- ・Mac上のwrkを用いて、Raspberry Piに対してランダムなHTTP負荷を継続的に注入。
- ・eBPFを通じて、カーネルレベルからプロセスやネットワークの情報を取得。
// Result
検証の結果、ARM64環境においても、アプリケーションの改修なしで詳細なメトリクスが取得できた。具体的には以下の成果が得られている。
- ・HostのCPU、メモリ、ネットワーク使用率の可視化。
- ・プロセス単位でのCPUおよびメモリ消費量の特定。
- ・New Relic上でのTransaction time、Throughput、Errorsの確認。
- ・アプリケーション内部のロジックは追えないものの、外側からのリクエスト状況は正確に把握可能。
Senior Engineer Insight
> 非侵入的な観測は、運用フェーズにおける「迅速な可視化」のニーズに合致する。コードを触らずにプロセス単位の負荷を特定できる点は、トラブルシューティングの初動を劇的に早める。ただし、eBPFはカーネル視点の観測であるため、アプリ内部の深いトレースには限界がある。既存のAPMエージェントと、このeBPF Agentを適切に使い分ける設計が、実戦的なオブザーバビリティ戦略には不可欠だ。ARM64対応は、Graviton等の採用拡大に伴い、極めて重要な武器となる。