DEV Community

Yilia for Apache APISIX

Posted on • Originally published at api7.ai

How to Determine Resources Needed for Your API Gateway?

Background

API gateway serves as a unified entry for a company's external services, underscoring its undeniable importance. Any disruptions in the availability of the API gateway itself directly impact all services provided by the company—a catastrophe that is unacceptable. Therefore, it is crucial to determine the appropriate deployment scale for the API gateway in the production scenarios.

Determining the resources needed is essential to ensure the performance, availability, and stability of the API gateway, optimizing resource utilization and cost-effectiveness. Inadequate resources may lead to issues such as request timeouts, congestion, and packet loss, affecting user experience and service quality. Conversely, excessive resources can result in resource waste, increased operational complexity, raising costs, and risks.

API gateway diagram

Therefore, determining the resources needed for the API gateway is a crucial step, requiring thoughtful planning and adjustments based on business requirements, traffic forecasts, and performance testing. This article, drawing on best practices of various industries, outlines a three-step process for reference:

  • Gateway Selection: Single-core QPS
  • Business Types: Financial or non-financial services
  • High Availability Requirements

Gateway Selection

The bottleneck for the API gateway's basic components usually lies in the CPU, not the network, disk, or memory. The single-core CPU processing of an API gateway significantly indicates whether it's excellent or not. When the resource consumption is lower for the same API request traffic, it implies fewer machines needed, simplifying operational management and enhancing service availability.

Apache APISIX, an open-source API gateway, conservatively estimates that a single-core CPU can support at least 10,000 QPS when common enterprise plugins for monitoring, rate limiting, etc., are enabled. Enterprises can conduct specific tests to collect results considering differences in enabled plugins, hardware environment, network conditions, and API request characteristics.

APISIX QPS 15000~18000

Business Types

Most non-financial enterprises can control CPU resource usage in API gateway in the range of 20-30% in a production environment, which is an ideal scenario. Even with a 3-5 times increase in service calls, they can handle it effectively. Industries like news, entertainment, and the internet can use this load.

However, for industries like banking, finance, and securities, where the API's value is high, maintaining a daily CPU load of 5-10% is ideal. This allows the API gateway to handle sudden traffic spikes 10-20 times higher than usual.

Requirements for High Availability

For higher requirements for availability, API gateway proxy instances should have a minimum of 2 nodes.

Practical Examples

User from the Financial Services Sector

Enterprise Example:

  • QPS for the daily API calls is 100,000
  • Daily load of API gateway is 10%
  • Gateway selection: Apache APISIX (Single-core QPS: 10,000)

Based on the above information, the required number of CPUs is 100,000 / 10,000 / 10% = 100. If using machines with 4 CPU cores, 25 machines are needed; with 8 CPU cores, 13 machines are needed.

User from the Non-Financial Services Sector

Enterprise Example:

  • QPS for the daily API calls is 100,000
  • Daily load of API gateway is 25%
  • Gateway selection: Apache APISIX (Single-core QPS: 10,000)

Based on the above information, the required number of CPUs is 100,000 / 10,000 / 25% = 40. If using machines with 4 CPU cores, 10 machines are needed; with 8 CPU cores, 5 machines are needed.

Conclusion

In practical usage, traffic is complex and variable, requiring flexible adjustments to averages. By adopting excellent API gateways like APISIX and judiciously configuring hardware resources, enterprises can better balance costs and service requirements, ensuring secure, stable, and efficient exposure of enterprise APIs to end-users.

Top comments (0)