Day 2 - Storage Gateway 4종 비교: 온프레미스 스토리지를 클라우드로 확장하는 방법

온프레미스 인프라와 AWS 클라우드를 통합하는 과정에서 가장 먼저 맞닥뜨리는 현실적 문제는 스토리지다. 기존 시스템이 NFS, SMB, iSCSI, 테이프 드라이브 같은 전통적 프로토콜로 데이터를 쓰고 읽는다. 이 시스템들을 수정하지 않고 클라우드 스토리지(S3, Glacier)를 뒤에서 조용히 사용하게 하는 것이 AWS Storage Gateway의 핵심 역할이다. Storage Gateway는 온프레미스 애플리케이션이 기존 프로토콜로 데이터를 쓰면 그것을 S3 객체, EBS 스냅샷, Glacier 아카이브로 투명하게 변환한다. 오늘은 4종의 게이트웨이 각각의 내부 동작, 캐싱 메커니즘, 사용 시나리오를 깊이 이해한다.

Storage Gateway의 배포 모델: 가상 어플라이언스

Storage Gateway는 온프레미스에 가상 어플라이언스(VM) 또는 하드웨어 어플라이언스로 배포된다. VMware ESXi, Microsoft Hyper-V, KVM, Linux KVM 환경에 OVA 이미지를 배포하거나, AWS가 판매하는 전용 하드웨어 어플라이언스(Dell EMC PowerEdge 기반)를 사용한다.

가상 어플라이언스에는 두 종류의 디스크가 연결된다. 캐시 디스크: 로컬 캐시 데이터를 저장한다. 업로드 버퍼 디스크: AWS로 전송되기 전 데이터를 임시 저장한다. 이 두 디스크의 크기 설정이 Storage Gateway 성능을 결정하는 핵심 파라미터다.

Storage Gateway의 캐싱은 LRU(Least Recently Used) 알고리즘을 기반으로 한다. 가장 최근에 접근된 데이터가 캐시에 남고, 캐시가 가득 차면 가장 오래 접근되지 않은 데이터가 제거된다. 이는 지역성(Locality of Reference) 원칙에 근거한다. 자주 쓰는 파일이 캐시에 유지되면 클라우드 왕복 없이 로컬 속도로 접근 가능하다. 워킹셋(자주 쓰는 데이터 집합)이 캐시 크기 내에 들어오도록 캐시 디스크를 설계하는 것이 핵심이다.

네트워크 연결은 인터넷 또는 DX를 통해 AWS 리전의 Storage Gateway 서비스 엔드포인트와 HTTPS로 통신한다. DX를 사용하면 일관된 대역폭과 지연으로 대용량 파일 전송 성능이 향상된다.

S3 File Gateway: 파일을 S3 객체로 투명하게

S3 File Gateway는 NFS(v3, v4.1)와 SMB(v2, v3) 마운트 포인트를 제공하며, 파일 쓰기/읽기를 S3 GetObject/PutObject API 호출로 변환한다. 온프레미스 서버 입장에서는 일반 파일 시스템처럼 보이지만 실제로는 S3 버킷에 데이터가 저장된다.

[온프레미스 서버]
  cp video.mp4 /mnt/media-share/2024/video.mp4
        │
        ↓ NFS write
  [Storage Gateway VM]
    캐시에 저장
    업로드 버퍼로 이동
        │
        ↓ HTTPS PutObject
  [S3 Bucket]
    s3://company-media/2024/video.mp4
    메타데이터: Content-Type, Last-Modified, ETag 등
        │
        ↓ S3 Lifecycle 규칙
    30일 후 → S3 Standard-IA
    90일 후 → Glacier Instant Retrieval

S3 File Gateway의 중요한 특성은 파일이 S3에 네이티브 S3 객체로 저장된다는 점이다. Gateway를 거치지 않고 직접 S3 API, S3 콘솔, Athena, EMR에서 같은 객체에 접근할 수 있다. 이는 데이터 레이크 구축에서 특히 유용하다. 온프레미스 시스템이 파일을 쓰면 자동으로 S3 데이터 레이크의 원시 데이터가 된다.

