Datadogで支えるQastのObservability

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

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

any株式会社 / Shogo Arakawa

チームリーダー / フルスタックエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名

最終更新日2025/02/12投稿日2025/02/12

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
Datadog Pro	APM, Error Tracking, Monitors, Cloud SIEM, ASM, Logs	11名〜50名	2023年4月	B to B

利用プラン	Datadog Pro
利用機能	APM, Error Tracking, Monitors, Cloud SIEM, ASM, Logs
ツールの利用規模	11名〜50名
ツールの利用開始時期	2023年4月
事業形態	B to B

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

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

大前提としてトリッキーなことをせずに、公式マニュアル通りに設計を進めていくプラクティス通りの設計を心がけています。ベンダーロックインを防ぐために、Datadogにのみ連携する情報はできる限り無くすように工夫をしています。弊社はAWSを中心としたアプリケーションを構築しているため、CloudWatchなど標準的な仕組みを基本としながらも、追加でDatadogへ連携するということは重要視しています。

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

導入背景

ツール導入前の課題

弊社プロダクトのQastにおいては、AWSのFargateのアプリケーションとして主要なアプリケーションは構築されています。以前はEC2で構築していましたが、リアーキテクチャを経て、現在の構成になっています。また、これまで監視ツールとしてはMackerelを利用していましたが、CPUやメモリ使用率などのメトリクス監視に留まっていました。

リアーキテクチャを経てモノレポ構成のマイクロサービス化を推し進めてきましたが、MarkerelやAWSコンソールでのメトリクス監視、CloudWatch LogsをサブスクリプションフィルターでLambda経由でSlackにエラー通知するなどで、運用監視が徐々に苦労する場面が増えてきました。加速するマイクロサービス化にともなってObservabilityを強化していく必要性を強く感じ、Datadog導入の検討を開始しました。

どのような状態を目指していたか

マイクロサービスの分散アプリケーションにおいて、バグの原因やパフォーマンス問題を深く調査できる状態
- 調査の結果「原因がわからない」といった状況をできる限りなくすこと。問題が発生したときにログを仕込む必要を減らしたり、ログを仕込まずとも原因が把握できる状況を作り上げること
インフラ監視をMackerelから完全移行できる状態
- インフラ監視に限らず、前述したアプリケーションのトレースがうまく統合できること

比較検討したサービス

Sentry

フロントエンドのトレース目的では、著名なSentryが選択肢の一つとしてあがったため、Datadogと同時並行で導入を検討しました。フロントエンドで発生したエラーの集約やSession Replyなどの機能は非常に便利な一方で、バックエンドにかかわる運用監視についてはやや機能面が不足している印象でした。

最終的にブラウザ経由のエラーについてはSentryで集約し、バックエンドやインフラに関するエラーやメトリクスなどはDatadogに集約する形になっています。

Mackerel

すでに導入済みで、Datadogと比較してもシンプルな構成で一定期間の実績もありましたが、APMなどのより高度な機能を利用したいと考えて、移行に踏み切りました。現時点でもすべてを移行しきれてはいませんが、完全移行を推進しています。

選定理由

APM（アプリケーションのトラッキング）単体で利用可能なため、スモールスタートで開始できたことです。またDatadogには日本法人があるため、料金プランなどを相談しながら進められたことは非常に助かりました。もちろん日本語でコミュニケーションが可能であるため、導入を検討をしている場合、まずは相談することをオススメします。

導入の成果

改善したかった課題はどれくらい解決されたか

分散アプリケーションのトレーシングや、バックエンドで発生するエラー集約によって、本番環境のトレーサビリティやデバッグ環境は大きく向上しました。エラーやアラートが発生したときに、まずはDatadogに確認する状況を作れたことは、弊社プロダクトのQastの品質向上に大きく寄与していると思います。

アプリケーションのトレースと、インフラのメトリクス監視を統合したことにより、「このメモリ使用率が上昇したのは、このエンドポイントで意図せぬSQLが実行されたためである」などと一貫した調査が可能になった点は特にありがたいです。完全に移行はしきれていませんが、Mackerel脱却まであと一歩という段階まで利活用が進んでいます。

また、開発環境やステージング環境においても、DatadogのAPMやメトリクスを利用することで、パフォーマンス検証や負荷検証が容易になった点で、思わぬ収穫でした。

導入時の苦労・悩み

Datadogでは「オンデマンド」と「月額コミット制」がありますが、後者のコミット制のほうが安くなるため、大前提は先方と利用予定の範疇で契約を結ぶことになります。ただ導入初期は、利用を推進するごとに、あれもこれも利用してみたいという要望が次々と湧いてくるため、頻繁に上長に相談する必要性があります。幸いにも弊社は理解のある上長だったため、コミュニケーションコストはほとんどかかりませんが、それでも毎月のコストや契約については、苦労が多いと思われます。

また、Datadogを実装したことのある経験者がいなかったため、普段のプロジェクトの業務を進めるなかで、必要な工数を読みきれない点は非常に苦労しました。しかしながら、この時期に強度高く試行錯誤をしたおかげで、現在活用が大きく進んでいるため、ある程度「慣れる」時間が求められるはずです。

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

