本記事はany Product Team Advent Calendar 2024 4日目の記事です🎄
はじめに
anyのプロダクトチームでエンジニアをやっている荒川です。ついにanyのアドベントカレンダー始まりましたね！
今回は弊社プロダクトのQastというWebアプリケーションにおけるバックエンドのObservabilityの仕組みとして、Datadogの活用について紹介をしたいと思います！
QastもWebアプリケーションとして巨大化し、よりよいユーザ体験をObservabilityという観点からより強固に提供したいという想いのもと、今年の初め頃からDatadogを導入する機運が高まりました。この一年間少しずつ皆で協力しあいながら、現時点でかなり広範かつ有効的に活用することができています☺️
現時点でAPM / Logging / Dashboard / Monitors / Error Tracking / ASM / Cloud SIEM / Database Monitoringを利用しています。
本記事ではQastでの活用方法をいくつか紹介していきますね！
🐛 アプリケーションのトレーシング
一番最初にバックエンドのアプリケーションのトレーシングとして、APMという機能を有効にしています。見てもらうほうがイメージが湧きやすいと思うので早速ですが、こちらはとあるリクエストの処理のトレースです。とあるHTTPリクエストからデータベースアクセス、外部APIへのリクエストがSpanという単位ごとに可視化されて表示されています。
これらをトレースという単位で最終的に処理にどの程度時間がかかったのか可視化することができます。しかもそのときのコンテナのCPUやメモリ使用量などと同時に確認できます。とーっても便利ですね！🙌
QastにおいてはメインアプリケーションではAWS、特にバックエンドはFargateで構築されていますが、古めのアーキテクチャのアプリでは、EC2上で動作するアプリケーションも若干残っています。またサービス間通信はシンプルなHTTPリクエストのこともあれば、SQSを経由する場合もあります。APMを利用するとこれらの分散管理されたアプリケーションにおいても、互いのトレースをつなげることが可能になります。
下記はQastのAIサーバの入出力のインターフェースが自動で可視化されている様子です。これらのMapも自動で作成してくれるようになっています。
SQSやSNS経由の流れも追える
必要に応じて、APM Profilingも有効にしており、これは特定の処理のチューニングをするときに深掘りするタイミングで利用することもできます。階層構造で表示されるため、かなり具体的にどのライブラリの何のメソッドに時間がかかっているというレベルでも把握できるようになっています！
🪵 ログの一元管理プラットフォームとして
QastではほぼすべてのログがCloudWatch Logsにログを保存されています。古めのアプリケーションはEC2上で動作しているもの(つまりインスタンス内のログファイルとして出力)も若干ありますが、CloudWatch Agent を導入するなどしてアプリケーションに関わるログは転送するようにしています。
これだけでもログとしては集約されていますが、CloudWatch LogsをAWSコンソールなどからはログストリームやグループを横断するなどがやや煩雑になることも多いと思います。そこでAWS LambdaのForwarderを設定することで、CloudWatch LogsをDatadogに転送させることができます。
ほぼボカシで申し訳ないですが、この設定をすることで、ログをフィルタリングしたり、期間指定をしたり、ログ同士の関連をチェックすることができます。
直感的にログを検索可能！
ここまでは普通のログ管理ですが、Datadogの強力な強みはログとトレースを紐づけることができることです。特定のトレースをAPMからログを確認することもできますし、反対にログからトレースを確認することもできます！
この機能によって、ログだけでは見えてこない情報が勝手に可視化されるので、開発時も本番運用時も非常に有用な情報源となります🙌
また、古いアプリケーションはEC2上のGunicornアプリケーションなどとして構築されており、特に古めのアプリケーションの場合は完全な構造化ログになっていない場合があります。そこでDatadogのLog Pipelineを適用すれば、非構造ログを一定のルールでパースし、構造化してくれます。このルールはDatadog側から提供されており、有名どころであれば対応しているため、Gunicornやnginxなどのログなどもそのままパースさせることができます。
理想としては統一した構造化ログを出力する方が良いのですが、構造ログになりきっていないリアーキ前のアプリで、今後は徐々に移行されていくものなので、ワークアラウンド的な運用で必要十分とも思っています。
またSendGridなどの外部連携機能のログもDatadogに集約できます。これも非常に強力な機能で他ログと突合することができるのでトレースがより捗ります。
🚚 Error Tracking でエラーを棚下ろす
APM や Logs から集約した例外系に関するログを棚卸しできるものです。APMからであれば普通に例外を発行すればそれだけで検知されますし、構造化ログでレベルをエラーに設定すれば自動で収集されます。そのスタックトレースやAPMへのリンク、またLogsへのリンクも存在するため、統合的にエラーを管理できます。
緊急度の高いものは別の仕組みでアラートが飛ぶのですぐに対応できる状態にはなっているため、あくまでもDevOps的なツールとしての立ち位置の方が強い機能になっています。
エラーによっては将来的に解決される見込みなどがあればアテンションを外して良いパターンもあります。そう言った類のエラーをミュートにすることもできます。またデプロイ単位でDD_VERSIONという環境変数で設定するコミットハッシュ、つまりどのリリースから発生し始めたエラーかを検知できる点も非常に強力です。さらに頻度が低いエラーなども月に一度程度の頻度で棚卸しをしており、調査するメンバーを決めています☺️
📺 モニタリングの仕組みとして
一般的に運用管理でイメージされるようなアラートやダッシュボードを作成できる機能としても利用しています。APM経由、Log経由、AWSのAPI経由など複数の情報源からの情報を集約しているゆえに高精度かつリアルタイム性も優れています。
さらにデータベースモニタリングとしてはDBMという機能も利用しています。Qastのデータベースは、AWS RDS上に構築されており、DBMを利用することでCPU利用率からコネクション数などのメタデータも複数にわたって値を監視することができます。
データベースレイヤから直接取得できる情報のため、クエリの発行回数や実行時間なども細かに取得することが可能ですし、コンソールに入らずとも統計情報等も取得できるので、本番作業にヒヤヒヤする必要もありません。
DBMによって異常な回数のクエリをデータのクレンジング漏れを発見し、これによって特定の処理でボトルネックとなっていたCPUの使用率を減らすことができ、実際にデータベースのインスタンスタイプを落とすこともできた事例もあります!👋
🔁 Synthetics による外形監視の仕組みとE2Eテスト
ヘルスチェックとしてSyntheticsによる外形監視の仕組みを取り入れています。定期的な頻度で本番環境に対して作成したシナリオを自動で実行させ、環境が安定しているかどうかをエンドツーエンドで確認をしています。
また、これはまだ試行錯誤の段階ですがSyntheticsを利用して、いわゆるフロントエンドのE2Eテストを作成することも検討をしています。UIテストはflakyになりがちなので、慎重に進めている最中です。どなたかのお力添えがぜひ欲しいところです...！
🔑 ASM / Cloud SIEM によるセキュリティへの取り組み
セキュリティ関連なので大々的には記載ができませんが、アプリケーションのライブラリの脆弱性管理やAWS CloudTrail経由での監査ログの仕組みも整えています。DatadogではAPMでトレースを取得しているので、それ経由で攻撃の可能性のあるトレースを表示してくれるなども可能のため、そちらも定期的に確認をしています。
💪 今後強化していきたいこと
ここまで多くの機能を紹介してきましたが、他にもいくつか利用をしている機能もありますが、割愛させていただきます。一方で今後強化していきたい内容もあって...
- APMとLogsの改善
- 一部Mackerelからの完全移行
- 各種モニタリングのTerraform化
- 多機能すぎるゆえの利用敷居の高さの改善
- 全体的なコストカット💰
現時点ではプロダクト規模的にも、開発者側でSLOなどを設定しておらずなのですが、できる限り早い段階でやっていきたい気持ちです。なにより強度をもって監視していきたいという気持ちです!
おわりに
以上のようにQastにおいて非常に多機能にわたってDatadogを活用しており、Qastの品質を強く支えてくれています。まだまだ粗い箇所も多いのですが、今後はより強化していくので、ぜひ仲間を探しています！
カジュアル面談からでかまわないので、お待ちしております☺️
Discussion