バックエンド システムは、API プロキシがアクセスするサービスを実行します。つまりバックエンド システムは、API と API Management Proxy レイヤが存在する基本的根拠です。
Edge プラットフォーム経由でルーティングされる API リクエストは、バックエンドに到達する前に一般的なパスを通過します。
- リクエストはクライアントから送信されます。ブラウザからアプリまで、何でもクライアントになる可能性もあります。
- 送信されたリクエストは Edge ゲートウェイで受信されます。
- リクエストはゲートウェイ内で処理されます。この処理の一部として、リクエストは多くの分散コンポーネントに渡されます。
- 次にゲートウェイは、リクエストに応答するバックエンドに向けてリクエストをルーティングします。
- その後、バックエンドからのレスポンスは、Edge ゲートウェイ経由で逆方向のパスをたどってクライアントに戻ります。
実際には、Edge 経由でルーティングされる API リクエストのパフォーマンスは、Edge システムとバックエンド システムの両方によって決まります。このアンチパターンでは、パフォーマンスの悪いバックエンド システムを原因とする API リクエストへの影響に重点を置きます。
アンチパターン
バックエンドに問題がある場合を考えてみましょう。以下のような原因が考えられます。
バックエンドのサイズが不適切
これらのバックエンド システム上のサービスを API 経由で公開する際の課題は、アクセスできるエンドユーザーが極めて多いことです。ビジネス上の観点からはこれは歓迎される課題ですが、これに対処する必要があります。
多くの場合、バックエンド システムは、こうしたサービスへの追加需要に対応していません。その結果、適切なサイズより小さくなったり、レスポンス効率化のための調整が機能しなくなったりします。
「サイズが不適切」なバックエンドの問題は、API リクエストが急増すると、バックエンド システムの CPU、負荷、メモリなどのリソースに負担がかかることです。これにより、最終的には API リクエストが失敗します。
バックエンドが遅い
調整が不適切なバックエンドの問題は、バックエンドに到達するリクエストへの応答がかなり遅くなることです。その結果、レイテンシが増加し、タイムアウトが短すぎて、カスタマー エクスペリエンスが損なわれます。
Edge プラットフォームには、遅いバックエンドを回避、管理できる調整可能なオプションがいくつか用意されています。ただし、これらのオプションには制約があります。
影響
- バックエンドのサイズが不十分な場合、トラフィックの増加によりリクエストが失敗する可能性があります。
- バックエンドが遅い場合、リクエストのレイテンシが増加します。
ベスト プラクティス
- キャッシュを使用してレスポンスを保存することで、API の応答時間を改善し、バックエンド サーバーの負荷を軽減します。
- 遅いバックエンド サーバーの根本的な問題を解決します。