아키텍처 케이스 · 9

온프레미스 파일 서버를 클라우드로

파일 서버 마이그레이션은 서비스 이름을 외워서 푸는 문제가 아닙니다. 어떤 프로토콜로 · 누가 · 어디에서 접근하는가, 그리고 온프레미스를 남길 것인가 없앨 것인가를 물으면 Storage Gateway · Amazon FSx · AWS DataSync 중 하나로 자연스럽게 수렴합니다.

주 도메인: 고성능 아키텍처 설계(24%) · 비용 최적화 아키텍처 설계(20%)

학습 목표

공유 스토리지 후보를 프로토콜과 접근 주체 기준으로 좁힐 수 있습니다.
Storage Gateway의 유형별 경계(온프레미스에 무엇이 남는가)를 설명할 수 있습니다.
이관 도구(DataSync)와 상시 연결(Storage Gateway)의 역할 차이를 구분할 수 있습니다.
전송량과 가용 대역폭으로 소요 기간을 추정하고 전송 수단을 판단할 수 있습니다.
시험 문항에서 "기존 인프라를 유지"와 "완전히 이전"의 신호를 구분할 수 있습니다.

상황

제조업체의 본사 데이터센터에 Windows 파일 서버 두 대가 있습니다.

설계 부서가 SMB 프로토콜로 도면 파일을 공유합니다. 권한은 Active Directory 그룹으로 관리됩니다.
총 용량은 수십 테라바이트이고, 그중 최근 3개월 파일만 실제로 자주 열립니다.
본사 회선의 여유 대역폭은 크지 않고, 업무 시간에는 더 좁습니다.
공장 라인의 검사 장비가 파일 서버에 결과를 쓰는데, 이 장비는 소프트웨어를 수정할 수 없습니다.
분석 팀은 이 파일들을 AWS에서 처리하고 싶어 합니다.

요구는 상충합니다. 분석을 위해 데이터는 클라우드에 있어야 하지만, 공장 장비와 설계 부서는 지금과 똑같은 SMB 경로로 계속 접근해야 합니다. 그리고 회선이 좁아 한 번에 다 올릴 수도 없습니다.

Storage Gateway 유형별로 온프레미스에 무엇이 남고 무엇이 Amazon S3 · Glacier로 가는지의 경계. 캐시가 온프레미스에 남는다는 점이 지연 시간 요구를 만족시키는 근거이며, 이 경계가 곧 "기존 인프라를 유지하면서 확장한다"는 요구의 답이 됩니다

요구사항과 제약

요구사항과 제약, 그리고 각각이 후보를 어떻게 거르는가
구분	내용	후보 필터
요구 1	설계 부서와 장비가 SMB로 계속 접근한다	SMB를 제공하지 못하는 후보는 소거된다
요구 2	Active Directory 권한 체계를 그대로 유지한다	디렉터리 통합이 되는 후보만 남는다
요구 3	분석 팀이 AWS에서 같은 데이터를 읽는다	데이터가 AWS 쪽에 실체로 있어야 한다
제약 1	공장 장비의 소프트웨어를 바꿀 수 없다	경로와 프로토콜이 바뀌면 안 된다
제약 2	회선 대역폭이 제한적이다	초기 이관과 상시 동기화를 나눠 설계해야 한다
제약 3	자주 쓰는 파일은 지금과 비슷한 응답 속도여야 한다	온프레미스 캐시가 필요하다

배경 개념은 9장 파일 스토리지와 데이터 전송에 있습니다.

후보 설계안 비교

먼저 세 서비스의 역할이 다르다는 점을 정리합니다. DataSync는 옮기는 도구이고, Storage Gateway는 이어 주는 장치이며, FSx는 클라우드 쪽의 파일 서버 자체입니다. 셋은 경쟁 관계라기보다 조합해 쓰는 경우가 많습니다.

