Datadogで障害対応の高速化と開発効率を向上

ツール導入前の課題

検討当時は、現在のコンテナベースのメインプロダクトをリリースして1年ちょっと経過しておりプロダクトが本格的に成長フェーズに入るタイミングでした。
機能のリリースが加速し信頼性の要求が厳しいエンプラユーザも増え、可観測性の向上にむけて 監視手法やツールを試行錯誤している状態であり、ツールの分散とそれに伴う不具合調査の難しさが１つの課題となっていました。

それまで利用していたツールは以下の通りです。

• メトリクス監視：Cloudwatch
• ログ監視：Cloudwatch Logs、Amazon Athena/S3
• 外形監視：Cloudwatch synthetics Canary、Zabbix
• Agent監視(EC2)：zabbix

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

重視したポイントとしては以下の通り。

• 複数AWSアカウントの統合監視が可能か
• 機能の多様性、特にアプリケーションモニタリングに使用できるか
• インフラの知見のない開発者でも調査などに使うことができるか

特に「開発者が自分で調査し迅速に不具合の原因を特定できる」ことが重要でした。
SREの人数も少ないため、運用やサポートの手間が少なく開発者でも使いやすい手離れのよいツールを探していました。

• New Relic
• Prometheus、jmx_exporter、Micrometer

Datadogの決め手は以下の通りです。

• 複数AWSアカウントの監視を1つのDatadogアカウントに統合できること
• Logs、Metrics、APMなどの各種ログやメトリクスを組み合わせて分析できること
• 情報の集約性が高く、各環境のログを横串で検索・分析できること

例えば以下のような使い方ができます。

• 遅延が発生しているネットワークのログから、高負荷が発生していないか同時刻のコンテナリソースのメトリクスを確認する
• 同種の事象が他の本番環境(AWSアカウント)でも発生していないか、本番・開発環境すべてのログを横断して調査する

どのような成果が得られたか

• TTR(修復時間)の改善
  インシデント発生から原因特定までの時間を大幅に短縮
• 開発効率の向上
  開発中のパフォーマンス課題の発見や、リリース後の不具合調査工数を削減
• 監視基盤の運用コスト削減
  整備対象が集約されることにより、運用監視コストの削減
• 信頼性・品質意識の啓蒙
  ダッシュボードやSLOsによる信頼性の見える化と品質意識の向上

費用面は開発者工数削減で概ねトレードオフできているかと思います。
APMのFlameGraphを使うことでパフォーマンス課題が発生しているクラスやメソッドを一瞬で特定。原因箇所の調査にかかる
時間を大幅に削減することができるようになりました。

SkillnoteはアプリケーションのプラットフォームにAWS Fargate・AmazonAuroraを使用しています。
コンテナを監視するためにはDatadogAgentをアプリケーションに組み込んでビルドする必要があり、 最終的には以下のCI/CDに組み込む方法で導入しています。

Agentのビルド方法

CI/CDはCodepipeline(ビルドはCodebuild)を使用。

codebuildのbuildspec.ymlにて最新のDatadogAgentをDLし、アプリケーションソースと一緒にビルドする処理を記載しています。

• 料金は利用する機能単位です。どの機能はどのような課金がされるのか把握し管理する必要があります。
• コストは比較的高め。"Datadogはリアルタイム監視用"と割り切って保存するログの期間は短めに設定して使用しています。
  長期的な傾向分析や過去のログ調査はAWS CloudwatchやAthenaを使用。