マイクロサービスでの API ゲートウェイの使用Using API gateways in microservices

マイクロサービス アーキテクチャでは、クライアントは、1 つ以上のフロント エンド サービスと対話する可能性があります。In a microservices architecture, a client might interact with more than one front-end service. この事実を前提として、クライアントは、呼び出し先のエンドポイントをどのような方法で知るのでしょうか。Given this fact, how does a client know what endpoints to call? 新しいサービスが導入されたり、既存のサービスがリファクタリングされた場合は何が起こるのでしょうか。What happens when new services are introduced, or existing services are refactored? サービスは、SSL 終了、認証、およびその他の問題をどのように処理するのでしょうか。How do services handle SSL termination, authentication, and other concerns? "API ゲートウェイ" は、これらの課題に対処するのに役立ちます。An API gateway can help to address these challenges.

API ゲートウェイの図

API ゲートウェイとはWhat is an API gateway?

API ゲートウェイは、クライアントとサービスの間に位置します。An API gateway sits between clients and services. それは、要求をクライアントからサービスにルーティングするリバース プロキシとして機能します。It acts as a reverse proxy, routing requests from clients to services. さらに、認証、SSL 終了、レート制限などのさまざまな横断的タスクを実行できます。It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate limiting. ゲートウェイをデプロイしない場合、クライアントは、フロント エンド サービスに直接要求を送信する必要があります。If you don't deploy a gateway, clients must send requests directly to front-end services. ただし、クライアントにサービスを直接公開することには潜在的な問題があります。However, there are some potential problems with exposing services directly to clients:

  • クライアント コードが複雑になる可能性があります。It can result in complex client code. クライアントは、複数のエンドポイントを追跡し、回復力のある方法でエラーを処理する必要があります。The client must keep track of multiple endpoints, and handle failures in a resilient way.
  • クライアントとバックエンド間の結合が作成されます。It creates coupling between the client and the backend. クライアントは、個々のサービスを分解する方法を知る必要があります。The client needs to know how the individual services are decomposed. これにより、クライアントの管理がますます困難になり、同時にサービスのリファクターも難しくなります。That makes it harder to maintain the client and also harder to refactor services.
  • 単一の操作で、複数のサービスの呼び出しが必要な場合があります。A single operation might require calls to multiple services. これにより、クライアントとサーバー間で複数のネットワーク ラウンド トリップが発生し、待機時間が大幅に長くなる可能性があります。That can result in multiple network round trips between the client and the server, adding significant latency.
  • 各公開サービスで、認証、SSL、クライアントのレート制限などの問題を処理する必要があります。Each public-facing service must handle concerns such as authentication, SSL, and client rate limiting.
  • サービスは、HTTP や WebSocket などのクライアントに適したプロトコルを公開する必要があります。Services must expose a client-friendly protocol such as HTTP or WebSocket. これにより、通信プロトコルの選択肢が制限されます。This limits the choice of communication protocols.
  • パブリック エンドポイントを使用するサービスは潜在的な攻撃対象であるため、セキュリティで保護する必要があります。Services with public endpoints are a potential attack surface, and must be hardened.

ゲートウェイは、サービスからクライアントを分離することによって、これらの問題に対処するのに役立ちます。A gateway helps to address these issues by decoupling clients from services. ゲートウェイは、多数の異なる機能を実行できますが、そのすべてが必要であるわけではありません。Gateways can perform a number of different functions, and you may not need all of them. 機能は、次のデザイン パターンに分類できます。The functions can be grouped into the following design patterns:

ゲートウェイ ルーティングGateway Routing. 第 7 層のルーティングを使用して、1 つ以上のバックエンド サービスに要求をルーティングするリバース プロキシとしてゲートウェイを使用します。Use the gateway as a reverse proxy to route requests to one or more backend services, using layer 7 routing. ゲートウェイは、クライアントに単一のエンドポイントを提供し、サービスからクライアントを分離するのに役立ちます。The gateway provides a single endpoint for clients, and helps to decouple clients from services.

ゲートウェイ集約Gateway Aggregation. ゲートウェイを使用して、複数の個々の要求を 1 つの要求に集約します。Use the gateway to aggregate multiple individual requests into a single request. このパターンは、単一の操作で複数のバックエンド サービスを呼び出す必要がある場合に適用されます。This pattern applies when a single operation requires calls to multiple backend services. クライアントは、1 つの要求をゲートウェイに送信します。The client sends one request to the gateway. ゲートウェイはさまざまなバックエンド サービスに要求をディスパッチし、結果を集計し、それらをクライアントに送り返します。The gateway dispatches requests to the various backend services, and then aggregates the results and sends them back to the client. これにより、クライアントとバックエンド間の頻繁な通信を削減できます。This helps to reduce chattiness between the client and the backend.