후보 설계안 4종 비교
항목	A · Amazon EC2에 파일 서버 재구축	B · Amazon FSx for Windows File Server로 이전	C · S3 File Gateway로 S3에 연결	D · B + DataSync로 이관 + 온프레미스 캐시 유지
SMB 제공	가능(직접 구성)	관리형으로 제공	게이트웨이가 SMB로 제공	양쪽 모두
Active Directory 통합	직접 구성	기본 제공	게이트웨이에서 구성	기본 제공
AWS 쪽 데이터 실체	EBS 볼륨	FSx 파일 시스템	S3 객체 — 분석 도구가 바로 읽는다	FSx + 필요하면 S3
온프레미스 응답 속도	회선에 좌우된다	회선에 좌우된다	캐시가 로컬에 남는다	캐시가 로컬에 남는다
운영 부담	가장 높다 — 패치·백업·이중화 전부 직접	낮다	게이트웨이 어플라이언스를 운영한다	중간
판정	오답 — 운영 부담 한정어와 충돌	요구 1·2는 만족하지만 제약 3이 남는다	요구 3에 유리하지만 요구 2가 약하다	선택

Storage Gateway 유형

Storage Gateway 유형별 인터페이스와 백엔드
유형	온프레미스에 제공하는 인터페이스	AWS 쪽 저장 위치	언제 고르는가
S3 File Gateway	NFS · SMB 파일 공유	Amazon S3 객체	파일로 쓰고 객체로 분석하고 싶을 때
Volume Gateway (캐시형)	iSCSI 블록 볼륨	S3에 주 데이터, 자주 쓰는 부분만 로컬 캐시	블록 장치가 필요하고 용량을 클라우드로 넘기고 싶을 때
Volume Gateway (저장형)	iSCSI 블록 볼륨	주 데이터는 온프레미스, 스냅샷이 AWS로	전체 데이터가 로컬에 있어야 하고 백업만 클라우드로 보낼 때
Tape Gateway	가상 테이프 라이브러리(VTL)	S3와 아카이브 계층	기존 백업 소프트웨어를 그대로 두고 테이프를 없앨 때

Amazon FSx 4종

Amazon FSx 파일 시스템 유형과 선택 신호
유형	주 프로토콜	문제문의 신호
FSx for Windows File Server	SMB	Windows 파일 공유, Active Directory 권한
FSx for Lustre	Lustre	고성능 컴퓨팅, 대규모 병렬 처리, S3와 연동한 대량 읽기
FSx for NetApp ONTAP	NFS · SMB · iSCSI	기존 ONTAP 환경 이전, 다중 프로토콜 동시 지원
FSx for OpenZFS	NFS	기존 ZFS 환경 이전, 스냅샷 중심 워크플로

비교 대상인 Amazon EFS는 NFS이고 여러 가용 영역에서 동시에 마운트됩니다. "리눅스 인스턴스 여러 대가 같은 디렉터리를 공유한다"는 요구에는 EFS, "Windows와 Active Directory"라는 요구에는 FSx for Windows File Server가 답입니다.

선택과 근거

D안을 고릅니다. 역할을 셋으로 나눕니다.

역할 분담
역할	수단	해결하는 요구·제약
클라우드 쪽 파일 서버	Amazon FSx for Windows File Server	요구 1·2 — SMB와 Active Directory를 관리형으로
초기 이관과 주기 동기화	AWS DataSync	제약 2 — 대역폭 제한과 검증을 도구가 처리
아카이브 계층과 분석 입력	S3 File Gateway 또는 FSx에서 S3로의 내보내기	요구 3·제약 3 — 로컬 캐시와 객체 접근

먼저 대역폭으로 기간을 계산한다

전송 수단을 고르는 유일하게 신뢰할 수 있는 기준은 전송량 ÷ 실제 가용 대역폭 = 소요 기간입니다. 장비 모델과 용량을 외우는 것보다 이 계산이 먼저입니다.

회선 속도가 아니라 업무에 지장을 주지 않는 여유 대역폭으로 계산합니다.
계산 결과가 업무적으로 감당 가능한 기간이면 네트워크 전송(DataSync, 필요하면 전용 회선)입니다.
감당할 수 없는 기간이 나오면 물리 전송을 검토합니다.
대부분의 경우 초기 대량 이관 한 번과 이후의 증분 동기화는 다른 수단을 써도 됩니다.

DataSync로 이관

DataSync는 온프레미스에 에이전트를 두고 원본 위치와 대상 위치를 정의한 뒤 작업(task)을 실행합니다. NFS · SMB · HDFS · 객체 스토리지를 원본으로 삼을 수 있고, Amazon S3 · Amazon EFS · Amazon FSx 4종을 대상으로 삼을 수 있습니다.

