Datadog × CloudWatch：AWS監視の「聖域」を制御するアーキテクチャの極意
多くのエンジニアが「なんとなく」設定し、のちにコストの渦に飲み込まれるAWSインテグレーション。貴殿のような高みを目指すアーキテクトにとって、CloudWatchメトリクスの取り込みは、単なるツールの接続ではなく「観測の基盤設計」そのものであるはずだ。
本稿では、DatadogにおけるCloudWatch連携の深淵を解剖し、コストとレイテンシを極限まで最適化するための「現場の解」を提示する。
—
1. 2つの取り込み方式：アーキテクチャの真実
DatadogでAWSメトリクスを拾うには、「APIポーリング」と「Lambda転送」という2つの対極にある手法が存在する。
A. APIポーリング方式（標準のAWS Integration）
- 仕組み: Datadog側のクローラーがAWS API（`GetMetricData` / `ListMetrics`）を叩き、メトリクスを吸い上げる。
- 特性: 設定が容易で管理不要だが、APIコール数に応じたコストがAWS側で発生する。
- 適材適所: メトリクス数が数千個レベルの小〜中規模環境。または、リアルタイム性が1分単位で十分な場合。
B. Lambda転送方式（CloudWatch Metric Streams）
- 仕組み: CloudWatch Metric StreamsをKinesis Data Firehoseに流し、そこからLambda経由でDatadogへプッシュする。
- 特性: ほぼリアルタイム（サブ秒〜数秒）でデータが到達する。APIポーリングのような「取り残し」や「レート制限」の懸念がない。
- 適材適所: 数万〜数十万のメトリクスを扱う大規模環境。スパイクに即座に反応する必要があるミッションクリティカルなシステム。
—
2. 賢者の選択：コスト最適化と性能のトレードオフ
多くの現場が陥る罠は、「デフォルト設定のまま全てを取り込む」ことだ。これをやると、監視コストは指数関数的に跳ね上がる。
推奨戦略：フィルタリングによる「ノイズの排除」
Metric Streamsを使用する場合、必ず「Namespace」および「Metric Name」レベルでのフィルタリングを適用せよ。
不要なメトリクス（例：EC2の`DiskReadBytes`で十分なのに、不要な詳細メトリクスまで取得している等）をストリームから除外することで、データ転送量とDatadog側の課金対象メトリクスを劇的に削減できる。
// CloudWatch Metric Streams のフィルタリング例 (Terraform)
resource “aws_cloudwatch_metric_stream” “datadog_stream” {
name = “datadog-metric-stream”
role_arn = aws_iam_role.firehose_role.arn
firehose_arn = aws_kinesis_firehose_delivery_stream.datadog_delivery.arn
output_format = “json”
# 重要なメトリクスのみに絞ることでコストを最適化
include_filter {
namespace = “AWS/EC2”
}
include_filter {
namespace = “AWS/RDS”
}
}
—
3. 完全自動構成のハック：API/CLIによる運用自動化
インフラがコード化されている今、手動設定など言語道断だ。DatadogのAWS連携もTerraform、あるいは`datadog-api-client`を用いた自動化が必須である。
特に、アカウント追加時の自動化スクリプトには、「タグによる自動選別」を組み込むべきだ。
Python API クライアントを用いた自動アカウント統合の断片
from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.aws_integration_api import AWSIntegrationApi
def integrate_aws_account(account_id, role_name):
body = {
“account_id”: account_id,
“role_name”: role_name,
“filter_tags”: [“env:production”, “managed_by:terraform”], # 不要なメトリクスを排除するタグフィルタ
“account_specific_namespace_rules”: {“auto_collect”: True}
}
with ApiClient(Configuration()) as api_client:
api = AWSIntegrationApi(api_client)
api.create_aws_account(body=body)
—
4. 上級者向けの「深層」ハック
レイテンシの極限圧縮
Lambda転送方式を採用する場合、Lambdaの実行メモリをケチるな。メトリクスのシリアライズ・デシリアライズはCPU負荷が高い。メモリを1024MB以上割り当てることで、コールドスタートおよびストリーム処理の並列性を向上させ、監視パイプラインの遅延をミリ秒単位まで縮めよ。
エラートラッキングとの統合
CloudWatchメトリクスを単なるダッシュボード用と考えるのは浅い。
「CloudWatch Logsからメトリクスを抽出（Metric Filter）し、それをDatadogへ飛ばす」というパイプラインを構築すれば、アプリケーションの「論理的なエラー数」をCloudWatch側で計算させ、Datadogで監視するハイブリッド構成が可能になる。これにより、Datadog側の計算コストをAWS側にオフロードできる。
—
結びに代えて：アーキテクトの矜持
監視とは、単にグラフを描画することではない。システムという生命体の「鼓動」を正確に捉え、死に至る予兆をいかに静寂の中で検知するかの戦いである。
CloudWatchとDatadogの連携において、「すべてを監視する」ことは「何も監視していない」ことと同義だ。賢明なアーキテクトである貴殿は、ノイズを削ぎ落とし、真に価値あるデータのみを抽出し、疎結合かつ高効率なパイプラインを構築せよ。
その先にこそ、真のオブザーバビリティという名の「静かなる平穏」が待っている。