【実務・中級編】Datadog合成監視（Synthetics）とPrivate Locationを活用した閉域網・オンプレミス環境のAPI外形監視構築ガイド – 運用監視・オブザーバビリティ活用バイブル

Datadog合成監視(Synthetics) & Private Locationで閉域網APIを自在に监控: 現場が震える実践テクニック

「え、うちのAPI、インターネットからしか見えないの？ それって、まるで「見えない壁」の向こう側で戦ってるようなもんじゃないか！」

優秀なテックリードであるあなたなら、きっとこう思われるはずです。プロダクトの成長を加速させるためには、パフォーマンス、可用性、そしてセキュリティ。これら全てを網羅する監視体制が不可欠です。しかし、多くの企業が抱える「社内ネットワーク」「VPC内部」「閉域網」といった、パブリックインターネットから隔絶された環境にある重要なAPIやサービスは、従来のクラウドベースの合成監視ツールでは手が届かない、まさに「死角」となっていました。

この死角を埋め、開発スピードを劇的に加速させる秘密兵器こそ、Datadogの合成監視（Synthetics）とPrivate Locationの組み合わせです。この記事では、単なるマニュアルの翻訳に終わらない、現場のエンジニアが「なるほど！」と膝を打ち、すぐにでも実践できる、実践的かつ理論的な解説をお届けします。

なぜ、閉域網・オンプレミス環境のAPI監視が重要なのか？

まず、なぜこのテーマが重要なのかを再確認しましょう。

  • ビジネスロジックの根幹: 多くの企業では、顧客情報、決済処理、基幹システムなど、ビジネスの根幹をなすAPIが閉域網内に存在します。これらの可用性低下は、直接的なビジネスインパクトに繋がります。
  • セキュリティの確保: 閉域網はセキュリティの砦ですが、その内部で何が起きているかが見えなければ、セキュリティリスクを正確に把握できません。
  • 開発・デプロイサイクルの高速化: 開発環境やステージング環境も閉域網内に存在することが多く、これらのAPIの健全性を迅速に確認できることは、デプロイのリードタイム短縮に直結します。
  • 「見えない障害」の撲滅: インターネットからは正常に見えても、内部ネットワークの輻輳や、特定の内部サービスとの連携問題で障害が発生している、といった「見えない障害」を早期に発見できます。

Datadog合成監視(Synthetics) & Private Location: 連携の妙技

Datadog Syntheticsは、APIエンドポイントやWebサイトの可用性、パフォーマンスを定期的にチェックし、問題発生時にアラートを発報する強力な機能です。しかし、その監視ロケーションはデフォルトではDatadogのパブリックなインフラストラクチャに依存します。

そこで登場するのがPrivate Locationです。これは、あなたが管理するネットワーク環境（オンプレミス、VPC、社内ネットワークなど）にデプロイするコンテナベースのエージェントです。このPrivate Locationエージェントが、Datadog Syntheticsの「目」となり、閉域網内のAPIをまるでインターネット上にあるかのように、セキュアかつリアルタイムに監視してくれます。

連携イメージ

graph LR
A[Datadog Synthetics UI] –> B(Datadog Cloud)
B –> C{Private Location Agent};
C –> D[閉域網/オンプレミスAPI];
D –> C;
C –> B;
B –> E[Datadog Dashboards/Alerts];

構築手順: Step-by-Step、実践重視

ここからが本題です。具体的な構築手順を、現場で役立つTipsと共に解説します。

Step 1: Private Locationの準備

1. DockerとDocker Composeのインストール: Private LocationエージェントはDockerコンテナとして動作します。対象サーバー（Linux推奨）にDockerとDocker Composeがインストールされていることを確認してください。

  • Chef/Ansibleなどでの自動化: チーム開発においては、このインストールプロセスもIaC（Infrastructure as Code）で管理することを強く推奨します。
  • キーボードショートカット: `vim`や`emacs`で、Dockerコマンドの補完やスニペット登録を駆使すると、作業効率が格段に向上します。例えば、`vim`なら`~/.vimrc`に以下のような設定を追加し、`DOCKER_COMPOSE_UP`と入力すれば、`docker-compose up -d`が展開されるようにします。

” ~/.vimrc
” Docker Compose Up command
iabbrev DOCKER_COMPOSE_UP docker-compose up -d

2. Datadog Agentのインストール (オプションだが推奨): Private LocationエージェントはDatadog Agentとは独立していますが、同じサーバーにDatadog Agentをインストールしておくと、Private Locationエージェント自体のリソース使用状況（CPU、メモリ、ネットワーク）をDatadogで監視できるようになり、トラブルシューティングが容易になります。

  • Datadog Agentのインストールスクリプト: Datadogのドキュメントにあるインストールスクリプトは非常に便利です。

DD_AGENT_MAJOR_VERSION=7 DD_API_KEY= bash -c “$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_datadog.sh)”

  • APIキーの管理: APIキーは機密情報です。環境変数や、よりセキュアなSecrets Managementツール（Vaultなど）で管理しましょう。

3. Datadog Private Location Agentのデプロイ: DatadogのUIからPrivate Locationを作成し、提供されるDocker Composeファイルを取得します。

  • Datadog UIでの操作: `Synthetics` -> `Private Locations` -> `New Private Location`
  • コンテナ orchestration: KubernetesやDocker Swarmを利用している場合は、提供された`docker-compose.yml`を各プラットフォーム向けに変換してデプロイします。
  • Kubernetes Deployment Example (Conceptual):

# kubernetes-private-location-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: datadog-synthetics-private-location
labels:
app: datadog-synthetics-private-location
spec:
replicas: 1 # 必要に応じてスケール
selector:
matchLabels:
app: datadog-synthetics-private-location
template:
metadata:
labels:
app: datadog-synthetics-private-location
spec:
containers:

  • name: datadog-synthetics-private-location

image: gcr.io/datadog-cloud-solutions/synthetics/private-location: # 最新バージョンを指定
ports:

  • containerPort: 8080 # Agentがリッスンするポート

env:

  • name: DD_SITE

value: “datadoghq.com” # または “datadoghq.eu” など、ご利用のサイトに合わせる

  • name: DD_API_KEY

valueFrom:
secretKeyRef:
name: datadog-secrets # Kubernetes Secretの名前
key: api-key

  • name: DD_APP_KEY

valueFrom:
secretKeyRef:
name: datadog-secrets
key: app-key
resources: # リソース制限は必須
limits:
cpu: “1000m”
memory: “2Gi”
requests:
cpu: “500m”
memory: “1Gi”
# … (other Kubernetes specific configurations)

  • `DD_API_KEY` と `DD_APP_KEY`: これらのキーはDatadog UIで生成します。UIで「API Keys」と「Application Keys」のセクションを確認してください。`APP_KEY`はPrivate Locationの認証に必要です。
  • Kubernetes Secrets: APIキーやAPPキーは、Kubernetes Secretとして管理するのがベストプラクティスです。

Step 2: ネットワーク要件の確認

Private LocationエージェントがDatadogクラウドと通信するため、および監視対象のAPIにアクセスするために、以下のネットワーク設定が必要です。

1. Datadogクラウドへのアウトバウンド通信:

  • エンドポイント: `.datadog.com`, `.logging.datadog-gov.com` (GovCloudの場合) など、DatadogのAPIエンドポイントへのHTTPS (TCP 443) 通信を許可します。
  • ファイアウォール設定: ファイアウォールでこれらの通信を許可してください。

2. 監視対象APIへのアクセス:

  • Private Locationエージェントがデプロイされているネットワークから、監視したいAPIエンドポイントへのネットワーク経路が確保されていることを確認します。
  • VPC Peering/VPN/Direct Connect: オンプレミス環境や異なるVPCにあるAPIにアクセスする場合は、適切なネットワーク接続（VPC Peering、VPN、Direct Connectなど）が必要です。
  • セキュリティグループ/NACL: 監視対象APIのセキュリティグループやネットワークACLで、Private LocationエージェントのIPアドレス（またはエージェントがデプロイされているサブネット）からのインバウンド通信を許可します。

Step 3: 合成監視テストの作成

1. テストタイプの選択:

  • APIテスト: 特定のエンドポイントへのHTTPリクエスト（GET, POSTなど）を送信し、レスポンスコード、レスポンスタイム、レスポンスボディの内容などを検証します。
  • ブラウザテスト: 実際のブラウザ（Puppeteerベース）でWebアプリケーションの操作をシミュレートし、UIの表示やインタラクションを検証します。

