Azure Fundamentals · レッスン

正常性プローブとグレースフルデグラデーション

ロードバランサーと Traffic Manager の正常性プローブを構成して障害を迅速に検出し、アプリケーション層にサーキットブレーカーとグレースフルデグラデーションのパターンを設計します。

「正常性プローブとグレースフルデグラデーション」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

正常性プローブが不可欠な理由

正常性プローブは、ロードバランサーやトラフィックマネージャーが、バックエンドのインスタンスでリクエストを処理できるかどうかを検出するための仕組みです。正常性プローブがないと、ロードバランサーは障害が発生したサーバーや応答しないサーバーにトラフィックを送り続け、ユーザーにエラーが表示される可能性があります。正常性プローブを適切に構成すると、障害発生から数秒以内に異常なインスタンスからトラフィックを自動的に再ルーティングできます。

Azure Load Balancerの正常性プローブ

Azure Load Balancerは、2種類の正常性プローブをサポートしています。

TCPプローブ — 指定されたポートでバックエンドがTCP接続を受け付けられるか確認します。単純ですが、アプリケーションのロジックまでは検証しません。
HTTP/HTTPSプローブ — 指定されたパスにGETリクエストを送信し、200 OKのレスポンスを期待します。アプリケーションのエンドポイントを直接テストするため、より正確です。

構成可能な回数の連続した試行でプローブが失敗すると、バックエンドは異常としてマークされます。

# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
  --resource-group myRG \
  --lb-name myLoadBalancer \
  --name httpHealthProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 15 \
  --threshold 2

信頼性の高い正常性エンドポイントの設計

適切に設計された正常性エンドポイント（/health）は、200 OKを返すだけではありません。アプリケーションの重要な依存関係に到達できることも検証します。包括的な正常性チェックでは、データベース、キャッシュ、下流のAPIへの接続をテストします。いずれかの依存関係が利用できない場合、エンドポイントは5xxステータスコードを返し、ロードバランサーに対して、そのインスタンスを振り分け対象から除外するよう通知します。

# Example health endpoint response (JSON):
# GET /health
# {
#   'status': 'healthy',
#   'checks': {
#     'database': 'ok',
#     'cache': 'ok',
#     'externalApi': 'ok'
#   }
# }
# If database check fails, return HTTP 503 instead of 200

Traffic Managerの正常性プローブ

Azure Traffic Managerも正常性プローブを使用しますが、リージョンレベルで動作します。各リージョンで構成されたエンドポイントURLに対して、HTTPまたはHTTPSのGETリクエストを定期的に送信します。エンドポイントがタイムアウト時間内に応答せず、その状態が設定された回数の連続する間隔で続くと、Traffic Managerはそのエンドポイントを低下状態と判断し、そこへのDNSクエリのルーティングを停止して、ユーザーを正常なリージョンへリダイレクトします。

# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
  --resource-group myRG \
  --name myTMProfile \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /health \
  --monitor-interval 30 \
  --monitor-timeout 10 \
  --monitor-tolerated-failures 3

Application Gatewayの正常性プローブ

Azure Application Gatewayは、標準のLoad Balancerよりも高度な正常性プローブ機能を備えています。カスタムプローブをサポートしており、ホストヘッダー、期待するステータスコードの範囲（例：200～399）、本文の照合文字列を指定できます。また、Application Gatewayはパス単位のルーティングもサポートしているため、異なるバックエンドプールに対して、URLパスごとに異なる正常性プローブ構成を設定できます。

# Create a custom probe for Application Gateway:
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myRG \
  --name customProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /api/health \
  --interval 20 \
  --timeout 10 \
  --threshold 3

グレースフルデグラデーションとは

グレースフルデグラデーションとは、1つ以上の依存関係に障害が発生した場合でも、アプリケーションが機能の一部を継続して提供できる能力です。アプリケーションは完全にクラッシュするのではなく、重要度の低いサービスが利用できないことを検出し、機能は制限されるものの引き続き役立つ状態に切り替えます。たとえば、レコメンデーションサービスに障害が発生した場合、ECサイトは商品ページ全体をクラッシュさせるのではなく、一般的なおすすめを表示できます。

サーキットブレーカーパターン

サーキットブレーカーパターンは、障害が発生している下流サービスをアプリケーションが繰り返し呼び出すことを防ぎます。サービスで障害が発生し始めると、サーキットブレーカーがオープン状態になり、ネットワーク呼び出しを行わずにエラーまたはフォールバック応答を直ちに返します。クールダウン期間が経過するとハーフオープン状態になり、試行リクエストを1件許可します。そのリクエストが成功すると、サーキットがクローズされ、通常の処理が再開されます。

# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN:   service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
#           success -> CLOSED
#           failure -> OPEN (reset timer)

# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)

指数バックオフによる再試行

一時的な障害（短時間のネットワーク障害や一時的なサービス過負荷など）には、指数バックオフによる再試行戦略が適しています。アプリケーションは、失敗した呼び出しを遅延させて再試行し、最大値に達するまで、再試行のたびに遅延時間を倍増させます。遅延にジッター（ランダムな変動）を加えると、すべての再試行が同時に実行され、復旧中のサービスに過大な負荷をかけることを防げます。

# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s  + random(0-500ms)
# attempt 2: wait 2s  + random(0-500ms)
# attempt 3: wait 4s  + random(0-500ms)
# attempt 4: wait 8s  + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to caller

バルクヘッドパターン

バルクヘッドパターンは、アプリケーションの異なる部分をリソースプールに分離し、ある領域の障害によってすべてのリソースが消費され、システム全体が停止することを防ぎます。この名称は、船の一部が浸水しても船全体が沈没するのを防ぐ隔壁に由来します。Azureでは、障害を封じ込めるために、サービスごとに別のスレッドプールや別のApp Service プランを使用する方法が考えられます。

フォールバック応答とキャッシュデータ

一般的なグレースフルデグラデーションの手法は、ライブデータソースを利用できない場合にキャッシュ済みデータまたは古いデータを提供することです。たとえば、データベースに一時的に接続できない場合でも、商品カタログページでエラーを表示する代わりに、Azure Cache for Redisに保存された昨日のキャッシュ価格を表示できます。ユーザーが経験するのは、完全な障害ではなく、価格が少し古いという軽微な不便です。

デグラデーションの監視とアラート

グレースフルデグラデーションは可視化して測定する必要があります。Application Insightsを使用して、サーキットブレーカーがオープンになった回数、フォールバック応答、再試行の回数をカスタムメトリックとして追跡します。これらのメトリックがしきい値を超えたときにアラートを設定すると、ユーザー向けの体験が許容範囲に見える場合でも、アプリケーションがデグレード状態で稼働していることをオンコール担当チームに通知できます。

確認テスト

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、ヘルスプローブによってロードバランサーが障害のあるバックエンドを検出し、トラフィックを自動的に別の宛先へ振り分けられること、グレースフルデグラデーションによって依存先に障害が発生してもアプリケーションの一部の機能を維持できること、そしてサーキットブレーカー、バックオフによる再試行、バルクヘッドなどのパターンによってアプリケーションレベルの回復性を実現できることを学びました。次は、RTO、RPO、復旧ティアの定義など、ディザスターリカバリーの概念について学びます。

よくある質問

「正常性プローブとグレースフルデグラデーション」レッスンは無料ですか？

はい。「正常性プローブとグレースフルデグラデーション」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Azure Fundamentalsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Azure Fundamentalsコースには全4レッスンが含まれています。

「正常性プローブとグレースフルデグラデーション」で何を学びますか？

ロードバランサーと Traffic Manager の正常性プローブを構成して障害を迅速に検出し、アプリケーション層にサーキットブレーカーとグレースフルデグラデーションのパターンを設計します。ブラウザで直接実行するハンズオンコードでAzure Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Azure Fundamentalsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAzure Fundamentalsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「正常性プローブとグレースフルデグラデーション」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAzure Fundamentalsレッスンでコードを書いて実行できますか？

はい。すべてのAzure Fundamentalsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Azure Fundamentalsに戻る