Azure API Management の信頼性

Azure API Management は、組織が API の発行、セキュリティ保護、変換、保守、監視を行うのに役立つフル マネージド サービスです。 このサービスは、API コンシューマーとバックエンド サービスの間に配置されるゲートウェイとして機能し、認証、レート制限、応答キャッシュ、要求/応答変換などの重要な機能を提供します。 API Management を使用すると、基になるバックエンド サービスの複雑さを抽象化しながら、一貫性のある安全な API エクスペリエンスを作成できます。

Azure API Management には、API インフラストラクチャの高可用性とフォールト トレランスを確保するために設計された信頼性機能がいくつか用意されています。 このサービスでは、複数のデプロイ ユニットによる組み込みの冗長性、可用性ゾーン間の自動フェールオーバー機能、グローバル API 配布用の複数リージョンデプロイ オプションが提供されます。 API Management には、インテリジェントなトラフィック ルーティング、正常性の監視、およびインフラストラクチャの障害やトラフィックの多いシナリオでもサービス継続性を維持するのに役立つ自動再試行メカニズムが含まれています。

この記事では、可用性ゾーンや複数リージョンのサポートなど、 Azure API Management の信頼性について説明します。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

信頼性アーキテクチャの概要

Azure API Management は、スケール ユニットベースのアーキテクチャを使用して、組み込みの冗長性とスケーラビリティを提供します。 API Management インスタンスをデプロイするときは、1 つまたは複数の スケール ユニットを構成 します。 各ユニットは、API 要求を処理するために必要なコンピューティング リソースを含む容量の論理表現です。

2 つ以上のユニットでインスタンスを構成すると、使用可能なユニットが連携して要求が処理され、自動負荷分散が提供されます。 いずれかのユニットが使用できなくなった場合、残りのユニットは引き続きトラフィックを処理しますが、容量が減少する可能性があります。

高いレベルの信頼性を得るために、API Management では、リージョン内および複数のリージョン間の可用性ゾーン間でのユニット分散がサポートされます。

Azure API Management サービス レベルでは、さまざまなレベルの信頼性が提供されます。

• Premium レベル (クラシック): 最大の回復性を実現するために、可用性ゾーンとリージョン間で分散できる複数のユニットをサポートします。 Premium レベルでは、各ユニットは、API 要求を処理するコンピューティング リソースを提供する 2 つの仮想マシン (VM) で構成されます。
• Basic v2、Standard、Standard v2、Premium v2 (プレビュー) レベル: すべて、1 つのデータセンター内の複数のユニットをサポートします。 可用性ゾーンまたは複数リージョンのデプロイはサポートされていません。
• 開発者層: 1 つのユニットのみをサポートし、可用性ゾーンまたは複数リージョンのサポートを提供しません。 このレベルは、開発とテストのシナリオ向けに設計されており、運用環境のワークロードには適していません。
• 従量課金レベル: Azure API Management の従量課金レベルには、回復性機能が組み込まれており、1 つの Azure データセンター内のさまざまな障害に対する回復性があります。 ただし、従量課金レベルでは、可用性ゾーンまたは複数リージョンのデプロイはサポートされません。 従量課金レベルの Azure API Management インスタンスの予想されるアップタイムを理解するには、 サービス レベル アグリーメントを確認します。

インスタンス内のユニットは連携して要求を処理し、使用可能なユニット間で自動負荷分散を行います。 ユニットが使用できなくなった場合、残りのユニットは引き続きトラフィックを処理しますが、容量が減少する可能性があります。

運用環境のデプロイに関する推奨事項

ソリューションの信頼性要件をサポートするために Azure API Management をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、 Azure Well-Architected Framework での Azure API Management のアーキテクチャのベスト プラクティスに関するページを参照してください。

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

API の前で Azure API Management を使用する場合は、一時的な障害が原因で失敗した要求を再試行することが必要になる場合があります。 バックエンド API が多すぎる要求に圧倒されるのを防ぎ、API Management は再試行、レート制限、クォータ ポリシーを提供します。 負荷分散とサーキット ブレーカーの機能は、 バックエンド リソースを使用して構成することもできます。

