Datadogと末永くお付き合いするためのコスト最適化TIPS

Datadogと 末永くお付き合いするための コスト最適化TIPS 2024/8/27 実践事例から学ぶ！ あなたの知らないDatadogの世界 横山達男/tatsuo48

横山 達男(@tatsuo48) Money Forward ・SRE/テックリード SRE NEXT ・コアスタッフ AWSとDatadogが得意です。 家計簿歴:10年

Datadogの事例インタビュー Datadogを活用しプロダクト開発チームによる 自律的なシステム運用を推進

• https://www.datadoghq.com/ja/case-studies/money-forward/

お話すること ● ● ● ● オブザーバビリティは高い？ 価値を高める活動 ムダを撲滅していく活動 今後の展望&まとめ

オブザーバビリティは高い？

オブザーバビリティは高い？ ● オブザーバビリティの重要度の高まりと共にその価格に対する提言も 出てきている ○ ○ オブザーバビリティにはお金がかかる 私個人としても Datadogを利用していて「高いなぁ。。」と思ってしまうことは (正直) ある

• https://dev.henry.jp/entry/observability-and-cost

オブザーバビリティは高い？ ● 「高い」とはなにか？

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ 感じている 価値に対して 価格が見合ってない

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ ● 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性 どうするか？

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ ● 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性 どうするか？ ○ ○ 価値を高める 価値を感じていないのに課金されているもの (ムダ)を撲滅していく

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ ● 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性 どうするか？ ○ ○ 価値を高める 価値を感じていないのに課金されているもの (ムダ)を撲滅していく 価値 価格

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ ● 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性 どうするか？ ○ ○ 価値を高める 価値を感じていないのに課金されているもの (ムダ)を撲滅していく 価値 高める 価格 ムダを撲滅

オブザーバビリティは高い？ ● 「高い」とはなにか？ ○ ○ ● 感じている 価値に対して 価格が見合ってない 続くと、「末永くお付き合い」できなくなる可能性 どうするか？ ○ ○ 価値を高める 価値を感じていないのに課金されているもの (ムダ)を撲滅していく 価値 高める 価格 ムダを撲滅 価値に見合っていると 感じている状態 価値 価格

価値を高める活動

価値を高める活動 ● ● ● ● 社内のコミュニティの活性化 有用な共通ダッシュボード整備 APMの設定方法のベストプラクティスを啓蒙 新規機能の積極導入

社内のコミュニティの活性化 ● #datadogというSlackチャンネルが存在 ○ 参加者は20人ほどと少ない

社内のコミュニティの活性化 ● #datadogというSlackチャンネルが存在 ○ ○ 参加者は20人ほどと少ない あまり知られていないからでは？

社内のコミュニティの活性化 ● #datadogというSlackチャンネルが存在 ○ ○ ● 参加者は20人ほどと少ない あまり知られていないからでは？ エンジニア全員が参加するチャンネルで広報

社内のコミュニティの活性化 ● #datadogというSlackチャンネルが存在 ○ ○ ● 参加者は20人ほどと少ない あまり知られていないからでは？ エンジニア全員が参加するチャンネルで広報 ○ 20人ほどから100人規模へ🎉

社内のコミュニティの活性化 ● #datadogというSlackチャンネルが存在 ○ ○ ● 参加者は20人ほどと少ない あまり知られていないからでは？ エンジニア全員が参加するチャンネルで広報 ○ ○ ○ 20人ほどから100人規模へ🎉 開発者の関心の高さがわかったのは非常に嬉しかった 💪 実際に早期に解決にみちびいた課題も出てきている ■ 統合が正しく動いていないトラブルの解決 ■ 外形監視の方法に関する相談

有用な共通ダッシュボード整備 ● 弊社はEKSを利用したマルチテナントクラスター ○ ● SQSやDynamoDBといったサービスは各サービスごとのAWSアカウ ント ○ ● すべてのサービスが単一のクラスターで稼働 監視は各々で実施 以下のような共通ダッシュボードを整備 ○ ○ ○ SQS DynamoDB コスト最適化のため、 PodのCPU/メモリ使用率を把握できるダッシュボード

APMの設定方法のベストプラクティスを啓蒙 ● ● RailsでAPMを有効化した際にService名にgem名(例:mysql2)が使われる問題 複数のRailsアプリがある当社のような環境だとService Catalogでみた際に、すべ てのアプリが同一サービス(mysql2)と連携があるようにまとめられる mysql2サービスがあるときの Dependencies サービス A サービス A_mysql2 サービス B サービス B_mysql2 mysql2 サービス C サービス C_mysql2 サービス D サービス D_mysql2 サービス E サービス E_mysql2

