【AWS】SAA資格取得のための学習用備忘録(プロビジョニングサービス)

AWSにおけるプロビジョニングサービス

オンプレミス環境に比べ、クラウドではインフラリソースの構築を素早く簡単に行うことができる。

例えば、高負荷対策としてWebサーバーの数を増やそうと思った時に、オンプレミスの場合はサーバーの調達、ラックの調整、電源やネットワーク周りの作業が必要でリードタイムがかかってしまう。

それに対して、AWSをはじめとするクラウドでは、GUIで数クリックするだけで環境を増やすことができる。

こういった背景もあり、クラウドでは同じ環境、あるいは似たような環境を何度も作ることになる。

この時、全ての作業を手作業で行なっていると、ミスをしたり、環境間で思わぬ差異が生まれてしまったりする。

そこで、環境構築作業を自動化することを考える。

AWSでは、このような構築自動化・プロビジョニングサービスとして下記の3つが提供されている。

・Elastic Beanstalk：定番環境の自動構築

・OpsWorks：Chef環境を提供し、OSより上のレイヤーの自動構築をサポート

・CloudFormation：JSONあるいはYAMLのテンプレートを作成し、OSより下のレイヤーの自動構築をサポート

AWSではこれらのサービスを必要に応じて使い分けることで、環境構築の自動化を実現する。

Elastic Beanstalk

Elastic Beanstalkは、定番のインフラ構成を自動構築するサービス。

アーキテクチャのパターンは限られるが、AWSのベストプラクティスに沿った構成を簡単に構築できる。

インフラに詳しいメンバーがいない時でも、適切な環境を素早く用意でき、アプリケーション開発に集中できることがElastic Beanstalkの良さと言える。

★Elastic Beanstalkは、定番のインフラ構成を自動構築するサービス。インフラに詳しいメンバーがいなくても、適切な定番環境が素早く構築できる

Elastic Beanstalkで構築できる「定番」構成

Elastic Beanstalkで構築できる構成は大きく下記の2つ。

・Webサーバー構成(ELB+Auto Scaling+EC2)

・Batchワーカー構成(SQS+Auto Scaling+EC2)

それぞれ、無料利用枠をなるべく使う「低コスト」の構成、複数のサーバーを用意し、Auto Scalingの設定を含める「高可用性」の構成から選択することができる。

個別にカスタマイズすることもでき、例えば「高可用性」の構成にするが、サーバー台数は最大でも2台までにする、といった指定を行うこともできる。

また、プラットフォームとしてJava、Ruby、PHP、Pythonといった言語を選択することができ、あらかじめ用意されたサンプルアプリケーションを最初からデプロイすることも可能。

Elastic Beanstalkの様々な利用方法

Elastic Beanstalkはマネジメントコンソールから利用することができるが、それ以外にも様々な方法がある。

例えば、EclipseからElastic Beanstalkの機能を利用するAWS Toolkit for Eclipseというツールが提供されている。

また、他のサービスと同様にCLIや各言語のSDKを使って環境を構築することも可能。

さらに、Elastic Beanstalk専用のEB CLIというクライアントツールも提供されている。

このEB CLIはElastic Beanstalkの複数のAPIを束ねたコマンドになっており、AWS CLIから利用するのに比べ、より直感的に作業を行うことができる。

アプリケーションデプロイのサポート

Elastic Beanstalkの利点として、アプリケーションデプロイのサポートがある点も挙げられる。

自前で用意する場合は、どのEC2インスタンスをどの順番にELBから切り離すかなどを考慮する必要があるが、Elastic Beanstalkでは様々なデプロイ方式を提供しているため、デプロイのための開発が不要になる。

デプロイ方式は、デプロイにかかる時間や、システム停止時間をどれだけ許容できるかといった指針から選ぶことになる。

OpsWorks

OpsWorksは、Chefを利用した構成管理サービス。

Chefはレシピと呼ばれるファイルにサーバーの構成を定義し、ミドルウェアのインストールや設定を自動化するツール。

Apacheのインストール、サーバー起動時の自動プロセスの立ち上げ設定、そしてhttpdプロセスの立ち上げを自動で行うこと等が可能。

作業が複雑になればなるほど自動化の恩恵を受けることができる。

また、インフラ作業をコード化できるため、レシピをバージョン管理することができることも利点。