可用性ゾーンのサポート

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure API Management では、サポートされているリージョンに Premium (クラシック) API Management インスタンスをデプロイするときに、次の 2 種類の可用性ゾーンのサポートが提供されます。

• [自動]。 Azure API Management では、使用する可用性ゾーンを指定しない場合に、可用性ゾーンの自動サポートが提供されます。

• [手動]。 Azure API Management では、使用する可用性ゾーンを明示的に指定すると、可用性ゾーンの手動サポートが提供されます。

可用性ゾーンのサポートにより、Azure API Management は高可用性のために複数のゾーンにサービス コンポーネントをレプリケートします。 プライマリ リージョンでは、これらのコンポーネントにはゲートウェイ (スケール ユニット)、管理プレーン、開発者ポータルが含まれます。 セカンダリ リージョンでは、ゲートウェイ ユニットのみがレプリケートされます。 セカンダリ リージョンの詳細については、「 複数リージョンのサポート 」を参照してください。

可用性ゾーンの自動サポート

自動可用性ゾーンのサポートでは、ゾーン冗長性を実現するために、単一ユニットまたはマルチユニット インスタンス構成のいずれかを選択できます。

• マルチユニット構成 (推奨) インスタンスに 2 つ以上のユニットがある場合、Azure API Management は、リージョンの可用性ゾーン間でインスタンスのユニットを分散するようベスト エフォートで試行します。 ユニットがどの可用性ゾーンに配置されているかを判断する方法はありません。 可用性ゾーンの利点を最大限に活用するために、少なくとも 3 つのユニットをデプロイすることをお勧めします。このユニットは、リージョン内のすべての使用可能なゾーンに分散できます。

• 単一ユニット構成。 インスタンスに 1 つのユニットがある場合、ユニットの基になる VM は 2 つの可用性ゾーンに分散されます。 ユニットの VM がどの可用性ゾーンに配置されているかを判断する方法はありません。

可用性ゾーンの手動サポート

使用する可用性ゾーンを明示的に選択する場合は、ゾーン冗長構成とゾーン構成のいずれかを選択できます。

• ゾーン冗長: サポートされているリージョンの API Management インスタンスのゾーン冗長を手動で構成して、サービス コンポーネントの冗長性を提供します。 使用する 2 つ以上の可用性ゾーンを選択すると、Azure によって、選択したゾーン間でサービス コンポーネントが自動的にレプリケートされます。

• ゾーン: API Management サービス コンポーネントは、Azure リージョン内で選択した 1 つのゾーンにデプロイされます。 すべてのユニットが同じ可用性ゾーンに配置されます。

  Von Bedeutung

  単一の可用性ゾーンへのピン留めは、ニーズに合わせて ゾーン間の待機時間 が長すぎる場合、および待機時間が要件を満たしていないことを確認した場合にのみ推奨されます。 ゾーン インスタンス自体では、可用性ゾーンの停止に対する回復性は提供されません。 ゾーン API Management デプロイの回復性を向上させるには、個別のインスタンスを複数の可用性ゾーンに明示的にデプロイし、トラフィック ルーティングとフェールオーバーを構成する必要があります。

リージョンのサポート

Azure API Management では、可用性ゾーンをサポートするすべての Azure リージョンの Premium (クラシック) レベルの 可用性ゾーンがサポートされます。

要求事項

可用性ゾーンのサポートを構成するには、Premium (クラシック) レベルを使用する必要があります。 Azure API Management では、従来の従量課金レベル、開発者層、Basic レベル、Standard レベル、および現在の Basic v2、Standard v2、または Premium v2 レベルの可用性ゾーンはサポートされていません。 インスタンスを Premium (クラシック) レベルにアップグレードするには、「 Premium レベルへのアップグレード」を参照してください。

考慮事項

• ゾーン冗長インスタンスのユニット数: インスタンスのゾーン冗長を手動で構成する場合は、選択したすべての可用性ゾーンに均等に分散できる多数の API Management ユニットも構成する必要があります。 たとえば、2 つのゾーンを選択する場合は、少なくとも 2 つのユニットを構成する必要があります。 代わりに、4 つのユニット、または 2 つのユニットの別の倍数を構成できます。 3 つの可用性ゾーンを選択する場合は、3 つのユニット、6 つのユニット、または 3 つのユニットの別の倍数を構成する必要があります。

  単に自動可用性ゾーンのサポートを使用する場合、特定の数のユニットを使用する必要はありません。 デプロイするユニットは、ベスト エフォート方式で可用性ゾーン間で分散されます。 ゾーンの冗長性を最大限に高めるために、可用性ゾーンの停止がインスタンスに影響しないように、少なくとも 3 つのユニットを使用することをお勧めします。

  必要なゲートウェイのパフォーマンスを提供するユニット数を決定するには、 容量メトリック と独自のテストを使用します。 サービス インスタンスのスケーリングとアップグレードの詳細については、「 Azure API Management インスタンスのアップグレードとスケーリング」を参照してください。

• 自動スケール: 自動スケールで構成された API Management インスタンスで可用性ゾーンを手動で構成する場合は、構成後に自動スケール設定の調整が必要になる場合があります。 この場合、自動スケール ルールと制限内の API Management ユニットの数は、ゾーンの数の倍数である必要があります。 単に自動可用性ゾーンのサポートを使用する場合は、自動スケール設定を調整する必要はありません。

• IP アドレスの要件: 外部または内部の仮想ネットワークにデプロイされている API Management インスタンスで可用性ゾーンのサポートを有効にする場合、現在、インスタンスで使用するパブリック IP アドレス リソースを指定する必要があります。 内部仮想ネットワークでは、パブリック IP は API 要求に対してではなく管理操作にのみ使用されます。 詳細は「Azure API Management の IP アドレス」を参照してください。

費用

可用性ゾーンの構成に関係なく、ユニットを追加すると、コストが高くなります。 詳細については、「 API Management の価格」を参照してください。

可用性ゾーンのサポートを設定する

このセクションでは、Azure API Management インスタンスの可用性ゾーンのサポートを構成する方法について説明します。

• 可用性ゾーンをサポートする API Management インスタンスを作成します 。可用性ゾーンをサポートするリージョンに Premium (クラシック) API Management インスタンスを作成すると、既定では可用性ゾーンのサポートを使用して作成されます。 可用性ゾーンの自動サポートを選択するか、ゾーンまたはゾーン冗長のサポートを手動で構成できます。

• 可用性ゾーンのサポートを有効または再構成します。 可用性ゾーンの追加や可用性ゾーン間のゾーン インスタンスの移動など、API Management インスタンスの可用性ゾーンの構成を変更できます。 API Management インスタンスで可用性ゾーンのサポートを構成するには、「 Azure API Management インスタンスで可用性ゾーンのサポートを有効にする」を参照してください。 いずれの構成オプションにもダウンタイムの要件はありません。

  可用性ゾーンの構成を変更すると、変更が適用されるまでに 15 ~ 45 分 (またはそれ以上) かかる場合があります。 API Management ゲートウェイは、この間も引き続き API 要求を処理できます。

  可用性ゾーンの構成を変更すると、パブリック IP アドレスとプライベート IP アドレスの変更がトリガーされます。

容量の計画と管理

ゾーンダウンシナリオでは、別の可用性ゾーンでの追加容量の要求が成功するという保証はありません。 紛失したユニットのバックフィルは、ベスト エフォートベースで行われます。 可用性ゾーンが失われた場合に保証された容量が必要な時は、ゾーンの損失を考慮して API Management インスタンスを作成および設定する必要があります。 これを行うには、次の方法があります。

• API Management インスタンスのユニットを過剰プロビジョニングする
• 自動またはゾーン冗長可用性ゾーン構成の使用

