はじめに
Webサービスを開発して公開した後、本当に難しいのは「安定して運用し続けること」です。
ユーザー数が増えると、API、データベース、外部サービス、フロントエンドなど、さまざまな場所で問題が発生する可能性があります。
例えば、
- APIのレスポンスが突然遅くなる
- 一部のユーザーだけエラーが発生する
- データベース負荷が急上昇する
- 外部APIとの通信が不安定になる
といった問題です。
こうした障害を素早く発見し、原因を特定するために重要になるのが Observability（オブザーバビリティ） です。
本記事では、Webサービス運用におけるObservabilityの基本と、ログ・メトリクス・トレースをどのように活用するかを紹介します。
KRCLUBでも、安定したデジタルサービスを運営するため、システム監視と継続的な改善を重要な技術テーマとして考えています。
1. Observabilityとは
Observabilityとは、システム内部で何が起きているのかを、外部から取得できる情報を使って理解できる状態を指します。
従来の監視では、
Server CPU > 90%
のような単純な異常検知が中心でした。
しかし、現在のWebサービスは複数のサービスやAPIで構成されることが多く、単純な監視だけでは原因を特定できないことがあります。
そこで、
Logs
+
Metrics
+
Traces
を組み合わせてシステム全体を観察します。
2. Observabilityの3つの基本要素
Logs
ログは、アプリケーション内部で発生したイベントを記録する情報です。
例：
2026-09-11 10:03:15 INFO User login success
2026-09-11 10:03:18 ERROR Database connection timeout
ログを見ることで、
- どの処理で
- いつ
- どのようなエラーが
発生したかを確認できます。
Metrics
Metricsは、システム状態を数値として記録するデータです。
代表例：
- CPU使用率
- メモリ使用率
- APIレスポンスタイム
- エラー率
- リクエスト数
例えば、
API Response Time: 820ms
Error Rate: 3.2%
CPU Usage: 74%
のように数値化することで、サービス状態の変化を把握できます。
Traces
Traceは、一つのリクエストが複数のサービスを通過する流れを追跡する仕組みです。
例：
Browser
↓
Frontend
↓
API Gateway
↓
User Service
↓
Database
どこで処理時間が長くなっているのかを特定しやすくなります。
3. ログは「構造化」する
ログを単純な文字列として保存すると、大量になったときに検索が難しくなります。
例えば、
User 193 login failed
よりも、
{
"level": "error",
"event": "login_failed",
"user_id": 193,
"service": "auth"
}
のようなStructured Loggingが便利です。
Node.jsでは、JSON形式でログを保存するライブラリを利用できます。
logger.info({
event: "user_login",
userId: user.id
});
これにより、
event = user_login
のような条件で検索できます。
4. 重要なメトリクスを設計する
監視項目を増やしすぎても、必要な情報を見つけにくくなります。
そのため、まず重要な指標を決めます。
Request Rate
一定時間内に何回リクエストされたか。
Error Rate
どれくらいエラーが発生しているか。
Latency
APIレスポンスにどれくらい時間がかかっているか。
Saturation
CPUやメモリなどのリソースが限界に近づいていないか。
例えば、
| Metric | 状態 |
|---|---|
| Request / sec | 820 |
| Error Rate | 0.8% |
| P95 Latency | 420ms |
| CPU Usage | 61% |
のようにダッシュボード化すると、サービス状態をすぐに確認できます。
5. 平均値だけではなくP95を見る
APIパフォーマンスを見るとき、平均値だけでは問題を見逃すことがあります。
例えば、
Average Response Time = 180ms
でも、一部のユーザーは2秒以上待っている可能性があります。
そこで利用されるのが、
- P50
- P95
- P99
などのPercentileです。
例えば、
P50 = 120ms
P95 = 650ms
P99 = 1400ms
の場合、一部のアクセスでレスポンスが大きく遅れていることが分かります。
Webサービスでは平均値だけでなく、P95やP99も確認することが重要です。
6. Distributed Tracing
マイクロサービス構成では、一つのユーザー操作が複数のサービス