APMの設定方法のベストプラクティスを啓蒙 ● ● ● 以下のように直接依存関係を持つようにできる設定を周知 APMをより理解しやすくする 依存関係のマップも見やすくなる mysql2サービスがないときの Dependencies サービス A サービス A_mysql2 サービス B サービス B_mysql2 サービス C サービス C_mysql2 サービス D サービス D_mysql2 サービス E サービス E_mysql2

新規機能の積極導入(WIP) ● ● 弊社には大量のマイクロサービスが存在 Datadogの利用ルールを徹底していなかった経緯もあり、マイクロサービ ス間の境界が把握しづらい ○ ● 先程のmysql2サービスの話のように依存関係が不明瞭になっているケースなど webサービスとmysql2サービスを明示的に1つのアプリケーションとして 定義する必要がある サービス A サービス A_mysql2 アプリケーションA サービス B サービス B_mysql2 アプリケーションB サービス C サービス C_mysql2 アプリケーションC

新規機能の積極導入(WIP) ● ● DASH2023 Inferred services

• https://www.datadoghq.com/ja/blog/dash-2023-new-feature-roundup/#サービス間接続と推測サービスの可視性の強化
• https://docs.datadoghq.com/tracing/guide/inferred-service-opt-in/?tab=java&_gl=1*10co46e*_gcl_aw*R0NMLjE3MjM5NjYzMzYuQ2owS0NRand0NGEyQmhENkFSSXNBTGdIN0RvSHRIXzJSWkxUenNVaUlqZl9iZ29BczR3NzIzbUZnMC1JVkYzLXVfb1Q2MDRSTHlJZTJJOGFBcTFuRUFMd193Y0I.*_gcl_au*NDczNzIxNDA3LjE3MTk0NzEwNzY.*_ga*MTc1NTg2OTE1Ni4xNzE5NDcxMDc2*_ga_KN80RDFSQK*MTcyMzk4NzgxMi43NS4xLjE3MjM5ODgzNjIuMC4wLjUwOTAzODcxNQ..*_fplc*cWtkWlR0S2dQVDk4c2paeWtlbWpBYndiTHpEbndCTDYzendDUXBPY2hCcFZFT1FhWUZKVWJRRFhuSUZKMTdDYlpLWEhCT1Z4SWNOMkVMWFdUeVolMkJvbW9uZjNHeTlFajF4JTJCRlBsUUQ0dXd2N3lOeE5Sck9CVFU1eGJxeWFDZyUzRCUzRA..#global-default-service-naming-migration

新規機能の積極導入(WIP) ● まだベータだがInferred servicesを使うと解決できるかも？ ○ ○ ○ mysql2サービスは作られず、すべてアプリケーション名のサービスに統一されそ う？ 結果として、1つのマイクロサービスを構成する要素がすべて同じアプリケーション にまとめられるのでは？ お試し環境整備中 サービス A サービス A(@peer.db.name:db-a) サービス B サービス B(@peer.db.name:db-b) サービス C サービス C(@peer.db.name:db-c)

ムダを撲滅していく活動

ムダを撲滅していく活動 ● ● ● ホスト数の削減とモニタリング ログ量の削減とモニタリング カスタムメトリクスの削減とモニタリング

ホスト数の削減とモニタリング ● DatadogのAWS統合のデフォルト設定ではAgent未導入のEC２イン スタンスもデータ収集対象

ホスト数の削減とモニタリング ● ● DatadogのAWS統合のデフォルト設定ではAgent未導入のEC２イン スタンスもデータ収集対象 この挙動自体は便利 ○ 意図せず収集対象にしてしまっているケースが散見された

ホスト数の削減とモニタリング ● ● DatadogのAWS統合のデフォルト設定ではAgent未導入のEC２イン スタンスもデータ収集対象 この挙動自体は便利 ○ ● 意図せず収集対象にしてしまっているケースが散見された datadog:monitoredのタグが付いたインスタンスのみ対象とするよ うに設定追加

ホスト数の削減とモニタリング ● ● DatadogのAWS統合のデフォルト設定ではAgent未導入のEC２イン スタンスもデータ収集対象 この挙動自体は便利 ○ ● 意図せず収集対象にしてしまっているケースが散見された datadog:monitoredのタグが付いたインスタンスのみ対象とするよ うに設定追加

ホスト数の削減とモニタリング ● 二度と起きないよう以下に対してモニターを設定 ○ ● datadog.estimated_usage.hosts 直近4時間の最大値がしきい値を超えたらアラートにしている ○ avg(last_4h):max:datadog.estimated_usage.hosts{host_type:aws} > しきい値

ログ量の削減とモニタリング ● 以下の値をサービス単位でモニター設定 ○ ○ datadog.estimated_usage.logs.ingested_events 具体的なクエリは以下 ■ sum(current_1d):sum:datadog.estimated_usage.logs.ingested_events{data dog_index:*,datadog_is_excluded:false} by {service}.as_count() > しき い値