過剰プロビジョニングの原則の詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

容量メトリックと独自のテストを使用して、必要なゲートウェイパフォーマンスを提供するユニット数を決定します。 サービス インスタンスのスケーリングとアップグレードの詳細については、「 Azure API Management インスタンスのアップグレードとスケーリング」を参照してください。

通常の運用

このセクションでは、Azure API Management インスタンスが可用性ゾーンのサポートを使用して構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。

• ゾーン間のトラフィック ルーティング: 通常の操作中は、選択したすべての可用性ゾーンにわたって、使用可能なすべての API Management ユニット間でトラフィックがルーティングされます。

• ゾーン間のデータ レプリケーション: 次のデータは、Azure API Management によって格納およびレプリケートされます。

  • API やポリシー定義などのゲートウェイ構成は、インスタンス用に選択した可用性ゾーン間で定期的に同期されます。 可用性ゾーン間での更新の反映には通常、10 秒未満かかります。
  • Azure API Management によって提供される内部キャッシュを使用する場合には、内部キャッシュのデータがあります。 キャッシュ エントリは可用性ゾーン間で分散されます。 内部キャッシュは揮発性であり、データが永続化されるとは限りません。 キャッシュされたデータを保持する必要がある場合は、外部キャッシュの使用を検討してください。
  • レート制限カウンター (Azure API Management によって提供されるレート制限機能を使用する場合)。 レート制限カウンターは、インスタンスに対して選択した可用性ゾーン間で非同期的にレプリケートされます。

ゾーンダウン エクスペリエンス

このセクションでは、Azure API Management インスタンスが可用性ゾーンのサポートを使用して構成されていて、可用性ゾーンが停止した場合に想定される内容について説明します。

• 検出と応答: 検出と応答の責任は、インスタンスが使用する可用性ゾーンの構成によって異なります。

  • 自動およびゾーン冗長: 自動可用性ゾーンのサポートを使用するように構成されているインスタンスや、ゾーンの冗長性を使用するように手動で構成されたインスタンスの場合、Azure API Management プラットフォームは、可用性ゾーンの障害を検出して応答する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。

  • ゾーン： ゾーンに構成されているインスタンスの場合は、可用性ゾーンの損失を検出し、別の可用性ゾーンに作成したセカンダリインスタンスにフェールオーバーする必要があります。

• アクティブな要求: 可用性ゾーンが使用できない場合、障害のある可用性ゾーン内の API Management ユニットに接続されている進行中の要求はすべて終了し、再試行する必要があります。

• 通知： ゾーン レベルの停止は、Azure Resource Health と Azure Service Health に反映されます。

• 予想されるデータ損失: 次のデータは API Management によって格納されます。

  • ゲートウェイ構成の変更。これは、選択した各可用性ゾーンに約 10 秒以内にレプリケートされます。 可用性ゾーンの停止が発生すると、レプリケートされていない構成の変更が失われる可能性があります。
  • 内部キャッシュ機能を使用する場合は、内部キャッシュ内のデータ。 内部キャッシュは揮発性であり、データが永続化されるとは限りません。 可用性ゾーンの停止中に、キャッシュされたデータの一部またはすべてが失われる可能性があります。 キャッシュされたデータを保持する必要がある場合は、外部キャッシュの使用を検討してください。
  • レート制限機能を使用する場合は、レート制限カウンター。 可用性ゾーンの停止中に、レート制限カウンターが存続ゾーンで最新ではなくなる可能性があります。

• 予想されるダウンタイム: 予想されるダウンタイムは、インスタンスが使用する可用性ゾーンの構成によって異なります。

  • 自動： 可用性ゾーンの自動サポートを使用するインスタンスでは、可用性ゾーンの停止中にダウンタイムが発生しない可能性があります。 影響を受けないゾーンまたはゾーン内のユニットは引き続き機能します。

    自動アベイラビリティゾーン対応を使用するが、単一のユニットを有するインスタンスも停止時間がないと期待されます。 この場合、API Management はユニットの基になる VM を 2 つのゾーンに分散します。 影響を受けないゾーン内の VM は引き続き動作します。

  • ゾーン冗長: ゾーン冗長インスタンスでは、可用性ゾーンの停止中にダウンタイムが発生しない可能性があります。

  • ゾーン: ゾーン インスタンスの場合、ゾーンが使用不可の場合、可用性ゾーンが復旧するまでインスタンスは利用できなくなります。