通常、Chefの利用方式には次の2つがある。

・Chef Client ローカル方式：各サーバーがレシピを持ち、自分自身にレシピを適用する方式

・Chef Server/Client方式：マスターサーバーを用意し、レシピそのものや各サーバーへのレシピ適用状況を管理する方式

どちらの方式を用いる場合も、Chef環境のセットアップが必要になるが、OpsWorksを使えばこのセットアップを任せることができる。

Chefの利用方式に合わせて、OpsWorksもこの2つの機能を提供しているため、その詳細について解説。

OpsWorksスタック

Chef Client ローカル方式でChefを利用する場合は、OpsWorksスタックを利用する。

スタック及びレイヤーという概念は以下の通り。

・スタック：OpsWorksのトップエンティティ。スタック単位の構成情報をJSON形式で保持する。スタックの下に複数のレイヤーを定義できる

・レイヤー：インスタンスの特性ごとにレイヤーを用意する。レイヤーに対してChefレシピをマッピングする。レイヤーを指定してEC2インスタンスを起動することで、インスタンスに対してレシピが適用される

スタックをコピーすることも可能なため、東京リージョンで環境を作り、そのDR環境を別のリージョンにコピーするといった使い方ができる。

レイヤー内で起動したEC2インスタンスには、OpsWorksエージェントがインストールされる。

このOpsWorksエージェントがOpsWorksからレシピを取得し、自身のインスタンスに適用する。

インスタンスからOpsWorksへの通信経路が必要なため、その点に注意。

OpsWorks for Chef Automate

続いて、ChefをChef Server/Client方式で利用するシーンを考える。

ChefにはChef Automateという、Chefを統合的に利用するための機能がある。

Chef Automateでは、レシピが適用される各インスタンスをクライアントと呼び、それらとは別にクライアントを管理するマスターサーバーが存在するアーキテクチャを採用している。

OpsWorksでもこのChef Automateの利用をサポートしている。

OpsWorks for Chef Automateを利用すると、Chef Automateサーバーが自動構築される。

利用者側でChef Automateサーバーのプロビジョニングやインストール作業を行う必要がなく、Chef Automateサーバー自体のバックアップを行う機能なども標準提供されている。

Chef Automateサーバーにcookbookを登録した上で、クライアントノード(EC2インスタンス)を起動すると、このノードにレシピが適用される。

Auto Scalingにも対応しているため、クライアントノードを自動的に増やすことも可能。

また、Chef Automateの機能の一部であるダッシュボード機能も利用でき、このダッシュボード上で管理対象のノードやレシピを確認できる。

CloudFormation

マネジメントコンソールから手作業で環境を構築していくのは、最初は直感的でわかりやすい。

しかし、同じ環境を複数用意する、複数の環境に同じ修正を横展開するといった作業を人力でやり続けることは効率が悪く、設定ミスも発生しやすくなる。

CloudFormationは、AWSリソースを自動構築するためのサービスで、この問題を解決する。

CloudFormationを利用する流れは次の通り。

1.CloudFormationテンプレートを作成する

2.テンプレートを適用する

3.CloudFormationスタックが作成され、それに紐づく形でAWSリソースが自動構築される

★CloudFormationはAWSリソースを自動構築するためのサービス。構築されたAWSリソースはスタックと呼ばれる。スタックは、テンプレートと呼ばれる設計図に基づいて構築される

CloudFormationスタック

CloudFormationで構築されたAWSリソースは、CloudFormationスタックという集合体にまとめられる。

テンプレートを修正し、スタックを指定して再度適用することで、スタック上のAWSリソースの設定を変更したり、リソースを削除したりできる。

また、同じテンプレートを利用し、別のスタックとして新たに環境を作れるため、システムのDR環境を別リージョンに作成する際に重宝する。

同一システム内でテンプレートを分割することで、複数のスタックにリソースを分けることもできる。

例えば、次のようにスタックを分けることができる。

・IAMやCloudTrailといったアカウント設定用スタック

・VPCやサブネットといったネットワーク用スタック

・ELBやWebサーバーといったパブリックサブネット用スタック

・DBやインメモリキャッシュといったプライベートサブネット用スタック

このように分けて定義することで、他のシステムでテンプレートをを流用しやすくなる。