ゲートウェイ オフロードGateway Offloading. ゲートウェイを使用して、個々 のサービスからゲートウェイに機能をオフロードします。これは特に横断的問題に適用します。Use the gateway to offload functionality from individual services to the gateway, particularly cross-cutting concerns. すべてのサービスに機能を実装する責任を負わせるよりも、機能を 1 か所に統合するほうが有用である可能性があります。It can be useful to consolidate these functions into one place, rather than making every service responsible for implementing them. これは、認証や承認など、正しく実装するには専門的な技能を必要とする機能に特に当てはまります。This is particularly true for features that requires specialized skills to implement correctly, such as authentication and authorization.

ゲートウェイにオフロードすることができる機能のいくつかの例を次に示します。Here are some examples of functionality that could be offloaded to a gateway:

  • SSL ターミネーションSSL termination
  • 認証Authentication
  • IP ホワイトリスト登録IP whitelisting
  • クライアントのレート制限 (調整)Client rate limiting (throttling)
  • ログ記録と監視Logging and monitoring
  • 応答のキャッシュResponse caching
  • Web アプリケーション ファイアウォールWeb application firewall
  • GZIP 圧縮GZIP compression
  • 静的コンテンツの処理Servicing static content

ゲートウェイ テクノロジの選択Choosing a gateway technology

アプリケーションで API ゲートウェイを実装するためのいくつかのオプションを示します。Here are some options for implementing an API gateway in your application.

  • リバース プロキシ サーバーReverse proxy server. Nginx と HAProxy は、負荷分散、SSL、第 7 層のルーティングなどの機能をサポートする一般的なリバース プロキシ サーバーです。Nginx and HAProxy are popular reverse proxy servers that support features such as load balancing, SSL, and layer 7 routing. どちらも無料のオープン ソース製品であり、有償エディションで追加機能とサポート オプションが提供されます。They are both free, open-source products, with paid editions that provide additional features and support options. Nginx と HAProxy は、どちらも豊富な機能セットと高パフォーマンスを備えた完成度の高い製品です。Nginx and HAProxy are both mature products with rich feature sets and high performance. サードパーティ モジュールの使用や Lua でのカスタム スクリプトの記述によって、それらを拡張できます。You can extend them with third-party modules or by writing custom scripts in Lua. Nginx では、「NGINX JavaScript」と呼ばれる JavaScript ベースのスクリプト モジュールもサポートしています。Nginx also supports a JavaScript-based scripting module referred to as 'NGINX JavaScript'. このモジュールの正式名称は nginScript です。This module was formally named nginScript.

  • サービス メッシュ イングレス コントローラーService mesh ingress controller. linkerd や Istio などのサービス メッシュを使用している場合は、そのサービス メッシュのイングレス コントローラーによって提供される機能を検討します。If you are using a service mesh such as linkerd or Istio, consider the features that are provided by the ingress controller for that service mesh. たとえば、Istio イングレス コントローラーは、第 7 層のルーティング、HTTP リダイレクト、再試行、およびその他の機能をサポートしています。For example, the Istio ingress controller supports layer 7 routing, HTTP redirects, retries, and other features.

  • Azure Application GatewayAzure Application Gateway. Application Gateway は、第 7 層のルーティングと SSL 終了を実行できる負荷分散管理対象サービスです。Application Gateway is a managed load balancing service that can perform layer-7 routing and SSL termination. Web アプリケーション ファイアウォール (WAF) も提供します。It also provides a web application firewall (WAF).

  • Azure API ManagementAzure API Management. API Management は、API を外部顧客と内部顧客に公開するためのターンキー ソリューションです。API Management is a turnkey solution for publishing APIs to external and internal customers. 公開 API を管理するために役立つ機能 (レート制限、IP ホワイトリスト登録、Azure Active Directory やその他の ID プロバイダーを使用した認証など) を提供します。It provides features that are useful for managing a public-facing API, including rate limiting, IP white listing, and authentication using Azure Active Directory or other identity providers. API Management は負荷分散を実行しないため、Application Gateway やリバース プロキシなどのロード バランサーと組み合わせて使用する必要があります。API Management doesn't perform any load balancing, so it should be used in conjunction with a load balancer such as Application Gateway or a reverse proxy. API Management と Application Gateway の使用の詳細については、「内部 VNet 内の API Management と Application Gateway の統合」を参照してください。For information about using API Management with Application Gateway, see Integrate API Management in an internal VNet with Application Gateway.

ゲートウェイ テクノロジを選択するときは、以下を考慮してください。When choosing a gateway technology, consider the following:

FeaturesFeatures. 上記のオプションはすべてが第 7 層のルーティングをサポートしますが、その他の機能に対するサポートは異なっています。The options listed above all support layer 7 routing, but support for other features will vary. 必要な機能に応じて、複数のゲートウェイをデプロイできます。Depending on the features that you need, you might deploy more than one gateway.

デプロイ」を参照してください。Deployment. Azure Application Gateway と API Management は管理対象サービスです。Azure Application Gateway and API Management are managed services. Nginx と HAProxy は通常、クラスター内のコンテナーで実行されますが、クラスター外の専用 VM にデプロイすることもできます。Nginx and HAProxy will typically run in containers inside the cluster, but can also be deployed to dedicated VMs outside of the cluster. これを行うと、ゲートウェイはワークロードの残りの部分から分離されますが、高い管理オーバーヘッドが発生します。This isolates the gateway from the rest of the workload, but incurs higher management overhead.

管理Management. サービスが更新されたり、新しいサービスが追加されたりした場合、ゲートウェイのルーティング規則の更新が必要になる場合があります。When services are updated or new services are added, the gateway routing rules may need to be updated. このプロセスを管理する方法を検討してください。Consider how this process will be managed. 類似の検討が、SSL 証明書、IP ホワイトリスト登録、および構成の他の側面の管理にも適用されます。Similar considerations apply to managing SSL certificates, IP whitelists, and other aspects of configuration.

Nginx または HAProxy の Kubernetes へのデプロイDeploying Nginx or HAProxy to Kubernetes

Nginx または HAProxy は、Nginx または HAProxy コンテナー イメージを指定する ReplicaSet または DaemonSet として Kubernetes に デプロイできます。You can deploy Nginx or HAProxy to Kubernetes as a ReplicaSet or DaemonSet that specifies the Nginx or HAProxy container image. ConfigMap を使用してプロキシの構成ファイルを格納し、ConfigMap をボリュームとしてマウントします。Use a ConfigMap to store the configuration file for the proxy, and mount the ConfigMap as a volume. LoadBalancer という種類のサービスを作成し、Azure Load Balancer 経由でゲートウェイを公開します。Create a service of type LoadBalancer to expose the gateway through an Azure Load Balancer.

別の方法は、Ingress Controller の作成です。An alternative is to create an Ingress Controller. Ingress Controller は、ロード バランサーまたはリバース プロキシ サーバーをデプロイする Kubernetes リソースです。An Ingress Controller is a Kubernetes resource that deploys a load balancer or reverse proxy server. Nginx と HAProxy を含むさまざまな実装が存在します。Several implementations exist, including Nginx and HAProxy. Ingress と呼ばれる別のリソースが、Ingress Controller のルーティング規則や TLS 証明書などの設定を定義します。A separate resource called an Ingress defines settings for the Ingress Controller, such as routing rules and TLS certificates. つまり、特定のプロキシ サーバー テクノロジに固有の複雑な構成ファイルを管理する必要はありません。That way, you don't need to manage complex configuration files that are specific to a particular proxy server technology.

ゲートウェイは、システム内の潜在的なボトルネックまたは単一障害点であるため、高可用性のためには、常に少なくとも 2 つのレプリカをデプロイします。The gateway is a potential bottleneck or single point of failure in the system, so always deploy at least two replicas for high availability. 負荷に応じて、レプリカをさらにスケールアウトしなければならない場合があります。You may need to scale out the replicas further, depending on the load.

また、ゲートウェイをクラスター内の専用ノード セットで実行することを検討します。Also consider running the gateway on a dedicated set of nodes in the cluster. この方法には次のような利点があります。Benefits to this approach include:

  • 分離。Isolation. すべての着信トラフィックは、バックエンド サービスから分離できるノードの固定セットに送信されます。All inbound traffic goes to a fixed set of nodes, which can be isolated from backend services.

  • 安定した構成。Stable configuration. ゲートウェイが正しく構成されていない場合、アプリケーション全体が使用できなくなる可能性があります。If the gateway is misconfigured, the entire application may become unavailable.

  • パフォーマンス。Performance. パフォーマンス上の理由から、ゲートウェイ用の特定の VM 構成を使用できます。You may want to use a specific VM configuration for the gateway for performance reasons.

次のステップNext steps

これまでの記事では、マイクロサービスの、またはマイクロサービスとクライアント アプリケーションとの間のインターフェイスを見てきました。The previous articles have looked at the interfaces between microservices or between microservices and client applications. 仕様により、これらのインターフェイスではサービスをブラック ボックスとして処理します。By design, these interfaces treat each service as a black box. 具体的には、マイクロサービスでは、データを管理する方法について実装の詳細を公開することはありません。In particular, microservices should never expose implementation details about how they manage data. これにはデータの整合性とデータの一貫性に関わる意味があります。その意味について次の記事で説明します。That has implications for data integrity and data consistency, explored in the next article.