CLINICSの信頼性を守るDatadog 導入・活用事例(株式会社メドレー)

参考になった

レビュー投稿日の情報になります

株式会社メドレー / 大塚匡紀

EM / テックリード / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名

最終更新日2025/08/26投稿日2025/08/29

ツールの利用規模

ツールの利用開始時期

事業形態

101名〜300名

2020年

B to B

B to C

ツールの利用規模

101名〜300名

ツールの利用開始時期

2020年

事業形態

B to B

B to C

アーキテクチャ

アーキテクチャの意図・工夫

アーキテクチャの意図

電子カルテを中心とした医療機関向け SaaS である CLINICSにおいて、Datadog を中心に位置付け、主に APM、RUM、SLO、Dashboard を活用しています。しかし、すべての機能を Datadog に集約するのではなく、各領域で最適なツールを組み合わせる戦略をとっています。

具体的には、アプリケーションのエラートラッキングには長年利用し開発プロセスに深く根付いている「Sentry」を使用、緊急性の高いインシデント管理には「PagerDuty」を併用。さらに、一部インフラリソースの監視には AWS の「CloudWatch Logs」も活用し、それぞれのツールの強みを活かした構成を築いています。

導入の背景・解決したかった問題

導入背景

プロダクトの特性・チームの状況

メドレーが提供する医療機関向け SaaS である CLINICS は、電子カルテ・レセコンといった医療機関における基幹システムに加え、予約・問診・オンライン診療といった周辺業務の効率化を支援するシステムです。日々の運営に不可欠なサービスであるため、システムには極めて高い信頼性と安定性が求められます。

CLINICS では横断組織の SRE チームだけでなく、プロダクト開発チームもローテーションで監視・運用に参加する体制を構築し、開発者全員でサービスの品質に向き合う文化を、Datadog と共に築いています。

ツール導入前の課題

Datadog を導入した 2020 年頃、私たちが向き合った主な課題は以下の通りです。

属人化し、非効率的だったアラート対応:
- 監視ツールとして Amazon CloudWatch、New Relic、Sentry などを併用していましたが、アラート対応はチーム全体で標準化されておらず、特定のサービスに詳しいエンジニアの個人スキルに依存している状態でした。
兆候を掴めないリアクティブな監視:
- モニタリング自体は行っていたものの、その中心はインフラリソースの負荷状況などで、問題が発生した場合には事後対応になりがちでした。
- ユーザーへの影響が出る前に問題の兆候を掴み、プロアクティブに対処する体制が築けていませんでした。
勘に頼ったパフォーマンス改善:
- 「なんとなくここが遅い気がする」という感覚だけで改善を進め、効果測定が十分できていない状況でした。

比較検討したサービス

導入当時は New Relic を利用していましたが、チームとプロダクトの拡大に伴い、ツールの見直しを行いました。選定において重視したのは「コストパフォーマンス」と「開発チーム全体で活用する上での学習コストの低さ」です。プロダクトチーム自身へのオンボーディングを素早くこなし、チーム全体で監視の文化を育てるポテンシャルが重要でした。

その点で、高い拡張性とコストパフォーマンス、直感的なUI/UXによりチームへの浸透が期待できるDatadogが我々のニーズに最も合致すると判断し、移行を決定しました。

導入の成果

Datadog の導入は、我々の開発文化に 2 つの大きな変化をもたらしました。それは、「アラート対応の民主化」と「パフォーマンス改善の自律化」です。これにより、かつてのヒーロー頼りの体制から、プロダクトチーム自身が品質のオーナーとなる体制へと大きく前進しました。

成果 1：アラート対応の民主化

かつて一部のエンジニアに依存していたアラート対応は、プロダクトチームの開発者自身が自走できる体制へと変わりました。

Slack にアラートが通知されると、担当プロダクトチームの開発者が自ら Datadog の APM 画面を開き、エラーの継続性やエラーレートを解析します。「このエラーは今も継続しているか？」「影響範囲はどれくらいか？」といった初期調査を迅速に完了させることで、障害の深刻度を判断し、冷静な初期対応が可能となりました。