🔍 더 깊이: S3 File Gateway가 파일을 S3 객체로 변환할 때 파일 시스템 메타데이터(소유자, 권한, 타임스탬프)는 S3 객체의 사용자 정의 메타데이터(x-amz-meta-*)에 저장된다. 이 메타데이터는 나중에 파일을 다시 온프레미스로 읽을 때 파일 권한을 복원하는 데 사용된다. NFS와 SMB의 권한 모델이 다르므로, S3 File Gateway는 마운트 프로토콜에 따라 POSIX 권한(NFS) 또는 Windows ACL(SMB)을 메타데이터로 보존한다.

S3 File Gateway의 멀티사이트 고려사항: 여러 지점에서 같은 S3 버킷을 공유할 때 한 게이트웨이가 쓴 파일이 다른 게이트웨이에서 즉시 보이지 않을 수 있다. 각 게이트웨이가 독립적인 캐시를 유지하기 때문이다. 이를 해결하려면 S3 이벤트 알림이나 Lambda를 통해 캐시 무효화(RefreshCache API)를 트리거해야 한다.

⚠️ 함정: 여러 온프레미스 사이트가 같은 S3 File Gateway를 통해 동일 버킷에 쓸 때 동시 쓰기 충돌이 발생할 수 있다. S3는 강력한 일관성(Strong Consistency)을 2020년 12월부터 지원하지만, Storage Gateway의 캐시 레이어가 있어 두 게이트웨이가 동시에 같은 파일을 수정하면 마지막 쓰기가 이전 쓰기를 덮어쓴다. 동시 편집이 필요한 환경에서는 FSx for Windows File Server + FSx File Gateway가 더 안전하다(NTFS 락 메커니즘 지원).

FSx File Gateway: Windows 파일 공유의 클라우드 확장

FSx File Gateway는 온프레미스 Windows 환경을 위한 특화 솔루션이다. 온프레미스 서버가 SMB로 게이트웨이에 마운트하면, 게이트웨이는 자주 쓰는 파일을 로컬 캐시에 유지하고 실제 데이터는 AWS FSx for Windows File Server에 저장한다.

[온프레미스 Windows PC]
  \\gateway-ip\share → 로컬 캐시 히트면 즉시 반환
                     → 캐시 미스면 FSx for Windows에서 가져와 캐시 업데이트
        │
        ↓ SMB v2/v3
  [Storage Gateway VM]
    Windows ACL, NTFS 메타데이터 보존
    AD 통합 (도메인 조인)
        │
        ↓ 동기화
  [FSx for Windows File Server]
    AWS 관리형 Windows 파일 서버
    Multi-AZ 가용성
    VSS(볼륨 섀도우 복사본) 백업

SMB(Server Message Block) 프로토콜의 핵심은 파일 잠금(File Locking) 메커니즘이다. Windows 파일 공유에서 여러 클라이언트가 같은 파일에 동시 접근할 때 NTFS의 OpLock(Opportunistic Lock)이 캐싱 권한을 협상한다. FSx File Gateway는 이 잠금 메커니즘을 올바르게 구현해 동시 편집 충돌을 방지한다. S3 File Gateway가 S3의 객체 모델(잠금 없음)에 의존하는 것과 달리, FSx File Gateway는 진정한 Windows 파일 시스템 의미를 유지한다.

FSx File Gateway가 S3 File Gateway와 다른 결정적 차이: Active Directory 통합과 NTFS ACL 보존. 기업의 AD 그룹 정책으로 파일 접근을 제어하는 환경에서 S3 File Gateway로 전환하면 이 권한 체계가 깨진다. FSx File Gateway는 도메인 조인을 지원해 기존 AD 정책이 그대로 적용된다.

Volume Gateway: 블록 스토리지의 클라우드 확장

Volume Gateway는 iSCSI(Internet Small Computer Systems Interface) 프로토콜로 온프레미스 서버에 블록 스토리지 볼륨을 제공한다. 서버는 이 볼륨을 일반 디스크처럼 포맷하고 파일시스템을 올릴 수 있다.

