3.3. プラットフォームゲートウェイプロキシーおよび認証サービスのスケーリングに関する考慮事項

プロキシーまたは認証へのリクエストのボリュームが既存のプラットフォームゲートウェイサービスの機能を超えると、プラットフォームゲートウェイプロキシーと認証サービスのスケーリングが適切である可能性があります。この場合、垂直スケーリングでは gRPC、Envoy、Nginx、および WSGI サービスのすべてのワーカープール値が自動的に調整されないため、水平スケーリングが推奨されます。

CPU 使用率にボトルネックが見られる場合、gRPC 認証サービスをスケーリングするとスループットが向上する可能性があります。ただし、外部認証プロバイダーが高レイテンシーの原因である場合、gRPC サービスの水平スケーリングによるメリットは最小限になります。アップストリームサービス時間と合計リクエストレイテンシーの差を確認することで、リクエストの gRPC 認証レイテンシーを判断できます。

最もパフォーマンスの高い認証方法は次のとおりです。

プラットフォームゲートウェイサービス Pod を水平方向にスケーリングすると、各 Envoy がこれを個別に追跡するため、各コンポーネントの API に対するヘルスチェックの数も増加します。これらは、ユーザーエージェント Envoy/HC のログで確認できます。ヘルスチェックはユーザーが開始したリクエストと同じサービスとキューを通過するため、過負荷が原因でリクエスト全体の時間が長引くと、ヘルスチェックもタイムアウトになる可能性があります。このような状況が発生すると、Envoy はこれらのサービスノードが再度ヘルスチェックに合格するまで、リクエストの転送を停止します。

*** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***

*** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***