• トラフィックの再ルーティング: トラフィックの再ルーティング動作は、インスタンスが使用する可用性ゾーンの構成によって異なります。

  • 自動およびゾーン冗長: 自動可用性ゾーンのサポートを使用するように構成されているインスタンスや、ゾーン冗長を使用するように手動で構成されているインスタンスの場合、ゾーンが使用できない場合、影響を受けるゾーン内のユニットは使用できなくなります。 インスタンスをスケーリングして、ユニットを追加することもできます。

  • ゾーン: ゾーン インスタンスの場合、ゾーンが使用できない場合、インスタンスは使用できません。 別の可用性ゾーンにセカンダリ インスタンスがある場合は、そのセカンダリ インスタンスへのトラフィックを再ルーティングする必要があります。

フェールバック

フェールバックの動作は、インスタンスが使用する可用性ゾーンの構成によって異なります。

• 自動およびゾーン冗長: 可用性ゾーンの自動サポートを使用するように構成されているインスタンスや、ゾーンの冗長性を使用するように手動で構成されている場合、可用性ゾーンが復旧すると、Azure API Management によって可用性ゾーン内のユニットが自動的に復元され、ユニット間のトラフィックが通常どおりに再ルーティングされます。

• ゾーナル： ゾーナル インスタンスの場合、可用性ゾーン復旧後に元の可用性ゾーン内のインスタンスへのトラフィックを再ルーティングするのはあなたの担当です。

ゾーン障害を検出するためのテスト

ゾーンの障害をテストするためのオプションは、インスタンスが使用する可用性ゾーンの構成によって異なります。

• 自動およびゾーン冗長: 自動可用性ゾーンのサポートを使用するように構成されているインスタンスや、ゾーンの冗長性を使用するように手動で構成されたインスタンスの場合、Azure API Management プラットフォームはトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。

• ゾーナル： ゾーナル インスタンスの場合、Azure API Management インスタンスを含む可用性ゾーンの障害をシミュレートする方法はありません。 ただし、アップストリーム ゲートウェイまたはロード バランサーを手動で構成して、別の可用性ゾーン内の別のインスタンスにトラフィックをリダイレクトできます。

マルチリージョン サポート

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

Azure API Management では、Premium (クラシック) レベルのマルチリージョン デプロイのみがサポートされます。 従量課金、開発者、Basic、Basic v2、Standard、Standard v2、Premium v2 (プレビュー) レベルでの複数リージョンのデプロイはサポートされていません。 詳細については、「 要件」を参照してください。

リージョンを追加するときは、次の要素を構成します。

• そのリージョンがホストするユニットの数。

• 可用性ゾーンのサポート (そのリージョンが可用性ゾーンを提供する場合)。

• 既存のリージョンでネットワークが構成されている場合は、追加されたリージョンの仮想ネットワーク設定。

リージョンのサポート

Azure API Management をサポートする任意の Azure リージョンを使用して、Premium (クラシック) レベルで複数リージョンのデプロイを作成できます。 複数リージョンのデプロイをサポートするリージョンを確認するには、「 リージョン別の製品の可用性」を参照してください。

要求事項

複数リージョンのサポートを構成するには、Premium (クラシック) レベルを使用する必要があります。 インスタンスを Premium (クラシック) レベルにアップグレードするには、「 Premium レベルへのアップグレード」を参照してください。

考慮事項

• ゲートウェイのみ: API Management インスタンスのゲートウェイ コンポーネントのみが複数のリージョンにレプリケートされます。 インスタンスの管理プレーンと開発者ポータルは、最初にサービスをデプロイしたプライマリ リージョンでのみホストされます。