iSCSI(RFC 7143)는 SCSI 명령을 TCP/IP 네트워크 위에서 전송하는 프로토콜이다. 물리 디스크에 SCSI 명령으로 데이터를 쓰는 것처럼, iSCSI로 원격 스토리지에 접근한다. Initiator(클라이언트, 온프레미스 서버)가 Target(서버, Storage Gateway)에 SCSI 명령을 보내면 Target이 블록 I/O를 처리하고 결과를 반환한다. 이 추상화 덕분에 운영체제는 iSCSI 볼륨을 로컬 디스크와 동일하게 취급한다.

Cached Mode vs Stored Mode

Cached Mode: 주 저장소는 S3이고 로컬에는 자주 쓰는 데이터만 캐시로 유지한다.

• 로컬 디스크는 캐시 용도로만 필요 → 작은 로컬 스토리지로 대용량 데이터 처리 가능
• S3에 저장된 데이터는 EBS 스냅샷으로 자동 변환되어 AWS 내 데이터 복구 용이
• 캐시 미스 시 S3에서 데이터를 가져오는 지연이 발생

Stored Mode: 전체 데이터가 로컬에 저장되고 S3에 비동기로 백업된다.

• 로컬 디스크에 전체 데이터가 있으므로 최저 지연
• 로컬 디스크 크기만큼 데이터가 제한됨
• S3 백업은 EBS 스냅샷 형태로 저장되어 DR 시 EC2에 EBS로 마운트 가능

🎯 시나리오: 지방 병원이 의료 영상 시스템(PACS)을 운영한다. 영상 데이터 총 50TB인데 로컬 스토리지는 5TB밖에 없다. 자주 보는 최근 3개월 영상은 빠르게 접근해야 하고, 오래된 영상은 S3에 있어도 된다. Volume Gateway Cached Mode를 쓰면 5TB 캐시로 최근 영상을 로컬 속도로 제공하고, 나머지 45TB는 S3에서 필요할 때 가져온다. S3 데이터는 EBS 스냅샷으로 자동 변환되어 DR 시 EC2에서 즉시 복원할 수 있다.

Tape Gateway: 가상 테이프 라이브러리

수십 년간 테이프 드라이브는 기업 백업의 표준이었다. Veeam, Veritas NetBackup, CommVault, IBM Spectrum Protect 같은 백업 소프트웨어가 iSCSI VTL(Virtual Tape Library) 인터페이스를 통해 테이프 드라이브에 데이터를 기록한다. Tape Gateway는 이 백업 소프트웨어가 AWS를 테이프처럼 인식하게 만든다.

[백업 서버: Veeam/NetBackup]
  iSCSI VTL 인터페이스로 테이프에 백업 job 실행
        │
        ↓ iSCSI (VTL 프로토콜)
  [Tape Gateway VM]
    가상 테이프 미디어 에뮬레이션
        │
        ↓ 테이프 쓰기 완료
  [S3 버킷] - Virtual Tape Library (현재 사용 중 테이프)
        │
        ↓ 테이프 보관(Archive) 명령
  [S3 Glacier Deep Archive] - Virtual Tape Shelf (보관 테이프)
        │
        복구 시: Glacier 테이프 꺼내기 → S3 복원 → 백업 SW에서 복원

(가상 사례) 한 방송사가 20년치 방송 콘텐츠를 물리 테이프 6만 개로 보관하고 있었다. 테이프 운반, 검색, 복원에 드는 인력 비용이 연간 수억 원이었다. Tape Gateway로 전환 후 물리 테이프 운반 없이 Veeam 백업 소프트웨어를 그대로 유지하면서 모든 백업이 S3와 Glacier Deep Archive에 저장됐다. 테이프 복원 시간이 수 일에서 수 시간으로 단축됐고 물리 테이프 재구매 비용이 없어졌다.

Tape Gateway 비용 모델: S3 Virtual Tape Library 저장 비용 + Glacier Deep Archive 저장 비용(GB당 $0.00099) + 검색 비용. 물리 테이프 대비 GB당 비용이 낮고 검색이 훨씬 빠르다.

