Datadogのアカウント作成と初期設定 - 失敗しない組織設計とセキュリティ ​

Datadogを導入し、オブザーバビリティの恩恵を最大限に受けるための道筋は、最初のアカウント作成から始まります。多くのユーザーが「とりあえずアカウントを作ってエージェントを入れればいい」と考えがちですが、Datadogには**「一度設定すると後から変更が極めて困難、あるいは不可能な項目」**がいくつか存在します。

特に大規模な組織や、セキュリティ要件の厳しい企業、グローバル展開を視野に入れている企業にとって、初期の組織設計と権限管理のミスは、後に膨大な移行コストやセキュリティリスクとして跳ね返ってきます。

本記事では、Datadogの「サイト（リージョン）」の選び方から、エンタープライズ向けの組織階層設計、ロールベースのアクセス制御（RBAC）、そしてAPIキーの安全な管理方法まで、運用開始前に知っておくべき重要事項を網羅的に解説します。

1. サイト（リージョン）の選択：不可逆な決断 ​

Datadogのアカウントを作成する際、最初に直面する重要な選択が「Datadog サイト（リージョン）」の選択です。Datadogのデータセンターは世界中に分散しており、それぞれ独立したインスタンスとして存在しています。

主要なサイトと特徴 ​

  • AP1 (ap1.datadoghq.com): 東京リージョン。日本国内の企業に最も推奨されるサイトです。データ主権（データを国内に留める必要がある）の要件を満たし、日本国内のインフラからのデータ送信レイテンシが最小限に抑えられます。
  • US1 (datadoghq.com): 米国メインサイト。最も歴史が古く、全ての新機能が最初にリリースされる標準的な場所です。特段の理由がないグローバル企業で選ばれることが多いです。
  • EU1 (datadoghq.eu): 欧州サイト。GDPR（欧州一般データ保護規則）への厳格な準拠が必要な場合に適しています。
  • US3, US5: それぞれAzure、Google Cloud上でホストされており、特定のクラウドプロバイダーとの近接性を重視する場合に選択されます。

注意事項 ​

最も重要なのは、**「異なるサイト間でのデータ移行やアカウント統合は公式にはサポートされていない」**という点です。US1で作り始めた後に「やはり日本リージョン（AP1）に移そう」と思っても、ダッシュボード、モニター、過去のメトリクスなどを簡単に移行する手段はありません。地理的な近接性、コンプライアンス、そして将来の拡張計画を考慮して慎重に決定してください。

2. 組織設計：シングル組織か、マルチ組織か ​

企業規模が大きくなると、どのようにDatadogのアカウントを分割すべきかという課題が生じます。

シングル組織（Single-Org）の原則 ​

Datadogは基本的に、一つの企業（またはグループ）で一つの組織を使用することを推奨しています。

  • メリット: 全システムの相関分析が容易。ダッシュボードやモニターの設定を共通化できる。ユーザー管理が一元化される。
  • デメリット: 権限管理が複雑になる可能性がある。課金の内訳を部署ごとに手動で計算する必要がある。

マルチ組織（Multi-Org）が必要なケース ​

以下のような特殊な状況下では、親組織と子組織に分ける「マルチ組織」構成が採用されます。

  • マネージド・サービス・プロバイダー（MSP）: 顧客ごとにデータを完全に分離する必要がある場合。
  • 厳格な法的分離: Mergers & Acquisitions（合併・買収）後で、技術的な統合が全く進んでいない、あるいは法的にデータを混ぜることが禁じられている場合。
  • サンドボックス環境: 本番環境の設定を誤って壊さないよう、検証専用の完全に独立した環境を設けたい場合。

Datadogには「Parent-Child」機能があり、親組織から子組織の課金やユーザーアクセスを一定レベルで統制することが可能ですが、基本的には「統合監視」のメリットを享受するために、可能な限りシングル組織でタグ付け（Tagging）によって環境を分離することを検討すべきです。

3. ロールベースのアクセス制御（RBAC）とセキュリティ ​

組織に多数のメンバーが参加する場合、「誰が何を表示し、誰が設定を変更できるか」を管理するRBACの設計が不可欠です。

基本ロールとカスタムロール ​

Datadogには以下の標準ロールが用意されています。

  • Datadog Admin: 組織設定、課金、ユーザー管理を含む全権限。
  • Datadog Standard: ダッシュボードの編集やモニターの作成ができる、一般的なエンジニア向けロール。
  • Datadog Read Only: 設定変更ができず、表示のみが可能なロール。

しかし、大規模な環境では、これだけでは不十分です。「ログは閲覧できるが、APMは見せたくない」「共有ダッシュボードの編集は特定のリーダーだけに限定したい」といったニーズに対して、カスタムロールを作成し、各権限（Permission）を細かく（Granular）設定することが推奨されます。

多要素認証（MFA）とSSO ​

セキュリティの観点から、以下の2点は必須の設定です。

  • MFAの強制: TOTP（アプリ）やWebAuthnによる認証を全ユーザーに義務付けます。
  • Single Sign-On (SSO): Okta、Azure AD (Entra ID)、Google Workspace などの IdP と SAML 連携を行います。SSO を導入することで、社員の入退社に伴う権限剥奪を自動化し、野良アカウントの発生（シャドーIT化）を防ぐことができます。

4. APIキーとアプリケーションキーの厳格な管理 ​

Datadogを使いこなすには、APIによる自動化（Terraform、CI/CD連携、カスタムメトリクス送信など）が欠かせません。そのために使用されるのが API Key と Application Key です。

API Key（APIキー） ​

  • 用途: データの送信用（Datadog AgentがDatadogにメトリクスを送る際に使用）。
  • 性質: 組織全体で共有され、データの「書き込み」に特化した権限を持ちます。

Application Key（アプリケーションキー） ​

  • 用途: 設定の操作やデータの取得（ダッシュボードの更新、ログの検索など）。
  • 性質: 特定のユーザーに紐付けられ、そのユーザーと同じ権限を行使します。

管理のベストプラクティス ​

  1. 最小権限の原則: 2022年に導入された「Scoped Application Keys」を活用し、そのキーが実行できる操作（例：モニターの読み取りのみ）を限定してください。
  2. 個人のキーをサービスに使用しない: CI/CDパイプラインやTerraformで使用する場合、個人ユーザーのキーではなく、専用の「サービスアカウント（Service Account）」を作成し、そのアカウントのキーを使用してください。これにより、担当者の退職によってシステムが停止するリスクを排除できます。
  3. キーのローテーション: 定期的にキーを再発行し、古いキーを無効化する運用ルールを設けてください。

5. まとめ：堅牢な基盤が優れた運用を生む ​

Datadogの導入成功は、最初の数時間の「設定作業」にかかっています。適切なサイトを選択し、SSOによる安全な入り口を整え、最小権限に基づいたRBACを設計することで、エンジニアが安心して、自由にかつ安全にモニタリング機能を活用できる環境が整います。

「とりあえず」で始めた環境を後から修正するのは、空中の飛行機のエンジンを修理するようなものです。本記事で紹介したベストプラクティスを参考に、まずは「堅牢な基盤」を構築することから始めてください。

関連記事:

出典: