16日目: Immutable InfrastructureとAMIによるデプロイ
はじめに：サーバーを「変更可能」から「不変」へ
皆さん、こんにちは！👋 昨日は、ダウンタイムを最小限に抑えるためのデプロイ戦略「ブルー/グリーンデプロイ」について学びました。このデプロイ戦略をさらに安全かつ効率的にする鍵となるのが、今日のテーマである「Immutable Infrastructure (不変のインフラ)」という考え方です。
これまでのデプロイでは、既存のEC2インスタンスに変更を加えたり、ソフトウェアを更新したりしてきました。このアプローチは Mutable Infrastructure (変更可能なインフラ) と呼ばれます。しかし、サーバーにパッチを当てたり設定を変更したりするたびに、予期せぬ不具合が発生するリスクが伴います。
Immutable Infrastructureとは、「一度デプロイされたサーバーは、その設定やソフトウェアを変更しない」という原則に基づいたインフラ管理手法です。代わりに、新しいバージョンのアプリケーションが必要な場合は、新しいサーバーイメージを構築し、それをデプロイします。本記事では、このImmutable Infrastructureの概念と、それをAWS上で実現するための核となる技術「AMI (Amazon Machine Image)」を使ったデプロイ方法について解説します。
1. Mutable Infrastructure vs. Immutable Infrastructure
まず、2つのインフラ管理手法の違いを明確に理解しましょう。
Mutable Infrastructure (変更可能なインフラ)
- 特徴: サーバーの稼働中に、ソフトウェアのインストール、設定ファイルの変更、パッチ適用などを行います。
- メリット: 設定変更が手軽で、迅速に対応できます。
- デメリット: 変更履歴の管理が難しく、構成が時間とともにばらつきやすくなります（Configuration Drift）。また、変更中に問題が発生した場合、復旧が困難になるリスクがあります。
Immutable Infrastructure (不変のインフラ)
- 特徴: 新しいバージョンのアプリケーションや設定が必要な場合は、新しいサーバーイメージ（AMI）を作成し、既存のサーバーと入れ替えます。既存のサーバーには一切変更を加えません。
-
メリット:
- 一貫性: すべてのサーバーが同じイメージから作成されるため、構成のばらつきがなくなり、一貫性が保たれます。
- 信頼性: 新しいイメージはデプロイ前に十分にテストできるため、本番環境での不具合発生リスクが低減します。
- 迅速なロールバック: 問題が発生した場合でも、古いイメージから作成されたサーバーにトラフィックを戻すだけで、迅速なロールバックが可能です。
-
デメリット:
- 新しいイメージを毎回作成するため、ビルドプロセスに時間がかかる場合があります。
- CI/CDパイプラインや自動化ツール（後述のPackerなど）の導入が必須となります。
Immutable Infrastructureは、CI/CDの原則である「一貫性」と「信頼性」をインフラレベルで実現するための、非常に強力なアプローチです。
2. AMI (Amazon Machine Image) とは？
AMIは、AWS上でEC2インスタンスを起動するためのテンプレートです。AMIには、OS、アプリケーションサーバー、アプリケーションコード、そして必要な設定などがすべて含まれています。
Immutable Infrastructureのワークフローでは、このAMIが中心的な役割を果たします。
- AMIの構築: CodeBuildのようなツールを使って、アプリケーションコードや依存ライブラリ、設定ファイルなどをベースとなるOSイメージに焼き付けて、新しいAMIを作成します。このプロセスは、Golden Image (黄金のイメージ) を作成するとも呼ばれます。
- インスタンスの起動: 新しく作成されたAMIから、EC2インスタンスを起動します。
- トラフィックの切り替え: ロードバランサーを使って、新しいインスタンスにトラフィックを切り替えます（これはブルー/グリーンデプロイの仕組みと非常に相性が良いです）。
- 古いインスタンスの終了: トラフィックの切り替えが完了し、新しいインスタンスが正常に稼働していることを確認したら、古いインスタンスを終了します。
3. CI/CDパイプラインにおけるAMIデプロイ
AMIを使ったデプロイをCI/CDパイプラインに組み込むことで、このプロセスを完全に自動化できます。
1. ビルドステージ (buildspec.yml)
通常のビルドプロセスに加えて、AMIを作成するためのツールを組み込みます。
-
Packer: HashiCorpが提供するオープンソースツールで、様々なクラウド環境向けのAMIを自動で構築できます。
jsonファイルでAMIの構成を定義し、シェルスクリプトなどでアプリケーションのセットアップを実行します。 -
CodeBuild: CodeBuild内でPackerコマンドを実行するように
buildspec.ymlを設定します。
# buildspec.yml (Packerを使ったAMI構築の例)
version: 0.2
phases:
install:
commands:
# Packer をインストール
- curl "https://..." > packer.zip
- unzip packer.zip
build:
commands:
- echo "Building AMI with Packer..."
# Packerを使ってAMIを作成
- ./packer build my-ami-template.json
このbuildspec.ymlを実行すると、Packerが指定されたAMIを作成し、AWSアカウントに登録します。
2. デプロイステージ (CodeDeploy)
AMIが作成されたら、次のデプロイステージでは、そのAMIから新しいEC2インスタンスを起動し、トラフィックを切り替えるように設定します。
- CodeDeployとAuto Scaling Group: CodeDeployは、Auto Scaling Groupと連携してブルー/グリーンデプロイを実行できます。新しいAMIから新しいAuto Scaling Groupを作成し、トラフィックをルーティングする設定が可能です。
これにより、アプリケーションコードの変更が検知されるたびに、新しいAMIが自動で作成され、それを使った安全なブルー/グリーンデプロイが実現します。
まとめ：Immutable Infrastructureで信頼性の高いリリースを
本日は、CI/CDパイプラインの信頼性を根本から高める「Immutable Infrastructure」の概念と、その実現に不可欠な「AMI」を使ったデプロイ方法について学びました。
- Immutable Infrastructure: 一度デプロイされたサーバーは変更せず、新しいイメージでサーバーを入れ替えるという原則。
- AMI: EC2インスタンスを起動するためのテンプレートで、アプリケーションや設定を固めた「黄金のイメージ」として機能します。
- CI/CDとの統合: CodeBuildとPackerを連携させてAMIを自動生成し、CodeDeployとAuto Scaling Groupでブルー/グリーンデプロイを実行することで、Immutable Infrastructureのワークフローを完全に自動化できます。
このImmutable Infrastructureは、コンテナ技術が主流となった現代のインフラ管理手法にも通じる考え方です。次回は、このコンテナ技術をCI/CDに組み込み、ECS/EKSへのデプロイパイプラインを構築する方法について解説します。お楽しみに！