はじめに
マイクロサービスを本番環境にデプロイするのは最もリスクが高い時期です。バグが発生した場合の爆発範囲は展開戦略によって決まります。影響を受けるのはユーザーの 100% ですか、それとも 5% だけですか?この記事では、戦略を比較し、適切な戦略を選択するためのガイダンスを提供します。
1. ローリングアップデート
Kubernetes mặc định:
Pod v1 ●●●●● (5 replicas)
Deploy v2:
Step 1: ●●●●● + ○ (1 new pod v2 starting)
Step 2: ●●●● + ○○ (2 v2 ready, 1 v1 terminated)
Step 3: ●●● + ○○○ (3 v2 ready)
Step 4: ●● + ○○○○
Step 5: ○○○○○ (all v2)
● = v1, ○ = v2
利点: ダウンタイムゼロ、段階的、K8s ネイティブ 欠点: ロールアウト中にバージョンが混在し、ロールバックが遅い ユースケース: 低リスクの変更、ステートレスなサービス
2. ブルー/グリーン展開
Blue (current, live): ●●●●● ← traffic
Green (new, staging): ○○○○○ ← no traffic
Test Green thoroughly, then switch:
Blue: ●●●●● ← no traffic (standby)
Green: ○○○○○ ← ALL traffic switched instantly
利点: 即時ロールバック (青色に戻る)、本番前の完全なテスト 欠点: 2 倍のリソースが必要、データベースの移行には下位互換性が必要 使用例: 即時ロールバックが必要な場合の重要なサービス
3. カナリア展開 ⭐
Step 1: ●●●●● (100% v1)
Step 2: ●●●●○ (90% v1, 10% v2) ← canary
Step 3: Monitor metrics (error rate, latency, CPU)
Step 4a: Metrics OK → ●●●○○ → ●●○○○ → ○○○○○ (promote)
Step 4b: Metrics BAD → ●●●●● (rollback, remove canary)
利点: 最小の爆発範囲、データ主導型プロモーション 欠点: セットアップが複雑で、適切なモニタリングが必要 使用例: ほとんどの実稼働環境 - 推奨されるデフォルト
4. Argo のロールアウト (プログレッシブ配信)
# rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: product-service
spec:
replicas: 5
strategy:
canary:
canaryService: product-service-canary
stableService: product-service-stable
steps:
- setWeight: 5
- pause: { duration: 5m }
- setWeight: 20
- pause: { duration: 10m }
- setWeight: 50
- pause: { duration: 15m }
- setWeight: 100
analysis:
templates:
- templateName: success-rate
startingStep: 2
args:
- name: service-name
value: product-service
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
metrics:
- name: success-rate
interval: 1m
successCondition: result[0] >= 0.99
provider:
prometheus:
address: http://prometheus:9090
query: |
sum(rate(http_requests_total{service="{{args.service-name}}",code=~"2.."}[5m]))
/
sum(rate(http_requests_total{service="{{args.service-name}}"}[5m]))
5. 機能フラグ
ユーザーに対して 有効化せずにコードを実稼働環境にデプロイします。
// Feature flag check
const unleash = require('unleash-client');
app.get('/api/products', (req, res) => {
const products = getProducts();
if (unleash.isEnabled('new-recommendation-engine', {
userId: req.user.id
})) {
// New feature, enabled for specific users
products.forEach(p => {
p.recommendations = newEngine.getRecommendations(p.id);
});
}
res.json(products);
});
機能フラグ + カナリア
1. Deploy v2 with feature flag OFF → 100% users get old behavior
2. Enable flag for 5% users → monitor
3. Gradually increase → 20% → 50% → 100%
4. Remove flag from code after full rollout
6. 意思決定マトリックス
| 戦略 | リスク | スピード | コスト | ロールバック | 最適な用途 |
|---|---|---|---|---|---|
| ローリング | 中 | 遅い | 低い | 遅い | 低リスクの変更 |
| ブルー/グリーン | 低い | 速い | 高 (2x) | インスタント | 重要なサービス |
| カナリア | 非常に低い | 中 | 低い | 速い | デフォルトの選択肢 |
| 機能フラグ | 非常に低い | インスタント | 低い | インスタント | UX の変更 |
推奨
E-Commerce Platform:
├── Backend services: Canary (Argo Rollouts) + Auto analysis
├── Micro Frontends: Canary via CDN traffic splitting
├── Database changes: Blue/Green (backward compatible)
└── UI features: Feature flags (Unleash)
7. ロールバック戦略
| コンポーネント | ロールバック方法 |
|---|---|
| K8s の展開 | kubectl rollout undo |
| アルゴのロールアウト | 失敗した分析時の自動ロールバック |
| CDN の MFE | 前のバージョンを指す |
| データベース | 順方向移行 (スキーマをロールバックしない) |
| 機能フラグ | フラグを即座に無効にする |
概要
- ローリング アップデート: K8 のデフォルト、シンプル、低リスクに適しています
- 青/緑: 即時ロールバック、コスト 2 倍
- カナリア: 最小爆発半径 — 推奨デフォルト
- Argo Rollouts: 分析による自動化されたプログレッシブ配信
- 機能フラグ: デプロイ ≠ リリース、インスタント有効化/無効化