ストーリー

プラットフォームアーキテクチャの全体像

レイヤー構成

┌─────────────────────────────────────────────────────┐
│                   消費レイヤー                        │
│  ダッシュボード │ アラート │ 分析 │ レポート           │
├─────────────────────────────────────────────────────┤
│                   分析レイヤー                        │
│  クエリエンジン │ 相関分析 │ 異常検知 │ ML基盤        │
├─────────────────────────────────────────────────────┤
│                  ストレージレイヤー                    │
│  メトリクスDB │ ログストア │ トレースDB │ 長期保管     │
├─────────────────────────────────────────────────────┤
│                   処理レイヤー                        │
│  フィルタリング │ サンプリング │ エンリッチメント      │
├─────────────────────────────────────────────────────┤
│                   収集レイヤー                        │
│  OTel Collector │ エージェント │ API受信              │
├─────────────────────────────────────────────────────┤
│                   計装レイヤー                        │
│  自動計装 │ 手動計装 │ SDK │ ライブラリ               │
├─────────────────────────────────────────────────────┤
│                   ソースレイヤー                      │
│  アプリケーション │ インフラ │ ネットワーク │ 外部SaaS │
└─────────────────────────────────────────────────────┘

計装（Instrumentation）戦略

OpenTelemetryを標準計装に

計装の階層

計装例（Go + OpenTelemetry）:

// 自動計装: HTTPサーバーのミドルウェア
handler = otelhttp.NewHandler(handler, "api-service")

// ビジネス計装: カスタムスパン
ctx, span := tracer.Start(ctx, "process-payment")
defer span.End()
span.SetAttributes(
    attribute.String("payment.method", method),
    attribute.Float64("payment.amount", amount),
)

// カスタムメトリクス
paymentCounter.Add(ctx, 1, metric.WithAttributes(
    attribute.String("status", "success"),
))

アーキテクチャパターン

パターン1: 集中型（Centralized）

全サービス → OTel Collector → 単一バックエンド
                                (例: Datadog, Grafana Cloud)

適用: 中小規模の組織（サービス数30以下）

パターン2: 分散型（Distributed）

全サービス → OTel Collector → ルーティング → メトリクス: Prometheus/Mimir
                                           → ログ: Loki
                                           → トレース: Tempo
                              → 統合可視化: Grafana

適用: 大規模な組織、OSSを好む組織

パターン3: ハイブリッド型（Hybrid）

全サービス → OTel Collector → ルーティング → SaaS（メイン分析）
                                           → OSS（長期保管・コスト最適化）
                                           → 別SaaS（特定ユースケース）

適用: 大規模組織、コスト最適化が重要な組織

ツール選定の評価フレームワーク

「ツール選定で最もよくある失敗は”機能比較表”だけで決めることだ。TCO（総所有コスト）、運用工数、組織のスキルセット、将来の拡張性。これらを含めた総合評価が必要だ」 — 田中VPoE

まとめ

チェックリスト

• 7層のプラットフォームアーキテクチャを理解した
• OpenTelemetryを標準計装とする理由を理解した
• 3つのアーキテクチャパターンの特徴と適用基準を理解した
• ツール選定の評価フレームワークを理解した

次のステップへ

次は「データ収集パイプライン」を学びます。テレメトリデータをどのように効率的に収集し、処理するかの設計手法を身につけましょう。

推定読了時間: 30分