NGINX를 Object Storage Gateway로 사용
실수로 CDN 대신 Amazon S3와 같은 Object Store에 파일에 대한 링크를 게시하고 그것이 소문이 나는 것을 본 적이 있습니까? 클라우드 서비스 요금이 너무 많이 나왔거나 클라우드 공급자가 액세스를 차단한 것에 놀랐습니까? 만약 그렇다면 이 포스트는 당신을 위한 것입니다. NGINX를 Caching Gateway로 사용하여 Private S3 Bucket을 전면에 배치하여 Private Bucket과 Public Internet 사이에 보호 Layer을 배치하는 방법을 설명합니다. 두 가지 이점이 있습니다. NGINX는 Object Store에 대한 요청을 Cache하고 해당 콘텐츠의 공개 검색을 방지합니다.
목차
1. Amazon S3 및 호환 가능한 Storage 제품 정보
2. 사용 사례
2-1. Caching
2-2. 보안 제어
2-3. 내부 애플리케이션에 대한 액세스
2-4. 압축 및 콘텐츠 최적화
2-5. 보안
2-6. 애플리케이션 Gateway
3. Docker에서 Gateway 구성 및 실행
3-1. NGINX Plus Gateway Docker 이미지 Build
3-2. NGINX 구성 파일 생성
3-3. Gateway 시작하기
3-4. Gateway 사용자 정의
3-5. 요약
1. Amazon S3 및 호환 가능한 Storage 제품 정보
Amazon S3 API는 Object Storage 시스템의 사실상의 표준 인터페이스가 되었으며, Backblaze, Digital Ocean, Google Storage, Minio, NetApp, Nutanix, Tencent Cloud, VMware, Wasabi 등 많은 공급업체가 호환 가능한 storage 제품을 제공하고 있다. S3 API에 대한 광범위한 지원에도 불구하고 특정 S3 API 구현은 대용량 공용 인터넷 트래픽 처리와 같은 non‑storage 작업에 적합하지 않은 경우가 많습니다. 이와 같이 S3 API 앞에 있는 Layer가 Storage 인터페이스를 다른 애플리케이션 또는 사용자별 인터페이스로 연결할 필요가 있습니다. NGINX는 이 bridge 역할을 할 수 있으며 모듈 생태계와 구성 가능성 때문에 추가적인 가치를 제공할 수 있습니다.
이 포스트에서는 GitHub에서 호스팅되는 완벽하게 작동하는 Docker 기반 구현을 탐색하여 NGINX 오픈소스 및 NGINX Plus를 S3 호환 object store에 대한 read‑only Gateway로 구성하는 방법을 보여줍니다. S3 호환 서비스의 Gateway이로 NGINX만 다루지만 AWS API Request Signing을 사용하는 모든 서비스로 접근 방식을 확장할 수 있습니다.
2. 사용 사례
“내 Object Store는 이미 대규모로 파일을 제공하는데 내가 왜 그 앞에 다른 Layer을 더 놓으려고 하겠어?”라고 당신은 궁금해 할 수도 있습니다.
S3와 같은 Object Store는 Object를 저장하고 검색하는 한 가지 일을 잘 합니다. 반면에 NGINX는 Basic Object Storage Gateway 위에 추가 기능을 제공하는 고도로 구성 가능한 Reverse Proxy입니다. 따라서 다음과 같은 다양한 사용 사례에 적합한 솔루션이 될 수 있습니다.
2-1. Caching
Object Storage 시스템은 방대한 양의 데이터를 저장하도록 설계되었으며 동일한 개체(예: 파일 또는 binary 데이터)를 반복적으로 검색하도록 최적화되지 않았습니다. 일반적으로 불필요한 읽기 작업을 방지하기 위해 Object Store 앞에 Caching Layer를 두는 것이 모범 사례로 간주됩니다. NGINX를 Cache로 사용하면 Object 전달 지연 시간이 단축되고 운영 중단으로부터 보호되며 사용 비용이 절감됩니다.
2-2. 보안 제어
S3에는 자체 인증 및 policy‑based access 시스템이 있지만 특정 인증 요구 사항을 수용할 필요는 없습니다. NGINX는 다양한 보안 제어를 지원하므로 Gateway로서 이러한 요구를 충족하는 인증 및 액세스 제어를 제공할 수 있습니다. Secure Link 모듈을 사용하여 서명된 링크를 만들 수도 있습니다!
2-3. 내부 애플리케이션에 대한 액세스
AWS 서명 기반 인증을 구현하는 것은 까다롭습니다. 많은 애플리케이션과 플랫폼에는 S3와 쉽게 통신할 수 있는 클라이언트 라이브러리가 없습니다. NGINX를 S3에 액세스하는 내부 서비스의 Gateway로 사용하면 이러한 애플리케이션이 AWS 서명을 생성하지 않고도 S3 리소스에 쉽게 액세스할 수 있습니다.
2-4. 압축 및 콘텐츠 최적화
Storage 비용을 절약하기 위해 Object Store의 데이터를 압축하고 압축을 지원하지 않는 클라이언트에게는 콘텐츠를 제공할 수 있습니다. 이 경우 데이터를 전송하기 전에 실시간으로 압축을 풀도록 NGINX를 구성할 수 있습니다.
또는 압축되지 않은 상태로 Object Store에 콘텐츠를 저장하고 전송 전에 데이터를 압축하여 전송 시간을 줄이려는 경우가 있습니다. 이 경우 최종 사용자에 대한 전송 시간을 줄이기 위해 내장된 Gzip 모듈 또는 Brotli 동적 모듈을 구성합니다.
NGINX는 또한 GIF, JPEG 및 PNG 이미지를 변환하기 위한 Image-Filter 동적 모듈과 같은 콘텐츠에 대한 다른 유형의 실시간 수정과 웹 성능 모범 사례를 페이지 및 관련 페이지에 자동으로 적용하여 페이지 로드 시간을 줄이는 PageSpeed와 같은 도구를 지원합니다.
2-5. 보안
NGINX를 사용하면 S3 API 앞에 또 다른 보안 Layer을 구축할 수 있습니다. 예를 들어 과도한 다운로드 요청을 하는 사용자의 속도를 제한하고 bucket 내에서 액세스할 수 있는 object 경로를 제한할 수 있습니다. NGINX App Protect WAF 와 같은 통합 웹 애플리케이션 방화벽(WAF)으로 S3 API를 추가로 보호할 수 있습니다.
2-6. 애플리케이션 Gateway
사이트에서 콘텐츠를 제공할 때 보안, Branding, 일관성 및 이식성 요구 사항을 충족하기 위해 모든 리소스에 대해 동일한 도메인 이름을 사용하는 것이 일반적입니다. 따라서 동일한 호스트에서 정적 콘텐츠와 동적 콘텐츠를 함께 제공하는 것이 일반적인 요구 사항입니다. S3 API Gateway 역할을 하는 Object Store의 정적 파일을 제공하는 동안 NGINX는 애플리케이션 서버에서 시작되는 동적 콘텐츠에 대한 요청을 Proxy하고 Load Balance할 수도 있습니다.
3. 기능 및 제한 사항
이 포스트에서 설명하는 NGINX S3 Gateway 구현에는 다음과 같은 기능과 제한 사항이 있습니다.
- AWS Signature Version 2 and Version 4 지원
- GET 및 HEAD 요청만 지원
- NGINX 오픈 소스 및 NGINX Plus 지원
- Single Bucket 지원
- 1시간 동안 콘텐츠 Cache를 지원
- SSL/TLS로 구성되지 않음
- 기본적으로 설치된 WAF가 없습니다.
- 압축(예: Gzip 또는 Brotli)은 기본적으로 사용하도록 설정되어 있지 않습니다.
- Proxy Buffering 설정이 기본값으로 설정되어 있습니다(Workload 및 Object Size에 따라 이러한 설정을 수정할 수 있습니다).
3. Docker에서 Gateway 구성 및 실행
NGINX 오픈소스와 NGINX Plus를 모두 S3 또는 호환 가능한 Object Store의 Gateway로 사용할 수 있습니다.
NGINX 오픈소스를 사용하려면 Docker Hub의 공식 NGINX 이미지와 GitHub에서 제공하는 Dockerfile로 시작하십시오. NGINX 구성 파일 생성을 진행합니다.
NGINX Plus를 S3 API Gateway로 사용하면 다음과 같은 몇 가지 이점이 있습니다.
- NGINX Plus API를 사용한 Upstream의 동적 DNS 확인 – S3 API 도메인이 백 IP 주소를 변경할 때마다 NGINX는 새 주소를 사용하도록 자동으로 재구성합니다. 이 기능은 Amazon S3 및 기타 S3 호환 API가 load balancer를 추가하거나 제거하여 시스템을 더 잘 확장하기 때문에 중요합니다. DNS 변경 후 upstream에 대한 NGINX 구성을 reload하지 않으면 모든 백업 IP 주소 레코드가 더 이상 유효하지 않으면 서비스가 중단될 수 있습니다.
- Key‑Value Store를 사용하여 시간 및 리소스 소비 감소 – AWS 버전 4 인증 서명을 생성할 때 암호화 서명(서명 키)의 일부가 유효하고 최대 24시간 동안 cache될 수 있습니다. 서명의 부분을 Key‑Value Store에 저장하면 인증 요청을 계산하는 데 필요한 전체 시간과 CPU 리소스가 줄어듭니다. 이는 요청이 많은 사용 사례에 대한 유용한 성능 향상 기능입니다.
NGINX Plus 자격 증명을 통합해야 하기 때문에 NGINX Plus용 Docker 이미지 배포하지 않습니다. 다음 섹션의 지침에 따라 제공된 Dockerfile로 NGINX Plus Docker 이미지를 build하십시오. 여기에는 NGINX Plus binary를 다운로드하기 위한 설정이 포함됩니다.
3-1. NGINX Plus Gateway Docker 이미지 Build
1. NGINX Plus Docker 이미지를 build하려면 다음 단계를 수행하십시오.
GitHub Repo에서 NGINX S3 Gateway 프로젝트를 clone합니다.
git clone https://github.com/nginxinc/nginx-s3-gateway.git
2. nginx-s3-gateway 디렉터리로 이동합니다.
cd nginx-s3-gateway
3. NGINX Plus 인증서와 키(nginx-repo.crt 및 nginx-repo.key)를 plus/etc/ssl/nginx 하위 디렉터리에 복사합니다.
4. 컨테이너 이미지를 build합니다. Docker BuildKit을 사용하면 데이터를 노출하거나 Docker build layer 간에 데이터가 남아있을 위험 없이 NGINX Plus 라이선스 파일을 Docker build context에 전달할 수 있으므로 Docker BuildKit을 사용하는 것이 좋습니다.
- BuildKit을 사용하여 build하려면 다음 명령을 실행합니다.
DOCKER_BUILDKIT=1 docker build -f Dockerfile.buildkit.plus -t nginx-plus-s3-gateway --secret id=nginx-crt,src=plus/etc/ssl/nginx/nginx-repo.crt --secret id=nginx-key,src=plus/etc/ssl/nginx/nginx-repo.key --squash .
- BuildKit 없이 build하려면 다음 명령을 실행합니다.
docker build -f Dockerfile.plus -t nginx-plus-s3-gateway .
5. NGINX 구성 파일 만들기를 계속 합니다.
3-2. NGINX 구성 파일 생성
Gateway(NGINX 오픈 소스 또는 NGINX Plus) 실행을 시작하려면 먼저 NGINX를 S3 API upstream과 연결하기 위한 설정으로 구성 파일을 생성해야 합니다. GitHub repository에서 샘플 구성 파일을 찾을 수 있습니다. 다른 S3 API backend에 대한 몇 가지 샘플 구성을 살펴보겠습니다.
Amazon S3
다음은 Amazon S3를 backend로 사용하기 위한 구성입니다. AWS에서 Version 2를 더 이상 사용하지 않기 때문에 AWS Signature Version 4를 사용하고 있습니다.
S3_BUCKET_NAME=my-bucket-name
S3_ACCESS_KEY_ID=PUBLICACCESSKEY4TEXT
S3_SECRET_KEY=ProtectThisPrivateKeyBecauseItIsASecret!
S3_SERVER=s3-us-west-2.amazonaws.com
S3_SERVER_PORT=443
S3_SERVER_PROTO=https
S3_REGION=us-west-2
AWS_SIGS_VERSION=4
ALLOW_DIRECTORY_LIST=trueWasabi
다음은 Wasabi를 S3 호환 backend로 사용하기 위한 구성입니다. 여기에서는 Wasabi가 해당 인증 방법에 대한 지원을 유지하고 있으며 일반적으로 성능이 더 우수하기 때문에 AWS Signature Version 2를 사용하고 있습니다.
S3_BUCKET_NAME=my-bucket-name
S3_ACCESS_KEY_ID=PUBLICACCESSKEY4TEXT
S3_SECRET_KEY=ProtectThisPrivateKeyBecauseItIsASecret!
S3_SERVER=s3.us-west-1.wasabisys.com
S3_SERVER_PORT=443
S3_SERVER_PROTO=https
S3_REGION=us-west-1
AWS_SIGS_VERSION=2
ALLOW_DIRECTORY_LIST=true3-3. Gateway 시작하기
구성을 파일에 저장했으면(현재 디렉터리의 s3-settings.env), Docker를 사용하여 Gateway를 시작할 준비가 된 것입니다.
- 포그라운에서 NGINX 오픈소스 Gateway를 시작하려면 다음을 실행합니다.
docker run -it --env-file ./s3-settings.env -p8080:80 nginxinc/nginx-s3-gateway
- 포그라운드에서 NGINX Plus Gateway를 시작하려면 다음을 실행하십시오.
docker run -it --env-file ./s3-settings.env -p8080:80 nginx-plus-s3-gateway
이미지가 예상대로 작동하는지 확인한 후에는 더 광범위하게 사용할 수 있도록 조직의 Private Docker Repository에 이미지를 Push할 수 있습니다. 하지만
Note: NGINX Plus 이미지를 Docker Hub와 같은 공개 Repository에 업로드하지 마십시오. 그렇게 하는 것은 라이선스 계약을 위반하는 것입니다.
NGINX가 시작된 후 http://localhost:8080에서 Gateway에 액세스할 수 있습니다.
3-4. Gateway 사용자 정의
기본 구성에서 NGINX S3 Gateway를 실행하는 데 익숙해지면 특정 요구 사항에 따라 해당 Gateway의 구성을 확장하는 방법을 검토할 수 있습니다. 기본 NGINX Docker 이미지는 /etc/nginx/conf.d 디렉터리에 있는 *.conf 파일을 자동으로 로드하도록 구성되어 있어 추가 기능에 대한 구성을 비교적 쉽게 추가할 수 있습니다.
예를 들어 Gzip 압축 모듈에 대한 구성을 etc/nginx/conf.d/gzip_compression.conf 경로의 로컬 디렉터리에 저장할 수 있습니다. GitHub repository에서 Gzip 압축과 함께 작동하도록 NGINX S3 Gateway를 사용자 지정하는 작업 예제를 제공합니다.
구성에 기능을 추가하려면:
1. 로컬 etc/nginx/conf.d/ 디렉터리에 지원할 기능에 대한 구성 파일(예: gzip_compression.conf)을 생성합니다.
2. 로컬 etc/nginx/conf.d 디렉터리에서 .conf 확장자를 가진 파일을 자동으로 로드하려면 다음 행을 Dockerfile에 추가합니다.
FROM nginxinc/nginx-s3-gateway
COPY etc/nginx/conf.d /etc/nginx/conf.d3-5. 요약
우리는 NGINX를 Amazon S3 또는 다른 호환 Object Store에서 Private Bucket 앞에서 Caching Gateway로 사용하는 방법을 보여 주었습니다. 이렇게 하면 Object Store에 대한 트래픽이 줄어들 뿐만 아니라 Object Store와 공용 인터넷 사이에 보호 Layer을 배치하여 Object Store의 콘텐츠를 원하지 않는 공개 검색을 방지할 수 있습니다.
NGINX Plus를 직접 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
[hubspot portal=”21811816″ id=”45fd3f0e-bc44-45f5-9c32-d26811d0a620″ type=”form”]
