ストーリー
高橋アーキテクトがサービスマップを表示した。ノードとエッジで構成されたグラフに、リクエスト数やエラー率がリアルタイムで表示されている。
サービスマップとは
サービスマップは、トレースデータから自動生成されるサービス間の依存関係図です。
┌───────────┐
│ Client │
└─────┬─────┘
│ 1200 req/s
▼
┌───────────┐
│API Gateway│
│ 0.1% err │
└─────┬─────┘
┌──────┼──────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ Auth │ │ Order │ │ Notification │
│ Service │ │ Service │ │ Service │
│ 0.0% err │ │ 0.3% err │ │ 0.1% err │
└──────────┘ └────┬─────┘ └──────────────┘
┌────┼────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│Inventory │ │ Payment │
│ Service │ │ Service │
│ 0.1% err │ │ 2.5% err │ ← 問題あり!
└──────────┘ └────┬─────┘
│
▼
┌──────────┐
│ Stripe │
│ (外部) │
└──────────┘
サービスマップから読み取れる情報
1. 依存関係の方向
// トレースデータから依存関係を抽出
interface ServiceDependency {
source: string; // 呼び出し元
destination: string; // 呼び出し先
requestRate: number; // リクエスト率 (req/s)
errorRate: number; // エラー率 (%)
p99Latency: number; // P99レスポンスタイム (ms)
}
const dependencies: ServiceDependency[] = [
{ source: 'api-gateway', destination: 'auth-service', requestRate: 1200, errorRate: 0.0, p99Latency: 30 },
{ source: 'api-gateway', destination: 'order-service', requestRate: 450, errorRate: 0.3, p99Latency: 350 },
{ source: 'order-service', destination: 'payment-service', requestRate: 200, errorRate: 2.5, p99Latency: 3200 },
{ source: 'payment-service', destination: 'stripe-api', requestRate: 200, errorRate: 3.0, p99Latency: 3000 },
];
2. 障害の影響範囲の予測
Stripe API が障害 → Payment Service に影響
→ Order Service に影響 → API Gateway に影響 → 全ユーザーに影響
Notification Service が障害 → API Gateway の一部に影響
→ 注文は成功するが通知が届かない(影響は限定的)
3. クリティカルパスの特定
// 最も遅延に寄与しているパスを特定
interface CriticalPath {
path: string[];
totalLatency: number;
bottleneck: string;
}
const criticalPath: CriticalPath = {
path: ['api-gateway', 'order-service', 'payment-service', 'stripe-api'],
totalLatency: 3500,
bottleneck: 'stripe-api (3000ms)',
};
ツールによるサービスマップの可視化
Jaeger DAGビュー
Jaegerは収集したトレースから自動的にDAG(有向非巡回グラフ)を生成します。
Grafana + Tempo
Grafana → Service Graph パネル → Tempoのトレースデータからサービスマップを自動生成
AWS X-Ray
AWS X-Ray → Service Map → AWSサービスとの依存関係も含めた自動マップ生成
サービスマップの活用パターン
| パターン | 説明 | 例 |
|---|---|---|
| 障害影響分析 | 障害サービスの下流への影響を予測 | Payment障害→注文不可 |
| 変更影響分析 | デプロイ前に影響範囲を確認 | Auth変更→全サービスに影響 |
| パフォーマンス分析 | クリティカルパスのボトルネック特定 | Stripe API遅延 |
| 設計レビュー | 不要な依存関係の発見 | 循環依存の検出 |
| キャパシティプランニング | 高負荷サービスの特定 | API Gatewayの1200 req/s |
依存関係の健全性チェック
// サービスマップから検出すべき問題パターン
interface DependencyHealthCheck {
// 循環依存の検出
circularDependency: {
check: 'A → B → C → A のような循環がないか';
severity: 'critical';
};
// 単一障害点の検出
singlePointOfFailure: {
check: '特定サービスが多くのサービスに依存されていないか';
severity: 'warning';
example: 'Auth Serviceが全サービスから呼ばれている';
};
// 外部依存の脆弱性
externalDependencyRisk: {
check: '外部APIへの依存にフォールバックがあるか';
severity: 'warning';
example: 'Stripe API障害時の代替手段';
};
// 深い呼び出しチェーン
deepCallChain: {
check: '呼び出しの深さが5段以上になっていないか';
severity: 'info';
impact: 'レイテンシの累積、障害伝搬リスク';
};
}
まとめ
| ポイント | 内容 |
|---|---|
| サービスマップ | トレースから自動生成されるサービス間依存関係図 |
| 読み取れる情報 | 依存方向、リクエスト率、エラー率、レイテンシ |
| 活用 | 障害影響分析、変更影響分析、ボトルネック特定 |
| 健全性チェック | 循環依存、単一障害点、外部依存リスクの検出 |
チェックリスト
- サービスマップの役割と生成方法を理解した
- サービスマップから依存関係情報を読み取れる
- 障害影響分析にサービスマップを活用できる
- 依存関係の問題パターンを検出できる
次のステップへ
次は「パフォーマンスボトルネックの特定」を学びます。トレースデータを使って、具体的にボトルネックを特定し解消する方法を見ていきましょう。
推定読了時間: 40分