GitHub Actions デプロイ後ヘルスチェック実装：複合監視と自動復旧の実践¶
この記事は朝の記事のフォローアップです
ゴール¶
- 複数指標による包括的ヘルスチェックを5分で実装
- 障害検知から30秒以内での自動ロールバック実行
- Slack・メール・PagerDuty連携による運用チーム即座通知
アーキテクチャ概要¶
本格的なヘルスチェックは単一のエンドポイント確認を超え、以下の4層で障害を早期検知します：
- Basic Health - HTTP応答とステータスコード
- Performance - レスポンス時間とスループット
- Dependencies - DB・外部API・キューサービス接続
- Business Logic - 主要機能の動作確認
実装ステップ¶
ステップ1: 包括的ヘルスチェックスクリプト¶
#!/bin/bash
# health_check_comprehensive.sh
set -e
ENDPOINT="${1:-https://your-app.com}"
MAX_RESPONSE_TIME=2000 # milliseconds
RETRIES=3
WAIT_BETWEEN_TESTS=10
echo "🏥 Starting comprehensive health check for: $ENDPOINT"
# Basic HTTP Health Check
for i in $(seq 1 $RETRIES); do
HTTP_CODE=$(curl -s -o /dev/null -w "%%{http_code}" "$ENDPOINT/health")
RESPONSE_TIME=$(curl -s -o /dev/null -w "%%{time_total}" "$ENDPOINT/health" | cut -d. -f1-3)
if [[ $HTTP_CODE == "200" ]]; then
echo "✅ HTTP Check passed ($HTTP_CODE) - Response: ${RESPONSE_TIME}ms"
break
else
echo "❌ HTTP Check failed ($HTTP_CODE) - Attempt $i/$RETRIES"
[[ $i -eq $RETRIES ]] && exit 1
fi
sleep $WAIT_BETWEEN_TESTS
done
ステップ2: 依存サービス監視統合¶
# .github/workflows/health-check-advanced.yml
name: Advanced Health Check
on:
workflow_call:
inputs:
environment:
required: true
type: string
endpoint:
required: true
type: string
jobs:
health-check:
runs-on: ubuntu-latest
steps:
- name: Multi-layer Health Check
run: |
# Database Connection Test
curl -f ${{ inputs.endpoint }}/health/db || echo "DB_FAIL=true" >> $GITHUB_ENV
# Redis/Cache Test
curl -f ${{ inputs.endpoint }}/health/cache || echo "CACHE_FAIL=true" >> $GITHUB_ENV
# External API Dependencies
curl -f ${{ inputs.endpoint }}/health/external || echo "EXT_FAIL=true" >> $GITHUB_ENV
# Performance Test (load simulation)
ab -n 50 -c 5 ${{ inputs.endpoint }}/api/test > perf_results.txt
- name: Analyze Performance Metrics
run: |
RESPONSE_TIME=$(grep "mean.*per request" perf_results.txt | head -1 | awk '{print $4}')
REQUESTS_PER_SEC=$(grep "Requests per second" perf_results.txt | awk '{print $4}')
echo "⏱️ Average Response Time: ${RESPONSE_TIME}ms"
echo "🚀 Requests per Second: $REQUESTS_PER_SEC"
# Performance thresholds
if (( $(echo "$RESPONSE_TIME > 1000" | bc -l) )); then
echo "PERF_FAIL=true" >> $GITHUB_ENV
fi
ステップ3: 自動復旧とアラート連携¶
- name: Rollback Decision Engine
if: env.DB_FAIL == 'true' || env.CACHE_FAIL == 'true' || env.PERF_FAIL == 'true'
run: |
echo "🚨 Critical failure detected - initiating rollback"
# Get previous successful deployment
PREV_VERSION=$(curl -s ${{ secrets.DEPLOYMENT_API }}/versions/previous)
# Execute rollback
curl -X POST ${{ secrets.DEPLOYMENT_API }}/rollback \
-H "Authorization: Bearer ${{ secrets.DEPLOY_TOKEN }}" \
-d "{\"version\": \"$PREV_VERSION\", \"reason\": \"health_check_failure\"}"
- name: Instant Notification Pipeline
if: failure()
uses: 8398a7/action-slack@v3
with:
status: failure
text: |
🔥 CRITICAL: ${{ inputs.environment }} deployment failed health check
Failed Components:
- DB: ${{ env.DB_FAIL }}
- Cache: ${{ env.CACHE_FAIL }}
- Performance: ${{ env.PERF_FAIL }}
Rollback Status: ${{ steps.rollback.outcome }}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}
ベンチマーク比較¶
| 監視レベル | 検知時間 | 偽陽性率 | 復旧時間 | 運用コスト |
|---|---|---|---|---|
| 基本HTTP確認のみ | 30秒 | 15% | 5-10分 | 低 |
| パフォーマンス統合 | 45秒 | 8% | 2-3分 | 中 |
| 依存サービス含む | 60秒 | 3% | 30秒-1分 | 高 |
| ビジネスロジック検証 | 90秒 | 1% | 30秒 | 最高 |
失敗パターンと回避策¶
| 症状 | 原因 | 回避策 |
|---|---|---|
| タイムアウトによる誤検知 | ネットワーク遅延 | リトライ回数を3-5回に設定、待機時間調整 |
| ロードバランサーでの502エラー | デプロイ中のインスタンス切り替え | ヘルスチェック前に60秒待機時間挿入 |
| 依存サービスの一時的障害 | 外部APIのレート制限 | サーキットブレーカーパターンで監視除外 |
| アラートスパム | 小さな障害での過剰通知 | 障害レベル分類と通知頻度制限 |
高度な監視パターン（運用レベル拡張）
### カナリア監視統合- name: Canary Traffic Health Check
run: |
# 本番トラフィックの1%をcanaryにルーティング
kubectl patch service app-service -p '{"spec":{"selector":{"version":"canary"}}}'
# 5分間のエラー率監視
sleep 300
ERROR_RATE=$(kubectl logs -l version=canary | grep ERROR | wc -l)
if [[ $ERROR_RATE -gt 5 ]]; then
echo "Canary error rate too high: $ERROR_RATE"
exit 1
fi
- name: Custom Metrics Collection
run: |
# Prometheus metrics endpoint
METRICS=$(curl -s ${{ inputs.endpoint }}/metrics)
# Extract key business metrics
ACTIVE_USERS=$(echo "$METRICS" | grep active_users_total | awk '{print $2}')
ORDER_SUCCESS_RATE=$(echo "$METRICS" | grep order_success_rate | awk '{print $2}')
# Threshold validation
if (( $(echo "$ORDER_SUCCESS_RATE < 0.95" | bc -l) )); then
echo "ORDER_ALERT=true" >> $GITHUB_ENV
fi
自動化拡張案¶
- AI障害予測: ログパターン解析による障害発生前アラート
- マルチリージョン監視: 地域別レイテンシとフェイルオーバー自動化
- ビジネスメトリクス統合: 売上・ユーザー体験指標での異常検知
- ChatOps統合: Slackコマンドによる手動ロールバック・詳細調査
- 学習型しきい値: 過去データに基づく動的パフォーマンス基準調整