【AWS】【技術紹介】CloudFormation利用時の​工夫と​運用時の​注意点

はじめに

SKYPCEでは、Amazon SES・SNS・SQSを連携し、メール配信を担う基盤をAWS上に構築しています。

このような複数のサービスが絡むインフラを手作業で構築しようとすると、人的な設定ミスなどが生じやすくなります。

私たちのチームでは、お客様に提供する環境を正しく構成するために、AWS CloudFormationでインフラをコード化（IaC）し、同じ構成を安全に再現できる仕組みを整えています。

本記事では、CloudFormationを用いたメール配信基盤を構築例にして、その際の工夫と運用時の注意点についてご紹介します。

そも​そも​CloudFormationとは？

AWS CloudFormationは、AWS上のさまざまなリソースをJSONやYAML形式のテンプレートで定義し、自動的に構築・管理できるサービスです。

手動でマネジメントコンソールをクリックしながら構築する代わりに、設計図となるテンプレートをアップロードするだけで、AWSがその内容通りに自動で環境を構築してくれます。

これにより、誰が実行しても同じ環境を、迅速かつ正確にデプロイできるのが利点です。

利用時の​工夫：パラメータ活用に​よる​環境の​共通化

SKYPCEでは用途に合わせて開発（dev）、貸出（trial）、本番（prod）といった複数の独立したインフラ環境を用意しています。

もし環境ごとに別々のテンプレートを作成してしまうと管理が煩雑になり、設定漏れや環境差異を生む原因となってしまいます。

それを防ぐため、以下のように環境名（dev/trial/prodなど）を外部からの変数として受け取れるように設計し、同じ1つのテンプレートから環境ごとにリソースをデプロイしています。

Parameters:
  EnvironmentName:
    Type: String
    AllowedValues:
      - dev
      - trial
      - prod
    Description: デプロイする環境名を選択してください

Resources:
  MySQSQueue:
    Type: AWS::SQS::Queue
    Properties: 
      # パラメータを活用して、環境名に応じたリソース名を自動生成
      QueueName: !Sub "EmailBounceQueue-${EnvironmentName}"

  MySNSTopic:
    Type: AWS::SNS::Topic
    Properties: 
      TopicName: !Sub "EmailBounceTopic-${EnvironmentName}"

  MySubscription:
    Type: AWS::SNS::Subscription
    Properties: 
      Endpoint: !GetAtt MySQSQueue.Arn
      Protocol: "sqs"
      TopicArn: !Ref MySNSTopic

運用時の​注意点：手動設定の​巻き戻りを​防ぐ​取り組み

システムの運用中には、新しい機能の追加などでリソースの更新を行う機会があるかと思います。

そこで注意しなければならないのが、マネジメントコンソールなどから行った手動変更が、最新のテンプレートによって上書きされ過去の状態に巻き戻ってしまう事象です。

この事象を防ぎ、リソースを安全に更新するために以下のような4つのステップで対策を行っています。

ステップ	内容	概要
Step 1	ドリフト（Drift）検出による現状把握	現在のリソースとテンプレートの差分を把握
Step 2	手動変更のテンプレートへのフィードバック	手動変更を最新としてテンプレートを修正、または既存スタックへのインポート
Step 3	変更セット（Change Sets）による最終確認	適用直前に、意図しないリソースの更新がないかを最終確認
Step 4	実行後の設定値確認	AWS ConfigやAWS CLIを使用し、意図通りに反映されたか確認

各ステップの​詳細

Step 1：ドリフト​（Drift）​検出に​よる​現状把握

CloudFormationには、現在のAWSリソースの状態と、テンプレートの定義に差分（ドリフト）がないかを確認する機能があります。

更新前にドリフトを検出し、予期せぬ手動変更が行われていないかを確認します。

Step 2：手動変更の​テンプレートへの​フィードバック

もし手動変更があった場合、そのまま更新するのではなく、現在のリソースの最新状態を正として使用するテンプレートを修正します。

または、リソースの既存スタックへのインポート機能を使用し、手動設定を維持した状態でCloudFormationスタックに取り込みます。

Step 3：変更セット​（Change Sets）に​よる​最終確認

テンプレートを適用する直前に変更セットを確認します。

これから行われる更新によってどのリソースが追加・変更・削除されるかの差分を一覧で確認し、意図しないリソースの更新がないかを最終確認します。

Step 4：実行後の​設定値確認

スタックの更新完了後も、意図した通りの設定が反映されているかを確認します。

具体的には、AWS Configを活用してリソースの構成変更履歴の追跡や、AWS CLIを用いてリソースの値を直接取得し、想定値と一致するかを確認します。

おわりに

今回は、SKYPCEのメール配信基盤を構築例に、CloudFormation利用時の工夫と、運用時の注意点についてご紹介しました。

CloudFormationはインフラ構築を自動化し、環境の複製などを容易にしてくれる便利なツールです。

一度コード化して終わりではなく、運用の中でコードと実際の環境の差異をどう管理し、安全に更新していくかが重要になります。

インフラのコード化をこれから導入される方など、私たちのチームでの取り組みが少しでも参考になれば幸いです。