一般に、Gatewayは2つのコンポーネントを接続して特定の機能を実現するための入口です。API Gatewayも大きくは異なりませんが、理解しておくべき重要なテーマです。
この記事で詳しく解説しています。
API Gatewayは、APIとその各種バックエンドサービスの間に確実に設置される仮想の入口のようなものです。リクエストを受け付け、適切なサーバやサービスに振り分けた後、目的のリソースへ返します。
企業向けやデータ主導の組織向けAPIには、さらに安全性、アクセス監視、利用制限の層が必要です。Gatewayは、リクエストのレート制御、データ使用量の管理、リクエスト元の検証、アクセスおよびユーザ認証を実施することで、これを実現します。
Gateway APIの考え方は、ルールに基づいたリソース標準を中心に据え、独立して動作する複数のサービスが一元化された通信基盤を共有できるようにする点にあります。以下のリソースタイプが強調されています:
初心者にはAPI呼び出しを適切に管理するための理想的な手段のように思われるかもしれませんが、その役割はそれだけにとどまりません。以下にAPI Gatewayの機能を簡潔に説明します:
アプリのテストや利用には大量のデータ交換が伴い、このような通信には高度な処理が求められます。API Gatewayは、様々なAPIリクエストをまとめて受け付ける中央プラットフォームとして機能します。
処理の過程では、複数のAPI呼び出しが一括して認証され、適切なAPIへ振り分けられます。
マイクロサービス環境では、各マイクロサービスへのリクエストのための効率的な入口を設け、アクセスおよび動作の基準を設定します。
さらに、API Gatewayはサービスディスカバリー、APIプロトコル変換、ビジネスロジック処理、キャッシュ管理、ネットワークトラフィック支援、API監視といった役割も担います。
API呼び出しを処理し、関係部署へ振り分ける能力により、GatewayはAPI管理に欠かせない存在です。ここでは、レート制限、通知、分析、認証、ポリシー、コスト計算、安全性といった業務を実行します。
多数の小さなコンポーネントから構成されるマイクロサービスは、開発者がユーザー体験を向上させるための手法です。しかし、API Gatewayがなければ成り立ちません。各コンポーネント間の通訳として機能し、迅速で手間のかからない、エラーの少ないAPI実装を実現します。
一般的なGatewayは、多数のクライアントリクエストを処理し、一元管理してまとめることが可能です。これにより、クライアントとアプリ間の通信時間が短縮され、運用コストも削減されます。
Gatewayを導入することで、エンドユーザー、アプリ、そしてAPIまたはソリューションの開発者に対し、API開発から運用コストの制御まで一括して実現できます。
API Gatewayは、特定のAPIの複数バージョンを同時に実行し、テスト、反復、更新を最小限の手間で行えるため、迅速かつ効果的なAPI開発を支援します。さらに、実際のAPI呼び出し数とデータ転送量に応じた料金体系のため、最低契約量はありません。
API Gatewayはレイテンシを最小限に抑え、エンドユーザーに優れた体験を提供します。加えて、トラフィックの制御とAPIリクエストの認証が可能で、バックエンドの開発チームが予期しないトラフィック急増にも対処し、継続的なAPIのパフォーマンスを確保します。
API Gatewayは、API呼び出し情報、エラー率、レイテンシ等のデータを一元にまとめ、統合的な可視化を提供します。これにより、各段階でAPIの性能を監視し、潜在する問題を迅速に発見できます。
API Gatewayは複数のサブスクリプションプランを提供しており、リクエスト数に応じたパッケージ選択が可能です。一般的には、100万件のAPIリクエストがわずか$ 0.90で処理でき、この柔軟な価格設定によりAPI開発のコストを抑えることができます。
各API呼び出しに個別の安全対策を施し、そのパフォーマンスを追跡するのは困難です。マイクロサービス環境では多くの小さなリクエストが存在するため、内部と外部APIそれぞれに別々の安全対策を講じる必要があり、大変な作業となります。
API Gatewayは複数のリクエストを統合するため、ひとつのGatewayが機能しなくなると、全体のAPIインフラが崩壊する可能性があり、信頼性を確保するのが難しくなります。
効果的に機能させるためには、各マイクロサービスの追加に合わせてAPI Gatewayの更新を継続する必要があります。1つのアプリが何百万ものマイクロサービスに分割される場合、その更新作業は途方もなくなります。
制御の中央集権を促すAPI専用Gatewayとは異なり、Service Meshは各マイクロサービスがそれぞれ異なる機能を果たす仕組みです。しかし、Service Mesh内のマイクロサービス間の通信にAPI Gatewayを介在させることで、デジタルソリューションの安全性と処理速度が向上します。
Comparison table
Differentiating Factor | API Gateway | Service-Mesh |
---|---|---|
Aim | Routing the organizational, outsider and database calls or requests securely. | Boosting the platform-independence within an organizational network using microservices. |
Functioning | Can interact with the outsider network and forward the requests to & fro the organizational network. | Acts within the organizational limits or a network. |
Responsibility | Management & safety of the network’s APIs. | To boost a system/network’s performance and portability. APIs hide service meshes from outsiders and secure them. |
Security Method | Allows the use of automation and policies | Requires manual implementation of security strategy. |
ご理解の通り、API Gatewayは各サービス間の仲介役として、通信を安全かつ迅速に行います。
一方、ロードバランサはサーバのトラフィックを分散させる役割を担いますが、厳格なルールはなく、API Gatewayは認証に基づくネットワークトラフィックのバランサと考えられます。
Comparison table
Differentiating Factor | API Gateway | Load-balancer |
---|---|---|
Use | Routing the inner and outer network traffic, alongside the database request, securely in a system/network. | Reducing the load for a server by diverting the traffic. Its work is to pace up the server’s working speed. |
Request Handling | It handles a request using an authentication method. Only the authorized users/requests can enter the network. | It checks the most suitable node for traffic diversion when a request arrives. This decision may be based on the location of the requesting user or on the fact that which resource/server is free. |
Security | It may have automated or manually-implemented security controls to decide who should be authorized and who should not be. | There may be explicit security implementations but the load balancers itself do not take care of security. |
よく読めば、API Gatewayもオンライン上の脆弱性から免れず、十分なAPIセキュリティ対策が必要であることが明らかです。まず、あらゆる通信にHTTPを用いることが基本で、例外はありません。
いくつかのユーザ認証方式を実装することで、不正なAPI呼び出しを防止し、重複を回避しながらアプリ開発の一貫性を保てます。
DDoS、SQL injection、およびブルートフォース攻撃などの脅威には、API Gatewayを守るための追加防御策が求められます。例えば、データが共有される前にサーバ側とクライアント側でユーザ検証を行うことで、SQLインジェクション攻撃を防止できます。
悪意あるコードがGatewayを攻撃するのを防ぐため、サーバ側で逆行APIチェックを行うのが賢明です。頻繁に発生するAPI呼び出しに対して、レート制限、スロットリング、リクエストサイズ管理を適用することで、各段階で適切にリクエストを制御できます。
アクセスされるAPIデータを把握することは、APIの利用価値を理解するために重要です。API Gatewayのログを記録することで、API呼び出しの監査や解析が容易になります。
上述の標準的なGatewayセキュリティ対策に加え、以下の追加対策も推奨されます:
最後に、各段階でAPIを監視することが重要です。効果的なAPIセキュリティのため、不要、旧式、またはセキュリティ基準を満たさないAPIやコンポーネントは削除することが望ましいです。こうした質の低いAPIを維持すれば、さらなる負担となり、セキュリティの穴を招く可能性があります。
最新情報を購読