datasync-migrate.sh — SMB 원본에서 FSx for Windows로 이관 (ARN과 서버 주소는 예시입니다)

# 1) 온프레미스 에이전트를 활성화합니다.
aws datasync create-agent \
  --activation-key 0123-4567-89AB-CDEF-0123 \
  --agent-name onprem-fileserver-agent

# 2) 원본(온프레미스 SMB 공유) 위치를 만듭니다.
aws datasync create-location-smb \
  --server-hostname fileserver.example.internal \
  --subdirectory /design \
  --user svc-datasync \
  --domain EXAMPLE \
  --password '***' \
  --agent-arns arn:aws:datasync:ap-northeast-2:123456789012:agent/agent-0123456789abcdef0

# 3) 대상(Amazon FSx for Windows) 위치를 만듭니다.
aws datasync create-location-fsx-windows \
  --fsx-filesystem-arn arn:aws:fsx:ap-northeast-2:123456789012:file-system/fs-0123456789abcdef0 \
  --security-group-arns arn:aws:ec2:ap-northeast-2:123456789012:security-group/sg-0123456789abcdef0 \
  --user svc-datasync \
  --domain EXAMPLE \
  --password '***'

# 4) 작업을 만들고 실행합니다. 대역폭 상한과 일정은 옵션으로 지정합니다.
aws datasync create-task \
  --source-location-arn arn:aws:datasync:ap-northeast-2:123456789012:location/loc-0src00000000000 \
  --destination-location-arn arn:aws:datasync:ap-northeast-2:123456789012:location/loc-0dst00000000000 \
  --name design-share-migration \
  --options '{"BytesPerSecond": 104857600, "VerifyMode": "ONLY_FILES_TRANSFERRED"}'

aws datasync start-task-execution \
  --task-arn arn:aws:datasync:ap-northeast-2:123456789012:task/task-0123456789abcdef0

전환 순서

무중단에 가깝게 전환하는 순서
순서	작업	확인 지점
1	대상 FSx 파일 시스템을 만들고 Active Directory에 조인한다	도메인 사용자가 SMB로 접근되는지
2	DataSync로 초기 전량 이관을 야간에 수행한다	전송 바이트와 검증 결과, 실패 목록
3	증분 동기화를 주기적으로 돌린다	동기화 소요 시간이 전환 창보다 짧은지
4	전환 창에 원본을 읽기 전용으로 바꾸고 마지막 증분을 돌린다	차이가 0인지
5	DNS 별칭이나 그룹 정책으로 클라이언트 경로를 전환한다	공장 장비가 설정 변경 없이 접근하는지(제약 1)
6	일정 기간 원본을 보존한 뒤 회수한다	되돌릴 수 있는 기간을 확보했는지

5단계가 제약 1의 핵심입니다. 장비 소프트웨어를 못 바꾼다면 이름이 같은 경로를 유지해야 하므로, 서버 이름을 DNS 별칭으로 옮기는 방식이 필요합니다. 새 경로를 알려 주고 각 장비를 재설정하는 계획은 이 제약에서 성립하지 않습니다.

자주 쓰지 않는 데이터의 처리

"최근 3개월만 자주 열린다"는 관찰은 계층화의 근거입니다. 오래된 도면을 S3로 내려 아카이브 클래스에 두면 고성능 파일 시스템의 용량을 줄일 수 있습니다. 보관 기간과 검색 지연 요구를 먼저 정하고 케이스 3 · S3 비용이 매달 늘어난다의 수명 주기 설계를 적용합니다.

비용과 운영에 미치는 영향

구성 요소별 비용·운영 항목 — 금액이 아니라 항목의 성격입니다
구성 요소	비용 항목	운영 항목
FSx for Windows File Server	프로비저닝한 용량과 처리량	백업 정책, 다중 가용 영역 여부 결정
DataSync	전송한 데이터양	에이전트 유지, 작업 실패 감시
Storage Gateway	게이트웨이 사용과 백엔드 스토리지	어플라이언스 자원(캐시 디스크) 관리
인터넷 수신	대체로 무료	업무 시간 대역폭 보호
이후의 내려받기	인터넷 송신은 과금	온프레미스에서 자주 읽는 데이터는 캐시로 흡수
EC2 자체 구축(A안)	인스턴스와 볼륨	패치·백업·이중화·용량 증설 전부 직접

