EXERCISE 90分

ストーリー

田中VPoE
プラットフォームアーキテクチャ、データ収集、ストレージ、可視化 — 4つの要素を学んだ。これを統合してTaskFlow社の可観測性プラットフォームを設計してもらう
あなた
Step 1の評価結果を踏まえた設計ですね
田中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: アーキテクチャ設計

要件

以下を設計してください。

  1. アーキテクチャパターンの選定(集中型/分散型/ハイブリッド型)と選定理由
  2. 全体アーキテクチャ図(テキストベース)
  3. 計装戦略(言語別の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-nodeHTTP, Express対応Next.js カスタム計装
Gogo.opentelemetry.io/otelEcho ミドルウェアgRPC interceptor
Pythonopentelemetry-pythonFastAPI, Airflow対応カスタムスパン追加
Javaopentelemetry-java-agentSpring Boot自動計装-javaagent方式
Kotlin/SwiftFirebase Performance + OTelモバイルSDKクラッシュレポート統合

Mission 2: データ収集・ストレージ設計

要件

以下を設計してください。

  1. サンプリング戦略(テイルサンプリングポリシー)
  2. ログ標準フォーマット(必須フィールド一覧)
  3. データティアリング設計(Hot/Warm/Cold/Archive)
  4. コスト見積もり(年間TCO)
解答例

サンプリング戦略

ポリシー条件サンプリング率理由
エラー保持HTTP 5xx or OTel status ERROR100%エラー分析に必須
遅延保持レイテンシ > 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日Datadog130万円
Warm集約メトリクス、重要ログ30日Datadog40万円
Coldダウンサンプリングメトリクス90日S3 + Athena5万円
Archiveコンプライアンスログ3年S3 Glacier1万円

年間TCO

項目現在移行後差分
Datadog1,800万円2,200万円+400万円(全チーム統合)
ELK Stack600万円0円-600万円
CloudWatch300万円100万円-200万円(最小限に)
Firebase120万円120万円±0
Jaeger200万円0円-200万円
S3長期保管0円70万円+70万円
合計3,020万円2,490万円-530万円

Mission 3: 可視化・移行計画

要件

以下を設計してください。

  1. ダッシュボード体系(4層の具体的なダッシュボード一覧)
  2. 移行ロードマップ(3フェーズ、チーム別の移行順序)
  3. リスクと緩和策
解答例

ダッシュボード体系

ダッシュボード名主要パネル対象者
L1Company OverviewSLA達成率、ビジネスKPI、インシデントサマリー経営層
L2[Service]-SLOSLI/SLO状態、エラーバジェット、REDメトリクスチームリード
L2Platform Health全サービスSLO一覧、依存関係マップSRE
L3InfrastructureKubernetes/ECS/Lambda リソース、USEメトリクスSRE・オンコール
L3On-Callアクティブアラート、変更履歴、比較ビューオンコール担当
L4Exploreログ検索、トレース検索、メトリクスクエリ開発者

移行ロードマップ

フェーズ期間対象チームアクション
Phase 1月1-3SRE + APIOTel導入、Datadog統合、ログ標準化、パイロット運用
Phase 2月4-6課金 + Web + 通知OTel導入、ELK→Datadog移行、ダッシュボード標準化
Phase 3月7-9検索 + データPF + モバイルOTel導入、CloudWatch最小化、Jaeger廃止、全体統合

リスクと緩和策

リスク影響度緩和策
移行中のデータ欠損並行運用期間を設け、新旧両方にデータ送信
OTel導入によるパフォーマンス影響ステージング環境で性能テスト後に本番導入
チームの学習コスト段階的な研修プログラムとハンズオン
Datadog費用の増加コミットメントプラン交渉、サンプリング最適化
レガシーサービスのOTel対応困難プロキシ方式でのテレメトリ収集

達成度チェック

観点達成基準
アーキテクチャパターン選定理由が組織の制約に即している
計装全言語のOTel導入計画が具体的に示されている
コスト現状と移行後のTCO比較が定量的に示されている
可視化4層のダッシュボード体系が設計されている
移行フェーズ分けされた現実的なロードマップが提示されている
リスク主要リスクと緩和策が特定されている

推定所要時間: 90分