---
title: "CloudFormation を使用した Datadog のデプロイと構成"
description: "Datadog を AWS CloudFormation と併用して、インフラストラクチャーをコードとして定義することで可視性を向上する方法を確認。"
author: "David M. Lentz"
date: 2019-01-14
tags: ["インフラストラクチャ モニタリング", "aws", "aws cloudformation", "cloudformation", "コードとしてのモニタリング"]
blog_type_id: the-monitor
locale: ja
---

この記事では、AWS CloudFormation を利用して Datadog へメトリクスおよびログを送信することを事前に構成されたインフラストラクチャーを自動的にデプロイする方法をご紹介します。この仕組みを解説するため、CloudFormation のサンプルテンプレートを使用します。まず Apache Web サーバーを実行する EC2 インスタンスを作成し、Datadog Agent をインストールして API キーで構成し Datadog と Apache のインテグレーションを可能にします。まだ Datadog をご使用でない場合は、<!-- Sign-up trigger (14 日間の無料トライアル) omitted -->を利用して、この記事でご紹介する方法をお試しください。

## AWS CloudFormation とは？

CloudFormation は、AWS が提供する構成管理サービスで、インフラストラクチャーをプログラムに従い作成および更新できます。CloudFormation の**テンプレート**は、お客様が希望するインフラストラクチャーを記述した JSON または YAML ファイルです。テンプレートは、各リソース（EC2 インスタンスタイプなど）のプロパティと、希望するインフラストラクチャーのステータスを保持するために CloudFormation が適用するコンフィギュレーションを定義します。各テンプレートは、EC2 インスタンス、VPC、Elastic Load Balancer、IAM ロールなどの関連リソース群である**スタック**を定義します。スタックのコンポーネントは、テンプレートの `Resources` セクションで定義されます。たとえば、CloudFormation を使用して事前定義された Amazon Machine Image (AMI) から EC2 インスタンスを作成する場合、テンプレートには以下のような YAML が含まれます。

```text
Resources:
  MyEC2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      InstanceType: t2.small
      ImageId: ami-011b6930a81cd6aaf
```

A CloudFormation テンプレートは、**コードを使用したインフラストラクチャー**です。インフラストラクチャーを作成する特定のパスを定義する命令型のコードではなく、テンプレートでは新しいスタックや既存のスタックへのリビジョンを定義するための宣言型の言語と言えます。テンプレートを実行（CloudFormation コンソール、SDK、または CLI を使用）すると、CloudFormation がインフラストラクチャーのステータスを確認し、事前に宣言されたご希望のステータスでない場合はそれを保持するよう必要なステップを実行します。

