2020.11.30 AWS

Cloudformationとは？

目次

– 概要
– AWSの構築自動化サービス
– CloudFormationの概念
– CloudFormationの運用ベストプラクティス
– SAMとは
– まとめ

CloudFormationとは？

CloudFormationとは、AWS(Amazon Web Services)内でサーバやネットワークといった
インフラリソースの構築を自動化を行えるサービスです。
事前にテキストファイルを用意し、テキストファイルにインフラの構成を記載しておくことで
インフラリソースの自動構築を行える、Infrastructure as Codeの性質を持っています。
例えば以下のような要件があったとき、CloudFormationが使えます。

  • AWSのインフラリソース構築を、自動で行いたい
  • インフラをコード化し、バージョン管理をしたい
  • インフラリソースの変更を検知したい

具体的な機能や、運用方法について、詳しく記載していきます。

AWSの構築自動化サービス

CloudFormationの説明の前に、AWSでは構築自動化サービスが複数用意されています。
ほかの構築自動化サービスを知っておくことで、CloudFormationがカバーする範囲を理解することができます。

CloudFormation

CloudFormation主に、ネットワーク、IAMなどのセキュリティ、EC2などのサーバといった、インフラ部分を構築することができます。
AWS上のほとんどすべてのインフラリソース構築を行えます。
逆に、アプリケーションのコードを自動でサーバに展開する、といった目的には向いていません。

Elastic Beanstalk

EC2、RDS、ELBといった限られたサービスの構築と、アプリケーションのデプロイを自動で実行します。
標準的なITシステムの構成を自動で構築したいときに向いていますが、複雑なインフラリソースの構築には向いていません。

Code Deploy

アプリケーションのコードを自動で展開することができます。
展開のオプションなどもそろえてあり、アプリケーションの自動デプロイに特化しています。
インフラリソースの自動構築には向いていません。

OpsWorks

OpsWorksは、Chefと呼ばれるオープンソースのソフトウェアをベースに作られた自動構築サービスです。
ミドルウェアの設定や、OSの設定、アプリケーションのコード配布など、
Chefを使って行うような、ミドルウェア～アプリケーションの操作を自動的に行えます。

CloudFormationがカバーする範囲

このようにAWSでは自動でインフラやアプリケーションの構築を行える様々なサービスが用意されています。
その中でも、Cloudforomationはインフラリソースを自動で構築することに特化しています。

CloudFormationの概念

CloudFormationの全体像や、用語について説明していきます。
CloudFormationを理解する上で必要な用語は、以下の2点です。

  • テンプレート
  • スタック

それぞれどのような内容なのか、詳しく見ていきます。

テンプレート

テンプレートは、どのようなインフラリソースを構築するか、といった内容を記載するファイルです。
YAMLかJSONのファイル形式で記載する必要があります。
テンプレートを構成する要素は以下の通りです。

  • AWSTemplateFormatVersion
    CloudFormationのテンプレートバージョンを記載します。
  • Description
    テンプレートがどのようなものなのか、説明文を記載します。
  • Metadata
    テンプレートに関する追加情報を記載します。
  • Parameters
    テンプレートによりインフラリソースを構築する時に、ユーザに入力させる情報を定義できます。
    例えば、CloudFormationでインフラリソースを構築させるときに、構築者の名前などを入力させる、といったことが可能です。
  • Conditions
    インフラリソースが構築されていく際に、条件分岐を行いたいときに利用します。
    例えば、開発環境と本番環境のインフラリソースを分けたいときに、
    『開発環境のVPCであればm4.large、本番環境のVPCであればm4.2xlargeをデプロイする』などの条件分岐を作成できます。
  • Resources
    EC2やELBなど、構築したいリソースを定義します。
    他の項目は記載の必要がありませんが、この項目は記載が必須となっています。
    リソースのタイプと、どのようなリソースを構築したいのかを記載します。
    たとえば、以下のようなテンプレートを考えてみます。
Resources:
  testVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 172.16.0.0/16

これは、CIDRブロックが172.16.0.0/16で、「testVPC」という名前のVPCが構築されます。

  • Outputs

ほかのテンプレートに、値を渡したいときに利用します。
例えば、テンプレートAで構築したVPCのIDを、テンプレートBでも利用したい場合、
テンプレートAのOutputs要素にExportの記載をしておくことで、テンプレートBでもVPCのIDが参照できるようになります。

テンプレート内の組み込み関数

テンプレート内では、以下のような関数を利用することができます。

  • !Ref関数
    リージョン名やリソースのIDを参照することができます。
    例えば、
    !Ref “AWS::Region”
    などと記載を行えば、テンプレートを実行しているAWSのリージョンを参照することができます。
  • !GetAtt関数
    リソースが持つ属性値を取得することができます。
    例えば、
    !GetAtt Ec2Instance.PublicDnsName
    などと記載を行えば、EC2インスタンスのDNS名を取得することができます。

スタック

スタックとは、1つのCloudFormationテンプレートから作成されるリソースの集合です。
CloudFormationでは、スタック単位でリソースの管理が可能になります。
例えば、スタックを削除すると、スタックに紐づくリソースがすべて削除されます。
スタックを作成する方法は、以下の3つです。

  • CloudFormationのマネジメントコンソールから作成
    テンプレートファイルの格納先S3などを指定して、GUIで作成ができます。
  • AWS CLIで作成
    IAMロールがアタッチされたEC2などから、CLIで操作が可能です。
  • AWS SDKなどで作成
    PythonやJavaなどでSDKが用意されており、スタックの操作が可能です。

CloudFormationの運用ベストプラクティス

CloudFormationはインフラリソースを自動で作成でき、
インフラ構築の工数を大幅に削減できる可能性を持っています。
ただし、むやみに使いすぎるとスタックが乱立してしまい、管理が煩雑になったり、
スタックを誤削除してしまったりと、思わぬ障害の原因になることがあります。
運用のベストプラクティスを理解することで、CloudFormationを最大限に活用することができます。

テンプレート管理に向けた機能

CloudFormationの運用管理に便利な、複数のスタックを連携できる機能を紹介します。。

  • ネストスタック
    ネストスタックとは、各テンプレートの共通部分を専用テンプレートとして作成し、
    スタックの親子関係を実現することができる機能です。
    たとえば、1つのアカウントの中で、何個もVPCやELBなどのリソースを作成する場合、
    VPC専用のスタック、ELB専用のスタックを作成しておけば、
    あとはスタックの組み合わせで迅速にインフラリソースを構築することができます。
  • Cross Stack Reference
    スタック間で値の参照が可能な機能です。
    例えば、VPC、セキュリティグループを自動構築するテンプレートファイルを個別に作成しておくと、
    VPCのテンプレートファイルをA、セキュリティグループのテンプレートファイルをBとし、
    BのテンプレートからAに記載されたVPCのIDを参照する、といった使い方ができます。
    この機能の利点は、VPCやセキュリティグループのIDなどをテンプレートにハードコーディングすることを回避し、
    テンプレートの再利用を可能したり、オーバーヘッドを防止したり、といったことができます。
  • Dynamic Reference
    ひんぱんに更新されるAWS AMIのIDや、セキュリティ要件で一定期間の間にローテーションさせる必要があるRDSの接続情報など、
    変更が予想され、ハードコーディングを行うと管理が困難になることが予想されるものについては、
    SystemsManagerのパラメータストアや、Secrets Managerにデータを格納しておき参照させるようにするといいでしょう。
  • ChangeSet
    テンプレートファイルを変更・修正した場合、影響を受けるリソースを事前に把握することができる機能です。
    リソース変更時は、リソースの停止や再作成が行われることもあります。
    この機能を活用することで、思わぬサービス停止を回避することができます。
  • ドリフト検出
    スタックと、現状のリソースの差分を検出できます。
    CloudFormationでリソースを作成した後、手動やAWS CLIなどで変更を行って、テンプレートファイルと差分が出てしまった箇所を
    事前に把握しておくことで、環境のデグレーションを防ぐことができます。
  • Stackの削除保護
    スタックが誤って削除されることを防ぎます。
    本番環境で利用されているリソースについては削除保護を有効にしておくといいでしょう。
    また、スタックポリシーと呼ばれるJSONファイルを利用することで、個別のリソースについての削除保護も可能です。
  • DeletionPolicy
    Stack削除時に、EC2やRDSのバックアップ等を取得したい場合はDeletionPolicyに定義しておくことが可能です。
    Delete,Retain(保持),Snapshot(スナップショット取得)が指定可能です。

運用のベストプラクティス

それでは、上記のテンプレート管理に向けた機能を利用し、運用のベストプラクティスを記載していきます。

  • テンプレートはレイヤや更新タイミングを考慮して分ける
    たとえば、VPCはあまり変更が入らないリソースですが、とセキュリティグループはVPCに比べて変更が入りやすいリソースといえます。
    したがって、VPCとセキュリティグループのテンプレートを分けておくと、デグレやオペレーションミスを防ぐことができます
  • 変更のフローを決めておく
    CloudFormationを利用していて一番恐ろしいことは、
    うっかり既存で稼働しているリソースを削除してしまい、障害を起こしてしまうことです。
    したがって、変更を行うためのフローを事前に決めておく必要があります。
    以下のような流れであれば安全でしょう。

  • ドリフト検出を行い、差分の有無を確認する。

  • テンプレートを更新する。
  • Change Setを確認する。
  • スタックを更新、テンプレートはGitなどで管理する。
    また、上記のフローの中で、レビュー者や開発・リリースを行う者など、
    役割分担を組織内で行っておくとスムーズに開発が進みます。

サーバレスアプリケーションモデル（SAM）とは？

サーバレスアプリケーションモデルとは、CloudFormationの拡張機能です。
LambdaやAPI Gateway、DynamoDBといった、サーバレスのリソースについては、サーバレスアプリケーションモデルと呼ばれるフレームワークを利用して、テンプレートファイルの記載を簡略化することができます。
具体的には、通常のCloudFormationテンプレートと比較して5割～8割の行数でテンプレートを作成できるほか、専用のCLIなどが用意されており、高速開発に役立ちます。

まとめ

CloudFormationはテンプレートの作成や運用について難しい点がありますが、
きちんと理解して利用すると、インフラの高速開発が可能になり工数の大幅な削減が見込めます。
便利な機能や公式のサンプルテンプレートも用意されているので、
これらを活用して生産性の高い高速開発を実現してみてください。

RECOMMENDこちらの記事も人気です。