ストーリー
佐
佐藤CTO
どんなに優れたコードも、安全にデプロイできなければ価値を届けられない
佐
佐藤CTO
NexPayのCI/CDパイプラインは、金融サービスとしてのセキュリティ基準を満たしながら、開発チームが自律的にデプロイできる仕組みでなければならない
佐
佐藤CTO
GitOpsベースのパイプラインを設計しよう。“どうデプロイするか”ではなく、“どう安全にデプロイし続けるか”が問われる
GitOpsアーキテクチャ
全体構成
NexPay CI/CD GitOps全体像:
┌─────────────┐ ┌─────────────────┐ ┌──────────────┐
│ Application │ │ GitHub Actions │ │ Container │
│ Repo │────→│ (CI Pipeline) │────→│ Registry │
│ │ │ │ │ (ECR) │
└─────────────┘ └─────────────────┘ └──────┬───────┘
│
│ Image SHA更新
▼
┌─────────────┐ ┌─────────────────┐ ┌──────────────┐
│ Production │←────│ Argo CD │←────│ GitOps │
│ EKS Cluster │ │ (CD Pipeline) │ │ Repo │
│ │ │ │ │ (k8s manifests)|
└─────────────┘ └─────────────────┘ └──────────────┘
原則:
- Application RepoとGitOps Repoを分離
- イメージタグはSHA256ダイジェストを使用（:latestは禁止）
- GitOps Repoへのマージ = デプロイのトリガー
- 手動のkubectl applyは禁止（Argo CDが唯一の反映経路）CIパイプライン
ステージ設計
# GitHub Actions: CI Pipeline
name: NexPay CI Pipeline
on:
pull_request:
branches: [main, develop]
push:
branches: [main]
jobs:
# Stage 1: 静的解析（並列実行、2分）
lint-and-analyze:
runs-on: ubuntu-latest
strategy:
matrix:
check: [ktlint, detekt, dependency-check]
steps:
- uses: actions/checkout@v4
- name: Run ${{ matrix.check }}
run: ./gradlew ${{ matrix.check }}
# Stage 2: ユニットテスト（3分）
unit-test:
runs-on: ubuntu-latest
needs: lint-and-analyze
steps:
- uses: actions/checkout@v4
- name: Run unit tests
run: ./gradlew test
- name: Upload coverage
uses: codecov/codecov-action@v4
with:
fail_ci_if_error: true
# カバレッジ閾値: 80%未満で失敗
threshold: 80
# Stage 3: インテグレーションテスト（5分）
integration-test:
runs-on: ubuntu-latest
needs: unit-test
services:
postgres:
image: postgres:15
redis:
image: redis:7
kafka:
image: confluentinc/cp-kafka:7.5.0
steps:
- uses: actions/checkout@v4
- name: Run integration tests
run: ./gradlew integrationTest
# Stage 4: セキュリティスキャン（並列実行、3分）
security-scan:
runs-on: ubuntu-latest
needs: unit-test
strategy:
matrix:
scan: [trivy, snyk, semgrep]
steps:
- uses: actions/checkout@v4
- name: Run ${{ matrix.scan }}
run: ./scripts/security/${{ matrix.scan }}.sh
# Critical/Highの脆弱性があれば失敗
# OWASP Top 10のチェックを含む
# Stage 5: コンテナイメージビルド & プッシュ（2分）
build-and-push:
runs-on: ubuntu-latest
needs: [integration-test, security-scan]
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- name: Build & Push to ECR
run: |
IMAGE_TAG="${{ github.sha }}"
docker build -t nexgpay/payment-service:${IMAGE_TAG} .
docker push nexgpay/payment-service:${IMAGE_TAG}
- name: Update GitOps repo
run: |
# GitOps Repoのイメージタグを更新してPR作成
./scripts/update-gitops-image.sh ${{ github.sha }}パイプラインの品質ゲート
■ 品質ゲート（すべてパスしないとデプロイ不可）
┌─────────────────────────────────────────────┐
│ Gate 1: コード品質 │
│ - ktlint / detekt: 警告0件 │
│ - テストカバレッジ: > 80% │
│ - 循環的複雑度: < 15 │
└──────────────────────┬──────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Gate 2: テスト │
│ - ユニットテスト: 全件パス │
│ - インテグレーションテスト: 全件パス │
│ - コントラクトテスト: 全件パス（Pact） │
└──────────────────────┬──────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Gate 3: セキュリティ │
│ - SAST: Critical/High脆弱性0件 │
│ - 依存関係: 既知の脆弱性なし │
│ - コンテナイメージ: Critical脆弱性0件 │
│ - シークレット検出: ハードコードされた秘密情報0件│
└──────────────────────┬──────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Gate 4: 承認 │
│ - コードレビュー: 2名以上のApprove │
│ - CDE変更時: セキュリティチームのApprove必須 │
└─────────────────────────────────────────────┘CDパイプライン
デプロイ戦略
■ デプロイ戦略の選択
| サービス | 戦略 | 理由 |
|---------|------|------|
| Payment Service | Canary (5%→25%→100%) | 決済は影響大。段階的に検証 |
| Account Service | Blue/Green | 残高に関わるため、即座ロールバック必要 |
| Investment Service | Rolling Update | 注文キューで非同期処理。部分更新可 |
| Notification Service | Rolling Update | 通知の遅延は許容可能 |
| BFF | Canary (10%→50%→100%) | ユーザー影響を段階的に確認 |
■ Canaryデプロイの自動判定
Step 1: Canary 5%にデプロイ
↓ 10分間モニタリング
↓ 判定基準:
↓ - エラーレート: < 0.1%（ベースラインの2倍以下）
↓ - レイテンシ p99: < 1000ms（ベースラインの1.5倍以下）
↓ - 決済成功率: > 99.5%
↓
自動判定: 基準クリア → Step 2へ / 基準未達 → 自動ロールバック
↓
Step 2: Canary 25%にスケールアップ
↓ 10分間モニタリング（同じ基準）
↓
Step 3: 100%にプロモートArgo CD設定
# Argo CD Application定義
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-service
namespace: argocd
spec:
project: nexgpay-production
source:
repoURL: https://github.com/nexgpay/gitops-config
targetRevision: main
path: services/payment-service/production
destination:
server: https://kubernetes.default.svc
namespace: payment
syncPolicy:
automated:
prune: true # 不要リソースの自動削除
selfHeal: true # ドリフト検出時の自動修復
syncOptions:
- CreateNamespace=true
retry:
limit: 3
backoff:
duration: 5s
factor: 2
maxDuration: 3m0s環境戦略
環境構成
■ NexPay環境構成
開発環境 (dev):
- PR単位のプレビュー環境（自動作成・自動削除）
- 共有開発DB（テストデータ）
- 外部APIはモック
ステージング環境 (staging):
- 本番と同一構成（スケール小）
- 外部API: サンドボックス接続
- E2Eテスト自動実行
- 負荷テスト実行（週次）
本番環境 (production):
- マルチAZ + DR構成
- 外部API: 本番接続
- Canaryデプロイ
- 24/365監視
環境間の昇格フロー:
dev → staging → production
↑ ↑ ↑
自動 自動 手動承認（Canary自動判定付き）まとめ
| ポイント | 内容 |
|---|---|
| GitOps | Application RepoとGitOps Repoを分離。Argo CDが唯一のデプロイ経路 |
| CI | 静的解析→テスト→セキュリティスキャン→ビルドの4ステージ |
| 品質ゲート | コード品質、テスト、セキュリティ、承認の4段階 |
| CD | サービス特性に応じたCanary/Blue-Green/Rollingの使い分け |
| 環境 | dev→staging→productionの3環境。PR単位のプレビュー環境 |
チェックリスト
- GitOpsアーキテクチャの全体構成を設計できた
- CIパイプラインの各ステージと品質ゲートを定義できた
- サービス特性に応じたデプロイ戦略を選択できた
- 環境構成と昇格フローを設計できた
次のステップへ
次は「移行計画とフェーズ設計」に進みます。設計したアーキテクチャをどのような順序で構築し、既存システムから移行するかを計画しましょう。
推定読了時間: 40分