Amazon S3

사용자 업로드를 웹 서버 디스크에만 두면 서버를 교체하거나 여러 대로 늘리는 순간 파일 위치가 꼬입니다. 백업과 공유를 따로 챙기지 않으면 한 서버 장애가 곧 파일 유실과 다운로드 장애로 이어집니다.

예전에는 NAS나 파일 서버를 직접 운영하면서 용량이 부족해지면 디스크를 주문하고 데이터를 마이그레이션하는 작업을 반복해야 했습니다. 백업은 스크립트로 돌렸지만 실패 알림이 없어 장애가 나서야 마지막 백업이 며칠 전이었다는 걸 알게 되기도 했습니다. 파일 서버 자체가 죽으면 복구에 수 시간이 걸렸고, 그 사이 서비스는 업로드와 다운로드를 모두 멈춰야 했습니다. 서버 수가 늘면서 파일을 어디에 두고 어떻게 공유할지 조정하는 일까지 겹치자, 용량·내구성·접근을 서비스 수준에서 해결하는 객체 저장소 모델이 자리 잡았습니다.

S3는 버킷 안에 객체를 키-값 구조로 저장합니다. 파일을 PUT하면 버킷 이름과 키(경로처럼 보이는 문자열)가 조합된 주소가 생기고, GET 요청을 보내면 해당 키에 매핑된 객체 본문이 그대로 반환됩니다. 파일시스템처럼 디렉터리를 탐색하는 것이 아니라 키를 알거나 prefix로 나열하는 방식이라 수백만 개 객체도 일관된 성능으로 읽고 씁니다. 스토리지 클래스와 Lifecycle 정책을 설정하면 접근 빈도가 줄어든 객체는 자동으로 저렴한 계층으로 이동해 비용이 내려갑니다.

S3, EBS, EFS는 모두 데이터를 저장합니다. 차이는 접근 방식입니다. EBS는 한 인스턴스에 붙는 블록 디스크이고 EFS는 여러 인스턴스가 공유하는 파일시스템이며, S3는 파일을 객체 단위로 다루는 API 기반 저장소입니다. 파일시스템처럼 마운트할 필요 없이 HTTP로 읽고 쓸 데이터라면 S3가 맞습니다.

가장 흔한 장면은 사용자 업로드와 정적 자산 호스팅입니다. 웹 서버 디스크 대신 S3에 이미지를 올려두면 서버가 몇 대든 같은 버킷을 바라보고, CloudFront를 앞에 두면 전 세계 엣지에서 바로 내려줄 수 있습니다. 또 다른 장면은 로그와 분석 데이터를 쌓아두는 데이터 레이크입니다. 애플리케이션 로그, 이벤트 스트림, 크롤링 결과를 날짜별 prefix로 적재하고 Athena 같은 분석 도구가 직접 읽어가는 구성이 많습니다. 파일시스템처럼 마운트해야 하거나 서버에 직접 붙는 디스크가 필요한 경우에는 맞지 않습니다.