次の方法で共有


Azure API Management のアーキテクチャのベスト プラクティス

Azure API Management は、ハイブリッドおよびマルチクラウドを含むすべての環境にわたる API の管理プラットフォームとゲートウェイです。 サービスとしてのプラットフォーム (PaaS) ソリューションとして、API Management はワークロードの API ライフサイクルをサポートするのに役立ちます。

この記事では、アーキテクトとして、 統合サービスのデシジョン ツリー を確認し、ワークロードの統合サービスとして API Management を選択したことを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。

Technology scope

このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。

  • Azure API Management

このガイドのスコープは、API Management サービスです。主にゲートウェイ コンポーネント (データ プレーン) は、クライアント アプリケーションからさまざまなプラットフォームまたはクロスプレミスの場所でホストされているバックエンド API に API 要求をプロキシします。 ワークロードのアーキテクチャでは、API Management コントロール プレーンと、ゲートウェイにアクセスするクライアント アプリケーションや、ルーティングされた要求を処理するバックエンド API などの関連コンポーネントを考慮する必要があります。 また、ネットワーク、監視、ID 管理、その他の機能など、Azure サービスのサポートも統合されています。

このガイドでは、 Azure API Center については説明しません。 API の設計上の考慮事項について適切に設計された観点を提供するのではなく、API Management に関連する API レベルのトピックに対処します。

Note

Not all recommendations apply to all service tiers of API Management. このガイドの多くの推奨事項は、ほとんどのエンタープライズ ワークロードに推奨される運用レベルである、Standard v2 と従来の Premium レベルの API Management に焦点を当てています。

Important

エンタープライズ機能を備えた Premium v2 レベルはプレビュー段階です。 設計が早期アクセス機能または一般公開されている機能に依存する必要があるかどうかを判断するには、Premium v2 のリリースと移行パスに関する利用可能な情報に関連して、設計と実装のタイムラインを評価します。

Reliability

信頼性の柱の目的は、十分な回復性を構築 し、障害から迅速に回復する機能をして継続的な機能を提供することです。

信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。

ワークロード設計チェックリスト

信頼性 設計レビュー チェックリストに基づいて、設計戦略を開始します。 API Management とその依存関係の階層と機能を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。

  • 信頼性と冗長性のためにゲートウェイの機能を評価します。 各環境のワークロードの信頼性要件を満たすために必要な API Management レベルと機能 を決定します。

    可用性ゾーン、複数のゲートウェイ ユニット、複数のリージョン、ワークスペースなど、ゲートウェイの冗長性機能を評価します。 これらの機能はすべて Premium レベルでサポートされています。 サービス レベル アグリーメント (SLA) を含まない開発者レベルは、運用環境のワークロードには適していません。 潜在的な障害点やパフォーマンスのボトルネックを引き起こす可能性がある外部キャッシュなどの機能を採用することのトレードオフを検討してください。

  • 監視機能を確認します。 Azure Monitor のログとメトリック、Application Insights、組み込みの分析、組み込みの診断など、サービスの 監視機能を検討します。 これらの機能を使用して、ワークロードの信頼性シグナルを監視します。

    たとえば、 Azure Monitor アラート を使用して、API Management ゲートウェイまたはその依存関係に関する潜在的な問題を通知することを検討してください。

  • スケーリング戦略を確認する: サービスの信頼性を維持するためにユニットを追加して、ゲートウェイを スケールアウト するための条件を定義します。 要求、例外、またはその両方に基づいてスケーリングするかどうかを検討します。 ワークロードの他のコンポーネントに対するゲートウェイ コンポーネントのスケーリングの影響を評価します。 たとえば、ネットワーク アドレス空間への影響やバックエンドのスケーリング機能などです。

  • 重要なワークロードを分離する: API でデータ主権やパフォーマンスの最適化などのワークロード要件を満たすためにコンピューティングの分離が必要かどうかを判断します。 クリティカルな API には専用ゲートウェイを使用し、重要度の低い API には共有ゲートウェイを使用します。

    専用ワークスペース ゲートウェイや別の API Management インスタンスの使用など、分離アプローチを選択します。 複数のインスタンスの場合は、安全なデプロイ プラクティスの一環として環境の同期を維持します。

  • サービス レベル目標 (SLO) のアラインメント: ワークロードの SLO を設定するときに、ゲートウェイの SLA スコープを考慮します。 サービスには独自の SLA が用意されていますが、API バックエンドなど、他のワークロード コンポーネントの予想される信頼性も考慮する必要があります。

  • バックエンド の障害に対処する: 予期されるバックエンド 障害と予期しないバックエンド 障害の両方を計画します。 これらのシナリオでクライアント エクスペリエンスをテストします。 Evaluate gateway policies to improve resiliency and enhance the client experience. API 仕様に記載されているように、クォータ、レート制限、再試行ポリシー、バックエンド サーキット ブレーカー、負荷分散、例外処理に重点を置きます。

  • テスト戦略を定義します。 ネットワーク内から Azure Load Testing などのテスト ソリューションを使用して、実際の運用ワークロードを反映します。 ワークロードに適用されない可能性がある、発行済みのスループットやその他の見積もりに依存しないでください。

  • ディザスター リカバリー (DR) の計画: ゲートウェイ インフラストラクチャと API のバックアップと復元のオプションを確認します。 組み込みの バックアップと復元の機能 は、一部のシナリオで役立つ場合があります。 But customer-managed options such as APIOps tooling and infrastructure as code (IaC) solutions can also be considered. ユーザー サブスクリプションなど、他のシステム データを維持するための戦略を策定します。