• ネットワーク要件: API Management インスタンスが仮想ネットワークにデプロイ (挿入) されたときにセカンダリの場所を構成する場合、仮想ネットワークとサブネット リージョンは、構成しているセカンダリの場所と一致する必要があります。 プライマリ リージョンで可用性ゾーンを追加、削除、有効化する場合、またはプライマリ リージョンのサブネットを変更する場合は、API Management インスタンス の VIP が変更されます。 詳細については、 Azure API Management サービスの IP アドレスに関するページを参照してください。 ただし、セカンダリ リージョンを追加する場合、すべてのリージョンには独自のプライベート VIP があるため、プライマリ リージョンの VIP は変更されません。

• DNS 名:各リージョン (プライマリ リージョンを含む) のゲートウェイには、https://contoso-westus2-01.regional.azure-api.netなどのhttps://<service-name>-<region>-01.regional.azure-api.netの URL パターンに従うリージョン DNS 名があります。

費用

リージョンを追加すると、コストが高くなります。 詳細については、「 API Management の価格」を参照してください。

複数リージョンのサポートを構成する

API Management インスタンスで複数リージョンのサポートを構成するには、「 Azure API Management インスタンスを複数の Azure リージョンにデプロイする」を参照してください。

API Management インスタンスからリージョンを削除するには、「 Azure API Management サービス リージョンの削除」を参照してください。

容量の計画と管理

リージョンダウン シナリオでは、別のリージョンでの追加容量の要求が成功するという保証はありません。 リージョンが失われたときに容量が保証される必要がある場合は、リージョンを失うことを考慮して API Management インスタンスを作成して構成する必要があります。 これを行うには、API Management インスタンスの容量をオーバープロビジョニングします。 過剰プロビジョニングの原則の詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

複数リージョンのデプロイでは、自動スケーリングはプライマリ リージョンにのみ適用されます。 セカンダリ リージョンでは、手動によるスケーリング調整またはユーザーが制御するカスタム ツールが必要です。

通常の運用

このセクションでは、Azure API Management インスタンスが複数リージョンのサポートで構成され、すべてのリージョンが運用可能な場合に想定される内容について説明します。

• リージョン間のトラフィック ルーティング: Azure API Management は、受信要求をリージョン ゲートウェイに自動的にルーティングします。 クライアントからの待機時間が最も短いリージョン ゲートウェイに要求がルーティングされます。 別のルーティング方法を使用する必要がある場合は、カスタム ルーティング規則を使用して独自の Traffic Manager を構成できます。 詳細については、「 API Management リージョン ゲートウェイへのカスタム ルーティングを使用する」を参照してください。

  要求が Azure API Management リージョン ゲートウェイに到達すると、通常はバックエンド API にルーティングされます (ポリシーがゲートウェイから直接応答 (キャッシュされた応答やエラー コードなど) を返さない限り)。 マルチリージョン ソリューションでは、パフォーマンス要件を満たすバックエンド API のインスタンスにルーティングするように注意する必要があります。 詳細については、「 リージョン バックエンド サービスへの API 呼び出しのルーティング」を参照してください。

• リージョン間のデータ レプリケーション: API やポリシー定義などのゲートウェイ構成は、追加するプライマリ リージョンとセカンダリ リージョンの間で定期的に同期されます。 リージョン ゲートウェイへの更新の反映には通常、10 秒未満かかります。

  内部キャッシュ内のデータとレート制限カウンターは、リージョン固有であり、リージョン間でレプリケートされません。

リージョン ダウン エクスペリエンス

このセクションでは、Azure API Management インスタンスが複数リージョンのサポートを使用して構成されていて、使用しているいずれかのリージョンで停止が発生した場合に想定される内容について説明します。

• 検出と応答: API Management は、リージョンの障害を検出し、構成した他のいずれかのリージョンのゲートウェイに自動的にフェールオーバーします。

