클라우드 마이그레이션: 파일 전송 전략 가이드

클라우드 마이그레이션 파일 전송 전략은 세 가지 결정에 달려 있습니다. 전송 경로(공용 인터넷, Direct Connect, 또는 물리적 어플라이언스), 전환 모델(빅뱅, 단계적, 또는 병렬 실행), 신뢰할 무결성 검사. 1 Gbps 회선으로 50 TB 데이터를 이전하면 순수 전송 시간은 약 5일이 걸립니다. 압축하면 줄어들고 회선을 공유하면 늘어납니다. 툴링을 선택하기 전에 순서를 계획하고, 재시도와 검증에 20%의 여유를 확보하세요.

회선을 건드리기 전에 데이터셋 파악

AWS DataSync, Azure AzCopy, Google Storage Transfer Service를 선택하기 전에 실제로 무엇이 있는지 인벤토리를 작성하세요. 파일 공유에서 du -sh를 실행하고, 데이터베이스 카탈로그에서 행 수를 쿼리하고, 오브젝트 스토어 매니페스트를 내보냅니다. 한 회사는 NAS에 8 TB가 있다고 생각했지만, 스냅샷과 숨겨진 ~$ Office 잠금 파일을 포함하면 실제 수치는 34 TB였습니다.

세 가지 축으로 인벤토리를 분류하세요. 크기, 변경 빈도, 규제 중요도. 1 MB 미만 파일은 객체당 오버헤드 때문에 바이트당 이동이 느립니다. 2억 개의 소형 파일이 담긴 버킷은 10 TB 비디오 버킷보다 오래 걸릴 수 있습니다. 매일 변경되는 핫 데이터와 PDF 아카이브, 2017년 인보이스 같은 콜드 데이터를 별도로 분류하세요. 콜드 데이터는 몇 주 앞서 이전할 수 있고, 핫 데이터는 전환 시점까지 동기화 로직이 필요합니다.

일정에 맞는 전송 경로 선택

10 TB 미만에 양호한 광섬유 회선이 있다면 TLS 1.3을 통한 온라인 전송이 보통 유리합니다. 10 TB에서 500 TB 사이는 기업 WAN을 포화시키지 않도록 AWS Direct Connect 또는 Azure ExpressRoute를 예약하거나 프로비저닝하세요. 500 TB 이상은 물리적 시딩이 인터넷을 이깁니다. AWS Snowball Edge는 80 TB를 담고, Snowmobile은 컨테이너 트럭으로 엑사바이트를 이동하며, Azure Data Box Heavy는 1 PB를 저장합니다.

계산을 정직하게 하세요. 1 Gbps(125 MB/s 이론, 오버헤드 후 현실적으로 80 MB/s)에서 100 TB는 중단 없는 전송으로 약 14일이 필요합니다. 운영 윈도우가 48시간이라면 회선은 현실적이지 않습니다. 디스크를 배송하세요. 이그레스도 계산하세요. 이전 공급자에서 100 TB를 이전하면 GB당 $0.09 이그레스로 대상지를 건드리기도 전에 $9,000이 발생합니다.

무결성: 신뢰하되 체크섬 확인

모든 마이그레이션에는 전송 계층 TLS만이 아닌 종단간 무결성 검증이 필요합니다. 소스에서 SHA-256 또는 xxHash64 해시를 생성하고, 페이로드와 함께 전송하고, 대상에서 다시 해시합니다. AWS DataSync는 기본으로 이를 수행합니다. rsync는 --checksum으로 강제하고, rclone은 --check-first와 crypt 백엔드를 지원합니다.

컴플라이언스 워크로드의 경우 전체 보존 기간 동안 경로, 바이트 수, 해시가 담긴 CSV 매니페스트를 보관하세요. HIPAA 적용 기관은 45 CFR 164.312(c)(1) 무결성 통제에 따라 모든 객체를 기록해야 하며, GDPR 제5조(1)(f)는 전송 중 파일이 변경되지 않았음을 증명할 것을 요구합니다. DICOM 스터디에서 한 바이트라도 어긋나면 방사선과 뷰어가 열기를 거부할 수 있습니다.

델타 동기화로 다운타임 최소화

빅뱅 전환은 불면의 적입니다. 대신, 몇 주 전에 초기 대량 복사를 수행하고, 전환 윈도우까지 야간에 증분 델타를 실행하세요. Rclone(--update --use-server-modtime), AzCopy(--overwrite=ifSourceNewer), Google의 gsutil rsync -d 같은 도구는 mtime 또는 해시로 변경된 파일을 감지해 델타만 이동합니다.

