AWS 環境自動化サービスの全体像

なぜ環境自動化が必要か

システムを手作業で構築・運用すると、担当者ごとに設定内容がばらつき、再現性のない環境が生まれやすくなります。さらに、変更のたびに人手を介するプロセスは対応速度が遅く、ヒューマンエラーの温床にもなります。

AWSでは、インフラの構築・コードのビルド・アプリケーションのデプロイという一連の流れを自動化するためのサービス群を提供しています。これらを組み合わせることで、システムの安定性・再現性を高めつつ、変更を迅速かつ安全に反映できるようになります。

環境自動化サービスの全体像

環境自動化に関わる主なAWSサービスは、次のように役割が分かれています。

サービス	役割
CodeCommit	Gitベースのソースコードリポジトリ
CodeBuild	ソースコードのビルドとテスト実行
CodeDeploy	ビルド済みアプリケーションのデプロイ
CodePipeline	上記を含むCI/CDフロー全体のオーケストレーション
CodeStar	プロジェクト単位でCI/CD環境をまとめて管理するダッシュボード
CloudFormation	インフラリソースをテンプレートで定義し構築する（Infrastructure as Code）
Elastic Beanstalk	Webアプリケーションの実行環境構築とデプロイを自動化するPaaS的サービス
OpsWorks	Chef/Puppetを利用したサーバー構成管理サービス
Amazon ECS / EKS	コンテナベースのアプリケーション実行環境をテンプレート化する
CloudWatch	構築後のリソースを継続的に監視する

CloudFormationとECS/EKSについては、それぞれ専用のトピックで詳しく扱います。ここでは、アプリケーションのビルド・デプロイを担う「Codeシリーズ」と、Webアプリ運用を簡素化する「Elastic Beanstalk」「OpsWorks」を中心に整理します。

Codeシリーズ：CI/CDパイプラインの構成要素

Codeシリーズは、ソースコードのコミットからビルド・テスト・デプロイまでを自動化する一連のマネージド型サービスです。

• CodeCommit：Gitベースのリポジトリをセキュアにホストするマネージド型のソース管理サービスです。独自のGitサーバーを構築・運用する必要がありません。
• CodeBuild：ソースコードをコンパイルし、テストを実行して、デプロイ可能なアーティファクトを生成する完全マネージド型のビルドサービスです。ビルド環境はコンテナとして提供され、利用した分だけ課金されます。
• CodeDeploy：ビルドされたアプリケーションを開発・テスト・本番環境へデプロイする自動化サービスです。EC2、オンプレミスサーバー、Lambda、ECSなど複数のデプロイ先に対応します。
• CodePipeline：これら各サービスを1つのワークフローとして連結し、コードの変更をトリガーに構築・ビルド・テスト・展開・運用までの流れを自動でオーケストレーションする、完全マネージド型の継続的デリバリーサービスです。

処理の流れを整理すると、以下のようになります。

CodePipelineは、CloudFormationと組み合わせることでインフラ構成の変更・実行・展開そのものを自動化することもでき、ECSと組み合わせればコンテナ化されたアプリケーションコードの自動ビルド・デプロイも実現できます。

AWS CodeStar

CodeStarは、これらのCode系サービスを束ねてプロジェクト単位で管理するためのプロジェクト管理サービスです。あらかじめ用意されたプロジェクトテンプレートを使うことで、EC2・Lambda・Elastic Beanstalkなどへデプロイするアプリケーション開発をすぐに始められます。CodeCommit・CodeBuild・CodeDeployによるCI/CD環境や、統合ダッシュボードでのプロジェクト管理機能も提供します。

AWS Elastic Beanstalk：Webアプリのデプロイ自動化

Elastic Beanstalkは、Webアプリケーションの典型的な構成の構築とデプロイを自動化するサービスです。開発者はコードをアップロードするだけで、キャパシティのプロビジョニング、ロードバランシング、Auto Scaling、アプリケーションのヘルスモニタリングまでを自動的に設定してもらえます。

Java、PHP、Ruby、Python、Node.js、.NET、Go、Dockerに対応しており、Apache、Nginx、Passengerなど使い慣れたサーバー技術でのデプロイとスケーリングが可能です。内部的にはCloudFormationを利用してインフラを構成しています。

Elastic Beanstalkはコードの内容に応じて、次の2種類の環境を構築できます。

• ウェブサーバー環境：ELBとAuto Scalingを組み合わせ、HTTPリクエストを処理するスケーラブルなWebアプリケーションを実行します。単一コンテナのDockerも実行可能で、複数コンテナ構成が必要な場合はECSを利用した環境実行に切り替えます。
• ワーカー環境：SQSキューとAuto Scalingを組み合わせ、時間のかかるバッチ処理やバックグラウンドジョブを実行します。定期実行するバックアップ処理のような、レスポンスを即時に返す必要のない処理に向いています。

Elastic Beanstalkの構成は、次の4つの要素で管理されます。

要素	内容
アプリケーション	バージョンと環境設定を含む、トップレベルの論理的な入れ物
バージョン	デプロイ可能なコードそのもの。S3で管理され、異なる環境・バージョンへ展開できる
環境	ウェブサーバー/ワーカーそれぞれに応じて構築されるインフラ環境。バージョンがデプロイされる
環境設定	環境に関連するリソースの動作を定義する設定パラメーター

AWS OpsWorks：Chef/Puppetによる構成管理

OpsWorksは、ChefまたはPuppetを使ってアプリケーションの設定・デプロイ・運用を自動化するための設定管理サービスです。ChefやPuppetは、様々な形式のインフラへサーバーやアプリケーションを展開することを容易にする環境自動化フレームワークであり、OpsWorksはこれらの仕組みをAWS上でマネージド型サービスとして提供します。

OpsWorksには3つのタイプがあります。

• OpsWorksスタック：スタック・レイヤー・インスタンス・アプリケーションというコンポーネントでモデル化する、オリジナルのサービスです。ライフサイクルイベントによるタスクの自動化が可能で、OpsWorksエージェントがChef Clientのローカルモードでレシピを実行するため、Chefサーバー自体は不要です。
• OpsWorks for Chef Automation：Chefサーバーを作成し、継続的デプロイメントやコンプライアンスチェックを行う完全マネージド型サーバーサービスです。Chefのcookbookやレシピを利用してインフラ管理を自動化します。
• OpsWorks for Puppet Enterprise：フルマネージド型のPuppetマスターにより、アプリケーションのテスト・展開・運用を自動化します。Puppetマスターは、インフラ内のノードの管理、ソフトウェアやOSの設定、パッケージインストール、変更管理などの幅広いタスクを処理できます。

Elastic BeanstalkとOpsWorksの違い

両者とも環境構築を自動化しますが、対象とする範囲と抽象度が異なります。

項目	Elastic Beanstalk	OpsWorks
対象	アプリケーションのデプロイの自動化	インフラの構成管理の自動化
管理対象	Webアプリケーションのインフラ設定	ロードバランサー、サーバーソフトウェア、データベースなどアプリケーション全体
構成管理の基盤	CloudFormation	Chef / Puppet
複雑度	シンプルで高速に立ち上げられる	より複雑だが高度な構成が可能
カスタマイズ性	制限がある	高度なカスタマイズが可能

Webアプリケーションを素早く標準的な構成でデプロイしたいならElastic Beanstalk、既存のChef/Puppetの運用資産を活かしたい場合や、より柔軟なインフラ構成管理が必要な場合はOpsWorksを選択します。