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

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

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

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

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

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

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

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

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

バックエンド の障害に対処する: 予期されるバックエンド 障害と予期しないバックエンド 障害の両方を計画します。 これらのシナリオでクライアント エクスペリエンスをテストします。 ゲートウェイ ポリシーを 評価して回復性を向上させ、クライアント エクスペリエンスを強化します。 API 仕様に記載されているように、クォータ、レート制限、再試行ポリシー、バックエンド サーキット ブレーカー、負荷分散、例外処理に重点を置きます。

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

ディザスター リカバリー (DR) の計画: ゲートウェイ インフラストラクチャと API のバックアップと復元のオプションを確認します。 組み込みの バックアップと復元の機能 は、一部のシナリオで役立つ場合があります。 ただし、 APIOps ツールやコードとしてのインフラストラクチャ (IaC) ソリューションなどのカスタマー マネージド オプションも考慮できます。 ユーザー サブスクリプションなど、他のシステム データを維持するための戦略を策定します。

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

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

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

共有ゲートウェイでセグメント化戦略を開発する: 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 の要件と機能を確認します。 または、 名前付き値 や マネージド証明書などの組み込みの API Management 機能を確認します。

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

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

ワークスペースを実装 する場合は、個別のワークスペース ゲートウェイと共有ワークスペース ゲートウェイを使用するコストを評価して、さまざまな API チームまたは利害関係者の個別の API フロー要件に対処します。

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

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

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

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

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

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

サービス操作をサポートするために標準ツールを評価します。 たとえば、 API を 発行し、API 構成を管理するために、GitOps や CI/CD などの APIOps メソッドを採用します。 サービス レベルの構成の変更には、IaC ツールを使用します。 開発環境から運用環境にシームレスに移行できる再利用可能な成果物を設計します。 自己管理型または Azure API Center などの Azure サービスに統合された、スペクトラルのようなリンターを API 承認パイプラインに統合することを検討してください。

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

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

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

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

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

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

テスト パフォーマンス: ロード テストを使用して、運用環境でパフォーマンスをテストします。

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

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