CloudFormationテンプレート

CloudFormationテンプレートは、JSON形式かYAML形式で記述する。

テンプレートを構成する要素としては、セクションと組み込み関数がある。

セクション

CloudFormationテンプレートは、いくつかのセクションに別れている。

よく使われるセクションは次の3つ。

・Resourcesセクション：最も重要なセクション。テンプレートはスタックの設計図だが、このResourcesセクションに、構築するAWSリソースの設計を書いていく。各リソースには論理IDをつける必要がある。この論理IDを使って、リソース間の紐付けを行う。続けて、リソースの型をTypeで定義する(VPCなど)。型によってPropertiesで設定できる項目が決まっている。VPCリソースの場合はIPアドレスレンジCidrBlockの定義が必須。さらに、任意項目であるTagsを使ってVPCリソースに名前をつけることもできる。CloudFormationで扱える型や項目は日々変わるため、AWSドキュメントを見ながら1つずつ定義する

・Parametersセクション：実行時に値を選択(入力)する項目を定義するセクション。例えば、インスタンスタイプを変数として定義し、実行時に選択する形にしている。Parametersセクションで定義された値は、RecourcesセクションでRef関数を用いて参照できる。インスタンスタイプやEC2のキーペアなど、環境によって変わる値をパラメータ化することで、環境が変わるたびに書き換える必要がない汎用的なテンプレートにできる

・Mappingsセクション：変数をMap形式で定義できる。実行環境によって変わる値を定義するのに用いられることが多い。例えば、EC2インスタンスを作る時に利用するAMIを選択するが、同じAmazon LinuxのHVM形式のものでも、AMI IDはリージョンによって変わる。その場合、まずはMappingセクションにAMI IDを定義する。この定義をResourcesセクション内でFindInMap関数を用いて参照することで、適切なAMI IDを取得できる。CloudFormationはDR環境の構築のために用いられることも多い。リージョンが変わってもテンプレートを書き換えなくて済む形を目指す。なお、AWS::Regionは、擬似パラメータと呼ばれる事前定義されたパラメータで、CloudFormationの実行リージョンを取得できる。擬似パラメータは他にも、実行されたAWSアカウントのアカウントIDを取得するAWS::AccountIdなどがある

組み込み関数

テンプレートを作成する際は、汎用的に作ることを心がけることが大切。

各セクションと同じく、その手助けをしてくれるのが組み込み関数。

Ref関数は、AWSリソースの値や設定されたパラメータの値を取得する関数。

VPCとサブネットを構築するテンプレートの中で、サブネットはVPCに紐づくため、VPC IDをプロパティとして指定する必要がある。

しかし、VPCもテンプレート実行時に作られるため、テンプレートを作成している時点ではVPC IDがわからない。

このようなときに、「VpcId: !Ref cfn Vpc」のようにVPCの論理IDを指定することで、実行時に決まったVPC IDをプロパティで指定できる。

Ref関数は、Parametersセクションで設定した値を取得する場合にも利用する。

10前後ある組み込み関数の中で、最も用いる機会が多い関数。

FindInMap関数は、Mappingセクションで定義したMap型の変数を取得する際に使う。

FindInMap関数を使って値を取得したい時は、「!FindInMap[MappingName,Key2,Name1]」のように記述する。

擬似パラメータと組み合わせることで、実行環境に応じて動的に値が変わる汎用的なテンプレートを作ることができる。

上記2つ以外にも、リストからインデックスを指定して値を取得するSelect関数、他のCloudFormationスタックの値を取得するImportValue関数などの組み込み関数が用意されている。

どうしても汎用的にテンプレートを作れない場合は、リファレンスを参考にしながら試行錯誤してみると良い。

まとめ

プロビジョニングサービス

・Elastic Beanstalkは、定番のインフラ構成を自動構築するサービス。インフラに詳しいメンバーがいなくても、適切な定番環境が素早く構築できる

・OpsWorksは、Chefを利用した構成管理サービス。Chefは、レシピと呼ばれるファイルにサーバーの構成を定義し、ミドルウェアのインストールや設定を自動化するツール

・CloudFormationはAWSリソースを自動構築するためのサービス。構築されたAWSリソースはスタックと呼ばれる。スタックは、テンプレートと呼ばれる設計図に基づいて構築される