ファストドクター株式会社のDatadog導入例と学びの共有
レビュー投稿日の情報になります
ファストドクター株式会社 / hi0314rn
メンバー / フロントエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
最終更新日投稿日
利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
よく使う主要機能をご覧ください | 51名〜100名 | 2023年12月 | B to B B to C |
利用機能 | よく使う主要機能をご覧ください |
---|---|
ツールの利用規模 | 51名〜100名 |
ツールの利用開始時期 | 2023年12月 |
事業形態 | B to B B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
弊社ファストドクター株式会社は患者様向けにオンライン診療・救急往診等の医療サービスプラットフォームを提供していますが、以下の点で課題感がありました。
技術的課題
断片的な監視体制
- AWSネイティブツール(CloudWatch)やsentryのみでの単一的なエラーの監視
- アプリケーションレベルの詳細な可視化不足
- 異なるサービス間での統一的な監視基準の欠如
障害対応の非効率性
- 問題発生時の原因特定に時間がかかる
- ログの分散により調査工数が増大
- 予兆的な異常検知の仕組み不足
スケーラビリティの限界
- 手動運用に依存した監視設定
- 新サービス追加時の監視設定の属人化
- パフォーマンス劣化の早期発見困難
組織的課題
- 開発速度とサービス品質のバランス: 高い開発速度を維持しながら、サービス品質も担保する必要性
- チーム間の情報共有: エンジニア以外のステークホルダーへの状況共有の困難
- 運用工数の増大: 監視・運用に関わる手動作業の負荷増
どのような状態を目指していたか
プロアクティブな運用
- 問題が顧客に影響する前の予兆検知
- 自動化されたアラートとエスカレーション
- データドリブンな意思決定支援
開発効率の向上
- 開発者が自分でサービスの状態を把握できる環境
- デプロイの影響を即座に可視化
- パフォーマンス改善のための具体的な指標提供
- IaCとしてTerraformを使ったオブザーバビリティ環境の一元的な管理
比較検討したサービス
監視ソリューションとして以下のサービスを検討しました:
サービス | 特徴 | 強み | 懸念点 |
---|---|---|---|
Datadog | 統合監視プラットフォーム | APM、ログ、インフラ監視の統合性 | コスト |
New Relic | APM中心の監視サービス | アプリケーション監視の充実 | UI/UX |
Grafana + Prometheus | オープンソースソリューション | 低コスト、カスタマイズ性 | 運用工数、学習コスト |
AWS CloudWatch + X-Ray | AWSネイティブ | 既存環境との親和性 | 機能の限界、UI/UX |
比較した軸
1. 技術的要件(重要度:高)
- 統合性: インフラ、アプリケーション、ログの一元管理
- スケーラビリティ: サービス成長に対応できる拡張性
- API: 自動化・カスタマイズのためのAPI提供
2. 運用効率(重要度:高)
- 学習コスト: チームメンバーの習得容易性
- 設定の簡単さ: 初期設定から日常運用まで
- UI/UX: 直感的な操作性と見やすいダッシュボード
3. コスト(重要度:中)
- 初期コスト: 導入時の費用負担
- 運用コスト: 月額費用の予測可能性
- ROI: 投資対効果の見込み
4. サポート体制(重要度:中)
- ドキュメント: 充実した技術資料
- コミュニティ: 問題解決のための情報源
- 企業サポート: 導入支援・技術サポート
選定理由
統合性の高さ
- APM、インフラ監視、ログ管理、RUMが単一プラットフォームで完結
- 異なるデータソース間での相関分析が容易
優れたユーザビリティ
- 直感的なダッシュボード作成
- エンジニア以外のステークホルダーにも理解しやすいUI
強力なAPI・自動化支援
- TerraformによるIaCでの設定管理が可能
- CI/CDパイプラインとの連携が容易
成長への対応力
- エンタープライズレベルでの実績
- 段階的な機能追加による拡張性
導入の成果
改善したかった課題はどれくらい解決されたか
開発者体験の向上
- デプロイ後の影響確認が即座に可能
- パフォーマンス問題の特定が容易
- 開発フィードバックループの高速化
チーム間コミュニケーション改善
- 統一された指標によるステータス共有
- 非エンジニアにも理解しやすいダッシュボード
- データドリブンな議論の促進
導入時の苦労・悩み
既存システムとの統合
- 既存のCloudWatch設定との重複回避
- cloudwatchのログ情報はサイドカーでfirelensを導入してdatadogに転送してログ管理を一元化
- Prisma利用時はクエリの詳細が見えない
- TypeORMではpgを使っているのでデフォルトで見えるが、Prismaでは非対応のためOpenTelemetry経由での考慮する必要があり
- Next.jsでdd-tracerの初期化がうまくいかずAPMが動かない
- 複数環境での設定統一化
- 既存のCloudWatch設定との重複回避
メトリクス設計
- ビジネスKPIとの関連付け
- アラート閾値の適切な設定
- エラーログを見る会を定期的に開催して、まずいエラーログが出ていないか見直す必要があります。
- 不要なメトリクス収集によるコスト増
導入に向けた社内への説明
上長・チームへの説明
- マイクロサービスを推進しているため、Datadogのように各サービス間の通信が直感的にわかるようなUI/UXのサービスを入れた方が良い
- 費用は高い部分があるが、オブザーバビリティ全体を一元化できクイックな対応によりエンジニア工数を削減できるため導入するべき
活用方法
よく使う機能
1. APM (Application Performance Monitoring)
使用場面:
- API エンドポイント毎のパフォーマンス分析
- データベースクエリの最適化
- 外部API呼び出しの監視
2. Infrastructure Monitoring
監視対象:
- ECS タスクのCPU・メモリ使用率
- RDS の接続数・クエリパフォーマンス
3. Log Management
ログ集約・分析:
- アプリケーションエラーログの集約
- セキュリティイベントの監視
- ユーザー行動ログの分析
- エラーログ時のslack即時通知
4. Real User Monitoring (RUM)
フロントエンド監視:
- ページロード時間の監視
- エラーの追跡
- ユーザー操作フローの分析
- RUM + APMを統合したフロントエンド、バックエンド横断的なログ分析
5.SLO
- アプリケーションのSLO監視
ツールの良い点
1. 統合性・一元管理
メリット:
- 複数のデータソースからの情報を単一画面で確認可能
- 関連性のあるメトリクス間での相関分析が容易
- 学習コストの最小化(複数ツールの習得不要)
2. 優れたユーザビリティ
具体例:
- 直感的なダッシュボード作成UI
- ドラッグ&ドロップでのウィジェット配置
- リアルタイムでのメトリクス表示
3. 強力な自動化・API
活用例:
- Terraform による設定のコード化
- APIを活用したカスタム統合
- アラートルールの自動生成
4. スケーラビリティ
実証例:
- サービス成長に伴うメトリクス増加への対応
- 新環境追加時の監視設定自動化
- チーム拡張時の権限管理スケール
ツールの課題点
1. コスト面の課題
現状の課題:
- 月額費用の予測困難性(使用量ベース課金)
- 機能追加に伴うコスト増加
- 小規模チームには高コスト
対策:
- メトリクス使用量の定期モニタリング
- 不要な機能の段階的停止
- コスト効率の良い代替手段の併用
2. 学習コストの高さ
課題:
- 高度な機能活用のための専門知識要求
- 効果的なダッシュボード設計スキル
- アラート設定の最適化知識
改善策:
- 社内トレーニングプログラム実施
- ベストプラクティス共有
- 段階的機能習得アプローチ
3. カスタマイズ性の限界
制約例:
- 特定業界向け機能の不足
- 独自メトリクスの表示制限
- レポート形式のカスタマイズ限界
ツールを検討されている方へ
導入成功のためのポイント
1. 段階的導入の重要性
- 一度にすべての機能を導入しない
- 各フェーズでの効果確認・調整
- チームの学習ペースに合わせた展開
2. 組織準備の重要性
事前準備チェックリスト:
- 現状課題の明確化・定量化
- 導入目標・成功指標の設定
- ステークホルダーの合意形成
- 予算・リソース計画の策定
- トレーニング計画の作成
3. コスト管理戦略
推奨手法:
- パイロット期間の設定: 小規模での効果検証
- 段階的機能追加: 必要性に応じた機能拡張
- 定期的な利用状況レビュー: 月次でのコスト最適化
- 代替手段との併用: オープンソースツールとの使い分け
失敗を避けるための注意点
1. 過度な完璧主義の回避
よくある失敗:
- 完璧な監視設定を最初から求める
- すべてのメトリクスを収集しようとする
- 複雑なアラートルールの初期設定
対策:
- 最重要指標から順次設定
- 最初からSLOを厳しくすると運用が大変になるので緩い値から初めて、徐々に調整していくのが良い
- シンプルなアラートルールから開始
- 運用しながらの継続改善
2. チーム巻き込み不足
リスク:
- 特定メンバーのみの理解・活用
- 組織的な活用文化の未定着
- 投資効果の限定的実現
対策:
- 全チームメンバーへのトレーニング
- 定期的な活用状況共有とナレッジベース化
今後の展望
Datadog MCP serverを利用したオブザーバビリティの改善
ファストドクター株式会社 / hi0314rn
メンバー / フロントエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
ファストドクター株式会社 / hi0314rn
メンバー / フロントエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名