CORCORS 캐쉬하기 - 성능과 비용 관련 정리된 내용을 소개합니다
해당 웹페이지에서는 아래와 같이 소개하고 있고요..
CORS is a necessity for many APIs, but basic configurations can create a huge number of extra requests, slowing down every browser API client, and sending unnecessary traffic to your backend.
CORS는 많은 API에 필요하지만 기본 구성은 엄청난 수의 추가 요청을 생성하여 모든 브라우저 API 클라이언트의 속도를 늦추고 불필요한 트래픽을 백엔드로 보낼 수 있다고 하네요..
This can be a problem with a traditional API, but becomes a much larger issue with serverless platforms, where your billing is often directly tied to the number of requests received, so this can easily double your API costs.
이는 기존 API에서 문제가 될 수 있지만 청구가 수신된 요청 수와 직접적으로 연결되는 서버리스 플랫폼에서는 훨씬 더 큰 문제가 되어 API 비용을 쉽게 두 배로 늘릴 수 있다고 하고요..
해당 주요 내용을 간단하게 정리하자면 아래와 같습니다.
CORS preflight 란 ?
- 복잡한 요청을 보내기 전에 OPTIONS로 권한을 있는지 먼저 요청하는 것
- 하지만 실제로는 대부분의 요청들이 이걸 필요로 함 (JSON/XML 바디가 있거나 크레덴셜을 포함하거나 등등 )
- 이게 나쁜 이유는 실제 요청에 걸리는 시간이 늘어난 다는 것
- OPTIONS 리퀘스트는 기본적으로 캐슁이 불가능해서, CDN들도 보통 처리하지 않아 요청이 서버까지 도달함
- 이 값들은 클라이언트에서 캐슁되며 기본적으로 5초만 유지됨.
- 즉 웹페이지가 API 폴링을 10초마다 한다면 preflight가 10초마다 한번씩 이루어짐
- 많은 경우 브라우저 클라이언트의 API 레이턴시를 증가시켜, 사용자 입장에서 성능이 절반으로 떨어짐
- 또한 API 서버에 쓸데없는 부담을 주고 비용을 증가 시킴
- 특히나 서버리스라면 더더욱. Lambda, Netlify Functions, Cloudflare Workers, Google Cloud Functions 모두 함수 호출당 비용을 받으므로, 이 preflight 도 그것에 포함됨
preflight 응답을 캐쉬하는 방법
- 브라우저에서 캐슁해서, 불필요한 동일 preflight 요청을 보내지 않게 만들기
- CDN 레이어에서 캐슁해서, 이 요청들을 실제 백엔드 서버가 처리할 필요없이 응답하도록 처리하기
CORS caching for browsers
- preflight 응답에 다음 헤더를 추가 Access-Control-Max-Age: 86400
- Firefox는 86400(24시간) 까지 가능하지만 크로미엄 기반 브라우저는 7200(2시간)이 최대 값
CORS caching for CDNs
- CDN 또는 프록시에서 캐슁하기 위해서 다음 헤더를 추가
Cache-Control: public, max-age=86400
Vary: origin - 중요한 건 OPTIONS는 기본적으로 캐슁하게 되어있지 않기 때문에 표준이 아니라는 것. 하지만 대부분의 CDN이 지원함
Configuration 예제
- Caching CORS with AWS Lambda
- Caching CORS in Node.js
- Caching CORS in Python
- Caching CORS with Java Spring
좀 더 자세한 내용은 아래웹페이지를 방문해 보시면 좋을것 같고요..
오늘의 블로그는 여기까지입니다.
항상믿고 봐주셔서 감사합니다.