Configuration recommendations

これらの信頼性に関する推奨事項は、サービス自体、または API とそのポリシーを通過するトラフィックに適用できます。 The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Service) Enable zone redundancy in the Premium tier and have a minimum of three units deployed.

この構成では、通常の動作条件下では、構成されているすべてのゾーンのすべてのスケール ユニットがアクティブになり、ゲートウェイ トラフィックを処理します。

アクティブ/アクティブなシナリオでは、障害が発生したゾーンで元々処理されていたユニットのトラフィックを処理するために、残りのアクティブ ゾーンでスケールアウトをサポートする計画を立てます。
回復性は、リージョン内のデータセンターの停止中に保証されます。 データセンターが完全に失われると、API トラフィックは他のゾーンにデプロイされた残りのユニットを通過し続けます。
(Service) Enable automatic scale-out based on traffic demands.

マルチリージョンデプロイでは、セカンダリ リージョンには自動スケールアウトまたはスケールイン機能がありません。 必要に応じてユニット調整を管理するために、Azure Monitor メトリック アラートに応答してアクティブ化するカスタム関数またはロジック アプリを実装する必要があります。
十分なリソースが API クライアントからの需要を満たすことが保証されるため、容量不足による障害を防ぐことができます。
(Service) Use a multiregion topology to support resiliency against a complete regional failure.

このアプローチでは、ワークロード内の他のコンポーネントと調整し、計画されたフェールオーバー特性を理解する必要があります。 アクティブ/アクティブなシナリオでは、現在非アクティブなリージョンが最初に処理したトラフィックを処理するために、残りのアクティブリージョンでのスケールアウトをサポートすることを計画します。

マルチリージョン トポロジが、転送中のデータまたはキャッシュ所在地内のデータに関するコンプライアンス要件と一致していることを確認します。
堅牢な回復性は、リージョン全体の停止中に提供されます。これにより、他のリージョンにデプロイされたユニットを介して API トラフィックが中断されないようにすることができます。
(Service) Isolate unrelated APIs with workspaces or additional API Management instances. 異なるコンピューティング インスタンス間で API を分離することで、構成ミスや障害による障害の影響が最小限に抑えられます。
(API)ポリシーの式とロジックを十分にテストし、API 管理ポリシーの 回復性のあるエラー処理手法 と組み合わせて使用します。 クライアント エクスペリエンスは、ゲートウェイでの障害の新しい原因を防ぎ、グレースフルな低下または安全な一時的な障害処理を提供することで強化されます。
(サービスと API) 信頼性メトリックを収集します

一般的な API 信頼性メトリックは次のとおりです。

- レート制限とクォータ違反。
- HTTP 状態コードに基づくエラー率。
- ベースラインからの要求レートの偏差。
- 依存関係の健康状態を含むヘルスチェック。
予想される動作と過去のベースラインからの逸脱が特定されます。 このデータを使用して、ユーザーの動作の変更、ルーチン操作からの干渉、新機能からの予期しない影響、ワークロード内の計画外の障害などの根本原因を追跡できます。
(サービスと API)DR プレイブックの一部として、API Management に組み込まれている組み込 みのバックアップと復元 の機能を使用します。 依存関係やバックエンドとの復旧調整など、さまざまなシナリオに対応できる堅牢なソリューションのために、これらの機能を IaC アーティファクトと APIOps プロセスで補完します。 ビジネス継続性は、API ゲートウェイの復旧と、完全なシステム損失後の定義済み API の復元を可能にすることで保証されます。

セキュリティ

セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。

セキュリティ設計の原則は、API Management ゲートウェイを保護する技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。

Note

このセクションのチェックリストと推奨事項は、API Management ゲートウェイ リソースのセキュリティ保護に焦点を当てています。 API 自体のセキュリティ保護は、簡単にしか対処できません。 詳細については、「 API Management での OWASP API セキュリティトップ 10 の軽減」を参照してください。

ワークロード設計チェックリスト

セキュリティ 設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。

  • セキュリティ ベースラインを確立します。API Management のセキュリティ ベースラインを確認し、ベースラインに適用可能なメジャーを組み込みます。

  • デプロイ パイプラインを保護します。 サービス プラットフォーム、継続的インテグレーションと継続的デプロイ (CI/CD) パイプライン、および個々の API の管理に必要な個人とロールベースのアクセス制御ロールを特定します。 承認された個人のみがサービスとその API を管理するアクセス権を持っていることを確認します。

  • データの機密性を評価する: API Management ゲートウェイの API 要求と応答を通じて機密データが流れる場合は、ライフサイクル全体にわたって保護を確保します。 異なるリージョン間でさまざまなデータ保護要件を考慮します。 Evaluate service features such as multiple regions to isolate specific data. また、キャッシュ戦略がこれらの分離要件と一致しているかどうかを確認します。

  • 共有ゲートウェイでセグメント化戦略を開発する: API Management インスタンスが複数のワークロード チームの API をホストしている場合は、 ワークスペースを 使用してロール、ネットワーク、および場合によってはゲートウェイを分離します。 このアプローチにより、各チームは、他のチームの API へのアクセスを制限しながら、管理する API に対する適切なアクセスと制御を確実に行うことができます。

  • ネットワーク制御を検討します。仮想ネットワークを使用して受信および送信ゲートウェイ トラフィックを分離またはフィルター処理するための要件とオプションを特定します。 ゲートウェイへのアクセスを Azure Private Link 経由で制限できるかどうか、またはゲートウェイへのパブリック アクセスが必要かどうかを判断します。 必要なネットワーク分離を実現し、ネットワーク トラフィックをフィルター処理するために、アーキテクチャに Azure Application Gateway の Azure Web アプリケーション ファイアウォールや Azure Front Door などの Web アプリケーション ファイアウォールを含める必要があるかどうかを評価します。

  • API の認証と承認の機能を検討します。 組み込みのグループを含む Microsoft Entra ID などの ID プロバイダーの使用を評価するか、 Microsoft Entra External ID を 使用してゲートウェイ要求をスクリーニングし、バックエンド API の OAuth 承認を有効にします。

  • ネットワーク トラフィックを暗号化する: ワークロードでサポートできる最も安全なトランスポート層セキュリティ (TLS) プロトコルのバージョンと暗号 を特定します。 安全でない TLS バージョンは必要ありません。 クライアントでサポートされている場合は、TLS 1.3 を使用します。

  • API Management で脅威モデリングを実行し、その領域を減らします 。直接管理 API や開発者ポータルへのパブリック アクセスなど、特定の API Management コンポーネントを無効にするか、制限するか、削除できるかを判断します。

  • ワークロードに必要なシークレットを特定します。 ゲートウェイ操作には、証明書、API キー、またはその他のシークレット値が必要な場合があります。 シークレットと証明書を格納するための Azure Key Vault の要件と機能を確認します。 Or review the built-in API Management capabilities such as named values and managed certificates.

Configuration recommendations

これらのセキュリティに関する推奨事項は、サービス自体、または API とそのポリシーを通過するトラフィックに適用できます。 The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(サービス)非推奨の ダイレクト管理 API を無効にします。 コントロール プレーンとして Azure Resource Manager を使用します。 コントロール プレーン アクセス ポイントを削除することで、サービスのサーフェス領域が縮小されます。
(サービス)正当なクライアントの接続先のみに基づいて、ゲートウェイの公開を制限します。

- すべてのクライアント が仮想ネットワーク 経由でトラフィックをルーティングできる場合は、パブリック IP アドレスなしで仮想ネットワークインジェクションを使用します。 ネットワーク セキュリティ グループ (NSG) を使用して、予想されるクライアント配信元 IP アドレスのみにトラフィックをさらに制限します。

- インターネットからトラフィックが必要な場合は、Application Gateway または Azure Front Door との 仮想ネットワーク統合 を使用します。 Configure the NSG to only accept traffic from the single point of entry.
ネットワーク トラフィックの機密性は、正当なクライアントが含まれると予想されるソース IP アドレス範囲への露出を制限することで保護されます。 これらの制限により、正当なクライアント通信を開始してはならないソースからのアクセスがブロックされます。 正当なトラフィック ソースへの公開を制限すると、サービスの機密性、整合性、可用性が向上します。
(Service) Disable developer portal if it's not in use. ポータルが使用中の場合は、 サインアップ エクスペリエンスを無効にし、 匿名アクセスを無効にして、信頼できるネットワークの場所のみにアクセスを制限します。 サービスの表面領域と、構成ミスや無視の可能性が減少します。
(サービス)クライアントとバックエンドでサポートされる最も狭い TLS バージョン、プロトコル、暗号 を明示的に設定します。 バージョンとサポートされている暗号は、クライアントとバックエンドがサポートするオプションのみに制限されます。 このアプローチは、接続が機密性のために可能な最高レベルの接続に優先順位を付けるのに役立ちます。
(サービス) カスタム証明書を Key Vault に格納します 証明書管理機能は、定期的なローテーションをサポートし、証明書へのアクセスを監査する Key Vault を使用して提供されます。
(サービス)バックエンドは API ゲートウェイからのトラフィックのみを受け入れ、他のすべてのトラフィックをブロックする必要があります。 悪意のあるトラフィックが、ゲートウェイに転送されたセキュリティやその他の共通の関心事をバイパスするのを防ぎます。
(サービス)複数のチームまたはセグメント化されたワークロードの API をホストする API Management インスタンスの場合は、堅牢なアクセス制御分離戦略を設計する必要があります。 Use workspaces or implement a rigorous APIOps process to achieve this strategy.

