S4 — Squished S3
GPU로 S3를 투명하게 압축하는 게이트웨이
언제 비용을 회수하나요?
예: 압축 가능한 S3 스토리지 월 $10,000
압축 가능한 S3 스토리지 지출이 월 $10,000라면 50–80% 절감으로 약 $5,000–$8,000/월의 총 사용료를 회피할 수 있습니다 — S4 소프트웨어 요금, 실행 컴퓨트, 워크로드 차이는 제외한 값입니다.
NVIDIA nvCOMP GPU 코덱이 사전 설치된 S4 투명 S3 압축 게이트웨이의 독립형 EC2 AMI입니다. GPU 인스턴스(g4dn / g5 / g6)에서 실행하고 S3 클라이언트를 연결하기만 하면, 애플리케이션 변경 없이 압축 가능한 데이터의 S3 스토리지 바이트를 50–80% 줄일 수 있습니다.
S4는 버킷으로 가는 모든 객체를 투명하게 압축하는 드롭인 S3 호환 게이트웨이입니다. 이 AMI에는 Amazon Linux 2023, NVIDIA 드라이버, 컨테이너 런타임, S4의 GPU 빌드(nvCOMP Bitcomp / zstd / GDeflate)가 systemd 서비스로 사전 설치되어 있어 CUDA, 드라이버, nvCOMP 설정이 필요 없습니다. GPU 인스턴스에서는 객체 단위로 정수 및 컬럼형 데이터(Parquet, ORC, postings, time-series)를 nvCOMP GPU 코덱으로, 텍스트 또는 로그 데이터를 CPU zstd로 라우팅합니다. 이미 압축된 입력은 변경 없이 통과시킵니다.
해결하고자 하는 과제
S3 스토리지 비용은 보관하는 바이트 수에 비례하여 선형적으로 증가하며, 로그, JSON, Parquet/ORC 등 보관하는 데이터의 대부분은 압축률이 매우 높습니다. 데이터를 저장하는 방식을 변경하는 엔지니어링 리소스 대비 효과가 크지 않아 애플리케이션은 데이터를 압축하지 않고 그대로 기록하므로, 실제로 필요하지 않은 바이트를 보관하는 데 비용을 지불하게 됩니다. 그 결과, 3배 이상 압축할 수 있는 데이터임에도 불구하고 매달 청구 비용이 지속적으로 상승합니다.
작동 원리
- 1
GPU AMI 시작하기
NVIDIA 드라이버와 nvCOMP가 사전 설치되어 있고 S4가 systemd 서비스로 실행되는 Amazon Linux 2023 기반의 S4 AMI를 자체 VPC 내의 g4dn, g5, g6 또는 g6e 인스턴스에서 시작합니다.
- 2
S3 클라이언트 엔드포인트 변경
boto3, aws-cli, Spark, Trino, DuckDB 클라이언트의 엔드포인트 URL만 변경하면 되며, SigV4 인증, 멀티파트 업로드, Range GET은 기존 그대로 동작합니다.
- 3
전송 시 투명하게 압축
각 PUT 요청 시 디스패처가 페이로드를 샘플링하여 최적의 코덱(텍스트/로그는 CPU zstd, 열 기준 정수는 GPU nvCOMP Bitcomp, 이미 압축된 데이터는 passthrough)으로 자동 라우팅하며, GET 요청 시에는 원본 바이트를 반환합니다.
주요 특징
GPU 압축 사전 설치: NVIDIA 드라이버 + nvCOMP(Bitcomp / zstd / GDeflate)가 AMI에 내장되어 있습니다. g4dn / g5 / g6에서 실행하면 S4가 정수 및 컬럼형 데이터에 GPU를 자동으로 사용합니다.
압축 가능한 데이터의 S3 스토리지 바이트를 50–80% 절감하며, 버킷별 실측 절감 리포트(s4 savings)가 내장되어 있습니다.
애플리케이션 변경 없이, lock-in 없이: S3 wire-compatible endpoint이며, 객체는 게이트웨이 없이도 Apache-2.0 CLI / Python / fsspec 도구로 계속 읽을 수 있습니다.
포함 사항
- NVIDIA 드라이버와 nvCOMP가 사전 설치되어 있고 S4가 systemd 서비스로 실행되는 EC2 AMI(Amazon Linux 2023)로, 비용은 일반 AWS 청구서에 인스턴스 시간당으로 청구됩니다.
- 지원되는 GPU 인스턴스 패밀리: g4dn, g5, g6, g6e.
- SigV4/SigV4a 인증, 멀티파트 업로드, Range GET, SSE를 지원하는 S3 와이어 호환 엔드포인트로, 모든 S3 SDK 또는 도구에서 드롭인 방식으로 바로 사용할 수 있습니다.
- 엔트로피 및 매직 바이트 샘플링을 통해 각 페이로드 단위로 CPU zstd, GPU nvCOMP Bitcomp / zstd / GDeflate, passthrough 중 최적의 코덱을 자동 선택하는 코덱 디스패치 기능으로, 이미 압축된 입력 데이터는 처리하지 않고 그대로 통과시킵니다.
- 절감 효과 리포팅: 배포 전 s4 estimate를 사용해 기존 버킷의 절감 효과를 예상하고, s4 savings 원장을 통해 실제로 절감한 스토리지 바이트 및 비용을 기록합니다. Prometheus 메트릭과 Grafana 대시보드가 기본 포함되어 있습니다.
- 특정 플랫폼 종속(Lock-in) 없는 읽기 도구 지원: Apache-2.0 라이선스의 s4-codec CLI, s4-codec Python 패키지, s4fs fsspec 어댑터(pandas / pyarrow / DuckDB) 및 WASM 브라우저 디코더를 활용하여 게이트웨이 없이도 객체를 읽을 수 있습니다.
- 운영(Day-2) 도구: s4 migrate를 통해 기존 객체를 소급하여 압축하고 s4 recompact를 사용하여 콜드 데이터를 재압축할 수 있으며, Parquet/ORC 리더와 호환되는 사이드카 프레임 인덱스를 사용하여 Range GET 요청도 빠른 속도를 유지합니다.
주요 활용 사례
nginx 액세스 로그나 애플리케이션 로그 등 대용량의 로그/JSON을 수집하여 S3 비용의 대부분을 압축률이 높은 텍스트 데이터가 차지하는 팀.
Parquet/ORC나 열 기준 정수 데이터(포스팅, 시계열)를 저장하며, Range GET 분석 속도를 유지하면서 저장 공간 사용량을 줄이고자 하는 데이터 레이크.
월별 S3 비용이 대략 $3,000 이상이거나, 이미 GPU 인스턴스를 운영하고 있어서 스토리지 절감 비용만으로 GPU 컴퓨팅 비용을 충분히 충당할 수 있는 조직.
애플리케이션 코드를 수정하지 않고 압축을 적용하고 싶은 ETL / ML 파이프라인. S3 엔드포인트의 경로만 재지정하면 됩니다.
도입 사례 · 벤치마크
Elasticsearch frozen-tier 스토리지 압축
실제 Elasticsearch 9.4.2 클러스터 환경(ES → S4 → MinIO, 400만 문서 로그 인덱스)에서 엔드투엔드로 측정했습니다. Frozen Tier의 스냅샷 리포지토리를 기본 zstd-3으로 압축하여 스토리지를 표준 −27% / LogsDB −22% 절감(s4 recompact 적용 시 최대 −33% 절감)하였으며, 콜드 Frozen 분석 쿼리는 S4 적용 여부와 관계없이 ±1ms 이내의 레이턴시를 유지했고 스냅샷 완료 시간의 지연도 거의 없었습니다. LogsDB와 함께 사용하면 절감 효과가 배가되어 기본 표준 설정의 직기록 방식보다 2.82× 작은 리포지토리를 확보할 수 있습니다.
상세 내용 및 벤치마크 읽기OpenSearch searchable-snapshot 스토리지 압축
실제 OpenSearch 2.19 클러스터 환경(OpenSearch → S4 → MinIO, 400만 문서 로그 인덱스)에서 엔드투엔드로 측정했습니다. Searchable Snapshots의 S3 리포지토리를 S4로 압축하여 인덱스 코덱별로 default −28%, best_compression −17%, zstd −17%, zstd_no_dict −17%의 스토리지를 절감했습니다. OpenSearch의 index.codec은 stored fields만 압축하기 때문에, 네이티브 zstd 코덱 환경에서도 S4는 doc-values 및 postings를 압축하여 추가로 약 17%를 절감합니다. 로컬 실행 환경에서 remote_snapshot 검색 레이턴시는 S4 적용 여부와 무관하게 ~1.5ms 이내를 유지했습니다(S4가 동등하거나 약간 더 빠름). OpenSearch의 repository-s3 연동을 위해서는 S4의 --logical-etag 플래그가 필요합니다(이번 작업에서 추가됨).
상세 내용 및 벤치마크 읽기Grafana Loki 청크 압축
실제 Grafana Loki 3.3.2 인스턴스 환경(Loki → S4 → MinIO, 400만 로그 라인)에서 엔드투엔드로 측정했습니다. Loki의 snappy 청크를 S4 zstd-3으로 재압축하여 버킷 스토리지를 18.4% 절감(zstd-9은 19.3% 절감)했습니다. 솔직히 말씀드리면, Loki 자체의 chunk_encoding을 zstd로 변경하는 것이 새로운 청크에 대해 38%를 절감하여 S4보다 더 효과적입니다. 따라서 S4의 가치는 신규 데이터(greenfield)가 아니라 forward-only 구조상 변경이 불가능한 '기존 snappy 백로그'에 국한됩니다(대체가 아닌 보완 관계). 읽기 작업의 경우, S4를 통한 전체 청크 GET 요청 시 바이트 단위는 완벽히 일치하나 로컬 실행 기준 디코딩 비용으로 인해 약 1.7ms의 비용이 추가로 발생했습니다. OpenSearch와 달리 Loki의 경우 --logical-etag 플래그가 필수는 아닙니다(정확한 ETag를 위해 권장).
상세 내용 및 벤치마크 읽기Kafka 계층형 스토리지 압축
실제 Apache Kafka 3.9.1 클러스터 환경(KIP-405 계층형 스토리지 + Aiven 플러그인 → S4 → MinIO, 토픽당 600k 레코드)에서 엔드투엔드로 측정했습니다. S3로 계층화된 로그 세그먼트를 S4 zstd-3으로 재압축하여, 프로듀서의 compression.type별로 none(미압축)은 74.7%, snappy는 22.6%, lz4는 20.6%, zstd는 0.0%의 스토리지를 절감했습니다. 솔직히 말씀드리면, 프로듀서가 직접 zstd를 전송할 경우 원천적으로 세그먼트 크기가 축소되며(43.9 MB, S4가 none에 적용하여 도달하는 42.0 MB와 유사한 수준), 이미 zstd가 적용된 세그먼트에는 S4가 추가로 기여하는 바가 거의 없습니다. 따라서 S4의 가치는 none/snappy/lz4를 사용하거나 프로듀서를 변경할 수 없는 환경의 세그먼트에 있습니다(대체가 아닌 보완 관계). 로컬 실행 시 콜드 리모트 패치(cold remote-fetch)에 대해 일관되게 발생하는 S4 패널티는 관찰되지 않았습니다(단발성 노이즈 샘플 제외). OpenSearch와 달리 Kafka의 경우 --logical-etag 플래그가 필수는 아닙니다(정확한 ETag를 위해 권장).
상세 내용 및 벤치마크 읽기콜드 Parquet 재압축
MinIO를 대상으로 로컬에서 측정했습니다(2,000,000행의 ECS 스타일 로그 Parquet, 13개 열). 새로운 s4 parquet-recompact 서브커맨드가 데이터 레이크의 콜드 Parquet 컬럼 청크를 zstd로 재인코딩하고 네이티브 Parquet를 다시 작성합니다. pyarrow, Spark, Trino, DuckDB는 읽기 경로에 S4 없이 이를 직접 읽을 수 있습니다. 데이터 레이크의 기본 코덱인 snappy 대비 36.6%, 미압축 대비 51.7%, gzip 대비 3.8%를 절감했으며, 이미 zstd가 적용된 경우에는 0.0% 절감으로 건너뛰었습니다. 모든 출력 값은 pyarrow의 table.equals를 통해 일대일로 완전히 일치함을 확인했습니다. 솔직히 말씀드리면, 작성기(writer)의 코덱을 zstd로 설정하면 원천적으로 동일한 수준(79.4 MB)에 도달하므로, S4의 주된 사용처는 아무도 작성기 작업을 재실행하지 않는 기존의 '기존 snappy/none/gzip 백로그'입니다(대체가 아닌 보완 관계). 제자리 덮어쓰기(in-place overwrite)를 진행하기 전에 행 그룹(row group)별로 메모리 한도 내에서 각 객체의 값을 검증하며, 검증할 수 없는 객체는 절대 덮어쓰지 않습니다.
상세 내용 및 벤치마크 읽기자주 묻는 질문
S4 실행을 중단해도 데이터를 계속 읽을 수 있습니까?
네. 압축된 객체와 S4IX 사이드카는 S3 네이티브 상태로 유지되므로 일반 aws-cli나 boto3을 사용하여 목록을 조회하고 다운로드할 수 있습니다. 원본 페이로드를 복구하려면 Apache-2.0 라이선스의 s4-codec CLI, s4-codec Python 패키지, s4fs fsspec 어댑터(pandas / pyarrow / DuckDB) 또는 WASM 브라우저 디코더를 사용하면 됩니다. 이 도구들은 모두 게이트웨이 런타임 없이 동작하는 순수 오픈소스 디코딩 라이브러리입니다.
애플리케이션을 수정해야 합니까?
아니요. S4는 S3 와이어 프로토콜을 그대로 사용하므로 SigV4 인증, 멀티파트 업로드, Range GET, SDK 호출 등이 기존과 모두 동일합니다. boto3, aws-cli, Spark, Trino, DuckDB 클라이언트가 가리키는 엔드포인트 URL만 변경하면 되며, 그 외에 다른 작업은 전혀 필요하지 않습니다.
청구 비용 중 실제로 저렴해지는 항목은 무엇인가요?
스토리지 바이트만 해당됩니다. S4는 압축 가능한 데이터에 대해 S3에 저장되는 바이트를 50–80% 줄여줍니다 — 예를 들어, 1 TiB의 nginx 로그는 약 6.6 GiB로 압축됩니다. 요청 비용(PUT/GET), egress 및 GPU 컴퓨팅은 변경되지 않습니다. GPU 인스턴스 비용 때문에 S4는 일반적으로 월 S3 비용이 약 $1,000 이상일 때 이득이 됩니다(스팟 인스턴스를 사용하거나 이미 GPU를 운영 중인 경우 더 낮아짐).
AMI는 어떤 GPU 인스턴스를 지원하나요?
EC2 AMI(Amazon Linux 2023, NVIDIA 드라이버 + nvCOMP 사전 설치됨)는 g4dn, g5, g6 및 g6e 인스턴스에서 실행되며, 일반 AWS 청구서에 인스턴스 시간당으로 청구됩니다. 라이선스 키는 없으며 미터링은 AWS Marketplace를 통해 처리됩니다.
S4는 어디에서 실행되며, 누가 내 데이터를 볼 수 있나요?
사용자의 AWS 계정 및 VPC 내에서 AMI를 실행하며, 사용자의 S3 버킷과 통신합니다 — 데이터가 계정 외부로 유출되지 않으며 경로상에 제3자 서비스가 존재하지 않습니다. TLS 및 서버 사이드 암호화(SSE)를 지원합니다.
왜 더 저렴한가
S3 Standard(us-east-1)에 약 3×로 압축 가능한 데이터(Parquet/ORC, JSON 등) 100 TB를 보관하는 경우를 가정합니다.
- S3 스토리지 (100 TB)
- $2,300 / 월
- 월 합계
- $2,300 / 월
- S3 스토리지 (압축 후 34 TB)
- $800 / 월
- S4 인스턴스 (g4dn.xlarge + 소프트웨어 요금)
- $385 / 월
- 월 합계
- $1,185 / 월
쓰기 부하에 맞춘 S4 인스턴스 선택
| 쓰기 부하 | 권장 인스턴스 | S4 인스턴스 비용 | 100 TB 보관 시 합계 |
|---|---|---|---|
| ~1 TB / 일 | g4dn.xlarge | $385 / 월 | $1,185 / 월 (−49%) |
| ~10 TB / 일 | g6.xlarge | $590 / 월 | $1,390 / 월 (−40%) |
| 고병렬 / 100 TB / 일 | g6.4xlarge | $965 / 월 | $1,765 / 월 (−23%) |
참고용 예시입니다. 스토리지는 S3 Standard(us-east-1) 공시 요율($0.023/GB·월)과 g4dn / g6의 EC2 온디맨드 가격을 기준으로 합니다. S4 소프트웨어 요금은 AWS Marketplace를 통해 시간당 청구되며 EC2 요금과 별도입니다 (1년 Savings Plan 적용 시 EC2 부분은 보통 30–40% 절감됩니다). 실제 절감 효과는 데이터의 압축 가능성(Parquet, JSON 약 3–5×; 텍스트 로그 약 4–10×)과 읽기/쓰기 패턴에 따라 달라집니다.
요금제 모델
시간당 소프트웨어 요금 + 선택한 GPU EC2(g4dn / g5 / g6). 인스턴스 유형별 종량 과금, 연간 옵션 제공, 라이선스 키 불필요.
