nginx와 docker-compose로 s3 cache proxy를 구축해봅니다.
포스팅에선 Presigned URL을 Nginx에 넘겨서 S3 리소스를 가져오는 내용을 다룹니다.
모든 소스코드는 아래에 있습니다.
먼저 pre-signed URL을 생성해야합니다.
아래 문서를 참고하여 pre-signed URL을 생성합니다.
다음으로 nginx를 실행시키는 docker-compose를 작성해줍니다.
docker-compose.yml
nginx 설정을 작성해줍니다.
nginx.conf
8번 라인의 proxy_cache_path 는 캐시 설정에 대한 정보를 넣어줍니다.
각 필드가 가지는 의미는 아래와 같습니다.
level
level 필드는 아래 문서에 따르면
Having a large number of files in a single directory can slow down file access, so we recommend a two‑level directory hierarchy for most deployments. If the levels parameter is not included, NGINX puts all files in the same directory.==> 싱글 디렉토리에 캐시 파일을 모두 담는건 파일 엑세스를 느리게함. 그러니 레벨 설정을 따로해라
라고합니다. 공식문서에서 시키는대로 설정해줍니다.
keys_zone
캐시에 접근하기 위한 key 값의 저장용량을 설정합니다
A 1‑MB zone can store data for about 8,000 keys, so the 10‑MB zone configured in the example can store data for about 80,000 keys.10m로 잡아서 최대 80,000개의 key를 저장하도록 합니다.
max_size
이름 그대로 cache의 총량입니다. 500mb로 설정합니다.
inactive
캐시가 활성화되지 않을 때 삭제 시간을 설정합니다. 60분으로 지정했으며, 60분동안 캐시가 히트되지 않으면 제거됩니다.
11번 라인에는 버킷 이름을 적어줍니다.
35번 라인은 캐시의 검증 주기를 설정합니다. 200, 304 코드를 반환한 응답에 대해서 1분 주기로 캐시를 검증합니다.
이제 Nginx에서는 캐시에 대한 정보를 X-cache-status 라는 헤더값에 담아 보내주게됩니다. 아래는 값에 대한 설명입니다.
이제 nginx를 실행시켜봅시다.
docker-compose up위에서 얻은 presigned URL을 아래에 대입해봅니다.
curl --location --request GET 'http://127.0.0.1/s3/proxy/<presigendUrl>'
최초에는 캐시가 없으므로 아래와 같이 응답헤더 X-cache-Status가 MISS로 반환됩니다.
다시 한번 호출해보면 HIT 로 나오는걸 알 수 있습니다.
이번엔 header if-None-Match 에 S3의 파일 해시값인 Etag를 추가해서 보내봅니다.
curl --location --request GET 'http://127.0.0.1/s3/proxy/<presigendUrl>--header 'If-None-Match: "638aa3721542490105f99daf75a15483"'
예상한대로 304 반환값과 X-cache-Status 가 HIT 인걸 확인할 수 있습니다.
이번엔 1분뒤 다시 요청해봅니다.
캐시 검증이 진행되고 Etag가 변경되지 않았으므로 캐시가 유지되면서 X-cache-Status는 REVALIDATED 가 반환됩니다.
이번엔 S3에 전혀 다른 파일을 덮어쓰고, 1분뒤 요청합니다.
파일이 달라졌으므로 Etag가 바뀌고, X-cache-Status 가 EXPIRED인걸 확인할 수 있습니다.
감사합니다.
