AWS re:Invent 2024 で発表された Datadog の新機能: Datadog Product 編

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている [**AoTo**](https://qiita.com/AoTo0330) です。

この投稿は **[<font color="#6495ED">AoTo Advent Calendar 2024</font>](https://qiita.com/advent-calendar/2024/aoto) 8日目**の記事です。

AWS の最大の年次イベント「**AWS re:Invent 2024**」に併せて Datadog が発表した様々な新機能を日本語でまとめました。AWS も Datadog の両方に興味がある・利用している、という方は是非ご参考ください:dog:

https://www.datadoghq.com/aws-reinvent/products/

こちらの内容は Datadog の製品の新機能に焦点を当てた**前編**となります。**AWS integration** や AWS サービスのアップデートに関連する新機能は[**後編**](https://qiita.com/AoTo0330/items/6b2686ce2ad01ffa54cf)でまとめています。

https://qiita.com/AoTo0330/items/6b2686ce2ad01ffa54cf

Datadog のプロダクトは既に発表されているものを含め、**8つの内容**がアナウンスされました。これらのプロダクトの概要と解説をしていきます。

:::note warn
2024年12月時点での情報を元に記載しています。
最新の情報は [Datadog の公式ドキュメント](https://docs.datadoghq.com/ja/)をご参照ください。
:::

## LLM Observability
### 概要
[**Datadog LLM Observability**](https://docs.datadoghq.com/ja/llm_observability/) はチャットボットをはじめとする LLM アプリケーションのパフォーマンス・トラブルシュート・評価・セキュリティ監視を実現できる**独立した Datadog の機能**です。発表時から **GA(一般公開)** となり、その後も対応する SDK やアプリケーション言語を増やしています。

現在は **Python, JavaScript** に対応しており、Python の場合 **OpenAI, Azure OpenAI, LangChain, Amazon Bedrock, Anthoropic, Google Gemini** を呼び出す標準の SDK を**自動計装**しトレースを記録します。**LLM Observability SDK** は **Datadog APM SDK(Tracer)** に含まれており、APM と合わせて利用することも独立して有効化できます。

https://www.datadoghq.com/ja/blog/datadog-llm-observability/

**Amazon Bedrock** 上のモデル呼び出しに [**`Boto3`**](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/bedrock-runtime.html)/[**`Botocore`**](https://botocore.amazonaws.com/v1/documentation/api/latest/reference/services/bedrock-runtime.html) を利用していれば、`ddtrace` ライブラリを読み込むだけで**自動的に LLM の呼び出しをトレース**します。自動的に計装される LLM スパンの他に **RAG** を実装し **Embedding(埋め込み)**/**Retrieval(取り出し)** を行っていれば、それらの処理を実行する関数に**デコレータ**で専用のスパンを作成し単一のトレースを作成できます。

この他にも、対応していない言語や SDK をトレースする際は [**LLM Observability API Reference**](https://docs.datadoghq.com/ja/llm_observability/setup/api/) に準拠した**スパンの作成**と**評価の送信**ができます。特に、実装した LLM アプリケーションに追加のスパンを作成しより詳細なトレースを作成したり、独自の評価を送信し LLM 応答の品質の変化を Datadog で確認できます。

### 以前までの機能
現在の **LLM Observability** に至る変遷は『[DASH 2024 で発表された Datadog の最新機能: Observe 編](https://qiita.com/AoTo0330/items/35551400a9fc3fa5a67a)』で紹介しています。ここでは AWS の ML/LLM プロダクトの監視機能について言及します。

2023年9月に **Amazon Bedrock** が発表されると、Datadog は11月に [**Amazon Bedrock integration**](https://docs.datadoghq.com/ja/integrations/amazon_bedrock/) を発表しました。これにより、**CloudWatch メトリクス** で提供される入出力トークン数・エラー数・レイテンシーなどのパフォーマンスメトリクスを Datadog に取り込み、専用のダッシュボードですぐに可視化することができました。

https://www.datadoghq.com/blog/monitor-amazon-bedrock-with-datadog/

しかし、実際にチャットボットなどの LLM アプリケーション毎にユースケースや入出力の内容は異なり、アプリケーションの観点からの LLM 呼び出しなどのビジネスロジックの監視の需要が高まっていました。**Datadog APM** はこの一定の需要を満たすことができますが、LLM 特有の入出力の品質管理やセキュリティとモデル比較などのユースケースに答えるには追加で情報を取得しなければなりませんでした。

## Network Path
### 概要
[**Datadog Network Path**](https://docs.datadoghq.com/ja/network_monitoring/network_path/#how-it-works) はネットワークトラフィックの発信元から宛先までのネクストホップとルートを検査し、ネットワークの問題が内部的なものか ISP や API の提供元など外部的なものかなどの洞察を得られる機能です。今回の発表で **Limited Availability** として提供され、申請に応じて [**Datadog Cloud Network Monitoring**](https://docs.datadoghq.com/ja/network_monitoring/cloud_network_monitoring/) を利用しているお客様から優先的に利用できる可能性があります。

本機能は想像に難くなく、`traceroute` を利用し **ICMP** で L4 レイヤーのネットワークの接続性を検査します。`traceroute` は宛先までの各ホップへのレイテンシーを測定し、測定された情報を元に Datadog 上で可視化します。

**Network Path** の特徴的な点は、従来の `traceroute` のみの監視と異なりその宛先を明示的に指定せずに [**Cloud Network Monitoring**](https://docs.datadoghq.com/ja/network_monitoring/cloud_network_monitoring/)[^1] で特定された宛先へ自動的にこの検査と可視化を行います。これにより、変化する接続先に対し設定変更を必要とせず継続的にそのネットワーク経路のパフォーマンスの測定と問題の特定を実現します。
[^1]: [**Cloud Network Monitoring**](https://docs.datadoghq.com/ja/network_monitoring/cloud_network_monitoring/) は **Network Performance Monitoring** をリブランディングした新名称です。

https://www.datadoghq.com/ja/blog/datadog-network-path-monitoring/

### 以前までの機能
**Network Path** が提供される以前は、Datadog Agent が導入されたサーバー(発信元)から宛先の疎通確認は [**HTTP チェック integration**](https://docs.datadoghq.com/ja/integrations/http_check/) や [**Ping integration**](https://docs.datadoghq.com/ja/integrations/ping/) が利用されてきました。その他にも、[**Network Device Monitoring**](https://docs.datadoghq.com/ja/network_monitoring/devices) や [**NetFlow Monitoring**](https://docs.datadoghq.com/ja/network_monitoring/netflow/) でネットワーク機器から **SNMP** や **NetFlow, sFlow, IPFIX** などのプロトコルを介したネットワーク情報を収集できました。

いずれの場合も外部向けの通信のように管理外のネットワーク経路を利用する場合、その経路上の監視情報は取得できず被疑箇所を特定することが困難でした。そのため、従来の `traceroute` や `ping` コマンドでの基本的な疎通確認・トラブルシュートを依然として必要とする場面がありました。

## DBM for NoSQL Databases
### 概要
**DBM for NoSQL Databases** は現時点では [**DBM for MongoDB**](https://docs.datadoghq.com/ja/database_monitoring/#mongodb) のことを指します。これは [**MongoDB integration**](https://docs.datadoghq.com/ja/integrations/mongo/) で収集できるメトリクスに加え、低速な操作の特定・CRUD 操作の記録・実行計画の取得・レプリケーションの状態変化・スキーマとインデックスの情報などを統合的に監視できる機能です。今回の発表で **GA(一般公開)** されており、全ての Datadog ユーザーが使用可能です。

[**Amazon DocumentDB**](https://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/what-is.html) は MongoDB 互換のマネージドデータベースで、[DBM for MongoDB での監視](https://docs.datadoghq.com/database_monitoring/setup_documentdb/)がサポートされています。これにより従来の [**Amazon DocumentDB**](https://docs.datadoghq.com/integrations/amazon_documentdb/) の監視情報に加えてデータベース内部のより詳細な監視情報を確認し、深い洞察を得られます。

https://www.datadoghq.com/ja/blog/mongodb-database-monitoring/

### 以前までの機能
[**Datadog Database Monitoring**](https://docs.datadoghq.com/ja/database_monitoring/) データベース内部の監視情報をリアルタイムに収集し、リソース/パフォーマンスメトリクスと同時に監視できる機能として **MySQL, PostgreSQL, SQL Server, Oracle Database** などの **RDBMS** 向けに提供されてきました。

これらと同等の監視機能を **NoSQL** に分類される **MongoDB** へ拡張することで、拡張性の高いデータセットを扱うスケーラビリティとパフォーマンスが求められるシステムに対しても、CRUD 操作の内容や実行計画を元により厳格にデータベースのパフォーマンスの問題を特定・解消できるようになります。

## Change Tracking
### 概要
[**Change Tracking**](https://docs.datadoghq.com/ja/change_tracking/) はサービスとその依存関係に関連する変更を Datadog のモニター・サービス・ダッシュボードに表示して、問題の発生時にその原因となる変更を特定するための洞察を得られる機能です。**Change Tracking** は各画面で段階的に有効化されるプラットフォーム側の機能で、現在は発表されたすべての画面で確認できます。

**Change Tracking** の機能を確認できる画面として、[サービス詳細画面](https://docs.datadoghq.com/ja/tracing/services/service_page/)・[モニターステータス画面](https://docs.datadoghq.com/ja/monitors/status/status_page/)・[ダッシュボードの変更追跡](https://docs.datadoghq.com/ja/dashboards/change_overlays/)があり、どれも全てのユーザーが利用できます。

### 以前までの機能
**Change Tracking** 提供前は、主に **Datadog APM** の [**Deployment Tracking**](https://docs.datadoghq.com/ja/tracing/services/deployment_tracking/) や **Datadog Container Monitoring** の [**Orchestrator(Kubernetes) View** の 情報パネル](**https://docs.datadoghq.com/infrastructure/containers/orchestrator_explorer?tab=datadogoperator#information-panel)ではそれぞれでデプロイや変更の影響を確認できました。

**Change Tracking** の類似機能として [**Datadog Resouce Catalog**](https://docs.datadoghq.com/ja/infrastructure/resource_catalog/) で提供される [**Recent Change Tab**](https://www.datadoghq.com/product-preview/recent-changes-tab/) 機能は、インフラストラクチャーの変更を専用のタブで表示する機能です。この機能は現時点で **Preview** で提供されています。

https://www.datadoghq.com/blog/infrastructure-troubleshooting-recent-changes/


## NextGen Lambda Extension
### 概要
従来の Golang ベースで構築された **Datadog Agent** を元にした [**Datadog Lambda Extension**](https://docs.datadoghq.com/ja/serverless/libraries_integrations/extension/) から、Rust ベースの独自の構築によりオーバーヘッドの削減と信頼性・効率性・持続可能性が向上されました。

この変更は **Rust** の特性である**厳格な所有権**と**独自のメモリ管理モデル**の恩恵を活用し、ガーベジコレクターを利用する以上のメモリ効率を実現しました。これにより、よりオーバーヘッドを抑えコールドスタートへの影響を抑制します。

https://www.datadoghq.com/blog/datadog-next-gen-lambda-extension/

本機能は今回の発表から **GA(一般提供)** されていますが、一部の APM トレースとプロファイル・ASM の転送は現時点ではサポートされていません。有効化するためには、`v67` 以上の Lambda Extension の実装時に `DD_EXTENSION_VERSION: compatibility` を設定する必要があります。

### 以前までの機能
以前までは **Datadog Lambda Extension** は元となる **Datadog Agent** を踏襲し Golang での機能拡張がされていました。しかし、**Lambda Extension** の実装によりコールドスタートと実行時間への影響があり、頻繁に呼び出される関数の場合は都度実行時間が増加し、実装が推奨されない場合もありました。

このコールドスタートを克服するためには、効率的で軽量なコードが求められていました。Rust の特性を活かし、Lambda の[呼び出しフェーズ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle-invoke)後に CPU 使用率を最適化することで、拡張機能による実行時間の増加や課金への影響を最小限になりました。

## Exploit Prevention(RASP)
### 概要
[**Datadog Exploit Prevention**](https://docs.datadoghq.com/security/application_security/threats/exploit-prevention/#enabling-exploit-prevention) チューニングや再構成を行わずに、重要なアプリケーションと API をゼロデイ脆弱性から保護できる [**Datadog Application Security Management - Threat Management**](https://docs.datadoghq.com/security/application_security/threats/) 内の機能です。

**Datadog ASM** は **Datadog APM** のトレース情報とコンテキスト認識機能により、ロジック・データフロー・ステータスを元にアプリケーションの挙動を捉えます。これらの情報と定義されたヒューリスティックにより、エクスプロイトをより高い精度で検出できます。**Exploit Prevention** は実際の損害が出る前にリアルタイムでこの攻撃をブロックし、正当なトラフィックが影響を受けないように対処した上で、セキュリティシグナルを発報します。

本機能は発表時から **GA(一般提供)** されすべての Datadog ユーザーが利用可能ですが、[ライブラリの互換性](https://docs.datadoghq.com/security/application_security/threats/exploit-prevention/#library-compatibility)に準じたバージョンのライブラリを実装した上で、[セットアップ](https://docs.datadoghq.com/security/application_security/threats/setup/)を完了する必要があります。

https://www.datadoghq.com/ja/blog/datadog-exploit-prevention/

### 以前までの機能
**Exploit Prevention** の提供前から、[**ASM Threat Management**](https://docs.datadoghq.com/ja/security/application_security/threats/) で既知のアプリケーション攻撃を[保護ルール](https://docs.datadoghq.com/ja/security/default_rules/#cat-application-security)によって攻撃の検知・防御・通知・洞察・事後分析を行えます。しかし、ゼロデイ脆弱性のような未知の攻撃はこうした保護ルールが適用されず、事後的に攻撃の影響分析を行ったり対処方法を策定する必要がありました。

**Exploit Prevention** によりルールベースの検知から、APM のコンテキストを活かしたヒューリスティックな検査が利用できるようになり、リクエストの振る舞いから確率的に疑わしいリクエストを攻撃として検出します。これにより、ゼロデイ脆弱性を利用したエクスプロイトに代表される攻撃にも、事後的な対処ではなくリアルタイムにリクエストのブロックと攻撃の検知が行えるようになりました。

## Observability Pipelines
### 概要
[**Datadog Observability Pipelines**](https://docs.datadoghq.com/ja/observability_pipelines/) は [**Vector**](https://vector.dev/) OSS をベースとした **Observability Pipeline Worker(OPW)** を利用した独自のログ収集・処理・ルーティングを制御できる機能です。Datadog 上の **Observability Pipelines UI** により OPW を管理し、パイプラインの構築・編集・健康のデプロイが可能です。

本機能は既に **GA(一般提供)** されており、2024年4月の最新メジャーバージョンの発表により現在の形となりました。

https://www.datadoghq.com/blog/observability-pipelines/

### 以前までの機能
前述の最新メジャーバージョンの発表前は、**Vector** の機能とほとんど際はなく、**メトリクス・ログ・トレース**の収集・処理・ルーティングを行う機能でした。その機能は「DASH 2021」で既に発表されています。

https://www.datadoghq.com/blog/dash-2021-new-feature-roundup/#observability-pipelines

こうした背景から、Datadog Agent の機能拡充に伴いその役割が限定されていた **Observability Pipelien** は2024年に取扱データをログのみに変更し、豊富な[パイプライン](https://docs.datadoghq.com/ja/observability_pipelines/set_up_pipelines/)テンプレートとリモート構成を中心としたエコシステムに変化しました。

## Flex Logs
### 概要
[**Flex Logs**](https://docs.datadoghq.com/ja/logs/log_configuration/flex_logs/) は [**Datadog Log Management**](https://docs.datadoghq.com/ja/logs/) で提供される新しいログの保持方式です。**Flex Logs** は、大容量・長期保持のログのニーズに最適な専用のインデックスを提供し、[**Logs Explorer**](https://docs.datadoghq.com/ja/logs/explorer/) や [**Log Workspaces**](https://docs.datadoghq.com/ja/logs/workspaces/) などでリアルタイムにアドホックな分析を低コストで実施できます。

本機能は、「**DASH 2023**」で最初に発表され2024年10月より **GA(一般公開)** となりました。

https://www.datadoghq.com/ja/blog/flex-logs/

昨年の『[AWS re:Invent 2023 で発表された Datadog の新機能: Datadog Product 編](https://qiita.com/AoTo0330/items/8cc0e5ff5ea5ccf4c431#flex-logs)』でも解説をしているため、ぜひご覧ください。

https://qiita.com/AoTo0330/items/8cc0e5ff5ea5ccf4c431#flex-logs

### 以前までの機能
**Flex Logs** は**ログの保持ストレージ**と**ログの検索コンピューティング**に分離して課金を行う新しい課金体系を採用しています。そのため、本機能の **GA(一般公開)** 前は、[コンピューティングサイズ](https://docs.datadoghq.com/ja/logs/log_configuration/flex_logs/#determine-the-compute-size-that-you-need)の中でも最小の **Extra Small** を利用してもログ量が十分になく、[スタンダードインデックス](https://docs.datadoghq.com/ja/logs/log_configuration/indexes)と比較して費用対効果が出せないユースケースも多くありました。

2024年の **GA(一般公開)** に伴い新たに **Starter** サイズが用意され、モニターや Watchdog の恩恵を必要としないアドホックな分析を行うログを保持するための選択肢として選びやすくなりました。

## おわりに
**AWS re:Invent 2024** に合わせて Datadog は多くの製品の発表を行いました。中には既に発表されたものや追加のアップデートのみのものも含まれるため、本ブログを参考に理解を深めていただければ嬉しいです🐶

Datadog は製品開発投資に最も力を入れているオブザーバビリティツールであり、年間のアップデートは数百にも及びます。是非多くの製品をお試しいただき、運用監視上の課題を解決できる機能を見つけていただけると幸いです。