• アクティブな要求: 障害のあるリージョンで処理されているアクティブな要求はすべて削除される可能性があり、クライアントが再試行する必要があります。

• 予想されるデータ損失: 構成、キャッシュ、レート制限カウンターを除き、Azure API Management はデータを格納しません。

  構成の変更は、約 10 秒以内に各リージョンにレプリケートされます。 プライマリ リージョンの停止が発生すると、レプリケートされていない構成の変更が失われる可能性があります。

  内部キャッシュ内のデータとレート制限カウンターは、リージョン固有であり、リージョン間でレプリケートされません。

• 予想されるダウンタイム: ゲートウェイのダウンタイムは予想されません。

  プライマリ リージョンがオフラインになると、API Management 管理プレーンと開発者ポータルは使用できなくなりますが、セカンダリ リージョンは最新のゲートウェイ構成を使用して引き続き API 要求を処理します。

• トラフィックの再ルーティング: リージョンがオフラインになった場合、API 要求は、障害が発生したリージョンを中心として、次に最も近いゲートウェイに自動的にルーティングされます。

フェールバック

プライマリ リージョンが復旧すると、Azure API Management によってリージョン内のユニットが自動的に復元され、ユニット間のトラフィックが再ルーティングされます。

リージョンの障害のテスト

予期しないリージョンの障害に対応するには、リージョンの障害に対する応答を定期的にテストすることをお勧めします。 リージョン ゲートウェイへのルーティングを無効にすると、リージョンの障害の一部の側面をシミュレートできます。

バックアップ

Azure API Management 自体は、ほとんどのランタイム データを格納しません。 ただし、Azure API Management サービス構成をバックアップすることはできます。 また、バックアップおよび復元操作は、開発やステージングなど、運用環境間の API Management サービス構成のレプリケートで使用できます。

バックアップは、Developer レベル、Basic レベル、Standard レベル、Premium レベルでサポートされています。

Azure API Management でのバックアップの詳細については、「Azure API Management で サービスのバックアップと復元を使用してディザスター リカバリーを実装する方法」を参照してください。

一部のサービス コンポーネントまたはリソースのバックアップまたは復元では、 APIOps ツール やコードとしてのインフラストラクチャ (IaC) ソリューションなどのカスタマー マネージド オプションも考慮できます。

サービスメンテナンス中の信頼性

Azure API Management では、定期的なサービス アップグレードやその他の形式のメンテナンスが実行されます。

Basic、Standard、Premium (クラシック) レベルでは、更新プロセスでインスタンスが更新プログラムを受け取るタイミングをカスタマイズできます。 ワークロードに対するアップグレードの影響を検証する必要がある場合は、更新サイクルの早い段階で更新プログラムを受信するようにテスト インスタンスを構成し、サイクルの後半で更新プログラムを受信するように実稼働インスタンスを設定することを検討してください。 メンテナンス期間を指定することもできます。これは、インスタンスでサービス更新プログラムを適用する時刻です。

メンテナンス設定の詳細については、 API Management インスタンスのサービス更新設定の構成に関するページを参照してください。

サービス水準合意書

Azure API Management のサービス レベル アグリーメント (SLA) では、サービスの予想される可用性について説明します。 また、その可用性に対する期待を達成するために満たす必要がある条件についても説明しています。 これらの条件を理解するには、「オンライン サービスのサービス レベル アグリーメント (SLA)」を確認することが重要です。

API Management インスタンスを複数の可用性ゾーンまたはリージョンにデプロイすると、SLA で定義されているアップタイムの割合が増加します。

サービスには独自の SLA が用意されていますが、API バックエンドなど、他のワークロード コンポーネントの予想される信頼性も考慮する必要があります。

関連コンテンツ

• API Management のディザスター リカバリーとビジネス継続性
• Azure API Management で可用性ゾーンを使用する
• API Management の複数リージョンデプロイ
• Azure API Management の監視
• Azure API Management の容量計画
• API Management のアーキテクチャのベスト プラクティス