成果 2：パフォーマンス改善の自律化

APM は、プロダクトチームにまるで「透視能力」のような力を与えてくれました。開発者は、担当機能のパフォーマンス劣化やボトルネックを、SRE に頼ることなく特定できるようになりました。

この自律的な改善サイクルを支えているのが、週次のパフォーマンスレビューです。開発チームは毎週、専用のダッシュボードで先週比のパフォーマンス（レイテンシ、エラーレート等）を定点観測することで、緩やかな性能劣化も確実に捉え、データに基づいた品質管理を文化として定着させています。さらに、APM のトレースとContinuous Profilerの情報を組み合わせることで、ボトルネック調査はより一層、効率的になりました。

活用方法

Datadog の真価は、SRE だけでなくプロダクトチームを含む全開発者が日常的に活用している点にあります。私たちは主に APM、Metrics、RUM、Dashboards、そして SLO といった機能を駆使しています。

これらの機能を組み合わせ、システムの状況を俯瞰できるダッシュボードを作成し、日々のパフォーマンスをモニタリング。アラート発生時の迅速な対応や、リリース後のパフォーマンス比較に役立てています。また、SLO の導入も進めており、Datadog 上で SLI の計測からエラーバジェットの管理までを行っています。

導入に向けた社内への説明

上長・チームへの説明

導入の意思決定にあたり、経営層やチームメンバーには以下の点を中心に説明し、合意形成を図りました。

投資対効果の明確化: 「障害調査やパフォーマンス改善にかかる工数を削減でき、長期的には生産性向上によって十分な ROI が見込める」
事業成長への貢献: 「サービスの複雑化が進む中で、システム全体の依存関係を可視化し、安定性を担保する統合監視基盤は不可欠である」
属人化解消とチーム力向上: 「特定の個人スキルに依存する体制から脱却し、チーム全体で品質と向き合う文化を醸成するために必要な投資である」

活用方法

よく使う機能

APM / Continuous Profiler / RUM / Monitor / Dashboard / SLI・SLO

ツールの良い点

圧倒的な統合性: インフラ、バックエンド、フロントエンドの情報を単一プラットフォームで横断的に分析できる点が強みです。
強力な IaC 連携: 公式の Terraform Provider が提供されており、モニターやダッシュボードをコードで管理できます。CLINICS でも一部を Terraform で管理し、再現性の高い構成を実現しています。

ツールの課題点

全てを使いこなすにはそれなりの学習コストが必要: Datadog は多機能なため、0 から 1 で最適な監視の仕組みを構築するには相応の学習時間が必要です。ただし、一度仕組みが整えば、その後のチームへのオンボーディングはスムーズに進められます。
複雑な料金体系とコスト管理: 料金体系が複雑で、特に APM の Span 数など、利用量に基づいた正確なコスト試算が難しい点は課題です。意図しないコスト増を防ぐため、常に利用状況を意識する必要があります。
既存ツールとの棲み分け: エラートラッキングに関しては Sentry に特化した実装が既にあり、移行コストの観点から現在も併用しています。全ての機能を Datadog に集約することが必ずしも最適解とは限りません。

ツールを検討されている方へ

小さく始める: Datadog は多機能ですが、最初から全てを使いこなそうとすると、その多機能さの罠にハマりがちです。まずは APM だけでも導入してみるなど、最も課題を感じている領域からスモールスタートすることをお勧めします。
文化を育てる: 優れた監視の仕組みが一度できあがれば、それを軸に開発者全員を巻き込んだ監視文化を育てることが可能です。Datadog は、そのための共通言語となり得ます。
将来の拡張性を見据える: Datadog の多機能さは、将来の事業成長やチームの変化に合わせて監視体制を拡張していく上での大きな強みとなります。長期的な視点で、自社の成長に合わせて活用範囲を広げていく計画を持つと良いでしょう。