2. テスト設定:

  • URL: 監視したい閉域網内のAPIエンドポイントのURLを指定します。
  • HTTP Method & Headers: 必要に応じてHTTPメソッド、カスタムヘッダー（認証トークンなど）を設定します。
  • Body: POSTリクエストなどの場合に、リクエストボディを指定します。
  • Assertions (アサーション):
  • `status code` is `200` (HTTPステータスコードが200であることを確認)
  • `response body` contains `{“status”: “success”}` (レスポンスボディに特定の文字列が含まれることを確認)
  • `response time` is less than `500ms` (レスポンスタイムが閾値以下であることを確認)
  • `json.path` of `user.id` is not null (JSONレスポンスの特定のフィールドが存在することを確認)
  • Location: ここで、先ほど作成したPrivate Locationを選択します。これにより、テストがそのPrivate Locationから実行されるようになります。
  • Schedule: テストの実行間隔を設定します（例: 1分ごと、5分ごと）。
  • Alerting: 問題発生時に通知を受け取るためのアラート設定を行います。Datadogの強力なアラート機能と連携させましょう。

Step 4: アラートとダッシュボードの設定

1. アラート設定:

  • メトリクス: Datadog Syntheticsは、レスポンスタイム、成功率などのメトリクスを自動的に収集します。これらのメトリクスに対して、閾値ベースのアラートを設定します。
  • イベント: テストの失敗などのイベント発生時にもアラートを発報できます。
  • 通知チャンネル: Slack, PagerDuty, Emailなど、チームの運用体制に合わせた通知チャンネルを設定します。
  • 「静寂」の活用: メンテナンスウィンドウなど、意図的にテストが失敗する可能性がある期間は、アラートを一時停止する「静寂（Mute）」機能を活用しましょう。

2. ダッシュボードの構築:

  • Synthetics Dashboard: Datadogのダッシュボード機能を使って、Syntheticsテストの結果を可視化します。
  • グラフの種類:
  • タイムチャート: レスポンスタイムの推移、成功率の推移を表示。
  • リスト/テーブル: 各テストの最新ステータス、レスポンスタイム、エラーメッセージなどを一覧表示。
  • ステータスパネル: 監視対象のAPI全体の状態をアイコンなどで一目で把握できるようにする。
  • チーム共有: 作成したダッシュボードはチームメンバーと共有し、チーム全体の状況認識を高めましょう。

チーム開発を加速する隠しワザ

神プラグイン・拡張機能 (VS Codeを例に)

  • Datadog Official Extensions: VS Codeには、DatadogのダッシュボードやSyntheticsテストをVS Code内から操作できる公式拡張機能があります。これにより、コンテキストスイッチを減らし、開発効率を向上させます。
  • `Datadog` (Datadog Synthetics, Dashboards, Monitors へのアクセス)
  • `Datadog Infrastructure` (Infrastructure & APM へのアクセス)
  • YAML/JSON Linting: Syntheticsテストの定義ファイル（TerraformやCI/CDパイプラインで管理する場合）や、設定ファイルのバリデーションに役立ちます。
  • `YAML`
  • `JSON`

設定ファイルのベストプラクティス (YAML/JSON)

Syntheticsテストは、Datadog UIから手動で作成するだけでなく、TerraformやDatadog CLI (DDCTL) を使ってコードとして管理（IaC）することを強く推奨します。これにより、バージョン管理、レビュー、再現性が担保されます。

例: Synthetics APIテスト定義 (YAML)

datadog-synthetics-tests/api/user-service-healthcheck.yml
Datadog Synthetics API Test for User Service Healthcheck
Purpose: To monitor the health and responsiveness of the User Service API
Author: Your Name/Team
Created: 2023-10-27
Last Modified: 2023-10-27
— Configuration —
TEST_TYPE: api
TEST_NAME: User Service Healthcheck
TEST_ID: (Datadog will assign this after creation)
PUBLIC_ID: (Datadog will assign this after creation)
— Network —
PRIVATE_LOCATION_NAME: “my-internal-network” # Datadog UIで定義したPrivate Locationの名前
— Test Details —
URL: “http://user-service.internal:8080/healthcheck”
METHOD: GET
EXPECTED_STATUS_CODE: 200
EXPECTED_RESPONSE_BODY_SUBSTRING: ‘”status”: “ok”‘
RESPONSE_TIME_THRESHOLD_MS: 1000 # milliseconds
SCHEDULE: “/5 ” # Run every 5 minutes (cron syntax)
— Alerting —
ALERT_MESSAGE: “User Service Healthcheck failed: {{ test_name }} ({{ env }}) is {{ status }} for {{ value }}ms. Check Datadog for details.”
NOTIFY_ON_FAILURE: true
NOTIFY_NO_DATA: false
RECIPIENT_GROUPS: [“backend-oncall”, “platform-team”]