Teams は、自分が所有する API にのみアクセスできる必要があります。 同じインスタンスでホストされている可能性のある他の API にアクセスすることはできません。
侵害された 1 つの API セットから他の無関係な API への攻撃者による横移動が減少します。
(API) Store secrets in Key Vault and expose them to policies through named values. Key Vault を使用して秘密でないものを格納しないでください。 これらの値には、名前付き値プロパティを直接使用します。 シークレットのローテーションは、証明書に使用される方法と同様に、Key Vault の 1 つの管理プレーンを通じて推奨されます。 このプロセスにより、API Management が適切に更新されます。 また、名前付き値により、シークレットと非シークレットの両方に対するポリシー構成のエクスペリエンスが一貫しています。 すべてのシークレット アクセスも Key Vault で監査され、アクセス履歴が提供されます。 Key Vault にシークレットを格納するだけで、Key Vault への依存関係が最小限になり、Key Vault がアプリケーション構成サービスに変わることはありません。
(API) Use different user-assigned managed identities for different APIs by using the authentication-managed-identity policy. 各 API は、各 API の最小特権アクセスによるセグメント化の目標をサポートする独立した ID を持つことが可能です。 また、バックエンド システムの監査性も向上します。
(API)可能な場合は、サブスクリプション キークライアント証明書を含む事前共有キーのみを使用するのではなく、クライアントに OAuth 2.0 フローでの認証を要求します。 監査目的のクライアント識別が改善され、キーのローテーションが排除され、事前共有キーを使用する場合と比較して、シークレットを保護するためのクライアントの負担が軽減されます。
(API) Suppress HTTP headers from API responses by using the set-header policy that might expose implementation details. 攻撃者に対するコストは、実装情報を隠すことで増加します。
(API) Don't use API tracing in production. 機密データは、要求トレースで公開されないようにします。
(API) Defender for API を使用します API セキュリティの分析情報、推奨事項、脅威検出が提供されます。
(API) Protect back-end resources by delegating key security checks in API policy, such as validate-jwt, ip-filter, validate-headers, validate-content. ゲートウェイでセキュリティ チェックを実行することで、バックエンド サービスに到達する非デジタル化トラフィックの量が減ります。 このオフロード アプローチは、これらのリソースの整合性と可用性を保護するのに役立ちます。
(API)ワークロード内のアプリケーション コードに提案された変更を適用するのと同じ方法で、API ポリシーの変更に セキュリティ開発ライフサイクル (SDL) プラクティスを適用します。 ポリシーは、API トラフィックの高い特権を持つビューで実行されます。 侵害された API ゲートウェイによる機密性、整合性、可用性に対するバックエンド保護を回避することは防止されます。
(Service & API) Use managed identities for service and API dependencies. Key Vault、Azure Event Hubs、およびその他の依存関係 (証明書や名前付き値など) への接続は、事前共有シークレットに依存せずに確立されます。
(サービスと API)可能な場合は、Key Vault、Event Hubs、バックエンドなどの依存関係にプライベート ネットワーク接続経由で接続します。 トラフィックの機密性は、プライベート ネットワークを超えてトラフィックを公開しないことで保護されます。
(サービスと API)インターネットで公開されている API を対象とするクライアント トラフィックは、API Management に到達する前に、まず Web アプリケーション ファイアウォール (Web アプリケーション ファイアウォールなど) を通過する必要があります。 また、 Azure DDoS Protection を使用してパブリック エンドポイントを保護します。 Web アプリケーション ファイアウォールを使用してセキュリティ チェックを行うことで、ゲートウェイおよびバックエンド サービスに到達する非デジタルトラフィックの量が削減されます。 このトラフィックを減らすことは、これらのリソースの整合性と可用性を保護するのに役立ちます。
(サービスと API)ワークロードに関連するすべての Azure Policy 規制コンプライアンスコントロールを 評価して有効にします。 API Management インスタンスは、必要な状態に合わせ、セキュリティ ポリシーを設定することでワークロードの進化に合わせて調整されます。