Tape Gateway의 가상 테이프 크기는 100GB ~ 5TB로 설정 가능하다. 물리 테이프 드라이브 종류(LTO-5부터 LTO-9까지)에 따른 테이프 크기를 에뮬레이션한다. 백업 소프트웨어가 큰 테이프를 사용하도록 구성하면 테이프 수가 줄어 관리가 단순해진다. 가상 테이프의 "꺼내기(Eject)"와 "보관(Archive)" 명령이 S3 → Glacier Deep Archive 이동으로 구현된다.

Storage Gateway vs DataSync vs Transfer Family

혼동하기 쉬운 세 서비스의 차이를 명확히 정리한다.

DataSync는 전송 작업(Task)을 실행하는 에이전트 기반 서비스다. 에이전트가 소스(온프레미스 NFS/SMB)를 스캔하고 목적지(S3, EFS, FSx)와 차이를 계산해 변경된 파일만 전송한다. 병렬 전송과 네트워크 가속으로 1Gbps DX 환경에서 약 30% 높은 실효 처리량을 달성한다. Storage Gateway가 "상시 마운트"라면 DataSync는 "효율적 배치 전송"이다. 마이그레이션 완료 후에는 DataSync 에이전트를 중지하고 Storage Gateway만 유지하는 것이 일반적인 패턴이다.

다른 클라우드와의 비교

글로벌 미디어 그룹이 온프레미스와 AWS의 하이브리드 편집 워크플로를 구축했다. NAS에 저장된 원본 영상 파일을 S3 File Gateway로 마운트해 AWS 편집 시스템이 S3 API로 직접 접근한다. 완성된 영상은 자동 S3 Lifecycle으로 아카이브된다. 동시에 편집 프로젝트 파일(Adobe Premiere, Avid)은 FSx File Gateway를 통해 온프레미스 편집실과 AWS 클라우드 편집 워크스테이션이 공유한다. Windows 도메인 환경의 파일 잠금이 올바르게 동작해 충돌 없이 공동 작업이 가능하다.

실전 CLI: Storage Gateway 구성

# Storage Gateway 활성화
aws storagegateway activate-gateway \
  --activation-key XXXXX-XXXXX-XXXXX-XXXXX-XXXXX \
  --gateway-name "Seoul-FileGateway" \
  --gateway-timezone "GMT+9:00" \
  --gateway-region ap-northeast-2 \
  --gateway-type FILE_S3
 
# 로컬 디스크를 캐시로 구성
aws storagegateway add-cache \
  --gateway-arn arn:aws:storagegateway:ap-northeast-2:ACCT:gateway/sgw-xxx \
  --disk-ids /dev/sdb
 
# S3 File Share 생성 (NFS)
aws storagegateway create-nfs-file-share \
  --client-token "unique-token-123" \
  --gateway-arn arn:aws:storagegateway:...:gateway/sgw-xxx \
  --role "arn:aws:iam::ACCT:role/StorageGatewayS3Role" \
  --location-arn "arn:aws:s3:::company-media-bucket" \
  --default-storage-class S3_STANDARD \
  --squash RootSquash \
  --nfs-file-share-defaults '{"FileMode":"0666","DirectoryMode":"0777","GroupId":0,"OwnerId":0}'
 
# Volume Gateway - Cached Volume 생성
aws storagegateway create-cachedi-scsi-volume \
  --gateway-arn arn:aws:storagegateway:...:gateway/sgw-yyy \
  --volume-size-in-bytes 107374182400 \  # 100GB
  --target-name TargetA \
  --network-interface-id 10.0.1.100 \
  --client-token "unique-token-456"
 
# Tape Gateway - 가상 테이프 생성
aws storagegateway create-tapes \
  --gateway-arn arn:aws:storagegateway:...:gateway/sgw-zzz \
  --tape-size-in-bytes 107374182400 \  # 100GB
  --tape-barcode-prefix AMZN \
  --num-tapes-to-create 5

Storage Gateway는 "기존 프로토콜 그대로, 백엔드만 클라우드"로 요약된다. 온프레미스 애플리케이션을 수정하지 않고 클라우드 스토리지의 비용 효율성, 가용성, 확장성을 바로 활용할 수 있다. SAP-C02에서 Storage Gateway 문제의 핵심 판단 기준은 프로토콜(NFS/SMB/iSCSI/VTL)과 AD 통합 여부, 그리고 상시 접근이냐 일회성 전송이냐다.