Datadog API Test definition structure (example, actual format depends on tool like DDCTL or Terraform provider)
This is a conceptual representation.

name: “User Service Healthcheck”
type: “api”
subtype: “http”
options:
ci:
executionRule: “ci” # Only run in CI if needed
ticketing:
enabled: true
template: “User Service Healthcheck failed for {{ test_name }}. Please investigate.”
payload: “Please investigate {{ test_name }} on {{ env }}. Status: {{ status }}. Response time: {{ value }}ms. Link: {{ test_url }}”
webhook_url: “https://your-ticketing-system.com/api/v1/tickets” # Example webhook

requests:
–
url: “http://user-service.internal:8080/healthcheck”
method: “GET”
timeout: 10 # seconds
# If authentication is needed:
# headers:
# Authorization: “Bearer {{ env.MY_AUTH_TOKEN }}” # Using environment variable
# body: “”

assertions:
–
type: “statusCode”
operator: “eq”
target: 200
–
type: “body”
operator: “contains”
target: ‘”status”: “ok”‘
–
type: “responseTime”
operator: “lt”
target: 1000 # milliseconds

locations:

  • “my-internal-network” # This should match the name of your Private Location in Datadog

This section would typically be handled by your IaC tool (e.g., Terraform, DDCTL)
For manual creation via UI, these are configured directly.
schedule:
cron: “/5 ” # Every 5 minutes
timezone: “UTC”
notification_handles:
– “backend-oncall@example.com”
– “@pagerduty-integration-key”

ポイント:

  • コメント: 各設定項目や意図を明確にするコメントは必須です。
  • 変数/環境変数: URL、認証情報などは、環境変数や変数として定義し、再利用性・秘匿性を高めます。
  • テストID/パブリックID: Datadogが自動生成するIDは、IaCツールで管理する際に参照されます。
  • CI/CD連携: `options.ci.executionRule` のような設定で、CI/CDパイプラインでのみテストを実行するルールを定義できます。
  • ティケッティング: Datadog Syntheticsのチケッティング機能と連携し、障害発生時に自動でチケットを作成する設定も可能です。

チーム開発で役立つ設定の共有化ルール

1. リポジトリの確立: Syntheticsテスト定義ファイル、Private Locationのデプロイ用IaCコード（Terraform/Kubernetes manifests）、CI/CDパイプライン設定などを一元管理するGitリポジトリを作成します。
2. Pull Request (PR) ベースのレビュー: 全ての変更はPRを通して行い、チームメンバーによるコードレビューを必須とします。これにより、誤設定や意図しない変更を防ぎます。
3. 命名規則の統一: テスト名、Private Location名、アラート名などに一貫した命名規則を適用します。
4. ドキュメンテーション: テストの目的、対象API、ネットワーク要件、トラブルシューティング手順などを、リポジトリ内のREADMEやDatadogのMonitor/DashboardのDescriptionに詳細に記載します。
5. 定期的な棚卸し: 不要になったテストやPrivate Locationは定期的に削除し、監視体制をスリムに保ちます。

まとめ: 閉域網監視は「攻め」のインフラ

Datadog SyntheticsとPrivate Locationの組み合わせは、単なる「監視」ではありません。それは、閉域網というブラックボックスを可視化し、開発・デプロイサイクルを加速させるための「攻め」のインフラです。

この記事で紹介したテクニックが、あなたのチームの生産性を劇的に向上させ、より堅牢で信頼性の高いサービス開発に貢献できれば幸いです。
「見えない壁」の向こう側で何が起きているのかを把握し、自信を持ってプロダクトを成長させていきましょう。

スポンサーリンク
タイトルとURLをコピーしました