Cost Optimization

コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。

コスト最適化の設計原則は、API Management とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。

ワークロード設計チェックリスト

  • API Management のコスト モデルについて考えてみましょう。 組織のアカウントの利点と SLA とスケーラビリティの基準と共に Azure 料金計算ツール を使用して、API Management サービス レベルの使用に関する正確なコスト見積もりを作成します。 チャージバック モデルが必要かどうかを判断し、メトリック、タグ、トークンに基づいて計算する方法を決定します。

    サービス コスト モデルは、主にサービス レベル、ユニット数、ゲートウェイの数の影響を受けます。 予約ユニットの維持またはアクティブ/パッシブ DR 構成の実装に関連する追加コストを評価します。

    If you implement workspaces, evaluate the costs of using separate versus shared workspace gateways to address the distinct API flow requirements of various API teams or stakeholders.

  • スケーリング コストを見積もる: ゲートウェイ リソースの使用率を高く維持するためのスケーリング条件を開発します。 実稼働前環境でベースライン コストを評価し、予想されるワークロード トラフィックに基づいてスケールアウトのコストをモデル化するためのテストを実行します。

    ゲートウェイの誤用を防ぐための軽減戦略を設計します。これにより、想定される使用を超えてコストのかかるスケーリングが発生する可能性があります。

  • サービスの構成とポリシーを評価します。レート制限制限コンカレンシーなどの機能は、要求の負荷を管理するためのコスト最適化手法として使用できます。

  • ロジックの配置を最適化する: バックエンド サーバーがロジックの処理にコスト効率が高いか、ゲートウェイがリソースの使用状況を処理する必要があるかを評価します。 このゲートウェイは、横断的な懸念事項を実装するための強力なコンポーネントですが、特定のシナリオでは過剰な機能を実行する可能性があります。 ゲートウェイが実行するリソースの多い要求処理タスクを特定し、そのロジックをバックエンド サーバーに移動することでコストを削減できるかどうかを判断します。

Configuration recommendations

これらのコスト最適化の推奨事項は、サービス自体、または API とそのポリシーを通過するトラフィックに適用できます。 The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(サービス)ワークロードの要件をサポートする 最も安価なレベル を使用します。 たとえば、ワークロードが投資収益率 (ROI) を正当化する方法で追加された機能の恩恵を受けない場合は、Premium レベルではなく Standard レベルを選択します。 未使用または未使用の機能の購入は避けられます。
(Service) Use nonproduction tiers or transient infrastructure in lower environments, such as development environments, proof-of-concept deployments, and initial cost modeling activities. リソース コストは、運用環境の正確な構成やアップタイムの要件を完全にミラーリングしなくても役に立つ環境に対して節約されます。
(サービス)需要が減少したときにスケールインします。 Configure autoscale rules or other automated processes to reduce units when gateway capacity drops below defined thresholds. 不要なコストは、需要に合わせた容量によって削減されます。
(Service) Calculate any cost advantages of a federated model for API management by using workspaces to serve APIs while also providing team isolation. 展開と管理の画面が縮小されます。 このアプローチは、時間とリソースの購入からスケールの経済を達成することを目的としています。
(Service) Decommission workspaces when they're no longer in use. 未使用のリソースへの支出は回避されます。
(Service) Use the built-in cache if your workload's cached data fits within the constraints of the built-in cache in your tier. 外部 Redis と互換性のあるキャッシュの購入と保守に関連するコストは回避されます。
(Service) Block malicious traffic before it reaches the gateway by using network controls, DDoS protection, and web application firewalls. API Management の特定のレベルでは、ゲートウェイが処理する HTTP 要求操作の数に基づいて料金が発生します。 その結果、ボットによって生成された要求などの望ましくないトラフィックによって、コストが増加する可能性があります。

ブロック メカニズムのコストと HTTP 操作の削減の推定コストを評価して、このアプローチに ROI があるかどうかを評価します。
ゲートウェイに対する過剰な悪意のある HTTP 操作または迷惑な HTTP 操作が原因で発生する料金が削減されます。
(API)プロセッサ、ネットワーク、メモリなどの過剰なコンピューティング リソースの使用を回避するために、 ポリシーの式と処理 とコードを最適化します。 最適化されていないポリシー実装とコードの容量を提供するために、より多くのユニットを不必要にデプロイすることは避けられます。
(API)ゲートウェイ、バックエンド、またはパブリック エントリ ポイント (Azure Front Door など) 間のロジック配置のコストを評価します。 同じ処理は、多くの場合、これらのレイヤーのいずれかで、それぞれ独自のトレードオフを持つ場合に発生する可能性があります。 ただし、一部のレイヤーでは、そのレベルで使用できる未使用の容量が原因でコストを削減できる場合があります。 たとえば、もともとバックエンドで実装されていたキャッシュ ロジックは、組み込みのキャッシュを使用して、ゲートウェイ レベルでよりコスト効率の高い方法で実装される場合があります。 この方法により、バックエンド サービスでの追加のネットワークとコンピューティングのオーバーヘッドが削減されます。 コストの高いリソースに対する負荷は、最もコスト効率の高いレイヤーに機能を配置することで最小限に抑えられます。 このアプローチでは、予備の容量または低コストのコンピューティング オプションを持つレイヤーにワークロードを移行します。