上長・チームへの説明

比較的ツール導入に関しての理解のある上長のため、大きな苦労はしていませんが、まずはスモールスタートで、月2万円程度で始められるAPMやインフラ監視などの機能から導入しました。一定の時間と労力をかけて、検証を進めたことにより、導入したことによる既存バグ改修、パフォーマンス問題の解消、外形監視の重要性などのメリットを明確に打ち出すことができました🎉

それらの導入効果を上長やチームにしっかり伝えることでDatadogの必要性の理解が進み、必要性をより強く上長やチームに定着させることができ、プロダクトに問題が生じたときに、「まずはDatadogで確認する」文化を定着させることができました。また教育の一環として『🐶Datadog虎の巻』という社内ドキュメントを作成し、各メンバーへの周知を行うなどの工夫をするなど徹底しました。

活用方法

バグの検知、ダッシュボード、外形監視など、いわゆるDevOpsツールとして最大限活用を推し進めています。特定の問題が発生したタイミングで弊社のSlackへの通知も可能なため、普段の運用業務においても大いに活用をしています。また直近では、GitHubやCloudTrailなどの監査ログを集約するなど、開発にまつわる業務の運用ツールを統合しつつあり、非常に多角的なツールとして活用を推し進めています。

よく使う機能

Qastのバックエンドのアプリケーションのトレースを確認できる機能です。Fargateのサイドカーコンテナとしてのエージェント、またEC2のエージェントプロセスとして常駐させることで、アプリケーションのトレースを行うことができます。常駐させるプロセスから直接Datadogにトレース情報が送信されるため、リアルタイム性、情報の網羅性ともに非常に高く、最も有効活用している機能です。

DBM(Database Monitoring)

弊社ではMySQL on RDSをデータストアとして採用していますが、スロークエリやコネクション数などをDBMを利用することでリアルタイムで監視しています。固有のパラメータやメタデータなども非常にこと細やかに取得できるため、日々のチューニング観点では大いに活用をしています。実際にDBMを導入したおかげで、負荷の高いクエリを削減でき、RDSのインスタンスタイプを落とすことにも成功しています🎉

Logs

CloudWatch Logs、CloudTrail、GitHubのAudit Log、SendGridのログなどを連携して統合させています。構造化ログにしておくことで自動で絞り込みやソートができるため、CloudWatch LogsのBetter UIとして利用できるほか、Error TrackingやMonitoringと連携できる点も非常に強いです。SendGridなどの外部ツールからのログも取り込むことができる点も非常に強力で、ログを集約できることで多角的に問題を特定することが容易になりました。

Error Tracking

動作するアプリケーションで発生したエラーを集約する機能です。ある機能のエラーを指定した期間で集約できるほか、あるデプロイから頻度が増加したなどに検知させることが可能です。いわゆるエラーログのみならず、APMが自動で検知したトレースなども取得できるため、非常に便利な機能になっています。

Monitoring

ダッシュボード機能、メトリクスの監視、Slackへのアラートなどを行っています。AWSのCloudWatchから取得した情報で、ECS、EC2、ALB、RDS、OpenSearchなど関連するサービスすべてを監視できる状態になっています。APMやAgentから取得できる情報と統合することもできます。

Cloud SIEM

もともとは利用を想定していなかったものの、社内セキュリティ向上の取り組みの一つとしてトライアルを経て、弊社で活用できると実感を得て導入をしました。GitHubやCloudTrailなどのAudit Log（監査ログ）を取り込むことで、不正なログを自動で検知してSlack通知を行っています。

例えば、AWSのRoot Userの意図せぬログイン試行やGitHubのリポジトリのダウンロードなどの不審な挙動が発生したときに自動で通知をしてくれます。Datadog側で規定したルールがのもとで危険度を自動で判断したうえで通知してくれるため、一度設定をしておけば「検知」については一任できるので、弊社のようにエンジニアメンバーが多くない状況でも、セキュリティを一定担保できるため有用です。

そのほか、弊社におけるDatadogの活用についてはSaaS開発のObservabilityを支えるDatadogも参考にしてください。

ツールの良い点

多機能かつ利用上で求める機能はほぼカバーされていること
新機能のリリースサイクルが早いため、プロダクトを触っていてワクワクすること
技術サポートの反応が迅速かつ丁寧であること

ツールの課題点

特定の人物に知見が集中しやすい

非常に高機能であるゆえに、特定の人に知見が集中してしまう点は難点です。学習コストも高めで、特に最初期は目的を達成するためにどの機能を利用するべきか理解が難しいです。

費用予測の難易度が高い

大前提はコミット利用を前提とはしているものの、新機能の追加やWeb画面からの機能有効化などによって、予期せぬ費用が発生することがあります。日本法人のアカウントマネージャーと密に連携することをオススメします。

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

Datadogは非常に多機能ゆえに、つかみどころも難しく、導入へのハードルが高いツールかと思います。金銭的にも格安のツールとはいえないため、もしトライアルを検討する場合は、一定コミットする前提で試行錯誤をすることをオススメします。ただし、これらを補うほどの強力な機能群があり、困ったことは大抵解決できる程度の多機能さは間違いなくあります。