ゲートウェイ オフロード パターンGateway Offloading pattern

共有または専用のサービス機能の負荷をゲートウェイ プロキシにオフロードします。Offload shared or specialized service functionality to a gateway proxy. このパターンは、SSL 証明書の使用などの共有サービス機能を、アプリケーションの他の部分からゲートウェイに移動することで、アプリケーション開発をシンプルにします。This pattern can simplify application development by moving shared service functionality, such as the use of SSL certificates, from other parts of the application into the gateway.

コンテキストと問題Context and problem

一部の機能は複数のサービスでよく使用されます。こうした機能には、構成、管理、およびメンテナンスが必要です。Some features are commonly used across multiple services, and these features require configuration, management, and maintenance. すべてのアプリケーションのデプロイで分散される共有または専用のサービスにより、管理オーバーヘッドが増加し、デプロイ エラーの可能性が高くなります。A shared or specialized service that is distributed with every application deployment increases the administrative overhead and increases the likelihood of deployment error. 共有機能に対するすべての更新を、その機能を共有するすべてのサービスにデプロイする必要があります。Any updates to a shared feature must be deployed across all services that share that feature.

セキュリティの問題 (トークンの検証、暗号化、SSL 証明書の管理) とその他の複雑なタスクを適切に処理するには、チーム メンバーに高度な専門スキルが必要です。Properly handling security issues (token validation, encryption, SSL certificate management) and other complex tasks can require team members to have highly specialized skills. たとえば、アプリケーションで必要な証明書は、すべてのアプリケーション インスタンスで構成およびデプロイする必要があります。For example, a certificate needed by an application must be configured and deployed on all application instances. 新しくデプロイするたびに、証明書の有効期限が切れないように、その証明書を管理する必要があります。With each new deployment, the certificate must be managed to ensure that it does not expire. 有効期限が切れそうな一般的な証明書は、すべてのアプリケーション デプロイで更新、テスト、および確認する必要があります。Any common certificate that is due to expire must be updated, tested, and verified on every application deployment.

認証、承認、ログ、監視、調整など、他の一般的なサービスについては、デプロイ数が膨大になると、実装および管理するのが困難です。Other common services such as authentication, authorization, logging, monitoring, or throttling can be difficult to implement and manage across a large number of deployments. オーバーヘッドとエラーの可能性を減らすために、この種類の機能は統合する方がよい場合があります。It may be better to consolidate this type of functionality, in order to reduce overhead and the chance of errors.

解決策Solution

一部の機能、特に証明書の管理、認証、SSL 終了、監視、プロトコル変換、調整など、分野横断的な懸念事項を、API ゲートウェイにオフロードします。Offload some features into an API gateway, particularly cross-cutting concerns such as certificate management, authentication, SSL termination, monitoring, protocol translation, or throttling.

次の図は、受信 SSL 接続を終了する API ゲートウェイを示しています。The following diagram shows an API gateway that terminates inbound SSL connections. これは、元の要求元に代わって、API ゲートウェイの HTTP サーバー アップ ストリームからデータを要求します。It requests data on behalf of the original requestor from any HTTP server upstream of the API gateway.

このパターンには次のような利点があります。Benefits of this pattern include:

  • Web サーバー証明書、安全な Web サイトの構成など、関連リソースを配布および管理する必要をなくして、サービス開発をシンプルにします。Simplify the development of services by removing the need to distribute and maintain supporting resources, such as web server certificates and configuration for secure websites. 構成がシンプルになると、管理が容易になり、スケーラビリティが実現し、サービスのアップグレードも簡単になります。Simpler configuration results in easier management and scalability and makes service upgrades simpler.

  • 専用チームが、セキュリティなどの専門的知識を必要とする機能を実装できます。Allow dedicated teams to implement features that require specialized expertise, such as security. これにより、こうした分野横断的で特殊な懸念事項を、関連するエキスパートに任せることができるため、コア チームはアプリケーション機能に集中できます。This allows your core team to focus on the application functionality, leaving these specialized but cross-cutting concerns to the relevant experts.

  • 要求と応答のログ記録および監視に対してある程度の一貫性を提供します。Provide some consistency for request and response logging and monitoring. サービスが正しくインストルメント化されていなくても、最小限の監視およびログ記録レベルが確保されるように、ゲートウェイを構成できます。Even if a service is not correctly instrumented, the gateway can be configured to ensure a minimum level of monitoring and logging.

問題と注意事項Issues and considerations

  • API ゲートウェイが高可用性を備え、障害に対する回復性があることを確認します。Ensure the API gateway is highly available and resilient to failure. API ゲートウェイの複数のインスタンスを実行し、単一障害点をなくします。Avoid single points of failure by running multiple instances of your API gateway.
  • アプリケーションおよびエンドポイントの容量とスケーリングの要件に対応できるようにゲートウェイが設計されていることを確認します。Ensure the gateway is designed for the capacity and scaling requirements of your application and endpoints. ゲートウェイがアプリケーションのボトルネックになっていないこと、また、十分にスケーラブルであることを確認します。Make sure the gateway does not become a bottleneck for the application and is sufficiently scalable.
  • セキュリティ、データ転送など、アプリケーション全体で使用される機能のみをオフロードします。Only offload features that are used by the entire application, such as security or data transfer.
  • ビジネス ロジックは API ゲートウェイにオフロードしないでください。Business logic should never be offloaded to the API gateway.
  • トランザクションを追跡する必要がある場合は、ログ記録のために関連付け ID を生成することを検討します。If you need to track transactions, consider generating correlation IDs for logging purposes.

このパターンを使用する状況When to use this pattern

このパターンは次の状況で使用します。Use this pattern when:

  • アプリケーションのデプロイに、SSL 証明書、暗号化など、共通の懸念事項があるとき。An application deployment has a shared concern such as SSL certificates or encryption.
  • アプリケーション デプロイで共通の機能に、さまざまなリソース要件 (メモリ リソース、ストレージ容量、ネットワーク接続など) があるとき。A feature that is common across application deployments that may have different resource requirements, such as memory resources, storage capacity or network connections.
  • ネットワーク セキュリティ、調整、他のネットワーク境界の懸念事項にかかわる問題への対応を、専門チームに任せたいとき。You wish to move the responsibility for issues such as network security, throttling, or other network boundary concerns to a more specialized team.

サービス間の結合が導入されている場合、このパターンは適切でない可能性があります。This pattern may not be suitable if it introduces coupling across services.

Example

次の構成は、Nginx を SSL オフロード アプライアンスとして使用して、受信 SSL 接続を終了し、接続を 3 台のアップストリーム HTTP サーバーのいずれかに分散します。Using Nginx as the SSL offload appliance, the following configuration terminates an inbound SSL connection and distributes the connection to one of three upstream HTTP servers.

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}