Operational Excellence

オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。

オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。

API Management に関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて、設計戦略を開始します。

ワークロード設計チェックリスト

  • サービスの運用に必要な主要な知識とスキルを確認します。 領域には、API ライフサイクル、DevOps プロセス、ネットワークと接続、監視と監視、ソフトウェア開発が含まれます。 このアプローチには、ポリシー構成、単体テスト、CI/CD パイプラインの作成が含まれます。

  • ドキュメントのニーズを考慮してください。 組織は、サービス レベルおよび API レベルの構成、ライフサイクル操作、および API チームのさまざまなアクセス パターンのプロセスの文書化にコミットする必要があります。

  • サービス操作をサポートするために標準ツールを評価します。 For example, adopt APIOps methods, such as GitOps and CI/CD, to publish APIs and manage API configurations. サービス レベルの構成の変更には、IaC ツールを使用します。 開発環境から運用環境にシームレスに移行できる再利用可能な成果物を設計します。 Consider integrating a linter like Spectral, either self-managed or as integrated into an Azure service like Azure API Center, into API approval pipelines.

  • 主要な運用メトリックとログを決定します。 運用環境の メトリック を確認します。 これらのメトリックには、ゲートウェイ容量、CPU 使用率、メモリ使用量、要求の数が含まれます。 Review logs and observability tools, such as Azure Monitor and Application Insights. 運用環境で大量の観測データを効果的に管理するために必要な戦略とツールを決定します。 ゲートウェイ オペレーターと、特定のホストされている API を監視する利害関係者の両方に対して実用的な分析情報を提供するクエリを決定します。

  • ロードテストを使用して、運用ワークロードを定期的にテストする計画を立てます。

  • 自動化を必要とする CI/CD または IaC プロセス以外の運用タスクを特定します。 API Management ポリシーのソース管理、Azure ポリシー、特定の開発者ポータルの構成などの領域で自動化を計画します。

Configuration recommendations

これらのオペレーショナル エクセレンスの推奨事項は、サービス自体、または API とそのポリシーを通過するトラフィックに適用できます。 The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(サービス) API Management 用に Azure Diagnostics リソース ログを構成します。 プラットフォームで生成されたログは、日常的な操作、オンデマンドのニーズ、またはセキュリティ監査などの緊急のシナリオを照会するために使用できます。
(サービス) api Management インスタンスで発生する意味のあるイベント ( APICreatedなど) に基づいて自動化するには、Azure Event Grid を使用します。 自動化または通知タスクは、API Management インスタンスで発生する主要なライフサイクル イベントを中心に構築できます。
(Service) Avoid using a self-hosted gateway if a Microsoft-hosted gateway unit works in your scenario. 自動化または通知タスクは、API Management インスタンスで発生する主要なライフサイクル イベントを中心に構築できます。
(サービス)インスタンスを管理し、セキュリティ要件を含むワークロード要件に合わせて制限するのに役立つ 、すべての組み込みの Azure Policy ポリシー を適用します。 For example, use deny policies to prevent APIs from being exposed over HTTP or to prevent the enabling of the direct management REST API. Use audit policies if deny policies aren't available, or create custom deny policies if it's important to your workload. API Management インスタンスは設計に合わせて調整され、ワークロードの進化に合わせて調整されたままになります。
(サービス)Azure portal の問題の 診断と解決 機能について理解します。

