티스토리 뷰
API 서버는 클라이언트로부터(웹 브라우저 또는 다른 서버) API 요청을 받고, 응답을 주어야 합니다. 클라이언트의 수가 점점 많아질수록, API 서버에 많은 요청(Request)이 전달되고, 클라이언트로 응답(Response)을 주어야 하므로 서버에 과부하가 발생합니다. 이번 포스팅에서는 API 서버에 과부하가 발생할 경우, API Gateway의 캐싱기능을 활용하여 API 서버의 과부하를 줄이는 방법에 대해 설명하겠습니다.
API Gateway 캐싱 원리
캐싱(Caching)이란, 컴퓨터의 저장소 중에 가장 접근시간이 빠른 저장소에 데이터를 저장하는 방법을 말합니다. 캐싱을 활용하면, 접근속도가 상대적으로 느린 보조기억장치(HDD, SDD)의 데이터를 검색하지 않고도 빠른 시간 내에 처리할 수 있습니다. API 캐싱을 알아보기 전에, 클라이언트로부터 API 요청 및 응답을 주는 과정은 아래 그림과 같습니다.
클라이언트는 웹 브라우저 또는 다른 서버가 될 수 있습니다. 여기서 API는 널리 알려져 있는 REST API 또는 HTTP API입니다. Request라 하면, HTTP의 호출 method 중 GET, POST, PUT, DELETE 중 하나라고 이해하시면 됩니다. API Gateway는 클라이언트로부터 API 요청을 제일 먼저 수신받아, 권한, 인증, 로드밸런싱, 리다이렉트 등 다양한 처리를 할 수 있는 인스턴스입니다. 여기서는 API 요청을 리다이렉트 하여 API 실행( 프로세스 또는 스레드를)을 담당합니다.
문제는 서버가 클라이언트로부터 많은 API 요청이 발생할 경우, 서버는 API 실행을 위해 프로세스 또는 쓰레드가 많이 실행되고, 서버의 리소스(CPU, RAM, Network)의 경합이 발생하고 서버의 처리속도는 느려지게 됩니다. 이러한 상황에서 API Gateway는 많은 기능 중 캐싱 기능을 통해 서버의 과부하가 발생하는 것을 막을 수 있습니다.
API 캐싱이란 API 실행을 담당하는 프로세스 또는 쓰레드의 실행 없이, 이전의 동일한 요청(Request)의 응답을 그대로 활용하여 클라이언트에게 즉시 응답하는 방법입니다. 동일한 Http Mehtod와 Parameter로 API를 요청할 경우, API 프로세스를 실행할 필요 없이, 캐싱된 응답을 그대로 클라이언트에 전송하여 API 처리량을 획기적으로 높이는 방법입니다. 아래 그림을 보시면, 클라이언트의 요청을 API Gateway 캐싱 인스턴스로 전달하여, 동일한 양식의 요청에 대한 응답을 한 적이 있는지 확인합니다. 만약 응답이 존재하면, Cache hit이 되어 클라이언트로 즉시 응답을 반환합니다.
만약, cache miss(캐시에 데이터가 없는 경우)가 발생하면, 정상적으로 API 실행을 과정이 진행됩니다. 클라이언트로 응답을 전송한 이후 또는 전송 이전에 API Gateway 캐싱 인스턴스로 응답을 저장하여 이후에 동일한 요청이 왔을 때 캐싱처리를 할 수 있도록 합니다.
AWS API Gateway 캐싱 기능 활성화하기
AWS에는 API Gateway 캐싱 기능을 지원합니다. 캐싱 기능을 활성화하려면, 아래 그림과 같이 API Gateway 메뉴에 진입하여 스테이지 설정을 클릭하신 후 Caching Settings에서 Enable API cache를 체크하시면 됩니다. 아래 그림 중 Cache time-to-live(TTL) 설정에 따라서 캐시 데이터의 유효 시간을 지정할 수 있습니다. TTL은 초단위로 설정가능 합니다. TTL을 60초로 설정하였다면 1시 1분에 "GET /test API"를 호출하여 "success 1시 1분"이라는 응답을 받았다면, 1시 2분이 되기 전까지는 "GET /test API"요청은 "success 1시 1분"으로 응답이 가고, 1시 2분 이후로부터는 "success 1시 2분"이라는 응답이 전송됩니다.
스테이지 설정에서 API캐싱은 GET 메소드에 대해서 활성화되고, 다른 POST, PUT, DELETE 메소드도 캐싱을 하고 싶다면, 메소스 설정 재정의 메뉴에서 진행하실 수 있습니다. GET 메소드 실행 시, Query String Pamameter 중 특정 인자 값 단위로 캐싱을 지정하고 싶다면, 아래와 같이 파라미터를 추가한 후 Caching을 활성화하여 cache key를 지정할 수 있습니다.
캐싱 기능 사용 시 주의사항
캐싱 기능은 TTL 설정 값만큼 동일 요청에 대해서는 최초 한번 응답한 결과를 재활용하는 방법이므로, API가 실행되어 갱신된 데이터를 조회해야 하는 경우에는 캐싱된 데이터로 인해 사용자에게 실시간 결과를 전송해주지 못하여 혼란을 야기시킬 수 있습니다. 만약, 실시간 성이 보장되어야 하는 API 서버의 경우에 과부하를 주지 않고 응답시간을 줄이고자 한다면 서버의 scale up, scale out을 통해 서버의 처리량을 늘려야 합니다. 그렇다면, API Gateway 캐싱은 언제 사용해야 좋을까요? 캐싱 기능은 주기적으로 갱신되는 데이터를 조회하는 API에 적용하면 좋습니다. 배치에 의해 데이터가 갱신되기 전에는 항상 동일한 응답을 갖기 때문에, 이 때는 캐싱을 활용하는 것이 좋습니다.
'IT 기술' 카테고리의 다른 글
[Selenium] 동적 페이지에서 iframe 내부 Tag 찾는 방법 (2) | 2023.02.20 |
---|---|
Python, Selenium 기반 웹 자동화 테스트 구현하기 (0) | 2023.02.20 |
[Node.js] Promise.all을 활용한 비동기 코드 작성법 (0) | 2022.09.16 |
[Node.js] Promise, Await, Async로 동기, 비동기 작성하기 (0) | 2022.09.16 |
디자인 패턴 - 책임 연쇄(Chain of Responsibility) (0) | 2022.09.16 |
- Total
- Today
- Yesterday
- 디자인패턴
- 테스팅 자동화
- 스프링부트빌드
- codesmell 유형
- springboot rest api 서버
- 코드스멜 유형
- springboot 실행
- iframe 태그 찾기
- 스프링부트 restapi
- 디자인패턴 구조패턴
- springboot build
- 스프링부트실행
- oracle 메모리
- oracle pga sga
- MPA
- selenium
- notion 업무일정관리
- notion
- token
- TCP/UDP
- python
- springboot restapi
- C++
- 클린코드작성원칙
- SPA
- 멀티코어 멀티프로세서
- AWS
- 클린코드작성법
- API Gateway 캐싱
- OSI 7계층
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |