ヘルスチェック、サーキットブレーカー、リトライロジック
ELBのヘルスチェック、Route 53のエンドポイントチェック、アプリケーションレベルのサーキットブレーカーを使用して障害を検出し、トラフィックを自動的に振り替えます。
「ヘルスチェック、サーキットブレーカー、リトライロジック」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
自動障害検知が重要な理由
分散システムでは、インスタンスのクラッシュ、ネットワークパーティションの発生、下流サービスの過負荷など、コンポーネントの障害が継続的に発生します。自動障害検知がなければ、障害が発生したコンポーネントへトラフィックが流れ続け、連鎖的な障害を引き起こします。AWS は複数の層でヘルスチェックを提供しています。ELB ヘルスチェックは異常なインスタンスを検知し、Route 53 ヘルスチェックは異常なエンドポイントを検知し、Auto Scalingは障害が発生したインスタンスを置き換えます。サーキットブレーカーやリトライなどのアプリケーションレベルのパターンを組み合わせることで、レジリエンスをさらに高められます。
ELB ヘルスチェック
Elastic Load Balancer のヘルスチェックは、登録されたターゲットに定期的にリクエストを送信し、正常な状態かどうかを判定します。ヘルスチェックパス(例:/health)、プロトコル、ポート、間隔(デフォルトは30秒)、および正常/異常のしきい値(連続した成功/失敗の回数)を設定します。ターゲットがヘルスチェックに失敗すると、ELBはそのターゲットへのトラフィックのルーティングを停止します。ターゲットの状態は継続的に再評価され、正常のしきい値を満たすと再び追加されます。
# Configure ALB target group health check
aws elbv2 modify-target-group \
--target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
--health-check-protocol HTTPS \
--health-check-port 443 \
--health-check-path /health \
--health-check-interval-seconds 15 \
--healthy-threshold-count 2 \
--unhealthy-threshold-count 3 \
--matcher HttpCode=200Route 53 ヘルスチェック
Route 53 ヘルスチェックは、グローバルに分散した複数の場所からエンドポイントを監視し、DNSフェイルオーバールーティングと連携します。種類は3つあります。エンドポイントチェックは、アプリケーションのURLに直接ポーリングします。計算済みチェックは、複数の子ヘルスチェックをAND/ORロジックで組み合わせます(複雑な監視に便利です)。CloudWatchアラームチェックは、正常性の判定をCloudWatchに委任します。パブリックなヘルスエンドポイントを公開できない場合や、メトリクスに基づいて正常性を判断する必要がある場合に便利です。
# Create endpoint health check
aws route53 create-health-check \
--caller-reference ref-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true
}'Auto Scaling のヘルスチェック
Auto Scaling Groupsでは、2種類のヘルスチェックを使用できます。EC2ヘルスチェックは、ハイパーバイザーレベルでインスタンスの障害(インスタンスステータスチェックの失敗)を検出します。ELBヘルスチェックは、よりアプリケーションの状態を反映します。インスタンスが稼働していてもエラーを返している場合があり、ELBヘルスチェックはこの状態を検出します。ASGがELBヘルスチェックを使用するように設定すれば、基盤となるEC2の障害だけでなく、アプリケーションレベルの障害でもインスタンスの置き換えを開始できます。
# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--health-check-type ELB \
--health-check-grace-period 300
# Grace period: time after launch before health checks start
# Prevents premature termination during startupサーキットブレーカーパターン
サーキットブレーカーは、ダウンストリームサービスへの呼び出しを監視し、障害がしきい値を超えたときに呼び出しを一時的に停止することで、連鎖的な障害を防ぐアプリケーションレベルのパターンです。サーキットには3つの状態があります。Closed(通常動作)、Open(障害がしきい値を超え、呼び出しが直ちにブロックされる状態)、Half-Open(タイムアウト後、サービスが復旧したかを確認するため少数のテスト呼び出しが許可される状態)です。AWS App MeshやResilience4jなどのアプリケーションSDKがこのパターンを実装しています。
# Circuit breaker states
# CLOSED: All calls pass through
# failureCount < threshold -> stay CLOSED
# failureCount >= threshold -> open circuit
# OPEN: All calls fail immediately
# After timeout -> enter HALF-OPEN
# HALF-OPEN: Allow limited test calls
# Success -> return to CLOSED
# Failure -> return to OPEN
# Example threshold: 5 failures in 10 seconds -> OPENサーキットブレーカーのための AWS App Mesh
AWS App Meshは、コードを変更せずに、インフラストラクチャレベルでサーキットブレーカー、リトライ、タイムアウトのポリシーを実装するサービスメッシュです。仮想ノードまたは仮想ルーターの設定でサーキットブレーカーポリシーを定義します。アップストリームサービスが異常になると、App MeshのEnvoyプロキシが自動的にサーキットを開き、タイムアウトを待つのではなく、直ちにエラーを返します。これは、ECSやEKS上で稼働するマイクロサービスアーキテクチャで特に有効です。
# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
'spec': {
'listeners': [{
'outlierDetection': {
'consecutiveErrors': 5,
'interval': {'unit': 'ms', 'value': 10000},
'baseEjectionDuration': {'unit': 's', 'value': 30},
'maxEjectionPercent': 50
}
}]
}
}リトライロジックと指数バックオフ
リトライロジックは、失敗した処理を自動的に再試行します。ただし、単純なリトライロジック(短いループで直ちに再試行する方式)は、過負荷の状況を悪化させる可能性があります。指数バックオフでは、再試行の間隔を指数関数的に延ばします:1秒、2秒、4秒、8秒……。これにより、負荷が高まっているサービスへの負荷を軽減し、復旧する時間を与えられます。ジッター(リトライ間隔をランダム化すること)は、短時間の障害の後にすべてのクライアントが同時に再試行する群集轟音問題を防ぎます。AWS SDKは、ジッター付きの指数バックオフを自動的に実装します。
# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds
# Python boto3 custom retry configuration
import boto3
from botocore.config import Config
config = Config(
retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)安全なリトライのための冪等性
リトライが安全なのは、操作が冪等である場合に限られます。つまり、同じ操作を複数回実行しても同じ結果になります。たとえば、同じキーでS3オブジェクトを作成する操作は冪等です(結果は同じです)。一方、注文を2回実行すると2件の注文が作成されるため、冪等ではありません。クライアントが指定する冪等性キーを使用してAPIを冪等に設計します。サーバーは最初のリクエストの結果を保存し、同じキーを使った後続のリクエストには同じ結果を返します。DynamoDB、SQS、API Gatewayは、冪等性キーのパターンをサポートしています。
# SQS message deduplication ID for FIFO queues
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
--message-body '{"orderId":"ord-123","items":[...]}' \
--message-group-id 'customer-456' \
--message-deduplication-id 'ord-123-attempt-1'
# SQS deduplicates messages with same ID for 5 minutesタイムアウトの設定
明示的なタイムアウトを設定しないと、低速なダウンストリームサービスによってスレッドが無期限にブロックされ、接続プールが枯渇して連鎖的な障害が発生します。すべてのレイヤーでタイムアウトを設定します。接続タイムアウト(TCP接続の確立にかける時間)、読み取りタイムアウト(レスポンスを受信するまでの時間)、リクエスト全体のタイムアウトです。AWSでは、ELBのアイドルタイムアウト(デフォルト60秒)、Lambdaの実行タイムアウト(最大15分)、API Gatewayの統合タイムアウト(最大29秒)を設定します。タイムアウトを契機に、リトライまたはサーキットブレーカーのロジックが実行されます。
# Lambda: set execution timeout
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30
# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn <ALB-ARN> \
--attributes Key=idle_timeout.timeout_seconds,Value=60
# API Gateway: integration timeout max 29000ms処理失敗に備えたデッドレターキュー
メッセージ処理が繰り返し失敗すると、Dead Letter Queue (DLQ)は、最大受信回数に達しても処理できなかったメッセージを取り込みます。SQSキューとLambdaイベントソースマッピングにDLQを設定し、不正なメッセージによってキューが無期限にブロックされるのを防ぎます。DLQ内のメッセージは、調査したり、バグを修正した後に再実行したり、アーカイブしたりできます。DLQは、回復力の高いイベント駆動アーキテクチャに不可欠な構成要素です。
# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
}'
# After 3 failed processing attempts, message goes to DLQCloudWatchによる障害の可視化
効果的なヘルスチェックとサーキットブレーカーには、障害のパターンを把握するための監視が必要です。CloudWatchは可観測性のレイヤーです。ELB UnHealthyHostCount(ヘルスチェックに失敗したインスタンス数)、Lambda Errorsの割合、SQS NumberOfMessagesSentToDLQ(DLQに送られたメッセージ数)、ターゲットグループのRequestCountPerTargetに対してアラームを作成します。SNS通知を設定し、自動ヘルスチェックが劣化を検出したときにオンコールチームへ直ちに通知されるようにします。
# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
--alarm-name 'ALB-UnhealthyHosts' \
--alarm-description 'Alert when targets fail health checks' \
--metric-name UnHealthyHostCount \
--namespace AWS/ApplicationELB \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-team理解度チェック
このレッスンで扱ったAWS Solutions Architect (SAA-C03)の概念について、理解度を確認します。
レッスンのまとめ
このレッスンでは、ELBとRoute 53のヘルスチェックにより、インフラストラクチャレベルでの障害検出を自動化できること、サーキットブレーカーにより、異常なサービスへの呼び出しを停止して連鎖的な障害を防げること、そしてジッター付きの指数バックオフにより、負荷が高い状況でも安全にリトライできることを学びました。デッドレターキューは、失敗したメッセージを調査のために保持します。次は、RTO、RPO、災害復旧の各ティアについて学びます。
よくある質問
「ヘルスチェック、サーキットブレーカー、リトライロジック」レッスンは無料ですか?
はい。「ヘルスチェック、サーキットブレーカー、リトライロジック」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
「ヘルスチェック、サーキットブレーカー、リトライロジック」で何を学びますか?
ELBのヘルスチェック、Route 53のエンドポイントチェック、アプリケーションレベルのサーキットブレーカーを使用して障害を検出し、トラフィックを自動的に振り替えます。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Cloud & IT Cert Prepを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「ヘルスチェック、サーキットブレーカー、リトライロジック」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?
はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- 高可用性とフォールトトレランス:定義とトレードオフ
- ステートフルサービスのマルチAZパターン
- マルチリージョンのアクティブ-アクティブとアクティブ-パッシブ
- ヘルスチェック、サーキットブレーカー、リトライロジック