ポータルの [ネットワークの状態] ブレード を使用して、ネットワーク接続のトラブルシューティングを行います。
サイト信頼性エンジニアリングの個人は、すべての環境でゲートウェイのパフォーマンス、サービスの可用性、ネットワーク接続の問題を特定してトラブルシューティングできます。
(API) Use Event Hubs to handle log or event streams from API invocations that require near real-time reactions or short-timeframe windowed operations. ログ エントリのほぼリアルタイムの可用性が提供されます。 API 内で Azure Monitor にログを記録するときに発生する ログ データ インジェストの遅延 が回避されます。
(API) Support the usage of API tracing in development to help developers understand their policy implementation. 開発者の生産性は、API 内のポリシーの実装に関する分析情報を提供することによって最適化されます。 この機能がないと、開発者は分析情報を得るためにポリシー実装にハッキングを導入する必要があります。
(API) Always define back ends by using the backends feature of API Management. Reference these back ends by ID in policy by using set-backend-service. Load balanced back ends should be defined as a backend pool. バックエンド接続の変更は、個々のポリシー コードの更新を必要とせずに、バックエンドを使用するすべての API に適用されます。 構成ミスや見落とされた API ポリシーの変更のリスクが軽減され、複数の API が同じバックエンドを共有するシナリオは、この構成抽象化レイヤーに適しています。
(API)API Management のバージョン管理 とリビジョン機能に合わせて、API のバージョン管理アプローチを設計します。 このアプローチを API デプロイ操作に組み込みます。 API Management ですぐに使用できる API バージョン管理戦略は、カスタム ソリューションを構築する代わりに組み込みの機能を利用するために使用されます。
(サービスと API)API を追加、変更、削除するための一貫性のある持続可能な運用プロセスを定義します。 Determine whether to manage this experience manually through the portal or implement it through an APIOps process. ポータル ベースのアプローチではなく、IaC ベースのアプローチを使用することを好みます。

API Management's representation in the Resource Manager API consists of many child resources, so it's important to adopt a layered approach for IaC-based management of this resource collection.
API 仕様とそのゲートウェイ実装は、ワークロードの変更制御プロセスに統合されます。 この方法では、バックエンド API への変更を、ゲートウェイ経由で API クライアントに公開する方法とは異なる方法で処理することを防ぎます。

Performance Efficiency

パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。

パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。

API Management の主要業績評価指標に基づいてベースラインを定義するための パフォーマンス効率の設計レビュー チェックリスト に基づいて、設計戦略を開始します。

ワークロード設計チェックリスト

  • パフォーマンスターゲットを定義します。 API Management ゲートウェイのパフォーマンスを評価するための主要なメトリックには、ゲートウェイ インフラストラクチャの CPU とメモリ使用量の割合、要求期間、要求スループットなどの容量メトリックが含まれます。 マルチリージョンデプロイでは、各リージョンのパフォーマンスターゲットを定義します。 お客様は、トラフィック パターン、API ワークロード、およびスケーリング時間に基づいて適切なスケーリングしきい値を定義する必要があります。

  • パフォーマンス データの収集: 組み込みの分析、Azure Monitor メトリック、Azure Monitor ログ、Application Insights、Event Hubs の機能を確認して、さまざまなレベルの粒度でパフォーマンスを収集および分析します。

  • ライブ パフォーマンスの問題を特定する方法を確認します。 ライブ パフォーマンスの問題のインジケーターには、Azure サービスの可用性、HTTP 応答エラー、ポータルの [ 問題の診断と解決 ] セクションで発生したエラーが含まれます。 Azure portal の API Management 診断の Application Insights、Kusto クエリ、および推奨事項を使用して、パフォーマンスと可用性の問題のトラブルシューティングを行います。

  • Test performance: Test performance under production conditions by using load testing.

  • パフォーマンスを向上させる可能性がある隣接するサービスを評価します。 キャッシュ ポリシーまたは外部キャッシュにより、特定の API 操作のパフォーマンスが向上する可能性があります。 Azure Front Door と Application Gateway は、TLS オフロードの一般的な選択肢です。

  • 文書化されている制限と制約を確認する:API Management には制限と制約があります。 文書化された制約を確認し、ワークロードの要件と比較して、これらの制約を回避するソリューションを設計する必要があるかどうかを確認します。

Configuration recommendations

これらのパフォーマンス効率の推奨事項は、サービス自体、または API とそのポリシーを通過するトラフィックに適用できます。 The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(サービス)需要に合わせて動的にスケーリングします。 Configure autoscale rules or other automated processes to adjust gateway units to match a target usage capacity. 弾力性は、同時使用に基づいて実現されます。これにより、現在デプロイされているユニットのリソースの枯渇や容量の過剰割り当てを防ぐことができます。
(API) Minimize expensive processing tasks, such as generating large buffered payload sizes, by using the validate-content policy on large request bodies or by maintaining a high number of active WebSockets. スケール ユニットの負荷が軽減されるため、スケールアウトする必要がある前に、より多くの要求を同時に処理できます。
(サービスと API) パフォーマンス メトリックを収集します

一般的な API パフォーマンス メトリックは次のとおりです。

