ストーリー
田
田中VPoE
プラットフォームアーキテクチャ、データ収集、ストレージ、可視化 — 4つの要素を学んだ。これを統合してTaskFlow社の可観測性プラットフォームを設計してもらう
田
田中VPoE
そうだ。現状の7種類以上のツール乱立状態から、統合されたプラットフォームへの移行計画を含めた設計だ。技術的な正しさだけでなく、移行の現実性とコストの妥当性も重要だ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | 統合可観測性プラットフォーム設計書 |
| 想定時間 | 90分 |
| 成果物 | プラットフォーム設計書(アーキテクチャ + データ収集 + ストレージ + 可視化 + 移行計画) |
| 対象組織 | TaskFlow株式会社(Step 1と同一) |
前提条件
Step 1の演習で明らかになった状況に加え、以下の技術的制約があります。
技術的制約
インフラ環境:
クラウド: AWS(主要)、一部GCP(データPF)
コンテナ: ECS Fargate(API, 課金)、EKS(SRE管理の一部)
サーバーレス: Lambda(通知・連携)
VM: EC2(検索・分析、データPF)
開発言語:
TypeScript, Go, Python, Java, Kotlin, Swift
既存ツール(年間コスト3,020万円):
Datadog: 1,800万円
ELK Stack: 600万円
CloudWatch: 300万円
Firebase: 120万円
Jaeger: 200万円
Mission 1: アーキテクチャ設計
要件
以下を設計してください。
- アーキテクチャパターンの選定(集中型/分散型/ハイブリッド型)と選定理由
- 全体アーキテクチャ図(テキストベース)
- 計装戦略(言語別のOpenTelemetry導入計画)
解答例
アーキテクチャパターン: ハイブリッド型
選定理由:
- Datadog契約(年間1,800万円)が最大のコスト要因だが、課金・決済チームのAPM活用が成熟しており急な移行はリスクが高い
- ELK/Jaegerの自前運用(年間800万円)は運用負荷が高く、SaaS移行のメリットが大きい
- 長期データはS3ベースの低コストストレージで保持
全体アーキテクチャ
[アプリケーション]
├── TypeScript (Web) ── OTel SDK ──┐
├── Go (API) ────── OTel SDK ──────┤
├── Python (検索) ── OTel SDK ─────┤
├── Java (課金) ── OTel SDK ───────┤ [Agent Collector]
├── Lambda (通知) ─ OTel Layer ────┤───→ (各ホスト/Pod)
└── Kotlin/Swift ── OTel SDK ──────┘ │
↓
[Gateway Collector Cluster]
├── フィルタリング
├── テイルサンプリング
├── エンリッチメント
└── ルーティング
│
┌─────────────────┼────────────────┐
↓ ↓ ↓
[Datadog] [Grafana Cloud] [S3 + Athena]
(メイン分析) (一部チーム) (長期保管)
メトリクス ログ(Loki) アーカイブ
トレース(APM) メトリクス(Mimir) コンプライアンス
ログ
└─────────────────┼────────────────┘
↓
[Grafana]
(統合可視化)
計装戦略
| 言語 | OTel SDK | 自動計装 | 追加対応 |
|---|
| TypeScript | @opentelemetry/sdk-node | HTTP, Express対応 | Next.js カスタム計装 |
| Go | go.opentelemetry.io/otel | Echo ミドルウェア | gRPC interceptor |
| Python | opentelemetry-python | FastAPI, Airflow対応 | カスタムスパン追加 |
| Java | opentelemetry-java-agent | Spring Boot自動計装 | -javaagent方式 |
| Kotlin/Swift | Firebase Performance + OTel | モバイルSDK | クラッシュレポート統合 |
Mission 2: データ収集・ストレージ設計
要件
以下を設計してください。
- サンプリング戦略(テイルサンプリングポリシー)
- ログ標準フォーマット(必須フィールド一覧)
- データティアリング設計(Hot/Warm/Cold/Archive)
- コスト見積もり(年間TCO)
解答例
サンプリング戦略
| ポリシー | 条件 | サンプリング率 | 理由 |
|---|
| エラー保持 | HTTP 5xx or OTel status ERROR | 100% | エラー分析に必須 |
| 遅延保持 | レイテンシ > 2秒(P99相当) | 100% | パフォーマンス問題分析 |
| 課金サービス | service.name = payment-* | 50% | ビジネスクリティカル |
| ヘルスチェック除外 | url.path = /health* | 0% | ノイズ除去 |
| 通常トレース | その他すべて | 10% | コスト削減 |
推定削減効果: トレースデータ量75%削減
ログ標準フォーマット
{
"timestamp": "2026-03-04T10:30:00.123Z",
"level": "ERROR",
"message": "Payment processing failed",
"service.name": "payment-service",
"service.version": "1.5.2",
"environment": "production",
"trace_id": "abc123def456ghi789",
"span_id": "jkl012mno345",
"user_id": "usr_hash_xxx",
"error.type": "PaymentGatewayTimeout",
"error.message": "Gateway response timeout after 30s",
"http.method": "POST",
"http.url": "/api/v1/payments",
"http.status_code": 504
}
データティアリング
| ティア | データ | 保持期間 | ストレージ | 月間コスト概算 |
|---|
| Hot | 全メトリクス、直近ログ、トレース | 7日 | Datadog | 130万円 |
| Warm | 集約メトリクス、重要ログ | 30日 | Datadog | 40万円 |
| Cold | ダウンサンプリングメトリクス | 90日 | S3 + Athena | 5万円 |
| Archive | コンプライアンスログ | 3年 | S3 Glacier | 1万円 |
年間TCO
| 項目 | 現在 | 移行後 | 差分 |
|---|
| Datadog | 1,800万円 | 2,200万円 | +400万円(全チーム統合) |
| ELK Stack | 600万円 | 0円 | -600万円 |
| CloudWatch | 300万円 | 100万円 | -200万円(最小限に) |
| Firebase | 120万円 | 120万円 | ±0 |
| Jaeger | 200万円 | 0円 | -200万円 |
| S3長期保管 | 0円 | 70万円 | +70万円 |
| 合計 | 3,020万円 | 2,490万円 | -530万円 |
Mission 3: 可視化・移行計画
要件
以下を設計してください。
- ダッシュボード体系(4層の具体的なダッシュボード一覧)
- 移行ロードマップ(3フェーズ、チーム別の移行順序)
- リスクと緩和策
解答例
ダッシュボード体系
| 層 | ダッシュボード名 | 主要パネル | 対象者 |
|---|
| L1 | Company Overview | SLA達成率、ビジネスKPI、インシデントサマリー | 経営層 |
| L2 | [Service]-SLO | SLI/SLO状態、エラーバジェット、REDメトリクス | チームリード |
| L2 | Platform Health | 全サービスSLO一覧、依存関係マップ | SRE |
| L3 | Infrastructure | Kubernetes/ECS/Lambda リソース、USEメトリクス | SRE・オンコール |
| L3 | On-Call | アクティブアラート、変更履歴、比較ビュー | オンコール担当 |
| L4 | Explore | ログ検索、トレース検索、メトリクスクエリ | 開発者 |
移行ロードマップ
| フェーズ | 期間 | 対象チーム | アクション |
|---|
| Phase 1 | 月1-3 | SRE + API | OTel導入、Datadog統合、ログ標準化、パイロット運用 |
| Phase 2 | 月4-6 | 課金 + Web + 通知 | OTel導入、ELK→Datadog移行、ダッシュボード標準化 |
| Phase 3 | 月7-9 | 検索 + データPF + モバイル | OTel導入、CloudWatch最小化、Jaeger廃止、全体統合 |
リスクと緩和策
| リスク | 影響度 | 緩和策 |
|---|
| 移行中のデータ欠損 | 高 | 並行運用期間を設け、新旧両方にデータ送信 |
| OTel導入によるパフォーマンス影響 | 中 | ステージング環境で性能テスト後に本番導入 |
| チームの学習コスト | 中 | 段階的な研修プログラムとハンズオン |
| Datadog費用の増加 | 中 | コミットメントプラン交渉、サンプリング最適化 |
| レガシーサービスのOTel対応困難 | 低 | プロキシ方式でのテレメトリ収集 |
達成度チェック
| 観点 | 達成基準 |
|---|
| アーキテクチャ | パターン選定理由が組織の制約に即している |
| 計装 | 全言語のOTel導入計画が具体的に示されている |
| コスト | 現状と移行後のTCO比較が定量的に示されている |
| 可視化 | 4層のダッシュボード体系が設計されている |
| 移行 | フェーズ分けされた現実的なロードマップが提示されている |
| リスク | 主要リスクと緩和策が特定されている |
推定所要時間: 90分