【AWS SysOps】プロビジョニングの自動化<br/>CloudFormation

こんにちは！在宅カエルです！
今回もAWS SysOps Administrator Associate（SOA）受験に向けて学習を進めます。

主に自分の勉強用ですが、SOAを受験する方も
是非参考にしてみてください！

こんな方に読んでほしい！
・AWS SysOps Administrator Associate を勉強中の方
・AWS CloudFormationのリソース管理について知りたい方

モニタリングとレポートについてもまとめています。

CloudWatchを用いたシステムの監視については他記事を参照ください。

今回はCloudFormationについて書きます！

AWSにおけるプロビジョニングとは
AWS CloudFormationとは
リソースの起動
1. テンプレート
2. スタック
  1. DependsOn 属性
  2. UpdatePolicy 属性
スタックの更新
1. 直接更新
2. 変更セット
まとめ

AWSにおけるプロビジョニングとは

AWSではEC2やRDSなど複数のサービスを組み合わせてシステムのインフラを構築します。
このサービスを組み合わせて構築することをAWSではプロビジョニングと呼びます。

プロビジョニングを実現するAWSのサービスとしてCloudFormation、OpsWorks、ElasticBeanstalkなどがあります。

AWS のプロビジョニングとオーケストレーション

今回の記事ではCloudFormationについて勉強していきます！

AWS CloudFormationとは

システムを構築するにはサーバーにEC2、DBにRDS、ストレージにS3・・・など複数のサービスを組み合わせる必要があります。

しかしそれをAWSのコンソール上から一つずつ設定すると手間もかかりますし、ミスなども発生します。そこで利用するのがAWS CloudFormationになります。

AWS CloudFormation の概要 - AWS CloudFormation

この AWS CloudFormation ユーザーガイドに記載されている AWS CloudFormation サービスをご紹介します。

CloudFormationを使用するとAWSインフラの構成要素一式をテンプレートとして定義することができ、用意したテンプレートを使って環境を自動構築することができます。

よく利用するインフラ構成などはテンプレートを作成しておくことで、何度でも簡単に構築することができます。

リソースの起動

CloudFormationはテンプレートに基づいてスタックを作成することで、環境を自動構築します。
テンプレートとスタックについて確認していきましょう。

簡単な説明は以下の通りです。

＊テンプレート・・・
AWSリソースを作成する際の設計図となるJSONまたはYAML形式のテキストファイル。

＊スタック・・・
テンプレートから作成されるリソースの集合。

テンプレート

テンプレートは前述の通り、AWSリソースの設計図となります。
テンプレートには構築したいAWSリソースや必要なプロパティを記述します。

詳細な記述方法は試験では問われないため、簡略化したものを例として載せておきます。

{　
 　"AWSTemplateFormatVersion" : "2010-09-09",　//テンプレートのバージョン
　　"Description" : "Sample template",　//テンプレートの説明文
　　"Parameters" : {
　　　　//ユーザー名、パスワードなど実行時にユーザー入力が必要になる値
　　};
   "Mappings" : {
      //キーとキーに応じた値
   };
   "Conditions" : {
      //条件と条件名
   };　　
   "Resources" : {
　　　 //起動するリソースやプロパティの指定（必須項目）
　　}
　　"OutPuts" : {
      //出力値
   }
}

Resourcesのみ必須項目になり、あとは必要に応じて任意で記述していきます。
各項目の詳細は公式サイトを参照いただければ良いかと思います。

テンプレートの構造分析 - AWS CloudFormation

AWS CloudFormation テンプレートの必須の構成要素について詳しく説明します。

全項目詳細に暗記する必要はないですが、複数リージョンに跨ってリソースを構築する際に
AMIなど特定リージョンに依存するサービスはリージョンによっては使用できないため、
Mappingsでリージョンとの関係を記載する必要があるといった問題が出題されていました。

"Mappings" : {
    "AWSLinuxAMI" : {
      "ap-southeast-1" : { "201403": "ami-787c2c2a" },
      "ap-southeast-2" : { "201403": "ami-0bc85031" },
      "ap-northeast-1" : { "201403": "ami-a1bec3a0" },
    }
  }

{ "Fn::FindInMap" : ["AWSLinuxAMI",{"Ref : "AWS::Region"}, "201403"] }

スタック

スタックはテンプレートから構築されるリソースの集合体を指します。
なので、スタックの削除を実行するとスタックに紐づくリソースが削除されます。
スタックはAWSのコンソールやCLIを利用して作成、更新、削除を実行できます。

スタック作成の際にリソースの作成に失敗すると、
途中まで作成済みのAWSサービスも全てロールバックされ、削除されるので抑えておきましょう。

また、テンプレートのResourcesに属性を追加することで、
リソース作成の際の追加動作や実行順序などを指定できます。

リソース属性リファレンス - AWS CloudFormation

AWS CloudFormationの追加の動作を制御するために、リソースに追加できる属性を示します。

SysOps試験に出題されそうなものをいくつかピックアップしておきます。

DependsOn 属性

DependsOn 属性ではリソースを指定して、
他のリソースの後に実行されるように構築順序を明示的に設定できます。

基本的に作成するリソースの構築順は自動でCloudFormationが判断してくれますが、
例外としてVPCゲートウェイのアタッチメントなどはDependsOn属性で明示的に構築順序を
指定する必要があります。

UpdatePolicy 属性

UpdatePolicy 属性ではAutoScalingGroupなどに対して
リソースの更新処理の方法を指定できます。

CloudFormationでスタックが更新された場合にAutoScalingGroupの更新方法を定義しておかないと、更新中にサービスに繋がらなくなるなど想定外の結果になってしまうことがあります。

以下の２種類の方式で設定できます、ポイントを押えておきましょう。

＊AutoScalingRollingUpdate・・・
既存のAutoScalingGroup配下のインスタンスを数台ずつ入れ替えていく方法。

＊AutoScalingReplacingUpdate・・・
新しいAutoScalingGroupを作成して、新旧のグループを入れ替える方法。

スタックの更新

作成したスタックを用いてシステムを運用していく中で、
スタックの内容を更新したいという場合があるかと思います。

その場合直接更新または変更セットの２つの方式があります

直接更新

直接更新はその名のごとく、スタックを直接更新します。
変更を送信するとCloudFormationによって即時でデプロイされます。

迅速に変更を反映しなければならない場合に使用するプロセスです。

変更セット

変更セットはスタックを変更する際に変更箇所を確認することができる更新方式になります。
変更にはJSON形式のドキュメントに変更を記載し、利用します。

稼働中のシステムに変更を加える場合、どのような影響が出るか確かめないと怖いですよね？
変更セットを利用してシステムに与える影響を検証し、理解することによって安心してスタックを更新できます。

参考 » 変更セットを使用したスタックの更新より

まとめ

・サービスを組み合わせて構築することをAWSではプロビジョニングと呼ぶ
・CloudFormationはテンプレートを使って自動でプロビジョニングすることが
できるサービス
・スタックとはテンプレートにより実行されるリソースの集合
・スタックの更新は直接更新と変更セットを用いた更新の２種類がある

今回はプロビジョニングに注目してCloudFormationについて勉強してみました。

次回以降も引き続きSOAの勉強記事を作成していきます。

ではでは。

【AWS SysOps】プロビジョニングの自動化
CloudFormation