API를 게이트웨이로 HAProxy 사용하여, 제 1 부 [소개]

전송 : https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-1/

하여 API 게이트웨이로드 밸런싱, 보안, 속도 제한, 모니터링 및 API 서비스를위한 다른 교차 절단 문제를 처리한다. HAProxy 기업은 API 게이트웨이로 탁월한 방법을 배우고 읽기.

"위험! 눈사태 지역 "는 콜로라도의 일부를 드라이브 할 때 볼 표시이다. 겨울에 주변의 산들을 보면, 당신은 당신이 어떤 순간에 눈이 서지을 부어 수있는 거인을 자고로 들어온다있는 느낌을 얻을. 그것이 이젠 그만이 아니었던 경우에, 당신이 묻힐 것 인 경우처럼 보일 수있다 그런 장소를 혼자 운전, 누구도 알아?

의 IT 운영자 등의 작업에서, 현대의 IT 시스템을 관리의 무게는 당신에게 같은 불안 느낌을 줄 수 있습니다. 인프라에 구축 복잡성은 눈이 산에 형성 같다. 당신이 묻혀 있다면 사람들이 알기도 전에, 얼마나 걸립니까? 당신은 어디든지 당신이 할 수있는 복잡성을 오프로드 할 수있어!

우리가 여기서 해결거야 복잡성의 구체적인 형태는 외부 세계에 내부 microservices을 연결하는 것입니다. 이러한 인증과 같은 내부 기능, 고객의 데이터를 검색하는 제품 세부 정보를 가져 오는, 및 지불을 복용하여 프론트 엔드 클라이언트에 노출되어야합니다. 이것은 이들 기능 서명 표현 정의 애플리케이션 프로그래밍 인터페이스 (API)에 의해 수행된다.

문제는 클라이언트가 백엔드 API를 직접 연결할 수있는 것은 관리 및 확장하기 어려운 프론트 엔드 및 백엔드 구성 요소 간의 긴밀한 결합을 생성하는 것입니다. 방법은 이것을 처리, 심지어는 외부 클라이언트가 API에 액세스하는 방식을 통합하는 것입니다 무엇을 부르고있는 사람을 몇 가지 관찰을 얻을 수 있습니다. 단일, 통합 URL 뒤에 서로 다른 API를 결합하는 것은 API 게이트웨이의 범위이다. 이러한 방법으로, 클라이언트는 게이트웨이에 대한 단일 참조를 유지할 수 있습니다 그것은 바로 이곳 노선을 것이다. 또한 인터넷에 노출 될 필요가 작은 영역을 얻는다.

오픈 소스 API 게이트웨이

하는 API 게이트웨이는 라우팅 요청을 지능적으로 클라이언트와 백엔드 서비스 사이의 소프트웨어 계층입니다. HAProxy, 세계에서 가장 빠르고 가장 널리 사용되는 소프트웨어로드 밸런서는 매우 잘 API 게이트웨이와 같은 역할을 채 웁니다. 에 대한 API 호출을 라우팅하는 것 외에도  / 카트  또는  / 카탈로그  적절한 백엔드 서비스에, 그것도로드 밸런싱, 보안, 속도 제한, 모니터링 및 기타 크로스 커팅 문제를 처리합니다. 본질적으로, 공유 HAProxy 예를 뒤에 모든 API를 배치하여, 이러한 요구는 오프로드 할 수 있습니다.

API 게이트웨이는 프론트 엔드 코드와 백엔드 API 엔드 포인트가 밀접하게 결합되지 않도록 요청을 전달 오케스트레이션 층이된다. 모든 디바이스는 단일 도메인을 가리킬 수 있습니다 및 HAProxy는 라우팅을 처리합니다.

 

Due to its speed, high availability and reliability, HAProxy can be used as a API gateway

 

Here are some of the functions that an HAProxy API gateway will handle for you:

• High Performance
• Load balancing
• HTTP routing
• Security
• Rate limiting
• Observability
• Connection queuing
• Circuit-breaking
• Authentication
• Device Detection

Let’s explore some of these features in more detail.

HTTP Routing

The primary role of the API gateway is to route an incoming client request to the appropriate internal service. HAProxy can route based on any information found in the HTTP request, including portions of the URL path, query string, and HTTP headers.

