AWS CodeBuildを速くする方法 - 初心者向けパフォーマンス改善ガイド
CodeBuildのビルド時間が長いと、開発効率が下がりコストも増加します。初心者でも簡単に実践できる高速化テクニックとコスト削減方法を、具体例とともにわかりやすく解説します。
ビルドが遅くなる原因
よくある遅くなる理由
ビルド時間の内訳
一般的なWebアプリのビルド時間は以下のように分かれます:
改善のポイント: 依存関係のダウンロード時間(40%)を短縮すれば、大幅な高速化が可能です。
キャッシュ機能で高速化
キャッシュとは何か
キャッシュとは、「一度ダウンロードしたファイルを保存しておいて、次回は再利用する仕組み」です。
基本的なキャッシュ設定
キャッシュ設定の基本的な考え方
キャッシュ機能を有効にするためには、「どのファイルをキャッシュするか」を指定する必要があります。一般的には、プロジェクトの依存関係ファイル(ライブラリファイル)をキャッシュすることで、最大の効果を得られます。
プロジェクト種別のキャッシュ対象:
Node.js/JavaScriptプロジェクト:
node_modules
フォルダ—npmでインストールしたパッケージが保存されるフォルダで、ビルドのたびに数百から数千のファイルをダウンロードするため、キャッシュ効果が非常に高いです。Javaプロジェクト:
.m2/repository
フォルダ—Mavenの依存関係JARファイルが保存される場所で、Javaライブラリのダウンロード時間を短縮できます。Pythonプロジェクト: pipのキャッシュフォルダ—pipでインストールしたパッケージを保存し、次回のインストールを高速化します。
AWSコンソールでのキャッシュ設定: CodeBuildプロジェクトの設定画面で、「キャッシュ」セクションがあります。ここで「S3キャッシュ」を有効にし、キャッシュするファイルパスを指定するだけで、簡単に高速化を実現できます。
キャッシュの効果
実際の改善例:
- キャッシュなし: 8分
- キャッシュあり: 3分(依存関係ダウンロードを省略)
適切なコンピュートサイズの選択
サイズ選択の考え方
プロジェクトに適したサイズを選ぶことで、速度とコストのバランスを取れます。
実際の判断基準
プロジェクト種類 | 推奨サイズ | 理由 |
---|---|---|
個人ブログ、シンプルサイト | Small | ファイル数が少なく軽量 |
React/Vue.jsアプリ | Medium | JavaScriptビルドには適度な性能が必要 |
大規模Webアプリ | Large | 多くの依存関係とファイル処理が必要 |
サイズ変更のテスト方法
- Smallから始める: まずは最小サイズでテスト
- 時間を測定: ビルド時間を記録
- 必要に応じて拡大: 10分以上かかる場合は上位サイズを検討
不要なファイルの除外
.gitignoreの活用
ビルドに不要なファイルを除外することで、処理時間を短縮できます。
ファイル除外の実践的な考え方
.gitignoreファイルの適切な設定は、ビルド時間の短縮に大きな影響を与えます。特に、ビルドに必要のないファイルを除外することで、CodeBuildが処理するファイル数を減らし、結果的に高速化が実現されます。
除外すべき主なファイルカテゴリ:
- 依存関係フォルダ: node_modules、.venvなど—キャッシュ機能で管理されるため、ソースコードに含める必要なし
- ビルド生成物: dist、buildフォルダ—ビルド処理で自動生成されるため、ソースから除外
- テスト結果: coverage、test-resultsなど—テスト実行時に自動生成されるため不要
- OS固有ファイル: .DS_Store、Thumbs.dbなど—ビルドに関係ないシステムファイル
- エディタ設定: .vscode、.ideaなど—個人の開発環境設定で、ビルドに不要
除外設定の効果: 適切な.gitignore設定により、ソースコードリポジトリのサイズが小さくなり、CodeBuildが処理するファイル数が減ってビルド時間が短縮されます。特に、大規模なプロジェクトでは数分の短縮効果が得られることもあります。
実用的な高速化テクニック
1. 並列処理の活用
複数のタスクを同時に実行することで時間短縮できます。
並列処理の実装方法
並列処理の実装は、buildspec.ymlファイルで簡単に設定できます。基本的な仕組みは、コマンドの後に&
記号を付けることでバックグラウンド実行させ、最後にwait
コマンドですべての処理の完了を待つというものです。
適用すべきシナリオ:
- ユニットテストとビルド処理の同時実行
- 複数モジュールの独立ビルド
- フロントエンドとバックエンドの同時ビルド
並列処理の制約事項: すべてのタスクが並列実行に適しているわけではありません。例えば、テストが失敗した場合にビルドを中止したいなど、タスク間に依存関係がある場合は、順次実行のほうが適切です。
2. ビルドスクリプトの最適化
不要な処理の削除
phases:
build:
commands:
- echo "必要な処理のみ実行"
- npm run build --production # 開発用ツールを除外
- npm run optimize # ファイル圧縮・最適化
条件付き処理
phases:
build:
commands:
- |
if [ "$CODEBUILD_SOURCE_VERSION" = "refs/heads/main" ]; then
echo "本番用の完全ビルド"
npm run build:full
else
echo "開発用の簡易ビルド"
npm run build:dev
fi
コスト最適化の基本
料金の仕組み理解
CodeBuildは「使った分だけ」の料金体系です。
無料枠の活用
- 月100分まで無料(EC2コンピュート環境)
- Medium環境で月20回ビルド(各5分)なら無料枠内
- 目安: 個人プロジェクトなら無料枠で十分な場合が多い
コスト節約のコツ
1. 必要な時だけビルド
phases:
install:
commands:
- |
# 変更されたファイルをチェック
if git diff --name-only HEAD^ | grep -E '\.(js|ts|css)$'; then
echo "ソースコードが変更されました - ビルド実行"
else
echo "ドキュメントのみの変更 - ビルドスキップ"
exit 0
fi
2. ビルド時間の短縮
実践的な最適化例
Webサイトビルドの最適化
最適化前(遅い例)
version: 0.2
phases:
install:
runtime-versions:
nodejs: 18
build:
commands:
- npm install # 毎回すべてダウンロード
- npm test
- npm run build
- npm run test:e2e # 時間のかかるテスト
問題点:
- キャッシュなし
- 重いテストを毎回実行
- 順次処理で時間がかかる
最適化後(速い例)
version: 0.2
cache:
paths:
- 'node_modules/**/*' # 依存関係をキャッシュ
phases:
install:
runtime-versions:
nodejs: 18
pre_build:
commands:
- npm install # 2回目以降は高速
- npm test # 軽いテストのみ
build:
commands:
- npm run build
改善点:
- キャッシュで依存関係ダウンロードを高速化
- 重いテストは別途実行
- 必要最小限の処理に絞る
React/Vue.jsアプリの最適化
効果的な設定例
version: 0.2
cache:
paths:
- 'node_modules/**/*'
- '.next/cache/**/*' # Next.jsの場合
phases:
install:
runtime-versions:
nodejs: 18
commands:
- echo "React アプリのビルド開始"
pre_build:
commands:
- npm ci # npm installより高速
build:
commands:
- npm run build
- echo "ビルド完了"
artifacts:
files:
- 'build/**/*'
よくある問題と解決方法
Q1: キャッシュを設定したのに速くならない
原因: package.jsonが変更されて、依存関係が更新された
解決方法: これは正常な動作です。依存関係に変更がない場合のみキャッシュが使われます。
Q2: ビルド時間が安定しない
原因: ネットワーク状況やサーバーの負荷による変動
対策: 複数回のビルド時間を平均で評価しましょう。
Q3: 大きなサイズにしても速くならない
原因: プロジェクトがCPUではなく、ネットワーク(ダウンロード)がボトルネック
解決方法: キャッシュ機能を優先的に導入してください。
段階的な改善手順
ステップ1: 現状把握
まずは現在のビルド時間を測定します。
phases:
install:
commands:
- echo "ビルド開始時刻: $(date)"
build:
commands:
- npm run build
post_build:
commands:
- echo "ビルド終了時刻: $(date)"
ステップ2: キャッシュ導入
最も効果の高いキャッシュ機能を追加します。
cache:
paths:
- 'node_modules/**/*' # 最も効果的
ステップ3: 不要処理の削除
時間のかかる処理を見直します。
ステップ4: サイズ調整
必要に応じてコンピュートサイズを調整します。
実際の改善事例
改善事例1: 個人ブログサイト
改善前:
- ビルド時間: 6分
- コンピュートサイズ: Medium
- キャッシュ: なし
改善後:
- ビルド時間: 2分(67%短縮)
- コンピュートサイズ: Small(コスト削減)
- キャッシュ: node_modules
実施した主な改善:AWS Console でキャッシュ機能を有効化し、コンピュートサイズをSmallに変更。buildspec.ymlでキャッシュ対象フォルダを指定。
改善事例2: 企業Webアプリ
改善前:
- ビルド時間: 12分
- コンピュートサイズ: Medium
- 処理: すべて順次実行
改善後:
- ビルド時間: 6分(50%短縮)
- コンピュートサイズ: Large(処理能力向上)
- 処理: 一部並列化
監視と継続的改善
ビルド時間の追跡
時間計測と改善効果の確認
ビルドの最適化効果を定量的に確認するためには、改善前後のビルド時間を正確に計測することが重要です。AWS コンソールのCodeBuild実行履歴でもビルド時間を確認できますが、より詳細な分析のためにbuildspec.yml内で時間計測を行うことも可能です。
効果測定のポイント:
- 複数回の平均: ネットワーク状況などによるバラツキを考慮し、3-5回のビルドの平均時間で評価
- キャッシュ有効時の確認: 2回目以降のビルドで、キャッシュ効果が発揮されているか確認
- フェーズ別計測: install、pre_build、build各フェーズの時間を個別に計測し、ボトルネックを特定
AWS コンソールでの確認方法: CodeBuildの実行履歴ページで、各ビルドの所要時間やフェーズ別の詳細情報を確認できます。ここで最適化の効果を定量的に評価し、さらなる改善点を見つけることができます。
まとめ
CodeBuildの高速化は、適切な設定と段階的な改善により実現できます。
高速化の優先順位
- キャッシュ機能の導入(最も効果的)
- 適切なコンピュートサイズの選択
- 不要な処理の削除
- 並列処理の活用
始めるときのポイント
- まずはキャッシュから: 最も簡単で効果的
- 段階的に改善: 一度にすべて変更せず、少しずつ
- 時間を測定: 改善効果を数値で確認
- コストと速度のバランス: 過度な最適化は避ける
次の記事では、CodeBuildのセキュリティ設定について解説します。