데이터베이스는 별도 계획이 필요합니다. 2 TB PostgreSQL 인스턴스에는 pg_basebackup과 WAL 전달을 사용하고, MySQL에는 대상에 레플리카를 구성하고 전환 시 승격합니다. rsync를 통한 파일 시스템 델타는 최종 동기화를 시간에서 분으로 줄일 수 있어, 보통 토요일 밤 유지보수 윈도우 안에 들어맞습니다.

대역폭 제어와 시간대별 전송

WAN의 모든 대역폭을 독점하는 마이그레이션은 나쁘게 끝납니다. 출근 전부터 헬프데스크 티켓이 쌓입니다. 적극적으로 제한하세요. AzCopy는 --cap-mbps를 허용하고, rclone은 낮/밤 속도를 위한 --bwlimit 50M:100M을 지원하며, DataSync는 시간당 대역폭 상한으로 작업을 예약합니다. 합리적인 정책: 업무 시간에는 회선의 30%, 야간에는 90%, 주말에는 100%.

방화벽에서도 트래픽을 분리하세요. 마이그레이션 플로우에 DSCP 값을 태그하여 QoS 정책이 카카오톡이나 Zoom 통화를 굶기지 않도록 합니다. MPLS를 지사에 사용 중이라면 마이그레이션 트래픽이 본사를 경유하지 않고 로컬로 출구를 찾도록 SD-WAN 브레이크아웃을 고려하세요.

전송 중 민감 데이터 처리

PII, PHI, 또는 카드 소지자 데이터가 포함된 마이그레이션은 관련 기준을 충족하는 암호화가 필요합니다. TLS 1.3이 최소 기준이며, 스테이징 중 저장된 파일에는 업로드 전 AES-256-GCM으로 래핑하세요. PCI DSS 4.0 요건 4.2.1은 공용 네트워크를 통한 카드 소지자 데이터에 강력한 암호화를 의무화하고, HIPAA의 암호화 표준은 ePHI에 사실상 필수입니다.

마이그레이션 중 소규모 배치의 임시 전송(컨설턴트가 Salesforce 테이블을 내보내거나 DBA가 자격 증명 저장소를 이동하는 경우)에는 종단간 암호화 도구가 키를 전송 공급자의 손이 닿지 않는 곳에 유지합니다. HexaTransfer는 마이그레이션 중 일회성 파일을 깔끔하게 처리합니다. 암호화는 서버에 닿기 전 브라우저에서 이루어집니다.

실제 전환 전 드레스 리허설

일부를 대상으로 마이그레이션을 연습하세요. 마케팅 공유 드라이브의 300 GB처럼 한 부서를 선택해 전체 파이프라인을 실행하세요. 소스 인벤토리, 전송, 체크섬 검증, 권한 매핑, 애플리케이션 장애 조치. 각 단계를 측정하고 무엇이 중단되었는지 문서화하세요.

흔한 놀라움: S3 버킷 정책에 깔끔하게 매핑되지 않는 NTFS ACL, rclone이 파일로 처리하는 심볼릭 링크, 애플리케이션 설정에 포함된 SMB 공유 경로, Windows와 Linux 대상 간의 대소문자 구분 차이. 이런 문제들은 스테이징에서 해결하세요. 오픈 당일 새벽 2시가 아니라. 1주일이 걸리는 리허설이 1개월이 걸리는 롤백을 방지합니다.

마이그레이션 후 검증

검증 후에만 성공을 선언하세요. 소스와 대상의 객체 수, 총 바이트, 임의 1% 해시 샘플을 비교하세요. 애플리케이션 메트릭을 조회하세요. 문서 관리 시스템이 420만 개 파일을 보고했는데 대상에 419만 개가 표시된다면, 소스를 끄기 전에 누락된 10,000개를 찾으세요.

전환 후 최소 30일간 소스를 읽기 전용으로 유지하세요. 사용자들은 인벤토리된 공유 폴더가 아닌 ~/Desktop/old_stuff/에 있어서 마이그레이션되지 않은 파일이 반드시 필요한 상황이 생깁니다. 예산을 확보하고 놀라지 마세요. 롤백 런북은 필요하기 전에 작성하세요.

hexatransfer.com에서 사용해보세요 — 무료, 계정 불필요, 최대 10 GB.