閉域網の聖域を暴く：Datadog Synthetic Private Locationによるオンプレミス・VPC外形監視の極限実装
パブリッククラウドのAPIやSaaS監視であれば、DatadogのマネージドなManaged Locationに数行のJSONを投げ込むだけで終わる。しかし、我々が守るべき本番システムはそうではない。金融系のコアバッチ、医療データの基盤、あるいは厳重にプロテクトされたKubernetesクラスタ（VPC）の内部。これらはパブリックインターネットからのアクセスを完全に遮断している。
「外形監視をしたいが、社内ネットワークや閉域VPCの奥底にあるため、Datadogのマネージドプローブが届かない」
この古典的かつ強烈なジレンマに対し、多くのエンジニアは「踏み台サーバーからの定期curl実行＋Slack通知」という、前世紀の遺物のような自製スクリプトに逃げ込みがちだ。
断言しよう。それはオブザーバビリティの放棄に等しい。
Datadog Synthetic Private Locationを正しくデプロイし、その内部アーキテクチャを骨の髄まで理解すれば、閉域網のブラックボックスを、パブリック環境と同等以上の解像度で完全掌握できる。
本稿では、Private Locationの低レイヤの挙動から、コンテナのメモリ消費最適化ハック、そしてTerraformとAPIを駆使した完全自動プロビジョニングの極意まで、現場で震えるほどの知見を余すところなく解説する。
—
1. 内部アーキテクチャの解剖：Private Locationは中で何をしているのか
まず、Datadog Private Location（以下、PL）の本質を理解する。
PLは、単なる「外形監視を実行するDockerコンテナ」ではない。実体は、Datadogインフラストラクチャとの間で常時セキュアな外向きのアウトバウンド接続（TLS/gRPCあるいはHTTPS）を確立するエージェント群である。
[Datadog Cloud (SaaS)]
▲
│ (1) アウトバウンド接続 (WSS / HTTPS : ポート443)
│ (コンテナ側から自発的にコネクションを張る)
│
[Private Network / VPC]
┌─────────────────────────────────────────┐
│ Private Location Pod / Container │
│ ├── Worker (テスト実行エンジン) │
│ └── Synthetics-Runner (ブラウザ/API) │
└────────────────────┬────────────────────┘
│ (2) 閉域APIへ内部アクセス
▼
[ターゲットAPI / サービス]
ネットワーク要件の真実：なぜインバウンドポートを開けてはならないのか
セキュリティチームとインフラチームの最初の壁は「ファイアウォールをどう開けるか」だ。
ここで声を大にして言いたい。Private Locationのために、ファイアウォールやセキュリティグループのインバウンド（Ingress）ポートを開ける必要は一切ない。
PLコンテナは、起動時にDatadogのコントロールプレーンに対してアウトバウンド（Egress）の長寿命接続を確立する。すべてのテスト指示（APIテストのペイロード、実行間隔など）はこのコネクションの上を流れ、テスト結果も同じ経路でDatadogに送り返される。
必須のアウトバウンド通信先（Egress Requirements）
企業プロキシや厳格なファイアウォールの向こう側にデプロイする場合、以下の宛先へのTCP 443（HTTPS/WSS）を許可する必要がある。
- `.datadoghq.com` （または契約しているリージョン、例：`us5.datadoghq.com`, `ap1.datadoghq.com`）
- Datadogが使用するCDNおよびストレージドメイン（テスト結果のアーティファクト・スクリーンショット送信のため）
—
2. 最小にして最強：KubernetesへのPrivate Locationデプロイメント
Docker単体（ECSやDocker Compose）での運用も可能だが、高可用性とオートスケーリング、そしてリソース分離の観点から、生産環境ではKubernetes（EKS, GKE, AKS, オンプレK8s）へのデプロイがデファクトスタンダードとなる。
以下に、実運用で耐えうる堅牢なKubernetesマニフェストを示す。
セキュアなSecret構成とHelm/Manifestの極意
PLの認証には、DatadogのAPI Keyと、Datadog UI上で生成するPrivate Location専用のプローブキー（`DATADOG_SYNTHETICS_PRIVATE_LOCATION_KEY`）が必要だ。
apiVersion: v1
kind: Secret
metadata:
name: datadog-synthetics-private-location-secret
namespace: datadog-observers
type: Opaque
stringData:
api-key: “YOUR_DATADOG_API_KEY”
pl-key: “YOUR_PRIVATE_LOCATION_PROBE_KEY”
—
apiVersion: apps/v1
kind: Deployment
metadata:
name: datadog-synthetics-worker
namespace: datadog-observers
labels:
app.kubernetes.io/name: datadog-synthetics-private-location
spec:
replicas: 2 # 高可用性のため最低2レプリカを推奨
selector:
matchLabels:
app: datadog-synthetics-worker
template:
metadata:
labels:
app: datadog-synthetics-worker
spec:
containers:
- name: synthetics-private-location
image: public.ecr.aws/datadog/synthetics-private-location:v1.28.0 # ※常に最新の安定版を追従すること
env:
- name: DATADOG_API_KEY
valueFrom:
secretKeyRef:
name: datadog-synthetics-private-location-secret
key: api-key
- name: DATADOG_SYNTHETICS_PRIVATE_LOCATION_KEY
valueFrom:
secretKeyRef:
name: datadog-synthetics-private-location-secret
key: pl-key
- name: DATADOG_HOST
value: “app.datadoghq.com” # リージョンに応じ変更 (例: ap1.datadoghq.com)
- name: PROXY_HOST
value: “” # 社内プロキシ経由の場合はここに指定
resources:
limits:
cpu: “2”
memory: 4Gi
requests:
cpu: “500m”
memory: 1Gi
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: false
runAsNonRoot: true
runAsUser: 1000
# ヘルスチェックの設定 (K8sのライブネス/レディネスプローブ)
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 15
—
3. パフォーマンスとリソース最適化のハック
PLコンテナを運用していると、ある日突然、コンテナがOOMKilled（Out Of Memory）でクラッシュする現象に直面する。特に、APIテストではなく「ブラウザテスト（SeleniumベースのヘッドレスChrome実行）」をPrivate Locationで大量に回し始めると、メモリ食いが加速する。
メモリ消費のブラックボックスを暴く
1. ブラウザテストの並列度制限:
ヘッドレスChromeは驚異的なメモリを消費する。PLコンテナ内のワーカープロセスが同時に実行するブラウザテストの数（Concurrency）を制御しなければ、瞬く間にノードのメモリを枯渇させる。
環境変数 `MAX_CONCURRENT_TESTS`（デフォルト値はインスタンスサイズに依存）を適切にチューニングし、1ポッドあたりの許容量を明確に縛れ。
2. Shared Memory (`/dev/shm`) の枯渇対策:
ヘッドレスChromeは内部の一時ファイル保存に `/dev/shm` を多用する。Kubernetesのデフォルトでは `/dev/shm` はわずか64MBしか割り当てられておらず、これが原因でブラウザテストが突然死する。
ポッドの定義に `emptyDir` ボリュームを追加し、`/dev/shm` を拡張せよ。
Podの volumes / volumeMounts に以下を追加する
volumes:
- name: dshm
emptyDir:
medium: Memory
sizeLimit: 1Gi # 1GBを確保
containers:
- name: synthetics-private-location
volumeMounts:
- mountPath: /dev/shm
name: dshm
—
4. 完全自動化：TerraformによるPrivate LocationとAPIテストのコード化
手動でDatadog UIをポチポチ叩いてPrivate Locationを作るなど、モダンなDevOpsエンジニアのやることではない。PLの作成から、閉域網APIをたたくテストのデプロイまで、すべてInfrastructure as Code（Terraform）で完結させる。
以下のTerraformコードは、実践でそのまま使えるプロダクション・グレードの定義だ。
terraform {
required_providers {
datadog = {
source = “DataDog/datadog”
version = “~> 3.30.0”
}
}
}
1. Private Locationのリソース定義（Datadog側に論理的なプレースホルダーを作成）
resource “datadog_synthetics_private_location” “onprem_pl” {
name = “production-onprem-pl-tokyo”
description = “TokyoオンプレミスDCおよびVPC内部向けプライベートロケーション”
metadata {
restricted_roles = [] # 必要に応じてアクセス制御ロールを指定
}
}
2. Private Location上で実行するAPIテストの定義
resource “datadog_synthetics_test” “internal_core_api” {
type = “api”
subtype = “http”
name = “[Internal] Core Billing API Health Check”
status = “live”
# 先ほど定義したPrivate LocationのIDを指定
private_location_ids = [datadog_synthetics_private_location.onprem_pl.id]
request_definition {
method = “GET”
url = “https://internal.billing.corp.local/healthz” # 閉域網内のURL
# 必要に応じて内部ヘッダーや認証トークンを付与
http_headers = {
“X-Monitor-Source” = “Datadog-Synthetics”
“Authorization” = “Bearer ${var.internal_api_token}”
}
}
assertion {
operator = “is”
type = “statusCode”
target = “200”
}
assertion {
operator = “lessThan”
type = “responseTime”
target = “500” # 応答速度が500ms未満であることを検証
}
options_list {
tick_interval = 60 # 60秒ごとに実行
retry {
count = 2
interval = 30
}
monitor_options {
renotify_interval = 120
}
}
locations = [] # Private Locationを使う場合、マネージドlocationsは空にする
message = “ALERT: 社内基幹ビリングAPIが応答していません！ @slack-core-sre”
}
output “private_location_key_instructions” {
value = “以下のプライベートロケーションキーをKubernetesのSecretに設定してください: ${datadog_synthetics_private_location.onprem_pl.secret}”
sensitive = true
}
—
5. 障害の予兆検知とエラートラッキングの神髄
Private Locationを使った監視の真骨頂は、「ただ死活監視するだけではない」点にある。
閉域網特有のネットワーク揺らぎ、内部DNSのひずみ、証明書の有効期限切れといった「障害の予兆」をミリ秒単位でキャッチするための設計指針を授けよう。
1. DNS解決時間のメトリクス監視
閉域網では、社内DNSサーバー（Bind, CoreDNS, Route 53 Resolver等）の応答遅延がそのままAPI全体のレイテンシ悪化に直結する。
Datadog Syntheticsは、テスト結果の詳細なタイミングブレイクダウン（DNS lookup, TCP connection, TLS handshake, First Byte, Download）をメトリクスとして自動収集している。
- `synthetics.test.timing.dns` が徐々に右肩上がりになっていないか？
- TLSハンドシェイクの時間が急増していないか？（証明書のチェーン検証の破綻や、OCSP staplingの詰まりの予兆）
これらをDatadogのAnomaly Detection（異常検知モニター）やForecast（予測モニター）に繋ぐことで、「システムが死ぬ前に、インフラの劣化を予見してアラートを鳴らす」ことが可能になる。
2. プロードロップ（PL自身の死活監視）
Private Location自体が、ネットワークの分断やノード障害によってDatadogクラウドとの接続を失う（Stale状態になる）ことがある。
Datadogには、Private Location自体の稼働状態を監視するためのメトリクスが用意されている。
- 監視すべきメトリクス: `datadog.synthetics.private_location.status`
- 閾値アラート: ステータスが `0`（オフライン）になった瞬間、直ちにPagerDutyやSlackへクリティカルアラートを発報せよ。PLが沈黙している間は、「すべての閉域網APIが正常に見える（実際は何もチェックできていない）」という最悪の偽陰性（False Negative）の罠に陥る。
—
結び：オブザーバビリティの領域を広げよ
パブリッククラウドの向こう側、あるいは強固なファイアウォールの裏側に隠されたシステムは、かつて「ブラックボックス」と呼ばれ、監視の空白地帯であった。
しかし、Datadog Synthetic Private Locationをマスターしたエンジニアの手にかかれば、もはや聖域など存在しない。
コンテナのライフサイクルをコントロールし、Terraformでインフラストラクチャをコードとして焼き上げ、ネットワークの低レイヤの挙動までを可視化する。
そのとき、あなたの運用チームは「障害に怯える受動的な守り」から、「予兆を捉えて先手を打つ能動的な支配者」へと進化する。
さあ、今すぐコンテナをデプロイし、閉域網の心音をDatadogのダッシュボードに響かせろ。