API プロキシの役割を確認する
学習の目的
この単元を完了すると、次のことができるようになります。
- API プロキシがコンシューマーとバックエンドサービスの中継としてどう機能するかを説明する。
- セキュリティ、監視、トラフィック制御のために API プロキシを使用する利点を説明する。
- API 実装を直接公開する代わりにプロキシを使用する場合とその理由を特定する。
API プロキシについて学ぶ
Mule United Airport では、チームが新しいフライトデータ API の構築をちょうど完了したところです。この API は航空会社のシステムに接続し、スケジュールをリアルタイムで更新して、旅行者がスマートフォンからアクセスできる公開ダッシュボードを支えます。ただし、この API を公開する前に、どのようにアクセスされるかを管理し、安全かつ確実に実行されるようにする必要があります。
API プロキシは、それを実現するのに役立ちます。バックエンドサービスを直接公開する代わりに、チームは要求をそのサービスにルーティングするプロキシを設定します。これにより、API の使用方法と使用者を制御できます。
プロキシを設定することで、次のことが可能になります。
- レート制限やクライアント ID 要件などのルールを適用する。
- トラフィックとパフォーマンスを監視する。
- 公開インターフェースを変更することなく、バックエンドサービスを入れ替えたり更新したりする。
この構造により、特に複数の環境にまたがって作業する場合や、外部のコンシューマーにサービスを提供する場合に、チームは API をより安全かつ柔軟に管理できます。API プロキシが制御とセキュリティをどのように実現するかを理解したところで、次は Anypoint Platform 内でこの管理レイヤーを適用する方法を見ていきます。
API プロキシと API 自動検出の比較
Anypoint API Manager では、Mule Gateway 上で実行されている API を管理し、ポリシーを適用する一般的な方法が 2 つあります。
シナリオ |
API 自動検出を使用する? |
API プロキシを使用する? |
|---|---|---|
Mule で API を構築し、コードを所有している。 |
はい。API は Mule アプリケーションとして実行され、API ゲートウェイの自動検出用に設定できます。 |
いいえ。この場合は必要ありません。 |
ポリシーを適用する最もシンプルな方法を求めている |
はい。別のアプリケーションをデプロイすることなく、Mule アプリケーションに直接ポリシーが適用されます。 |
いいえ。通常は不要なセットアップが増えます。 |
API が Mule の外部にすでに存在している |
いいえ。API が Mule アプリケーションでないため、自動検出は使用できません。 |
はい。プロキシを使用すると、Mule 以外の API を API Manager で管理できます。 |
バックエンド API を変更できない |
いいえ。自動検出には、アプリケーションコードへ API ID を追加する必要があります。 |
はい。プロキシは、バックエンドに変更を加えることなく、ポリシーを適用します。 |
API がほかのチームやベンダーによって所有されている |
いいえ。自動検出には、Mule アプリケーションを更新するためのアクセス権が必要です。 |
はい。プロキシは、外部 API に対する制御されたフロントドアとして機能します。 |
API がすでに Mule 上で実行されており、その設定を更新できる場合、通常は API 自動検出が最もシンプルな方法です。直接変更できない、または変更したくない API を管理する必要がある場合や、バックエンドが Mule 上でまったく実行されていない場合は、API プロキシの方が適しています。
Anypoint Platform でのプロキシの動作
Anypoint Platform では、API プロキシがクライアントからの要求を受信し、設定済みのポリシーに基づいてその要求を評価した上で、バックエンドサービスに転送します。このバックエンドサービスは、多くの場合、CloudHub やその他のサポートされているランタイムにデプロイされた Mule アプリケーションです。
このプロセスは次のように機能します。
- クライアントが API の公開エンドポイントに要求を送信する。
- 要求は、API Manager で管理されているプロキシにルーティングされる。
- プロキシは、認証、レート制限、ヘッダー要件などの条件を確認する。
- 要求が条件を満たしている場合、バックエンド実装に転送される。
- バックエンドが要求を処理し、応答を返す。
- プロキシは、応答をクライアントに返す前に、追加のポリシーを適用できる。
このアプローチにより、API のインターフェースと実装が分離されます。開発者は、コンシューマーが API を操作する方法を変更することなく、バックエンドを更新または移動できます。API Manager は、プロキシを通じて、ポリシー適用、監視、バージョン管理をすべて処理します。
API Manager でプロキシを作成する
Anypoint API Manager でプロキシを作成するには、API をどのように公開および管理するかを定義する必要があります。まず Anypoint Exchange の API 仕様から開始し、次にプロキシの動作を制御する設定を定義します。
セットアップ時には、次を選択します。
- プロキシのデプロイ先 (CloudHub や Runtime Fabric など)
- バックエンドサービスがホストされている内部 URI
- 適用するポリシー (クライアント ID 適用や調整など)
作成が完了すると、このプロキシが API の公開エントリポイントになります。API Manager から、使用状況を監視したり、ポリシーを更新したり、API の進化に応じて新しいバージョンを公開したりできます。これにより、基盤となる実装を変更することなく、アクセスを管理し、ガバナンスを適用できます。
プロキシを通じて API を保護して管理する
プロキシを設定すると、Anypoint API Manager を使用してセキュリティポリシーや管理ポリシーを適用できます。これらのポリシーは、API の保護と、本番環境での確実な動作に役立ちます。
一般的なポリシー領域は次のとおりです。
-
認証: クライアントアプリケーションに、クライアント ID やシークレットなどのログイン情報を使用して自身を識別することを要求する。
-
レート制限と調整: 誤使用やシステムの過負荷を防ぐために、一定期間内に許可される要求数を制御する。
-
ヘッダーと IP のフィルタリング: カスタム要求ヘッダーや IP アドレスに基づいて、トラフィックを許可またはブロックする。
-
コンプライアンスチェック: ログ記録や監査を行うポリシー、または定義済みルールに基づいて要求を検証するポリシーを追加する。
これらのポリシーは、プロキシレベルで適用されます。バックエンドの実装を変更することなく、いつでもこれらを変更できます。
監視機能も、API Manager に組み込まれています。ダッシュボードには、使用状況トレンド、応答時間、エラー率などのメトリクスが表示されます。この可視性は、問題を早期に特定し、パフォーマンスを最適化し、今後の拡張を計画するのに役立ちます。
ポリシー適用と監視を組み合わせることで、コードを変更することなく API を保護したり、拡張したりするために必要な制御性が得られます。
MUA での活用例: フライトデータ API の保護
Mule United Airport では、開発チームが、発着案内板を支える新しいフライトデータ API の稼働開始に向けて準備を進めています。一般公開する前に、誰がアクセスできるか、どのくらいの頻度でコールできるか、高負荷時にどう動作するかを制御する必要があります。
チームは、Anypoint API Manager を使用して、フライトデータ API 用のプロキシを作成します。クライアント ID 適用ポリシーを設定し、承認されたパートナーアプリケーションのみが API をコールできるようにします。また、旅行のピーク時間帯での過剰な使用を防ぐために、レート制限ルールも設定します。
プロキシを設定することで、使用状況をリアルタイムで監視し、エラー率を確認し、エンドポイント全体の要求量を追跡します。問題が発生した場合は、航空会社のシステムに接続するバックエンドアプリケーションに変更を加えることなく、ポリシーを調整したり、API のバージョンを更新したりできます。
プロキシを通じて API を管理することで、MUA は安全なアクセス、明確な可視性、空港のニーズの拡大に応じて API を拡張できる柔軟性を確保しています。
プロキシが API の管理と保護にどのように役立つかを確認したところで、次はポリシー自体について見ていきます。次の単元では、特定のアクセス制御ポリシーを使用して API を保護し、使用できるユーザーを定義する方法について学習します。