Build-up
AWS S3, CloudFront 개발 비용 부담 줄이기
s3 버킷 비용을 localstack으로 무료로 개발할 수 있도록 환경을 구성했지만 실제 배포 환경에서는 s3가 아닌 cloudFront를 사용하고 있다. cloudFront와 유사한 환경을 가져가기 위해 localstack으로 설정할 수 있지만 cloudFront는 Pro비용을 지불해야 사용할 수 있기 때문에.. 비용적 부담이 생긴다. 이와 비슷한 환경을 제공하기 위해 nginx를 reveseProxy로 구성하고 컨텐츠를 릴레이 하려고 한다.
개발 환경 아키텍처 완성 [nginx를 통한 콘텐츠 릴레이 + 캐싱]
특정 콘텐츠 파일에 대한 uri들을 localstack으로 릴레이하여 컨텐츠의 재 요청을 cache로 방지할 수 있게 되었다.
그리고 특정 파일에 대한 컨텐츠 변경에 대해서는 이미 콘텐츠를 수정할때 기존에 있던 컨텐츠를 지우고 재 업로드하기 때문에 캐시에 남아 있는 경우는 없도록 반영하였다.
worker_processes 1; error_log /var/log/nginx/error.log debug; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; charset utf-8; client_body_buffer_size 16k; client_header_buffer_size 8k; client_max_body_size 0; large_client_header_buffers 4 8k; client_header_timeout 5s; client_body_timeout 5s; send_timeout 240s; resolver_timeout 5s; gzip on; gzip_comp_level 9; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/json application/javascript application/x-javascript text/xml text/css application/xml; server_tokens off; proxy_headers_hash_bucket_size 128; upstream comeus { server host.docker.internal:8080; } upstream aws { server host.docker.internal:4566; } server { listen 80; server_name localhost; charset utf-8; location /thumbnail { add_header Content-Type 'octet-stream'; # 없어도 됨 (컨텐츠 유형을 정확히 안다면) proxy_pass http://aws/come-us-local/product$uri; # aws/${s3_bucket_name}/${domain_suffix}/${s3에 저장된 파일이름} } location / { proxy_pass http://comeus; } } }
octetstream으로 렌더링한 이유
Nginx가 콘텐츠의 정확한 MIME 유형을 결정할 수 없기 때문이다.
MIME 유형은 전송되는 데이터 유형을 식별하고 브라우저가 콘텐츠를 처리하는 방법을 해석하는 데 사용된다. Nginx는 "Content-Type" 헤더에 지정된 MIME 유형을 사용하여 전송되는 데이터 유형을 식별한다.
그러나 경우에 따라 "Content-Type" 헤더가 설정되지 않거나 잘못 설정될 수 가능성이 있을수 있다. 이러한 경우를 대비하여 공통 일반 MIME 유형인 "octet-stream"으로 콘텐츠를 전송하도록 구성하였다.
postman 요청으로 확인해보면 이상한 문자들이 가득할 것이다.
하지만 브라우저는 각 파일 청크들을 조립하여 어떤 컨텐츠인지 로드하기 떄문에 잘 조립하여 컨텐를 볼 수 있으니 걱정할 필요가 없다.
Nginx Content Caching 적용
CloudFront는 콘텐츠의 캐싱 기능 또한 적용할 수 있다. Nginx로 콘텐츠를 릴레이 하는 만큼 Nginx 또한 캐싱기능을 제공하므로 서버 대역폭 및 클라이언트 로딩시간을 줄이기위해 적용할 것이다.
location/thumbnail { proxy_cache_methods GET; proxy_buffering off; proxy_max_temp_file_size0; add_headerContent-Type 'octet-stream'; add_headerCache-Control max-age=3600; #캐싱 시간 add_headerX-Proxy-Cache $upstream_cache_status; proxy_cache_bypass $http_cache_control; #캐싱 변수 proxy_pass http://aws/come-us-local/product$uri; }
결과
304코드는 Not Modified 로 요청된 리소스를 재전송할 필요가 없음을 나타낸다.
실제로 Nginx 내부에서 캐싱 되어서 304가 리턴되는 것을 확인할 수 있다. 그러므로 S3 버킷에 다시 요청하지 않는다!
