これまでVPC、EC2、RDSといったAWSのサービスを組み合わせてコーポレートサイトのシステムを構築してきました。これらのリソースは、AWSマネジメントコンソールを利用して手動で配置したり設定したりできます。

 しかし手動による基盤構築は、効率が悪いうえに間違いが起こりやすいという問題があります。

 開発環境、テスト環境、本番環境などの環境を用意することを考えてください。特にテスト環境は、結合テスト、総合テスト、ユーザー受け入れテストなどのテストごとに必要です。

 これらの環境について、整合を保ちながら正確に構築するのは、容易ではありません。たとえ基盤設計ドキュメントを作成して常に最新の仕様を反映していても、環境構築の作業ではタイプミスなどの間違いが起こります(筆者の経験ではデータベース名が多い)。

 テスト工程になって、リソースの設定ミスが原因の不良が見つかり、プロジェクトのスケジュールが遅れてしまった。そんな経験は誰しもあるでしょう。それはまだ不幸中の幸いです。本番環境の設定ミスは致命傷になります。

 この問題の解決策は、環境構築のコードを作成して作業を自動化することです。このコードは基盤設計ドキュメントという側面も持ちます。つまり、基盤設計ドキュメントとしてコードを作り、その内容の通りの環境を構築するというわけです。そうすれば、同一の環境を繰り返し正確に構築できます。さらに、複数の環境の整合を取りやすくなります。

基盤をコードで扱うのはAWSでは自然なこと

 このように基盤(インフラストラクチャー)をコードで表し自動的に配置したり設定したりする仕組みや取り組みを「Infrastructure as Code」と呼びます。

 AWSのようなクラウドサービスでは、そもそも基盤がソフトウエアによって制御できるようになっています。そのため基盤をコードとして扱うのは自然なことといえます。

 AWSにおいてInfrastructure as Codeを実現するサービスが「AWS CloudFormation」です。

 CloudFormationでは、基盤を表すコードは「テンプレート」と呼びます。テンプレートから作成されたリソースの集合は「スタック」です。

 VPC、EC2インスタンス、RDSインスタンスなどのAWSリソースの仕様を記述したテンプレートを作成しておけば、CloudFormationが自動的にこれらのリソースのプロビジョニング(配置や設定)を行い、スタックを作成します。

 権限不足などの原因でプロビジョニングが失敗した場合は、処理が中断され、既にプロビジョニングされたリソースは全て自動的に削除されます。

 望ましいのは、VPC、EC2インスタンス、RDSインスタンスなど、アプリケーションが使用する全てのAWSリソースを、CloudFormationによってテンプレートから作成することです。そうすれば、基盤構築を完全に自動化できます。

開発環境か本番環境かで適用するAMIを変更

 CloudFormationでは、状況に合わせた環境構築も行えます。例えば、テンプレートの起動が開発環境か本番環境かに応じて、異なるAMI(Amazon Machine Image)を適用できます。

 複数の環境間で整合を保つ機能もあります。EC2インスタンスのスタックにSecurity Groupを追加するよう一つのテンプレートを更新するだけで、関連付けた全ての環境でSecurity Groupリソースを追加できます(図1)。

図1 テンプレートを変更すれば全環境に反映される
[画像のクリックで拡大表示]

 テンプレートはJSON(JavaScript Object Notation)またはYAML(YAML Ain't Markup Language)の形式で記述されるテキストデータです。アプリケーションのソースコードと同じように、Gitなどのバージョン管理システムで管理できます。

 テンプレートは、JSON構文をサポートしたコードエディターで記述できます。マネジメントコンソールから利用できる「AWS CloudFormation Designer」のほか、「VisualOps」のようなサードパーティー製エディターを使用することもできます。

この先は有料会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら