1) 성능 및 부하 테스트가 필요한 이유
Proxy는 Forward Proxy, Reverse Proxy로 나뉘어 지는데, API Gateway는 Reverse Proxy입니다. Client로부터 받은 API 요청을 타겟이 되는 API 서버에 전달하고, API 서버로부터 받은 응답을 Client 에게 전달합니다.
API 요청은 HTTP를 통해 이뤄집니다. HTTP는 OSI 7 계층에서 7계층인 Application Layer에 해당하여, API Gateway를 L7 이라 부르기도 합니다.
HTTP 보안을 위해 암복호화 처리를 하게 되는데, 이때 SSL/TLS를 적용한 것이 바로 HTTPS 입니다. 브라우저에서는 URL 창에서 확인할 수 있습니다. 자물쇠가 걸려 있거나 ‘secure’ 문구가 있는 경우 HTTPS, 그렇지 않은 경우 HTTP 입니다. (참고로, 이제 웹 사용시 HTTPS는 필수로 여겨집니다.)
HTTPS는 Client가 Server에 TCP Handshake를 통해 TCP 연결을 맺고, SSL Handshake를 통해 SSL/TLS 연결을 맺는 과정이 필요합니다. 이 과정에서 CPU 연산이 많이 들어가기 때문에 Client 및 Server는 시스템 자원인 CPU를 많이 사용하게 됩니다.
Client가 API Gateway에 연결을 맺을 때 API Gateway는 Server 역할을 하지만, API Gateway가 API Server에 연결을 맺어야 할 때는 Client 역할을 하게 됩니다. 동시에 접속하는 사람(‘동접자’) 즉, Client가 많아지면, TCP 연결이 많아지고, SSL/TLS Handshake가 많아집니다. API Gateway는 HTTP 요청을 해석하고 어떤 API Server로 요청을 전달할지 판단합니다. API Gateway는 API Server에 TCP 연결과 SSL/TLS 연결을 맺어야 합니다. 이러한 과정에서 API Gateway는 시스템 자원인 CPU와 Memory를 많이 사용하게 됩니다.
API의 요청과 응답이 오고갈 때 출입문 역할을 하는 API Gateway는 bottle neck이 되지 않아야 합니다. 그렇기 때문에 API Gateway의 안정성과 성능은 상당히 중요합니다.
성능 및 부하 테스트가 필요한 이유는, ‘1명의 Client가 하나의 요청을 한번만 보내고 끝’ 이 아니기 때문입니다. 수많은 Client가 동시에 여러 요청을 보낼 수 있기 때문에, 서버는 이를 반드시 테스트하고 얼만큼 수용 가능한지 파악하고 있어야 사후 대응이 가능해집니다.
별 생각없이 서버프로그램을 개발한다면, 적은 부하에는 문제가 없겠지만, 어느 순간 Client가 받는 응답이 너무 느리다거나, 응답을 받지 못하는 일이 생길 수 있습니다. 다양한 Client로부터의 요청을 받아야 하는 서버라면 대량의 트래픽을 감당할 수 있도록 개발되어야 합니다.
•
참고로, 시스템 자원인 CPU와 Memory는 클라우드 환경에서 비용과 직결됩니다. AWS, Naver Cloud 등을 보더라도, 서버의 사양(시스템 자원)인 CPU, Memory 에 따라 비용 차이가 나는 것을 확인할 수 있습니다.
(계속) 테스트를 위해 준비해야할 것은..?
#API관리 #API게이트웨이 #API #GATEWAYAPIM #오픈API
#OPENAPI #API포털 #APIMANAGEMENT #API플랫폼 #API솔루션 #API마켓