API Management の可用性と信頼性を確保する

  • [アーティクル]

適用対象: Premium

この記事では、Azure の障害が発生した場合に、API Management インスタンスが API 要求を引き続き処理できるようにするためのサービス機能と考慮事項について説明します。

API Management では、 信頼性と回復性 に優れた Azure ソリューションに推奨される次の主要なサービス機能がサポートされています。 API Management ソリューションの可用性を向上させるには、それらを個別に、または一緒に使用します。

  • データセンターレベルの障害に対する回復性を提供する可用性ゾーン

  • リージョンの障害に対する回復性を提供する複数リージョンのデプロイ

Note

API Management では、Premium サービス レベルでの可用性ゾーンと複数リージョンのデプロイがサポートされています。

可用性ゾーン

Azure 可用性ゾーン は、データセンターレベルの障害にトレラントな Azure リージョン内の物理的に分離された場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワーク インフラストラクチャを備えた 1 つまたは複数のデータセンターで構成されています。 回復性を確保するため、すべての可用性ゾーン対応リージョンに、最低 3 つの個別の可用性ゾーンが存在します。

サポートされているリージョンで API Management インスタンスの ゾーン冗長性 を有効にすると、ゲートウェイ、管理プレーン、開発者ポータルなど、すべての サービス コンポーネントに冗長性が提供されます。 Azure では、選択したゾーン間ですべてのサービス コンポーネントが自動的にレプリケートされます。 ゾーン冗長は Premium サービス レベルでのみ使用できます。

リージョンでゾーン冗長性を有効にする場合は、分散させる必要がある API Management スケール ユニット の数を考慮してください。 最小限に抑えて、可用性ゾーンの数と同じユニット数を構成するか、ユニットがゾーン間で均等に分散されるように複数のユニットを構成します。 たとえば、リージョンで 3 つの可用性ゾーンを選択した場合、各ゾーンが 1 つのユニットをホストするように 3 つのユニットを使用できます。

Note

容量 メトリックと独自のテストを使用して、ニーズに合わせてゲートウェイのパフォーマンスを提供するスケール ユニットの数を決定します。 サービス インスタンスの スケーリングとアップグレード の詳細を確認します。

複数リージョンのデプロイ

複数リージョンのデプロイにより、API パブリッシャーは、サポートされている 1 つ以上の Azure リージョン内の既存の API Management インスタンスにリージョン API ゲートウェイを追加できます。 複数リージョンのデプロイにより、地理的に分散した API コンシューマーによって認識される要求待ち時間が短くなり、1 つのリージョンがオフラインになった場合でもサービスの可用性を向上できます。 複数リージョンのデプロイは、Premium サービス レベルでのみ提供されます。

  • 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 コンシューマーで発生する待機時間が短縮されます。

  • 各リージョン (プライマリ リージョンを含む) のゲートウェイには、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 バックエンド エンティティを使用すると、バックエンドのプロパティを管理および適用して、バックエンドの可用性を向上させることができます。 次に例を示します。

次のステップ