- ゲートウェイ自体と完全な操作の処理時間を要求します。
- ゲートウェイ ユニット リソースの使用状況メトリック。
- 1 秒あたりの要求数や 1 秒あたりのメガビット数などのスループット測定。
- キャッシュ ヒット率。
実際のパフォーマンスは、ワークロードのターゲットに対して測定されます。
(サービスと API)パフォーマンスに影響を与えずに十分な可視性を提供する Application Insights のサンプリング率 を定義します。 監視データのニーズは、全体的なパフォーマンスに影響を与えずに満たされます。
(サービスと API)ゲートウェイ、バックエンド、またはパブリック エントリ ポイント (Azure Front Door など) 間のロジック配置のパフォーマンスへの影響を評価します。 同じ処理タスクは、多くの場合、これらのレイヤーのいずれかで発生する可能性があります。パフォーマンスのトレードオフと、それぞれの最適化の機会に制限があります。 API Management API ポリシーなどのタスクで待機時間が長すぎる場合は、そのタスクがより最適化された方法で他の場所で実行できるかどうかを検討してください。 API に待機時間を追加するタスクは、ワークロードの要件を満たすように最適化されたコンピューティングで実行されます。

Azure policies

Azure には、API Management とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。

  • ゲートウェイはゾーン冗長用に構成されています。
  • 仮想ネットワークへのデプロイなど、API Management ゲートウェイに対して適切なネットワーク制御が行われます。
  • サービス構成エンドポイントにはパブリックにアクセスできません。
  • 直接管理 REST API が無効になっています。

包括的なガバナンスについては、API Management ゲートウェイのセキュリティに影響を与える可能性がある Azure Policy の組み込み定義 とその他のポリシーを確認してください。

Azure Advisor の推奨事項

Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。

For more information, see Azure Advisor.

Advisor では、次のような他の推奨事項も運用システムに表示される場合があります。

  • validate-jwt ポリシーで長い JWT キー サイズを要求できない。
  • 従来の Resource Manager API バージョンを使用してリソースをデプロイしました。
  • API キー トークンは有効期限に近い状態です。
  • 証明書のローテーション操作でエラーが発生しました。

Tradeoffs

柱のチェックリストのアプローチを使用する場合は、設計のトレードオフを行う必要がある場合があります。 利点と欠点の例をいくつか次に示します。

冗長性と分離による高可用性

  • High availability. アーキテクチャに冗長性を追加すると、コストに影響します。 たとえば、ゾーンの停止を回避するために少なくとも 3 つのユニットをプロビジョニングすることは、ワークロードに対して経済的に実現できない場合があります。 リージョンあたり少なくとも 6 ユニットまたは 3 ユニットが必要なマルチリージョン アーキテクチャでは、コストがさらに増加します。 マルチリージョンのセットアップでは、安全なデプロイ、信頼性の高いスケーリング、バックエンドとのフェールオーバー調整を調整するための運用コストも追加されます。

  • Isolation. ワークスペースまたは API Management インスタンス間でワークロードを分離すると、コンピューティングの分離を備えたマルチテナント システムの管理が含まれるため、運用の複雑さが増します。

需要に合わせてスケーリングする

  • 適切に動作するクライアントからの需要に合わせて自動的にスケールアウトする場合、それらのコストは既にコスト モデルに組み込まれています。 ただし、このスケーリング機能により、サービスをスケーリングして、迷惑なトラフィックや悪意のあるトラフィックからのトラフィックを処理することもできます。

  • 望ましくないトラフィックを軽減すると、コストが発生します。 Web アプリケーション ファイアウォールや DDoS 保護などのサービスを追加すると、コストが増加します。 トラフィックを処理するようにサービスをスケーリングすると、ユニットが追加されるため、コストが増加します。 スケーリングの上限を設定すると、支出が制限される可能性がありますが、悪意のあるトラフィックや有害なトラフィックが API を圧倒すると、正当なユーザーの信頼性の問題が発生する可能性があります。

フェデレーションと分散のアプローチ

API Management の基本的な決定は、1 つの API Management インスタンス内に異なるワークロードを併置するか、完全に自律的なトポロジで複数のインスタンス間でワークロードを分離するかです。

API Management ワークスペースを使用すると、複数の API チームのマルチテナント コロケーション プラットフォームとして効率的な操作が可能になります。 階層化された価格モデルは、ゲートウェイを使用するすべてのテナント間でサービス コストを共有できるように設計されています。 ただし、他のコロケーション プラットフォームと同様に、障害や構成の誤りにより、同じインフラストラクチャを共有する関連のないワークロードに広範な影響が及ぶ可能性があります。

各ワークロード チームが独自のインスタンスを管理する完全分散型モデルでは、定期的な操作で重複コストと冗長性が導入されます。 ただし、信頼性、セキュリティ、およびパフォーマンス関連のインシデントに固有の爆発半径の軽減策が提供されます。

Example architecture

主要な推奨事項を示す基本的なアーキテクチャ: API Management ランディング ゾーンアーキテクチャ

Next steps

API Management は、多くの場合、次のサービスと組み合わされます。 ワークロードに次のサービスが含まれている場合は、サービス ガイドまたは製品ドキュメントを必ず確認してください。

次の記事では、この記事で説明する推奨事項の一部を示します。