비용 관점의 결론은 방향입니다 — 올리는 것은 대체로 부담이 적고, 내려받는 것이 부담입니다. 따라서 마이그레이션 후에도 온프레미스에서 계속 대량으로 읽는 구조라면 캐시 계층을 남기는 편이 유리합니다. 전송 방향별 구조는 케이스 6 · 데이터 전송 요금이 예산을 넘겼다에서 다룹니다.

설계 체크리스트

요구 확인

필요한 프로토콜(SMB · NFS · iSCSI · 객체)을 명확히 했다
접근 주체가 온프레미스인지 AWS 안인지, 아니면 양쪽인지 정리했다
권한 체계(Active Directory 등)의 이전 방식이 정해졌다
온프레미스를 유지할지 없앨지가 결정되었다
클라이언트가 경로 변경을 감당할 수 있는지 확인했다

이관

전송량과 실제 여유 대역폭으로 소요 기간을 계산했다
초기 이관과 증분 동기화를 나눠 계획했다
대역폭 상한이나 실행 일정을 걸어 업무를 방해하지 않는다
파일 메타데이터와 권한 보존 옵션을 확인했다
전송 후 검증 방식이 정해져 있다
마지막 증분 동기화가 전환 창 안에 끝나는지 시험해 봤다
되돌릴 수 있도록 원본을 일정 기간 보존한다

이관 후

백업과 스냅샷 정책이 새 파일 시스템에도 적용된다
자주 쓰지 않는 데이터의 계층화 규칙이 있다
저장 데이터와 전송 중 데이터가 암호화된다
온프레미스에서의 접근 경로가 인터넷을 거치지 않는다
용량 증가 추이를 감시하고 있다

문제문의 신호와 정답 방향
문제문의 신호	고르는 것	소거하는 것
일회성 또는 주기적 대량 복사	AWS DataSync	Storage Gateway(상시 연결 장치다)
온프레미스 앱이 그대로 파일에 접근하되 저장은 클라우드로	S3 File Gateway	DataSync(옮기는 도구일 뿐이다)
백업 소프트웨어를 바꾸지 않고 테이프를 없앤다	Tape Gateway	S3에 직접 업로드하도록 재작성하는 안
Windows 공유와 AD 권한이 필요하다	Amazon FSx for Windows File Server	Amazon EFS(NFS다)
리눅스 인스턴스 여러 대가 같은 디렉터리를 공유	Amazon EFS	EBS 볼륨(가용 영역에 묶인다)
고성능 병렬 파일 시스템	Amazon FSx for Lustre	Amazon EFS
회선으로는 몇 달이 걸린다	물리 전송 수단 검토	네트워크 전송만 고집하는 안
전용 회선으로 안정적인 대역폭이 필요하다	AWS Direct Connect	인터넷 VPN만 쓰는 안(대역폭이 보장되지 않는다)

이어서 볼 곳

공식 문서 출처

AWS Storage Gateway API 레퍼런스 — ActivateGateway — 게이트웨이 유형 값(STORED · CACHED · VTL · FILE_S3 · FILE_FSX_SMB), 활성화 후 유형을 바꿀 수 없다는 제약, FSx File Gateway가 신규 고객에게 제공되지 않는다는 안내
Amazon FSx API 레퍼런스 — CreateFileSystem — 파일 시스템 유형 4종(WINDOWS · LUSTRE · ONTAP · OPENZFS)
AWS DataSync API 레퍼런스 — CreateTask — 원본·대상 위치와 전송 옵션, 일정 설정
AWS DataSync API 레퍼런스 — Options — 대역폭 상한(BytesPerSecond), 검증 모드, 삭제 반영과 덮어쓰기 옵션
AWS DataSync API 레퍼런스 — CreateAgent — 온프레미스 에이전트 활성화
AWS DataSync 사용 설명서 — 메타데이터 처리 구성 — 권한과 타임스탬프 등 메타데이터가 어떻게 보존되는지
AWS DataSync 사용 설명서 — 데이터 검증 옵션 — 전송 후 무결성 검증 방식