【第7回】パフォーマンス分析とリソース監視：eBPFと標準ツールでサーバーの「詰まり」を特定する

こんにちは、リナックス先生です。第6回でWeb・DBサーバーが立ち上がり、いよいよ実用的なシステムが動き始めました。しかし、運用フェーズに入ると必ず直面するのが「なんだかサーバーが重い」「特定の時間だけWebサイトのレスポンスが悪い」といったパフォーマンスの課題です。

第7回のテーマは「パフォーマンス分析とリソース監視」です。初心者は闇雲に再起動して解決を図ろうとしますが、プロは「何が、どこで、なぜ詰まっているのか」をデータで証明します。AlmaLinux 10が採用する最新カーネルの恩恵、eBPF（Extended Berkeley Packet Filter）を活用した次世代の監視手法から、伝統的な標準ツールの読み解き方まで、徹底的に解説します。

---

1. プロの分析フロー：USEメソッドを習得する

闇雲にコマンドを打つ前に、世界的なパフォーマンスエンジニアが提唱するUSEメソッドを覚えましょう。これは各リソースに対して以下の3項目を確認する手法です。

• U (Utilization)：使用率。リソースがどれくらい使われているか？（例：CPU使用率 80%）
• S (Saturation)：飽和度。処理しきれず順番待ちが発生しているか？（例：ロードアベレージ）
• E (Errors)：エラー。リソースにエラーが発生していないか？（例：パケットドロップ）

特に重要なのが「飽和度」です。使用率が100%に達していなくても、待ち行列（Queue）が発生していればレスポンスは悪化します。AlmaLinux 10では、この飽和度をより精密に測るためのツールが充実しています。

---

2. 基本ツールの「見るべきポイント」：top, vmstat, ss

まずはどの環境でも使える標準ツールで、全体像を把握します。

2-1. top：プロは「%wa」と「ロードアベレージ」を見る

top

• load average： 過去1分、5分、15分の待ちプロセス数。CPUコア数を超えている場合は、処理が追い付いていない（飽和）状態です。
• %wa (I/O Wait)： ディスクの読み書き待ちでCPUが暇をしている時間。ここが高い場合、CPU性能ではなく「ディスク性能」がボトルネックです。
• %si (Software Interrupts)： ネットワーク処理の負荷。DDoS攻撃や大量のパケット受信時に高くなります。

2-2. vmstat：システム全体の統計を一目で把握

# 1秒おきに統計を表示
vmstat 1

• r (runnable)： 実行待ちのプロセス数。ここがコア数を超え続けると深刻なCPU不足です。
• b (blocked)： I/O待ちでスリープしているプロセス数。
• si / so (swap in/out)： スワップが発生しているか。ここが 0 以外で頻繁に動いているなら、物理メモリ不足で低速なディスクに頼っている証拠です。

2-3. ss：ネットワークの詰まりを特定

# 接続待ち（Listen）状態のポートとプロセスを表示
sudo ss -tlpn

AlmaLinux 10では netstat ではなく ss コマンドが標準です。接続数が多い場合に ss の方が圧倒的に高速に動作します。

---

3. AlmaLinux 10の真価：eBPFとbcc-toolsによる可視化

従来のツールでは「ディスクI/Oが遅い」ことはわかっても、「どのプロセスが、どのファイルに対して、何ミリ秒かかったのか」という詳細までは追えませんでした。これを可能にするのがeBPFです。

AlmaLinux 10では、カーネルを安全にトレースできるeBPFを利用した bcc-tools や bpftrace が強力にサポートされています。

bcc-toolsの導入と活用

# ツールのインストール
sudo dnf install -y bcc-tools

# ディスクI/Oのレイテンシ（遅延）をヒストグラムで表示
sudo /usr/share/bcc/tools/biolatency

# 特定のプロセスがどのファイルを読み書きしているかリアルタイム監視
sudo /usr/share/bcc/tools/filetop

---

4. 現場の流儀：持続的な監視とアラート設計

コマンドでの調査は「点」の監視です。プロはこれを「線」にするために、監視エージェントを導入します。

4-1. CockpitによるGUI監視

AlmaLinux 10には、標準でブラウザベースの管理画面 Cockpit が用意されています。

# Cockpitの有効化
sudo systemctl enable --now cockpit.socket
# ポート 9090 を firewalld で許可
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload

ブラウザで https://サーバーIP:9090 にアクセスすると、CPUやメモリの履歴がグラフで確認できます。コマンドに不慣れなチームメンバーとの情報共有に最適です。

4-2. 閾値の設定

監視において最も難しいのが「どこからが異常か」の定義です。

• CPU： 80%以上が継続。
• メモリ： 空き容量（free + buffer/cache）が10%以下。
• ディスク： 使用率 90%超過（ログ肥大化やバックアップ失敗の予兆）。

これらを基準に、死活監視（ping）だけでなく「リソース監視」を組み合わせるのが現場の鉄則です。

---

5. まとめと次回予告

第7回、お疲れ様でした！サーバーの「声」を聴く準備が整いました。

• USEメソッド に基づき、使用率・飽和度・エラーを体系的に調査する。
• top/vmstat で全体を俯瞰し、%wa や swap からボトルネックを推測する。
• eBPF (bcc-tools) を活用して、カーネルレベルで低負荷かつ詳細なトレースを行う。
• Cockpit 等を使い、過去からの推移を可視化して異常を察知する。

さて、環境を構築し、守り、監視できるようになりました。連載も次がいよいよ最終回です。最後は、これまで学んだすべての技術を繋ぎ合わせ、エンジニアの最大の武器である「自動化」へと昇華させます。

次回の第8回は、「自動化とバックアップの極意編」です。シェルスクリプトによるバックアップ自動化と、cronによる定期実行。そして連載の総括をお届けします。完結編まで、あと一歩です！