はじめに
この記事では、AWS CodePipeline を使った CI/CD パイプラインの全体像を解説します。
実現したいこと
コードを GitHub にプッシュしたら、自動的に本番環境に反映される状態を目指します。
コード変更 → GitHub へプッシュ → 自動ビルド → 自動テスト → 自動デプロイ → 公開完了
利用サービスの全体像
今回使用するサービスを、処理の流れ順に説明します。
1. GitHub (ソースコード管理)
役割: コードを保管する場所
- 開発者がコードを書いて GitHub にプッシュ
- これがパイプラインのスタート地点
2. CodePipeline (パイプライン全体の制御)
役割: CI/CD の「監督」
- GitHub を監視して、コードの変更を検知
- 次に何をするか(ビルド、デプロイなど)を制御
- 各ステージの実行状況を管理
工場の生産ラインの管理者のようなもの。各工程が正しい順序で実行されるように制御します。
3. CodeBuild (ビルド実行)
役割: Docker イメージを作る
- Dockerfile を読み込む
- アプリケーションをビルド (npm run build など)
- Docker イメージを作成
- 作成したイメージを ECR に保存
設計図 (Dockerfile) を見ながら、実際に製品 (Docker イメージ) を作る工場。
4. ECR (イメージ保管庫)
役割: Docker イメージを保存する場所
- CodeBuild が作った Docker イメージを保管
- ECS が ECR からイメージを取得してコンテナを起動
完成した製品を保管する倉庫。
5. ECS (コンテナ実行環境)
役割: Docker コンテナを実際に動かす
- ECR から Docker イメージを取得
- コンテナを起動
- アプリケーションを実行し続ける
完成した製品を提供する店舗。
Fargate とは?
ECS の実行方法の一つで、サーバーの管理が不要になるサービスです。
- 従来: サーバーを用意して、そこでコンテナを動かす(サーバー管理が必要)
- Fargate: サーバーのことを考えずにコンテナだけを動かせる
6. CloudFormation (インフラ管理)
役割: AWS リソースを「コード」で管理
- VPC、ECS、ALB などの設定をコードで記述
- コードを実行するだけで、すべてのリソースが自動作成される
パイプラインの処理フロー
実際に GitHub へコードをプッシュしてから、アプリケーションが公開されるまでの流れを説明します。
ステップ 1. Source (ソース取得)
何が起こる?
- 開発者が GitHub にコードをプッシュ
- CodePipeline が変更を検知
- GitHub からソースコードをダウンロード
時間: 数秒
ステップ 2. Build(ビルド)
何が起こる?
- CodeBuild が起動
- Dockerfile に従って Docker イメージをビルド
- Node.js をインストール
- npm install で依存関係をインストール
- npm run build でアプリケーションをビルド
- Nginx と組み合わせて実行可能な状態にする
- 完成した Docker イメージを ECR にプッシュ
時間: 3〜10 分(プロジェクトの規模による)
ステップ 3. Deploy (デプロイ)
何が起こる?
- ECS に「新しいイメージを使ってください」と指示
- ECS が新しいコンテナを起動
- ヘルスチェックで正常動作を確認
- 正常なら古いコンテナを停止
- ALB (ロードバランサー) が新しいコンテナにトラフィックを流す
時間: 2〜5 分
全体の所要時間
コードをプッシュしてから公開まで、5〜15 分程度で完了します。
なぜこんなに複雑なのか
単純な構成ではダメなのか?
「ビルドしたファイルを直接サーバーにアップロードすればいいのでは?」と思うかもしれません。
しかし、本番環境では以下のような要件があります。
要件 1: 無停止デプロイ
- ユーザーがアクセスしている最中にサービスを止めるわけにはいかない
- 新しいバージョンと古いバージョンを同時に動かし、徐々に切り替える必要がある
要件 2: 環境の一貫性
- 開発環境で動いても、本番環境で動かないことがある
- Docker を使えば、どの環境でも同じように動く
要件 3: スケーラビリティ
- アクセスが増えたら、コンテナの数を増やして対応
- ECS と ALB の組み合わせで実現
要件 4: 安全性
- デプロイに失敗したら、すぐに前のバージョンに戻せる
- コンテナ単位で切り替えられるので、ロールバックが容易
それぞれのサービスが専門分野を担当
各サービスは「単一責任の原則」に従って設計されています。
- CodePipeline: 全体の流れを制御(何もビルドしない、何もデプロイしない)
- CodeBuild: ビルドだけに集中
- ECR: イメージの保管だけに集中
- ECS: コンテナの実行だけに集中
この分離により、各部分を独立して改善・交換できます。
React / TypeScript アプリケーションの場合
具体例として、React / TypeScript アプリケーションを本番環境に反映するケースを考えてみます。
なぜ Docker が必要なのか
React アプリケーションは、静的ファイル (HTML、CSS、JavaScript) を生成します。そのため S3 に置くだけでも公開できます。
ただ、Docker + ECS を利用することで、以下のようなメリットがあります。
1. サーバーサイドの制御と柔軟性
-
高度なルーティング制御: Nginx などの Web サーバーをコンテナ内に含めることで、SPA のルート設定（例: 存在しないパスでも
index.htmlを返す）や、複雑なリダイレクト、ヘッダー操作などを細かくカスタマイズできる - 将来的な拡張性への対応: フロントエンドとバックエンド（APIサーバー）を同じ環境・仕組み（ECSクラスター内）で管理・連携できるため、アプリケーションの動的な機能拡張が容易
2. 環境の一貫性
- 環境差異の解消: Docker により、開発・ステージング・本番の全環境で全く同じ実行環境（OS、依存関係、Webサーバー設定を含む）を再現できるため、「ローカルでは動いたのに」問題をなくせる
3. 安定稼働とデプロイの安全性
- 無停止デプロイ: ロードバランサー (ALB) と連携し、古いバージョンを稼働させたまま新しいバージョンに徐々に切り替えるゼロダウンタイムデプロイを実現できる
- 容易なロールバック: 問題発生時、コンテナ単位で即座に古い正常なバージョンへ戻す（ロールバック）のが簡単で、**サービスの安全性を高く保つことができる
- 自動スケーリング: アクセス負荷に応じて、ECSがコンテナ（タスク）の数を自動で増減させ、トラフィックの急増に対応できる
4. 高度なネットワーク機能とリソース効率
- セキュリティ機能の強化: ALB の前段で WAF (Web Application Firewall) や 認証機能 (Cognito/OIDC) など、高度なセキュリティ・アクセス制御を適用できる
- リソースの効率的な利用: Fargate を使用すれば、アプリケーションが必要とする CPU やメモリをコンテナごとに細かく指定でき、リソースを無駄なく利用できる
ビルドプロセスの理解
React アプリケーションは、2 つのステージでビルドされます。
ステージ 1: アプリケーションのビルド
TypeScript → JavaScript への変換
React コンポーネント → 最適化された JavaScript
複数ファイル → バンドル(一つにまとめる)
結果: dist ディレクトリに静的ファイルが生成される
ステージ 2: 実行環境の準備
Nginx をベースにした軽量なイメージを用意
dist ディレクトリの内容を Nginx に配置
SPA 用の設定を適用
結果: Web サーバーとして動作可能な Docker イメージが完成
ネットワーク構成の理解
アプリケーションが外部からアクセスできるようになるまでの経路を説明します。
1. インターネットからのアクセス
ユーザーがブラウザで URL を入力
2. ALB (Application Load Balancer)
役割: トラフィックの入り口
- 複数のコンテナに負荷を分散
- ヘルスチェックで正常なコンテナだけに転送
- HTTPS の終端 (将来的に SSL 証明書を設定可能)
3. ECS タスク (コンテナ)
役割: アプリケーションの実行
- Docker コンテナが動いている
- Nginx が HTTP リクエストを処理
- React アプリケーションを配信
VPC とサブネット
VPC (Virtual Private Cloud)
- AWS 上の仮想的なプライベートネットワーク
- 自分専用のネットワーク空間
サブネット
- VPC 内をさらに細かく分割したもの
- パブリックサブネット: インターネットからアクセス可能
- プライベートサブネット: 内部からのみアクセス可能
コスト
小規模なテスト環境なら、月額 20〜30 ドル程度です。
主なコスト:
- ECS Fargate: タスク実行時間に応じて課金(月 15〜20 ドル)
- ALB: 稼働時間 + データ転送量(月 5〜10 ドル)
- ECR: イメージ保存容量(月 1 ドル程度)
- CodeBuild: ビルド時間(月 1〜2 ドル)
使わないときは ECS サービスを停止すれば、コストを抑えられます。
もっとシンプルな方法
- 静的サイトだけなら: S3 + CloudFront
- サーバーレスなら: Lambda + API Gateway
- 簡単に始めるなら: Amplify Hosting
他に考慮が必要な点
- セキュリティ: HTTPS 対応 (ACM で SSL 証明書)
- 監視: CloudWatch でログとメトリクスを監視
- バックアップ: 設定のバックアップ
- スケーリング: オートスケーリングの設定
- コスト管理: 予算アラートの設定
まとめ
この記事では、AWS CodePipeline を使った CI/CD パイプラインの全体像を解説しました。
このパイプラインは、開発者がコードをプッシュしてから本番公開までを完全に自動化し、手作業によるミスや時間を大幅に削減します。 CodePipeline を監督として、CodeBuild がイメージを作成し、ECR に保管されたイメージを ECS がゼロダウンタイムで実行することで、高い安定性、一貫性、そして将来の拡張性を確保できます。各サービスが専門分野を担当することで複雑な要件に対応できるため、現代の Web アプリケーション開発において強力な基盤となります。