tech・5分で読める
CI/CD構築時の実践的考慮事項
CI/CDパイプラインを構築する際に考慮すべき実践的なポイントを、キャッシュ戦略、セキュリティ、パフォーマンス最適化、デプロイ戦略の観点から解説します。
#CI/CD#DevOps#セキュリティ#パフォーマンス#ベストプラクティス
CI/CD構築時の実践的考慮事項
CI/CDパイプラインを構築する際に直面する実践的な課題と、その解決策をまとめました。概念的な説明ではなく、実際に構築する際に考慮すべき具体的なポイントに焦点を当てています。
目次
キャッシュ戦略
依存関係のキャッシュ
考慮すべきポイント:
キャッシュキーの設計
- ロックファイル（
package-lock.json,yarn.lockなど）のハッシュを使用 - 依存関係が変わった時だけキャッシュを無効化
- OS情報を含めて異なる環境間での競合を防ぐ
- 部分一致による復元（fallback）を考慮
Docker ビルドキャッシュ
- レイヤーキャッシュの仕組みを理解する
- マルチステージビルドで依存関係とビルドを分離
- 変更頻度の低いレイヤーを先に配置
- キャッシュストレージの選択（ローカル、レジストリ、CI専用ストレージ）
キャッシュが効かない原因
- タイムスタンプの変化: ファイルコピーの順序が不適切
- 非決定的なコマンド: 実行のたびに結果が変わるコマンド
- ファイルの除外漏れ:
.dockerignoreや.gitignoreの設定不足
キャッシュサイズの管理
制限を把握する:
- GitHub Actions: リポジトリあたり10GB
- CircleCI: プランによる（Free: 500MB程度）
- GitLab CI: プランによる制限
管理戦略:
- 不要なファイルを除外設定に追加
- キャッシュの有効期限を設定
- 必要最小限のファイルのみキャッシュ
- 手動クリア機能の実装
セキュリティ
シークレットの管理
絶対に避けるべきこと
- ハードコーディング（コードやYAMLファイルに直接記述）
- ログへの出力（デバッグ時に気づかず出力してしまう）
- Gitリポジトリへのコミット
- 不適切な権限での共有
正しい管理方法
- CI/CDツールのシークレット管理機能を使用
- 環境変数として安全に渡す
- ログマスキング機能の活用
- シークレットへのアクセス履歴の記録
権限の最小化
パイプライン実行権限
- デフォルトは最小権限（読み取りのみ）
- 必要な操作ごとに権限を明示的に付与
- OIDC認証の活用（長期的な認証情報を保存しない）
サービスアカウントの設計
- 必要最小限のリソースへのアクセスのみ許可
- 読み取り専用と書き込みを明確に分離
- 定期的な権限の見直し
依存関係のセキュリティ
脆弱性スキャン
- 定期的な依存関係のスキャン（Dependabot、Snyk、など）
- 重要度（Critical、High）に応じた対応
- 自動アップデートの仕組み
検討すべき項目
- スキャン頻度（毎日、毎週）
- 自動修正の範囲（パッチバージョンのみ、マイナーバージョンまで）
- アラート通知先
- 承認フロー
コンテナイメージのセキュリティ
イメージスキャン
- ベースイメージの脆弱性チェック
- アプリケーション層の脆弱性チェック
- スキャン失敗時のパイプライン停止
ベストプラクティス
- 最小限のベースイメージ使用（alpine、distroless）
- 不要なツール・パッケージの削除
- 定期的なベースイメージの更新
シークレットのローテーション
計画の策定:
- 定期的な更新サイクル（3〜6ヶ月）
- 漏洩時の緊急対応手順
- 使用状況の監視とアラート
- 古いシークレットの無効化タイミング
パフォーマンス最適化
ビルド時間の短縮
並列実行の活用
- マトリックス戦略（複数バージョン、複数OS）
- 独立したジョブの同時実行
- 依存関係を最小限に設計
ジョブの依存関係設計
- 直列にする必要があるもの（lint → test → build → deploy）
- 並列実行できるもの（lint と test、複数環境へのデプロイ）
- 失敗時の影響範囲を考慮
実行環境の選択
考慮すべき要素:
- CPUコア数とメモリサイズ
- コスト（実行時間 × リソース）
- ビルド特性（CPU集約型、メモリ集約型）
選択肢:
- クラウドランナー（標準、ハイスペック）
- セルフホスト（専用マシン、コンテナ）
不要な処理のスキップ
スキップすべきケース:
- ドキュメントのみの変更時
- 特定ブランチ・タグのみ実行
- コミットメッセージに
[skip ci]が含まれる場合 - 変更されたファイルの種類による判断
インクリメンタルビルド
活用できる場面:
- ビルドキャッシュの再利用
- 変更差分のみのコンパイル
- Next.js、Turborepoなどのインクリメンタル対応ツール
注意点:
- キャッシュの一貫性
- クリーンビルドのタイミング
- ディスク容量の管理
環境変数とシークレット管理
環境ごとの変数管理
設計のポイント:
- 環境（dev/staging/production）ごとに異なる設定を管理
- 承認フローの設定（productionへのデプロイは承認必須など）
- 環境変数の優先順位（環境固有 > リポジトリ > 組織）
動的な環境変数の生成
よく使われる動的変数:
- ビルド時刻
- Gitコミットハッシュ
- バージョン番号
- ブランチ名
用途:
- デプロイ時のトレーサビリティ
- キャッシュキーの生成
- アーティファクトの命名
シークレットの階層管理
3つのレベル:
-
Organization Secrets
- 全リポジトリで共通（AWS アカウントID、レジストリURLなど）
-
Repository Secrets
- リポジトリ固有（データベースURL、特定のAPI キーなど）
-
Environment Secrets
- 環境固有（staging/productionで異なるAPI キー）
管理のベストプラクティス:
- 最も限定的なスコープを使用
- 必要なリポジトリ・環境のみにアクセス権を付与
- 定期的な棚卸しと不要なシークレットの削除
デプロイ戦略
Blue-Green デプロイ
概要:
- 新バージョン（Green）と旧バージョン（Blue）を並行稼働
- Greenへのデプロイ完了後、トラフィックを一気に切り替え
- 問題があれば即座にBlueに戻せる
メリット:
- ダウンタイムゼロ
- 高速なロールバック
- 本番環境で最終テスト可能
デメリット:
- 2倍のリソースが必要
- データベーススキーマ変更時の考慮が必要
Canary デプロイ
概要:
- 新バージョンを少量のトラフィック（5〜10%）で試験運用
- 問題なければ段階的に増やす（10% → 25% → 50% → 100%）
- 各段階でメトリクスを監視
監視すべきメトリクス:
- エラー率
- レスポンスタイム
- リソース使用率
- ビジネスメトリクス（コンバージョン率など）
メリット:
- リスクの最小化
- 本番環境での段階的検証
- A/Bテストとの組み合わせ
ローリングデプロイ
概要:
- 複数インスタンスを順次更新
- 常に一定数の稼働インスタンスを維持
設定項目:
- 同時更新数（1台ずつ、25%ずつ、など）
- ヘルスチェックの待機時間
- タイムアウト設定
適用場面:
- Kubernetes、ECS、EC2 Auto Scaling
- ステートレスなアプリケーション
ロールバック戦略
考慮事項:
- 自動ロールバックの条件（エラー率、タイムアウト）
- 手動ロールバックの手順
- データベースマイグレーションの巻き戻し
- ロールバック時の通知
準備すべきこと:
- 前バージョンの保持
- ロールバック手順の文書化
- テスト済みのロールバック機能
エラーハンドリングとリトライ
リトライロジック
考慮すべきポイント:
- リトライ回数（3〜5回が一般的）
- リトライ間隔（固定 or 指数バックオフ）
- リトライすべきエラーの種類（一時的なエラーのみ）
- 無限ループの防止
リトライが有効な場面:
- ネットワークの一時的な障害
- レートリミット
- 外部サービスの一時的な不調
リトライすべきでない場面:
- 認証エラー
- 構文エラー
- リソース不足（メモリ、ディスク）
タイムアウト設定
階層的なタイムアウト:
- ジョブ全体のタイムアウト
- 個別ステップのタイムアウト
- コマンドレベルのタイムアウト
設定の目安:
- ビルド: 15〜30分
- テスト: 10〜20分
- デプロイ: 5〜15分
注意点:
- 予想より余裕を持たせる（通常の1.5〜2倍）
- 環境によるばらつきを考慮
失敗時の通知
通知すべき情報:
- 失敗したジョブ/ステップ
- リポジトリとブランチ
- コミット情報（SHA、作成者、メッセージ）
- 失敗時刻
- ログへのリンク
通知チャンネル:
- Slack/Teams（チーム全体）
- Email（特定担当者）
- PagerDuty（本番デプロイ失敗）
通知のベストプラクティス:
- 重要度に応じたチャンネル分け
- メンション対象の明確化
- アクション可能な情報を含める
モニタリングとアラート
パイプラインのメトリクス
追跡すべき4つの主要指標（Four Keys）:
-
デプロイ頻度
- どれくらいの頻度でリリースしているか
- 目標: 日次〜週次
-
変更のリードタイム
- コミットからデプロイまでの時間
- 目標: 1日以内
-
変更失敗率
- デプロイの失敗率
- 目標: 15%以下
-
復旧時間（MTTR）
- 障害から復旧するまでの時間
- 目標: 1時間以内
その他の有用なメトリクス:
- ビルド時間（平均、P95、P99）
- キャッシュヒット率
- テスト成功率
- セキュリティスキャンの検出数
デプロイメント追跡
記録すべき情報:
- デプロイ日時
- デプロイ対象環境
- デプロイしたバージョン（Gitハッシュ）
- デプロイ実行者
- デプロイ結果（成功/失敗）
用途:
- インシデント時の原因特定
- ロールバック先の判断
- デプロイ頻度の可視化
パイプライン可視化
ダッシュボードで表示すべき項目:
- パイプライン実行状況（リアルタイム）
- 成功率のトレンド
- ビルド時間の推移
- 失敗の原因分析
- コスト（実行時間 × リソース）
可視化の目的:
- ボトルネックの特定
- 改善効果の測定
- チーム全体での共有
コスト最適化
実行条件の最適化
考慮すべきポイント:
- 実行する必要があるブランチの選定
- PRの種類による実行の制御
- ファイル変更による実行の制御
例:
- main/develop ブランチのみフルテスト
- PRは軽量テストのみ
- ドキュメント変更はCI/CDスキップ
無料枠の理解と活用
主要サービスの無料枠:
- GitHub Actions (Public): 無制限
- GitHub Actions (Private): 2,000分/月
- CircleCI: 月間一定クレジット
- GitLab CI: 月間一定分数
最適化戦略:
- パブリックリポジトリの活用
- 実行時間の短縮（並列化、キャッシュ）
- 不要な実行の削減
セルフホストランナーの検討
検討すべきタイミング:
- 月間実行時間が多い（数千分以上）
- 特殊なハードウェアが必要
- セキュリティ要件が厳しい
メリット:
- 長期的なコスト削減
- 実行速度の向上
- カスタマイズの自由度
デメリットと対策:
- 運用コスト → 自動化・監視の整備
- セキュリティリスク → ネットワーク分離、定期更新
- 可用性 → 冗長化、監視
実行時間の短縮
コスト削減の観点:
- 実行時間 × リソース = コスト
- キャッシュによる依存関係インストールのスキップ
- 並列実行による総実行時間の短縮
- 不要なステップの削除
チェックリスト
セキュリティ
- シークレットをハードコーディングしていない
- 最小権限の原則を適用している
- 依存関係のセキュリティスキャンを実施している
- イメージスキャンを実施している（Docker使用時）
- シークレットのローテーション計画がある
パフォーマンス
- 依存関係をキャッシュしている
- ビルド成果物をキャッシュしている
- 並列実行を活用している
- 不要なステップをスキップしている
- 適切なランナーサイズを選択している
信頼性
- リトライロジックを実装している
- タイムアウトを設定している
- ロールバック手順が定義されている
- ヘルスチェックを実施している
- 失敗時の通知を設定している
運用
- デプロイメントを追跡している
- メトリクスを収集している
- ログを集約している
- アラートを設定している
- ドキュメントを整備している