ログ量の削減とモニタリング ● 以下の値をサービス単位でモニター設定 ○ ○ ● datadog.estimated_usage.logs.ingested_events 具体的なクエリは以下 ■ sum(current_1d):sum:datadog.estimated_usage.logs.ingested_events{data dog_index:*,datadog_is_excluded:false} by {service}.as_count() > しき い値 しきい値を超えた場合は、サービス担当者に連携 ○ Exclusion Filterの設定を打診 🙏 ■ Archiveからのrehydrateはできることを伝えつつ

ログ量の削減とモニタリング ● 以下の値をサービス単位でモニター設定 ○ ○ ● しきい値を超えた場合は、サービス担当者に連携 ○ ● datadog.estimated_usage.logs.ingested_events 具体的なクエリは以下 ■ sum(current_1d):sum:datadog.estimated_usage.logs.ingested_events{data dog_index:*,datadog_is_excluded:false} by {service}.as_count() > しき い値 Exclusion Filterの設定を打診 🙏 ■ Archiveからのrehydrateはできることを伝えつつ リミットも設定可能だが、上限に達してインデックスされなくなったときの影響度がサービスにより まちまちなので合意形成が必要 ○ ○ サービスごとに上限を設定できると嬉しいかもしれない 日別の割り当てを設定する

• https://docs.datadoghq.com/ja/logs/log_configuration/indexes/#日別の割り当てを設定する

カスタムメトリクスの削減とモニタリング ● 以下の値をモニター設定 ○ ○ datadog.estimated_usage.metrics.custom 具体的なクエリは以下 ■ max(last_5m):sum:datadog.estimated_usage.metrics.custom{*} > しきい値

カスタムメトリクスの削減とモニタリング ● 以下の値をモニター設定 ○ ○ ● datadog.estimated_usage.metrics.custom 具体的なクエリは以下 ■ max(last_5m):sum:datadog.estimated_usage.metrics.custom{*} > しきい値 しきい値を超えたらCustomMetricsのUsageから怪しいものを確認 ○ Metric Summaryも活用

カスタムメトリクスの削減とモニタリング ● 以下の値をモニター設定 ○ ○ ● しきい値を超えたらCustomMetricsのUsageから怪しいものを確認 ○ ● datadog.estimated_usage.metrics.custom 具体的なクエリは以下 ■ max(last_5m):sum:datadog.estimated_usage.metrics.custom{*} > しきい値 Metric Summaryも活用 担当者に確認 ○ urlやuser_idなどカーディナリティが高い要素を利用している場合は代替案がないか一緒に検討 🤝

カスタムメトリクスの削減とモニタリング ● 以下の値をモニター設定 ○ ○ ● しきい値を超えたらCustomMetricsのUsageから怪しいものを確認 ○ ● datadog.estimated_usage.metrics.custom 具体的なクエリは以下 ■ max(last_5m):sum:datadog.estimated_usage.metrics.custom{*} > しきい値 Metric Summaryも活用 担当者に確認 ○ ○ urlやuser_idなどカーディナリティが高い要素を利用している場合は代替案がないか一緒に検討 🤝 利用者は課金体系の理解が薄い場合もあり、カーディナリティ依存であることを伝えると驚かれることも ある ■ この記事を紹介 ● Datadogのカスタムメトリクスによる予期せぬコスト増加を回避する

• https://zenn.dev/tkaga/articles/291af41d8e43b0

今後の展望&まとめ

今後の展望 ● ● Datadogと「末永くお付き合い」するためにはコストに対するリテラシーが必要 以下の両方を継続して検討 ○ ○ コストリテラシー強化のための勉強会開催 ■ 「なに」に「いくら」かかるのか？ ガードレールの制定 ■ インデックスできるログイベント数のリミット ■ アクセス権限の活用 ■ コストインパクトのある作業の制限と承認フローの導入

まとめ ● コスト最適化について2軸で実施 ○ ○ ● 高いとはなにか？を再考 ○ ● 価値を高める活動 ムダを撲滅していく活動 両面から対応していきましょう それが末永くおつきあいするための道 価値に見合っていると 感じている状態 価値 価格

宣伝

🎉Money Forward Tech Day 2024🎉 ● 公式サイト ○ ● コンセプト ○ ● 9/20(Fri)@東京ポートシティ竹芝 「Let’s make it!」 Money Forward Tech Day 2024 を開催 します！ ○ ○ connpass 応募締切：8月31日

• https://techday.moneyforward-dev.jp/2024/
• https://moneyforward-dev.jp/entry/2024/08/16/mf_techday_2024
• https://moneyforward.connpass.com/event/325167/

おわり ~Fin~