通常のコードのように、インフラストラクチャーを記述するテンプレートはバージョン管理をして再利用が可能です。CloudFormation のテンプレートを実行するたびに、テンプレートに基づき他のスタックと同一のスタックを作成するため、さまざまな目的（QA、開発など）に同一の環境を実行することができます。また、[ブルー/グリーンデプロイメント](https://aws.amazon.com/blogs/devops/bluegreen-infrastructure-application-deployment-blog/) など DevOps のプラクティスをサポートします。

CloudFormation は、インフラストラクチャーをコードとして管理する目的で使用される [Chef](https://www.datadoghq.com/blog/deploying-datadog-with-chef-roles.md) や [Ansible](https://www.datadoghq.com/blog/deploy-datadog-ansible-reporting.md) などのコンフィギュレーション管理ソフトウェアに似ています。

## CloudFormation + Datadog

CloudFormation を使用すると、容易に識別可能なインフラストラクチャーをデプロイできます。CloudFormation テンプレートに Datadog Agent のコンフィギュレーションとデプロイを含めることで、オンラインになると同時にインフラストラクチャーを可視化することが可能になります。

Datadog Agent は、メトリクスやログ、分散リクエストのトレースを収集し Datadog アカウントに送信するオープンソースの軽量なアプリケーションです。EC2 インスタンスで Agent を実行すると、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) で報告される以上のホストレベルのメトリクスをすぐに確認し、Datadog でログおよび wAPM データを可視化できます。

![EC2 インスタンスからのメトリクスおよびログが表示された Datadog カスタムダッシュボード](https://web-assets.dd-static.net/42588/1776299014-deploying-datadog-with-cloudformation-custom_timeboard4.png)

## Datadog インテグレーションのテンプレート

この [デモンストレーションテンプレート](https://gist.githubusercontent.com/davidmlentz/8e90571c63fda3e45b26dfb3ce5c7d2b/raw/6773bf0e584e93d232127c4b34b9ea7fdcfefdcc/datadog_cloudformation.yaml) では 2 つの AWS リソースが作成されます。EC2 インスタンス (Apache サーバーを含むためテンプレートで MyWebServerInstance として識別される) および、インスタンスのポート 80 のトラフィックを許可する関連するセキュリティグループ (MySecurityGroup として識別される) です。このテンプレートは Datadog API キーをパラメーターとして許可し、ホストが自動的にメトリックとログを Datadog アカウントに送信できるようにします。このセクションでは、デモンストレーションテンプレートの仕組みを確認し、テンプレートが生み出すスタックの主要な特性を定義するコードについて説明します。例となる CloudFormation テンプレートは複数のセクションに分解され、各セクションがスタック作成において役割を果たします。

- **Parameters: **このセクションはテンプレート実行時に提供される値を定義します。CloudFormation はユーザーが渡したパラメーター値 (またはパラメーターのデフォルト値) を使用して、Datadog の API キーまたは SSH キーペアの名前といったスタックのプロパティを構成します。
- **Resources:** CloudFormation の唯一の必須セクションであり、テンプレートで作成される (または更新される) AWS リソースを定義します。
- **Outputs:** このセクションはテンプレート実行時に返される値を定義します。各出力キーの名前はテンプレート内で定義されており、その値はテンプレートの実行が完了した際に返されます。

CloudFormation に含まれるその他のセクションとしては、**説明**、**変換**、**メタデータ**、**条件**、そして**マッピング**などがあります。これらのセクションについて詳しくは、[CloudFormation ユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html) を参照してください。

### Parameters セクション: API キー

テンプレートの最初のセクションは、パラメーターの定義です。CloudFormation テンプレートでは `Parameters` セクションは任意ですが、テンプレートのパラメーターを定義することで、ユーザーにテンプレートにプラグインされる値の提供を求め、リクエストされたリソースを構成することができます。デモテンプレートでは `APIKey` パラメーターのみを定義します。

```text
Parameters:
  APIKey:
    Description: "The API key for your Datadog account"
    Type: String
```

テンプレートを実行する際に Datadog API キーを入力し、CloudFormation が Agent を構成して Datadog アカウントにデータを送信できるようにします。

### Resources セクション: メタデータ

メタデータキー `AWS::CloudFormation::Init` を使用して、例えば表示されるべきユーザーやグループ、実行されるべきサービスなど、EC2 インスタンスの特性を指定することができます。これによりインスタンスのコンフィギュレーションの自動化について柔軟性が大幅に向上します。`AWS::CloudFormation::Init` を使ってできることについて詳しくは、[AWS のドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html) を参照してください。

このデモンストレーションテンプレートでは、`AWS::CloudFormation::Init` でインスタンスコンフィギュレーションの詳細が**コンフィグセット**と呼ばれる 3 つのグループに分類されています。コンフィグセットで、インスタンスのコンフィギュレーションを、インストール待ちパッケージ、Apache および Agent 向けコンフィギュレーションの詳細、更新されたコンフィギュレーションを適用するためにサービスの再起動を求める指示という 3 つのロジカルな領域に整理します。以下の YAML スニペットはコンフィグセットの定義を表しています。

```text
      AWS::CloudFormation::Init:
        configSets:
          # コンフィグセットとそれに含まれるコンフィグキーの一覧:
          Install:
            - "installHttpd"
            - "installDatadogAgent"
          Configure:
            - "configureModStatus"
            - "enableLogs"
            - "configureLogs"
          Restart:
            - "restart"
```

それぞれのコンフィグセットにはコンフィギュレーションアイテムのリストが 1 つだけ含まれ、**コンフィグキー**と呼ばれます。これがコンフィギュレーションの詳細を指定します。以下のセクションでは、各コンフィグキーに関して、実行されるコマンドとインスタンスにインストールされるパッケージを定義する YAML を見ていきます。

テンプレートが実行されると、CloudFormation はすべてのコンフィグキーを読み込み、望ましいコンフィギュレーションを実現する方法を決定するスクリプトをトリガーします。このプロセスについては、UserData のセクションで詳しく確認します。

#### コンフィグセット: インストール

セットに含まれる最初のコンフィグキー `installHttpd` には、インスタンスに Apache がインストールされ、実行されていることを確認する指示が含まれます。

```text
    installHttpd:
      packages:
        yum:
          httpd: []
      services:
        sysvinit:
          httpd:
            enabled: true
            ensureRunning: true
```

次のコンフィグキー `installDatadogAgent` は、ワンステップのインストールスクリプトを使用して Agent をダウンロード、インストールします。ユーザーがパラメーターとして提供した API キーをプラグインします。

```text
    installDatadogAgent:
      commands:
        01_download_and_install:
          env:
            DD_API_KEY: !Sub "${APIKey}"
          command: "bash -c \"$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)\""
```

#### コンフィグセット: 構成

`Configure` コンフィグセットに含まれる要素は Apache のコンフィギュレーションを変更し、次いで Agent のコンフィギュレーションを更新して Apache からタグメトリクスとログを収集できるようにします。

このコンフィグセットの最初のキー `configureModStatus` は、Apache の「mod_status」モジュールを有効化します。これにより Agent が [Apache のステータスページ](https://www.datadoghq.com/blog/collect-apache-performance-metrics.md#apache-s-status-module) をメトリクスデータのソースとして使えるようになります。

```text
    configureModStatus:
      commands:
        01_add_config:
          command:
            !Sub |
              cat <<EOT > /etc/httpd/conf.d/server-status.conf
                # /server-status ページの
                ExtendedStatus を有効にする
                <Location /server-status>
                SetHandler server-status
                Allow from localhost
                </Location>
                EOT
```

`mod_status` モジュールについて詳しくは、[Apache ドキュメント](https://httpd.apache.org/docs/2.4/mod/mod_status.html) を参照してください。

次のコンフィグキー `enableLogs` は、**datadog.yaml** ファイルを更新し、Agent がログを収集できるようにします。次に [アクセス制御リスト (ACL)](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/acls-setting) を Apache がログを保存するディレクトリに設定し、Agent がアクセスできるようにします。このコンフィグキーはさらに、ACL の指示をホストの `logrotate` コンフィギュレーションに追加し、Apache のログがロテートされた際に自動的に再適用されるようにします。

```text
    enableLogs:
      commands:
        01_update_datadog_yaml:
          cwd: "/etc/datadog-agent/"
          command: "sed -i 's/^# logs_enabled: false$/logs_enabled: true/' datadog.yaml"
        02_fix_logfile_permissions:
          command: "setfacl -m u:dd-agent:rx /var/log/httpd"
        03_sed_logrorate:
          cwd: /etc/logrotate.d
          command: "sed -i 's#/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true#/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true; setfacl -m u:dd-agent:rx /var/log/httpd#' httpd"

```

`configureLogs` キーは Agent の Apache コンフィギュレーションファイルを更新し、アクセスログおよびエラーログを収集してタグ付けできるようにします。また、Apache のステータスページからメトリクスを収集します。

```text
    configureLogs:
      commands:
        01_create_apache_conf_yaml:
          cwd: "/etc/datadog-agent/conf.d/apache.d/"
          command:
            cp conf.yaml.example conf.yaml
        02_update_apache_conf_yaml:
          cwd: "/etc/datadog-agent/conf.d/apache.d/"
          command:
            !Sub |
              cat <<EOT >> conf.yaml
                logs:
                - type: file
                    path: /var/log/httpd/access_log
                    source: apache
                    sourcecategory: http_web_access
                    service: myservice
                    tags:
                    - env:qa
                - type: file
                    path: /var/log/httpd/error_log
                    source: apache
                    sourcecategory: http_web_access
                    service: myservice
                    tags:
                    - env:qa
                EOT
```

このキーの最初のコマンドは、サンプルコンフィギュレーションファイル [**conf.yaml.example**](https://github.com/DataDog/integrations-core/blob/master/apache/datadog_checks/apache/data/conf.yaml.example) を **conf.yaml** にコピーし、Agent が認識して利用できるようにします。2 つ目のコマンドはファイルに `logs` 要素を追加します。これが Apache のログファイルへのパスを指定し、Agent にログを `service: myservice` および `env: qa` でタグ付けするように指示します。これらのタグはニーズに沿ってカスタマイズできます。`source` タグは Datadog に受信ログを Apache 独自の [処理パイプライン](https://docs.datadoghq.com/logs/processing/pipelines.md) を通じて転送するように指示し、`sourcecategory` タグはホストまたはサービス全体で関連するログを集計する役に立ちます。これらのタグの使い方について、詳しくは[タグ付けに関するドキュメント](https://docs.datadoghq.com/tagging.md) を参照してください。

#### コンフィグセット: 再起動

`restart` キーのコマンドは Apache と Agent を再起動し、コンフィギュレーション上のすべての変更を適用します。

```text
    restart:
      commands:
        01_restart:
          command: "systemctl restart httpd.service; systemctl stop datadog-agent.service; systemctl start datadog-agent.service"
```

### Resources セクション: インスタンスプロパティ

テンプレートの `Properties` セクションでは、作成対象の `MyWebServerInstance` の特性が定義されています。

#### UserData

インスタンスは、起動時にテンプレートの `UserData` セクションで bash スクリプトを実行します。まず、このスクリプトは対象のインスタンスに `aws-cfn-bootstrap` パッケージのアップデート指示を送信します。

```text
yum update -y aws-cfn-bootstrap
```

このパッケージには CloudFormation がインスタンスの構成時に使用するヘルパースクリプトが含まれています。これらのヘルパースクリプトのひとつが `cfn-init` です。CloudFormation は `cfn-init` を呼び出し、テンプレートの [`AWS::CloudFormation::Init` セクション](#resources-section-metadata) で定義されている 3 つのコンフィグセット（`Install`、`Configure`、`Restart`）を参照します。

```text
/opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource MyWebServerInstance --configsets Install,Configure,Restart --region ${AWS::Region}
```

#### InstanceType

`InstanceType` の値は EC2 インスタンスのクラスとサイズを表します。

```text
InstanceType: t2.nano
```

このデモテンプレートでは、`InstanceType` が `t2.nano` としてハードコーディングされています。より柔軟性の高いテンプレートでは `InstanceType` をパラメーターとして含めることができるため、ユーザーはテンプレートの実行時に `InstanceType` の値を選択することが可能となります。

`ImageId` エレメントは、CloudFormation が作成対象のインスタンスの基盤として使用する AMI を指定します。

```text
ImageId: ami-011b6930a81cd6aaf
```

このデモテンプレートでは us-west-1 リージョン向けの Amazon Linux 2 AMI を指定しています。テンプレートのコピーを変更して、異なるリージョンのイメージを指定することも可能です（異なるリージョンの AMI 用の `ImageId` を検索するには、AWS コンソールの EC2 セクションを開いて **Launch Instance（インスタンスの起動）**を選択します）。リリース可能な CloudFormation テンプレートには、各リージョンで利用できる AMI のマッピングが含まれ、テンプレートが実行されるリージョンとして適切なものが自動選択されます。そのため、テンプレートはどのリージョンでも再利用することができます。テンプレートを作成し、任意のリージョンとインスタンスタイプに応じた正確な AMI ID をプログラム上で決定する方法については、[AWS に関するこちらのドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/walkthrough-custom-resources-lambda-lookup-amiids.html)を参照してください。

### Resources セクション: セキュリティグループ

AWS のセキュリティグループは仮想ファイアウォールとして機能し、お使いのインフラストラクチャーを起点または着地点とするトラフィックのフローを統括します。すべての EC2 インスタンスには少なくとも 1 つの関連するセキュリティグループが存在し、基本的には[デフォルトのセキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#default-security-group)が適用されています。しかし、デフォルトのセキュリティグループがポート 80 から発される（またはそこへ向かう）トラフィックを許可しない場合、デモテンプレートが例外的にポート 80 へアクセスするためのカスタムセキュリティグループを作成します。

```text
  MySecurityGroup:
    Type: "AWS::EC2::SecurityGroup"
    Properties:
      GroupDescription: "Allow web traffic"
      SecurityGroupIngress:
      - CidrIp: 0.0.0.0/0
        FromPort: '80'
        IpProtocol: tcp
        ToPort: '80'
```

### Outputs セクション

EC2 インスタンスの作成後、CloudFormation はテンプレートに定義された出力変数に該当する値を返します。

```text
Outputs:
  URL:
    Description: "The URL of this instance's website"
    Value: !Sub "http://${MyWebServerInstance.PublicIp}"
  InstanceDashboard:
    Description: "Link to this instances's Datadog dashboard"
    Value: !Sub "https://app.datadoghq.com/dash/host_name/${MyWebServerInstance}"
```

以下では、`URL` と `InstanceDashboard` 出力値を使用して Datadog でスタックのモニタリングをはじめる方法について解説します。

## 統合スタックの作成

上記でもご説明したように、デモテンプレートには Apache サーバー（お使いの Datadog アカウントにメトリクスとログを送るよう構成）を稼働させる EC2 ホストを含む小規模スタックが定義されています。このセクションでは、テンプレートを実行してスタックを作成し、Datadog 上でインスタンスのメトリクスとログを確認する方法を順にご紹介します。

### テンプレートの実行

[デモテンプレート](https://gist.githubusercontent.com/davidmlentz/8e90571c63fda3e45b26dfb3ce5c7d2b/raw/6773bf0e584e93d232127c4b34b9ea7fdcfefdcc/datadog_cloudformation.yaml)をローカル環境にダウンロードした後、AWS コンソールの CloudFormation ページを開きます（このデモでは us-west-1 （**米国西部（北カリフォルニア）**）リージョンを使用してください。 [当該リージョンの AMI を指定](#resources-section-instance-properties)しているためです）。その後、**Create Stack（スタックの作成）**をクリックし、**Choose a template（テンプレートの選択）**から **Choose File（ファイルの選択）**を選んでテンプレートのローカルコピーを指定します。その後、**Next（次へ）**をクリックします。

次の画面で、**Stack name** フィールドにスタックの名前、**APIKey** フィールドに Datadog の API キーを入力してください（API キーが不明な場合は[こちらのページ](https://app.datadoghq.com/account/settings#api)の **API Keys** セクションを参照してください）。

次の画面では、**Key** と **Value** フィールドを使用してオプションでスタックをタグ付けすることができます。ここで追加したタグはすべて、スタック内のすべてのリソース（この場合は、EC2 インスタンスとセキュリティグループ）および CloudFormation 自体の双方に適用されます。これらのタグは自動で Datadog に取り込まれるため、モニタリングしたすべてのデータのフィルタリングや集約をすばやく行うことができます。1 つ以上のタグを追加する場合は、画面右側の＋マークをクリックします。このページに存在するその他のフィールドは空のままで構いません。画面を下にスクロールして **Next（次へ）**をクリックします。

入力したスタック情報を再度確認し、**Create（作成）**をクリックします。

その後、画面にスタックの一覧を含む表が表示されます。**Status** カラムは作成したスタックの最新ステータスを示します。作成当初は **CREATE_IN_PROGRESS** と表示されています。

![AWS コンソールに、スタック作成が進行中であることが表示されます。](https://web-assets.dd-static.net/42588/1776299018-deploying-datadog-with-cloudformation-create_in_progress1.png)

数分後にステータスが **CREATE_COMPLETE** に変わればこのプロセスは完了です。

### ホストのメトリクスとログを確認

スタックの作成が完了したら、表内で対象のスタックの行をクリックして選択し、**Outputs（出力）**タブをクリックします。

![AWS コンソールに、スタックの作成が完了した旨が表示されます。](https://web-assets.dd-static.net/42588/1776299022-deploying-datadog-with-cloudformation-create_complete2.png)

**InstanceDashboard** 行にある値をクリックし、お使いの Datadog アカウントのホストダッシュボードを開きます。

![新しい EC2 インスタンスのダッシュボードを、お使いの Datadog アカウントで確認できます。](https://web-assets.dd-static.net/42588/1776299027-deploying-datadog-with-cloudformation-host_dash2.png)

ここから、新しいスタックで作成された EC2 ホストから Datadog へメトリクスを送信できるようになります。AWS コンソールに戻り、**Outputs（出力）**タブで **URL** の値をクリックしてブラウザで当該インスタンスのウェブサイトを読み込みます。ページを数回再読み込みし、お使いの Web サーバーに向けたトラフィックを生成しましょう。その後、ホストダッシュボードに戻って **Apache - Hits rate（Apache ヒット率）**のグラフを確認します。先ほどブラウザで生成したトラフィックが、以下のスクリーンショットのようにグラフ上で急上昇する形で表れているのが確認できるでしょう。Agent から Apache のステータスページへ定期的なコールがかかる関係で、グラフ上には定期間隔でその他のリクエストも反映される可能性があります。

![apache_hits_rate2a](https://web-assets.dd-static.net/42588/1776299031-deploying-datadog-with-cloudformation-apache_hits_rate2a.png)

グラフ上のホストメトリクスを確認したら、関連するログもみてみましょう。**Apache - Hits rate（Apache ヒット率）**グラフ上の点をクリックし、 **View related logs（関連するログを表示）**オプションを選択するだけで簡単に切り替えが可能です。

![apache_hits_rate2b](https://web-assets.dd-static.net/42588/1776299036-deploying-datadog-with-cloudformation-apache_hits_rate2b.png)

ログエクスプローラーには、以下のスクリーンショットのように、お使いのホスト上の時間に基づく Apache のログが表示されます。

![ログエクスプローラーのビューは、上記のメトリクスと同じソース値を共有するログを表示します。](https://web-assets.dd-static.net/42588/1776299040-deploying-datadog-with-cloudformation-log_explorer3.png)

## CloudFormation を使用して Datadog を デプロイ

この記事では、Apache サーバーが稼働する EC2 インスタンスのデプロイ方法、Datadog Agent をインストールおよび構成して Apache とホスト自体を監視する方法をご紹介しました。CloudFormation を使って Datadog をご利用いただく場合、このテンプレート上にビルドして  1,000 種類にのぼる Datadog のその他のインテグレーションを構成することもできます。Datadog をまだご利用でないお客様は <!-- Sign-up trigger (14 日間の無料トライアル) omitted -->をぜひお試しください。