API Management の可用性と信頼性を確保する
適用対象: Premium
この記事では、Azure の障害が発生した場合に、API Management インスタンスが API 要求を引き続き処理できるようにするためのサービス機能の概要について説明します。
API Management には、Azure ソリューションの信頼性と回復性に優れた次の機能が用意されています。 これらを個別に、または一緒に使用して、可用性を強化します。
可用性ゾーン: データセンターレベルの障害に対する回復性を提供する
複数リージョンのデプロイ: リージョンの障害に対する回復性を提供する
Note
- 可用性ゾーンと複数リージョンのデプロイは、Premium レベルでサポートされています。
- 構成については、「API Management の可用性ゾーンへの移行に関するサポート」および「複数リージョンで API Management をデプロイする」を参照してください。
可用性ゾーン
Azure 可用性ゾーン は、データセンターレベルの障害にトレラントな Azure リージョン内の物理的に分離された場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワーク インフラストラクチャを備えた 1 つまたは複数のデータセンターで構成されています。 回復性を確保するため、すべての可用性ゾーン対応リージョンに、最低 3 つの個別の可用性ゾーンが存在します。 詳細情報
サポートされているリージョンで API Management インスタンスの ゾーン冗長性 を有効にすると、ゲートウェイ、管理プレーン、開発者ポータルなど、すべての サービス コンポーネントに冗長性が提供されます。 Azure では、選択したゾーン間ですべてのサービス コンポーネントが自動的にレプリケートされます。
リージョンでゾーン冗長性を有効にする場合は、分散させる必要がある API Management スケール ユニット の数を考慮してください。 最小限に抑えて、可用性ゾーンの数と同じユニット数を構成するか、ユニットがゾーン間で均等に分散されるように複数のユニットを構成します。 たとえば、リージョンで 3 つの可用性ゾーンを選択した場合、各ゾーンが 1 つのユニットをホストするように 3 つのユニットを使用できます。
Note
容量メトリックと独自のテストを使用して、ニーズに合わせてゲートウェイのパフォーマンスを提供するスケール ユニットの数を決定します。 サービス インスタンスの スケーリングとアップグレード の詳細を確認します。
複数リージョンのデプロイ
複数リージョンのデプロイにより、API パブリッシャーは、サポートされている 1 つ以上の Azure リージョン内の既存の API Management インスタンスにリージョン API ゲートウェイを追加できます。 複数リージョンのデプロイにより、地理的に分散した API コンシューマーによって認識される要求待ち時間が短くなり、1 つのリージョンがオフラインになった場合でもサービスの可用性を向上できます。
API Management インスタンスのゲートウェイ コンポーネントのみが複数のリージョンにレプリケートされます。 インスタンスの管理プレーンと開発者ポータルは、最初にサービスをデプロイしたリージョンであるプライマリ リージョンのみでホストされたままになります。
仮想ネットワークにデプロイ (挿入) されたときに API Management インスタンスのセカンダリの場所を構成する場合、VNet とサブネットリージョンは、構成しているセカンダリの場所と一致する必要があります。 プライマリ リージョンで可用性ゾーンを追加、削除、有効化する場合、またはプライマリ リージョンのサブネットを変更する場合は、API Management インスタンス の VIP が変更されます。 詳細については、Azure API Management サービスの IP アドレスに関するページを参照してください。 ただし、セカンダリ リージョンを追加する場合、すべてのリージョンには独自のプライベート VIP があるため、プライマリ リージョンの VIP は変更されません。
API やポリシー定義などのゲートウェイ構成は、プライマリ リージョンと、追加するセカンダリ リージョンとの間で定期的に同期されます。 リージョン ゲートウェイへの更新の反映には通常、10 秒未満かかります。 複数リージョンのデプロイでは、複数のリージョンで API ゲートウェイを利用でき、1 つのリージョンがオフラインになった場合にサービスの可用性を提供できます。
API Management がトラフィック マネージャー エンドポイントへのパブリック HTTP 要求 (外部 VNet および API Management のネットワークに接続されていないモードを要求) を受信すると、最も短い待機時間に基づいてリージョン ゲートウェイにトラフィックがルーティングされるため、地理的に分散された API コンシューマーで発生する待機時間が短縮されます。 内部 VNet モードでは、お客様は独自のソリューションを構成して、複数のリージョン ゲートウェイにわたってトラフィックをルーティングし、負荷分散する必要があります。 詳細については、「ネットワークに関する考慮事項」を参照してください。
各リージョン (プライマリ リージョンを含む) のゲートウェイには、
https://<service-name>-<region>-01.regional.azure-api.net
の URL パターンに従うリージョン DNS 名があります (例:https://contoso-westus2-01.regional.azure-api.net
)。リージョンがオフラインになった場合、API 要求は、障害が発生したリージョンを迂回して、次に最も近いゲートウェイに自動的にルーティングされます。
プライマリ リージョンがオフラインになると、API Management 管理プレーンと開発者ポータルは使用できなくなりますが、セカンダリ リージョンは最新のゲートウェイ構成を使用して引き続き API 要求を処理します。
可用性ゾーンと複数リージョンのデプロイを組み合わせる
リージョン内の冗長性のための可用性ゾーンと、リージョン障害が発生した場合にゲートウェイの可用性を向上させる複数リージョン デプロイの組み合わせにより、API Management インスタンスの信頼性とパフォーマンスの両方を向上させることができます。
例 :
可用性ゾーンを使用して、複数リージョン デプロイのプライマリ リージョンの回復性を向上させる
リージョン ゲートウェイのパフォーマンスを向上させるために、可用性ゾーンとリージョン間でスケール ユニットを分散する
SLA に関する考慮事項
2 つ以上の可用性ゾーンまたはリージョンに少なくとも 1 つのユニットをデプロイする場合、API Management では 99.99% の SLA が提供されます。 詳細については、価格に関するページをご覧ください。
Note
Azure では、クラウド プラットフォームの SLA で可能な限り高い回復性を継続的に目指しますが、ユーザーは、ソリューションの他のコンポーネントに対しては、独自のターゲット SLA を定義する必要があります。
バックエンドの可用性
バックエンド サービスがホストされる場所と方法によっては、サービスの可用性の要件を満たすために、異なるリージョンに冗長バックエンドを設定することが必要になる場合があります。 バックエンド のプロパティを構成して、バックエンド サービスの回復力と可用性を向上させることもできます。
リージョン バックエンド
リージョン バックエンドを管理し、API Managementを使用してフェールオーバーを処理して可用性を維持できます。 次に例を示します。
複数リージョンのデプロイでは、 ポリシーを使用して、リージョン ゲートウェイを経由してリージョン バックエンドに要求 をルーティングします。
特定のリージョンでバックエンド障害が発生した場合に、条件付きで異なるバックエンドに要求をルーティングするようにポリシーを構成します。
キャッシュを使用して、失敗する呼び出しを減らします。
詳細については、Azure API Manager を使用したバックエンド API の冗長性に関するブログ記事を参照してください。
バックエンドのプロパティを構成して可用性を向上させる
API Management バックエンド エンティティを使用すると、バックエンドのプロパティを管理および適用して、バックエンドの可用性を向上させることができます。 次に例を示します。
- URL プール へのトラフィックの分散と負荷分散
- サーキット ブレーカー ルール を構成して、サーキット ブレーカー パターンを適用し、バックエンドを多すぎる要求から保護します
次のステップ
- Azure の信頼性の詳細を確認する
- 信頼性の高い Azure アプリケーションの設計の詳細を確認する
- Azure Well-Architected Framework の API Management と信頼性 を読み取る