In the following example, our HAProxy configuration sets up a frontend that accepts incoming requests on port 443, checks their URL paths for /cart and /catalog, and then forwards them to the correct backend.

	frontend api_gateway
	bind :443 ssl crt /etc/hapee-1.8/certs/cert.pem
	acl PATH_cart path_beg -i /cart
	acl PATH_catalog path_beg -i /catalog
	use_backend be_cart if PATH_cart
	use_backend be_catalog if PATH_catalog
	backend be_cart
	server s1 10.0.0.3:80
	backend be_catalog
	server s1 10.0.0.5:80

If you are managing multiple website domains, then you can check the Host header when determining how to route requests. Here’s an example that will segregate API requests depending on the domain. When accessing, for example, api.haproxy.com, it will only route requests for /catalog and /cart. B2B partners that access partner.haproxy.com can access the /inventory API.

	frontend api_gateway
	bind :443 ssl crt /etc/hapee-1.8/certs/cert.pem
	acl VHOST_publicapi req.hdr(Host) -i -m dom api.haproxy.com api.haproxy.fr
	acl VHOST_partnersapi req.hdr(Host) -i -m dom partner.haproxy.com partner.haproxy.fr
	acl PATH_catalog path_beg -i /catalog
	acl PATH_cart path_beg -i /cart
	acl PATH_inventory path_beg -i /inventory
	use_backend be_cart if VHOST_publicapi PATH_cart
	use_backend be_catalog if VHOST_publicapi PATH_catalog
	use_backend be_inventory if VHOST_partnersapi PATH_inventory
	backend be_cart
	server s1 10.0.0.3:80
	backend be_catalog
	server s1 10.0.0.5:80
	backend be_inventory
	server s1 10.0.0.7

Note that HAProxy is extremely flexible and powerful and the examples provided are just simple use cases. HAProxy can apply more complex logic for HTTP routing and request handling.

 

If an application requires tens, hundreds, or even thousands of paths in a single ACL, then it is better to manage them through a map file. A map file stores key/value associations in memory. In our example, the key would be the “host/path” string and the value would be the name of the backend to route the request to. The map file routing.map would contain:

	# endpoint backend name
	api.haproxy.com/catalog/ be_catalog
	api.haproxy.fr/catalog/ be_catalog
	api.haproxy.com/cart/ be_cart
	api.haproxy.fr/cart/ be_cart
	partner.haproxy.com/inventory/ be_inventory
	partner.haproxy.fr/inventory/ be_inventory

Our HAProxy configuration would contain:

	frontend api_gateway
	# …
	use_backend %[base,map_beg(“/etc/hapee-1.8/routing.map”)]

 

DID YOU KNOW?The  base fetch method returns the concatenation of the Host header and the path part of the request, which starts at the first slash and ends before the question mark.

To simplify the process of adding or removing path-to-backend associations, you can enable the HAProxy Enterprise “lb-update” module. This module can read the contents of the map file and refresh the ACLs during runtime, without the need to reload HAProxy.

Load Balancing

 

With HAProxy, the load balancing algorithm can be adjusted to suit the type of service and protocol

 

In order to improve the performance and resilience of each API endpoint, it’s recommended to replicate the service over several nodes. Then, the API gateway will balance incoming client requests among them. You can adjust the load balancing algorithm to suit the type of service and protocol.

• For quick and short API calls, use the roundrobin algorithm
• For longer-lived websockets, use the leastconn algorithm
• For services that have backend servers optimized to process particular functions, use the uri algorithm

In the following example, the mobile API backend is balanced across two nodes using the roundrobin algorithm.

	backend mobile_api
	balance roundrobin
	server s1 10.0.0.3:80
	server s2 10.0.0.4:80

Load balancing your API endpoints improves performance and creates redundancy. Note that you can choose the most appropriate balancing algorithm on a per-backend basis.

 

You can also define active and passive health checks for your servers so that HAProxy automatically reroutes traffic if there’s a problem. In the following example, we monitor the health of our servers by sending GET requests to the /health URL and expecting a successful response.

	backend mobile_api
	balance roundrobin
	option httpchk GET /health
	server s1 10.0.0.3:80 check
	server s2 10.0.0.4:80 check

The option httpchk directive sets the method and URL to monitor. If you append \r\nyou can add additional HTTP headers to this request. A check parameter is added to each server to enable the feature. Being able to watch a URL endpoint works well with tools like Prometheus that already expose a /metrics web page used for scraping metrics.

 

HAProxy maxconn

The HAProxy load balancer stands in a strategic position, between your clients and services, ensuring that no backend nodes are saturated by spikes in traffic. Without this, all requests would be forwarded to the backend servers, risking high wait times and timeouts.

HAProxy implements queuing mechanisms to prevent sending too many requests at once to a service. Add the maxconn argument to a server directive to queue additional requests within the gateway, as shown:

	backend mobile_api
	balance roundrobin
	server s1 10.0.0.3:80 maxconn 100
	server s2 10.0.0.4:80 maxconn 100

In this case, up to 100 connections can be established at once to a server. Any more than that will be queued. This relieves strain on your servers, allowing them to process requests more efficiently. HAProxy is highly proficient at managing queues of this sort.

 

Rate Limiting

 

HAProxy’s Stick Tables can be used to limit the number of requests sent to the API by one client

 

You may want to limit the number of requests a client can send to your APIs within a period of time. This might be a to enforce a quota for various tiers of customers. To be allowed to send more requests, clients could subscribe to a higher-priced tier.

In HAProxy, stick tables can be used for such a purpose. You can track clients by IP address, cookie or other means such as API tokens passed in the URL or headers. In this example, the client is expected to pass a URL parameter called apitoken and is limited to 1000 requests within 24 hours. The period is set with the expire parameter on the stick-table directive.

	frontend api_gateway
	bind :443 ssl crt /etc/hapee-1.8/certs/cert.pem
	stick-table type string size 1m expire 24h store http_req_cnt
	acl exceeds_limit url_param(apitoken),table_http_req_cnt(api_gateway) gt 1000
	http-request track-sc0 url_param(apitoken) unless exceeds_limit
	http-request deny deny_status 429 if exceeds_limit

Now, as I make requests to the site, passing the URL parameter, apitoken=abcdefg, the count of HTTP requests is incremented. I can see this by logging into the server via SSH and querying the Runtime API. In the following example, I’ve made 12 requests using my API token.

 

	root@server1:~$ echo "show table api_gateway" | socat UNIX-CONNECT:/var/run/haproxy.sock stdio
	# table: api_gateway, type: string, size:1048576, used:1
	0x55bd73392fa4: key=abcdefg use=0 exp=86396974 http_req_cnt=12

When clients go past their limit, they’ll receive a 429 Too Many Requests response. Check out our blog post Introduction to HAProxy Stick Tables for more information about defining stick tables and other examples of rate limiting.

DID YOU KNOW?Adding  deny_status to the  http-request deny directive allows you to set a custom response code when rejecting requests. Possible values are 200, 400, 403, 405, 408, 425, 429, 500, 502, 503, 504

Optionally, instead of a daily limit as used above, you can also do it based on the rate of the requests. This acts as a security feature to prevent abuse or clients with runaway processes. The following example allows a client to make no more than one request per second.
(Note: While the above and below are separate examples they could also be combined to provide extra control)

Detailed monitoring and statistics

HAProxy is very famous for the level of details it provides on the traffic it processes. There are two main features: the statistic dashboard and the logs.

Statistics Dashboard

You can enable an HTML statistics page within HAProxy and HAProxy Enterprise, which comes as a set of tabular data with many metrics for each frontend, backend, backend server and frontend bind line. The image below shows an example of the HAProxy Enterprise Real Time dashboard:

 

HAProxy’s Real-Time Dashboard

 

This data is also available by querying the HAProxy Runtime API. JSON (within the Runtime API) and CSV (within both the dashboard and the Runtime API) are also available for easy integration with third party tools like Prometheus, Grafana, and SNMP. The image below shows an integration of HAProxy with Grafana, via the Prometheus exporter:

 

Integration of HAProxy with Grafana, via the Prometheus exporter

 

Logs

The HAProxy logs are a gold mine of information, since HAProxy can report the following information for each API call:

• Client IP, port
• Routing within HAProxy: frontend, backend, server
• URL endpoint with query string
• Timers: time for the client to send the request, server connection time, response time, total session duration, etc…
• Termination status: did the session finished properly or not, if not what happened and at what phase of the session (connection time, header time, data streaming time, etc…)
• Any custom header or cookie you want to capture
• Any SSL / TLS information

Based on all the information provided above, it is possible to build reports and to figure out when and where problems are occurring (e.g. Is it networking? The application? A particular server?).

 

Conclusion

이 글에서, API 게이트웨이가 무엇인지하고 외부 클라이언트 연결 microservices을 단순화하는 방법을 배웠습니다. 관리 라우팅,로드 밸런싱, 속도 제한 및 기타 복잡한 : 당신은 또한로드 밸런서는 API 게이트웨이로 작동하는 방법 HAProxy 보았다.