여기서 다루는 내용

· 들어가며
· 데이터를 옮길때 고려할 것
· AWS DataSync 개요
· 테스트 준비
· 테스트 수행
· 결과 리뷰
· 마치며

들어가며

안녕하십니까. GS네오텍 최준승입니다.

저는 빈번하게. “AWS는 말이죠. 제공하는 서비스가 정말 너무너무 많아요”라는 말을 입버릇처럼 합니다.
AWS는 서비스가 너무나 많아서. 보통은 “제가 모든 서비스의 모든 기능들을 다 알수 없다”는 핑계로 사용하곤 하죠.

단순 서비스수도 많지만. 더불어 AWS가 새로 내놓는 각 서비스의 두께? 뎁쓰? 복잡도? 또한 천차만별인데요.

EC2나 S3같이 거대한 뒷배가 느껴지는 초대형 써비스가 있는 반면
오픈소스로 추정되는 뭔가를 적당히 포장해서 매니지드 형태로 만든 캐주얼한 서비스도 심심치 않게 등장하곤 합니다.

후자의 경우 AWS의 생각은 그런것 같습니다. 일단 니즈가 있으면. 서비스든 기능이든 만들고 보자.
개발 및 구현에 대한 부담이나 투입 리소스. 이후 운영관리 비용/리스크는 감수할 수 있을만큼 우리는 이제 깜이 된다.
(실제 아마존 內 여러 사업중 AWS 부문에서 매년 많은 이익이 나고 있구요)

오늘 소개해 드릴 서비스도 그런것들 중 하나입니다.
굳이 서비스로 만들 필요는 없는데. 있으면 사용자가 한번쯤 고려해볼만한.
다른 말로 사용자의 선택지를 넓혀주는 그런 서비스 말이죠.

오늘의 주제는 AWS Datasync라는 서비스입니다.

그럼 시작!

데이터를 옮길때 고려할 것

이런 상황을 단계적으로 나눠서 떠올려 봅시다.

• 여러분들은 어떤 데이터를 AWS로 옮겨야 하는 엔지니어입니다
• 그게 DB면 DMS같은 서비스를 쓰고. VM이면 SMS같은 서비스를 쓰고. 오프라인으로 옮기려면 Snowball을 쓰고. 등등
• 각 계층별로 사용할 수 있는 AWS 서비스가 준비되어 있습니다. 물론 써드파티나 자신만의 방법을 사용해도 됩니다
• 이번에 여러분들이 옮길 대상은 파일입니다. 근데 개수가 좀 많습니다. 용량도 적당히 많습니다
• 물론 cp나 rsync를 사용할 수도 있습니다. 하지만 선택지가 하나 더 있습니다. AWS Datasync 서비스를 쓰는 것이죠

그렇다면 파일묶음을 들어 옮길때 고려할것들은 뭐가 있을까요?

제 뇌피셜로는 다음과 같은 것들을 생각나네요.

• 복제 대상(경로)을 선택적으로 필터링할수 있으면 좋겠어요
• 복제 과정에서 파일 권한이나 타임스탬프 정보도 선택적으로 복제할 수 있음 더 좋고
• 복제 후에 원본 객체가 제대로 복사되었는지 검증하는 로직은 당연히 있어야 하겠죠?
• 복제 작업을 병렬적으로 할 수 있었으면 좋겠어요. 그럼 복제 job을 분할하는 로직이 필요할테고
• On Prem to AWS 뿐만이 아니고. 역방향이나 AWS to AWS 환경에서도 쓸수 있음 좋겠어요. 리전이나 계정을 넘어가는
• 복제 과정에서 원본이나 타겟의 부하를 조절하기 위해 QoS같은 설정도 있음 금상첨화겠죠?

물론 이런 일들은 다른 사람 시키면 제일 편하겠지만.
여러분은 마침 돈도 별로 없고. 팀장도 아니고. 아랫사람도 없고. 마침 내가 담당자인데. 시간도 없습니다.

이런 시점에. 고려할 수 있는 관리형 파일 복제서비스가 바로 AWS DataSync입니다.

AWS DataSync 서비스는 무엇인고?

원하시는 분은 링크타고 공식문서 한번 보고 옵니다.
AWS Documentation – AWS DataSync – What Is AWS DataSync?

뭐 기능이야 둘째 치고. 복제 작업시 어떤 Source와 어떤 Destination를 지원하는지부터 알아야겠죠.

글자는 아무래도 직관성이 떨어지니. AWS가 그려놓은 그림으로 알아봅시다.

※ On Prem의 NFS 데이터를 / AWS의 S3나 EFS로 넘기기

※ AWS의 M-리전의 EFS 데이터를 / N-리전의 EFS로 넘기기

※ AWS의 M-리전의 S3 데이터를 / N-리전의 EFS로 넘기기

보니 앞뒤 대상은 크게 아래 3개의 조합입니다.

• NFS (On Prem or AWS)
• EFS (AWS)
• S3 (AWS)

여기에 추가로 다른 AWS 리전이나 계정으로 넘어가는 구성이 덧붙었다고 보면 됩니다.

자. 이때 복제는 스스로 하는게 아니라. 복제를 중계하는 녀석이 있습니다.
중계하는 녀석에는 Datasync의 Agent가 설치되어 있고.
AWS에서는 Agent를 따로 제공하지는 않고. 대신 Agent가 설치된 VM 이미지를 제공합니다.

아래 2가지 형태로 말이죠.

• On Prem 환경에서 사용하는 VMWare 이미지
• AWS 환경에서 사용하는 Region별 AMI

사전설명은 이쯤하고.
실제 테스트를 통해 어떤 기능들이 있고. 과연 쓸만한건지 살펴보도록 하겠습니다.

테스트 준비

테스트는 아래 시나리오로 진행합니다.

• Source: EFS
• Destination: S3
• Region: EFS와 S3 모두 ap-northeast-2
• 대상: 1MB 파일 100,000개 (총 100GB)
• 중계 서버: m5.4xlarge X 2 (클러스터 구성)

테스트를 위해서는 원본 데이터가 필요합니다.

기존에 만들어 놓은 EFS 파일시스템을 마운트한 후에.
dd 명령어로 더미파일을 다음과 같이 뭉테기로 만들었습니다.

# pwd
/home/ec2-user
# mkdir efs
# sudo mount -t efs fs-57128536:/ efs
# seq -w 1 100000 | xargs -n1 -P 256 -I % dd if=/dev/urandom of=/home/ec2-user/efs/% bs=1024k count=1
(중략)
# du -sh /home/ec2-user/efs
98G /home/ec2-user/efs
# ls | wc -l
100000


자. 이번엔 복사를 중계해주는 EC2 인스턴스를 만들어 보겠습니다.

AWS 공식 페이지에 보시면 친절하게 리전별로 “Launch Instance” 링크가 준비되어 있습니다.

※ 공식 문서상에는 복사하는 파일이 2천만개 미만이면 m5.2xlarge / 이상이면 m5.4xlarge를 권고한다네요

이후 단계는 좀 빨리 진행하겠습니다.

• VPC: 편의상 EFS 객체가 위치한 VPC 선택
• EBS: 복사 과정에서 추가 스토리지는 필요 없으므로 기본값 80GB
• Security Group: 기본적으로 Outbound는 Any Open, Inbound는 TCP:80만 Any로 열어놨음

참고로 Agent(가 설치된 인스턴스)를 기점으로 아웃바운드 통신을 다양하게 하므로. 이 부분은 ACL을 확인하셔야 합니다.
VPC 환경이면 상대적으로 고려할 점이 적은데 만약 VM을 On Prem 환경에 VMWare 이미지로 배포하셨다면. 신경쓸 부분이 많아집니다.

※ AWS 안내 참고. 저는 편의상 EC2(Agent가 설치된) 인스턴스를 Public Subnet에 위치시키고. Public IP도 할당했습니다

EC2 인스턴스 배포가 끝났으면. 인스턴스의 Public IP값을 복사해 놓구요.
이번엔 해당 Agent를 활성화 시키도록 하겠습니다.

[AWS Management Console] ▷ [AWS DataSync] ▷ [Agents] ▷ [Create Agent]

※ Agent Address 항목에 Agent가 설치된 EC2 인스턴스의 Public IP를 입력

※ 정상적으로 활성화되었으면 위와 같이 Activation key값이 표시됨

이어 Location을 설정해 보겠습니다.

참고로 저는 복제 작업에 2대를 사용할거라. 아래처럼 2대의 인스턴스를 미리 활성화시켜 두었습니다.

※ 2대가 Online 상태로 준비중. 참고로 각 인스턴스의 사양은 m5.4xlarge

Source와 Destination Location 객체를 각각 만들 예정이구요.

Source용 Location 먼저.
참고로 Source쪽 성능상 병목을 방지하고자 EFS의 성능 모드는 충분한 수치의 Provisioned Throughput 모드로 변경해 놓았습니다.

[AWS Management Console] ▷ [AWS DataSync] ▷ [Locations] ▷ [Create Location]

※ 참고로 S3로 복제할때는 EFS 객체를 NFS Type으로 만들어줘야 함. Agent는 2개를 선택하고 NFS Server에 EFS의 Private IP를 입력

이번엔 Destination으로 사용할 Location 생성.

[AWS Management Console] ▷ [AWS DataSync] ▷ [Locations] ▷ [Create Location]

※ S3는 버킷명과 Path 말고는 딱히 선택할게 없네요. 필요한 권한이 들어간 IAM Role은 자동 생성함

이제 참조할만한 모든 변수 및 객체가 셋팅되었습니다.

테스트 수행

이제 복제 Task를 생성해 봅시다.

[AWS Management Console] ▷ [AWS DataSync] ▷ [Tasks] ▷ [Create Task]

※ 앞에서 만들어 놓은 nfs 객체를 source로 지정

※ 앞에서 만들어 놓은 s3 객체를 destination으로 지정

※ 복사 과정에서 활용할 수 있는 옵션이 무엇이 있는지 여러분도 확인해보세요. QoS도 지정할 수 있네요?

※ 특정 경로를 제외(Exclude)할 수 있습니다. 업데이트가 활발한 경로를 지정하면 적절하겠죠?

※ 지정한 설정에 문제가 없다면 위처럼 Task Status가 Available 상태가 됩니다

참고로 여기까지 오기까지 저는 무수한 시행착오가 있었습니다.
Task 상태가 Unavailable이 뜨는데. 어느 부분에서 문제가 발생한건지 구체적인 메시지가 없어서 애를 먹었죠.

암튼 트러블슛 관련해서는 따로 AWS 문서가 있으니 참고하시고. 모든 준비가 되었으면 “Start” 버튼을 누르시면 됩니다.

결과 리뷰

Task는 아래 순서로 진행됩니다.

진행상황은 실시간으로 확인할 수 있으며.
작업이 완료되면 아래와 같이 간단한 레포팅을 제공합니다.

※ 1MB 파일 100,000개 = 100GB를 복제하는데 약 8분 30초가 걸렸네요

자. 이제 추가적으로 고려할 점 몇가지만 훑고 넘어갑시다.

• Performance: 복제 계층의 성능 외에도. Source/Destination 계층의 성능 요소(병목 구간)를 통합적으로 고려해야 함
• ACL: Agent가 설치된 VM에서 NFS 객체 등으로 접근이 가능해야. D/X든 VPC Peering이든 라우팅이 되고 ACL이 열려있음 OK
• Price: DataSync는 복제한 데이터량 기준 과금(0.0125$/GB) 이외 예시에서는 EC2 인스턴스 비용과 S3 Put API 요금 추가

끝났습니다. 정리하겠습니다.

마치며

오늘은 좀 글이 길었습니다.

처음에는 데이터 이전과 관련하여 고객사 문의가 있었구요.
복제하는 여러가지 방안을 검토하는 중에 이런 서비스가 있어서 한번 써볼까? 했던게.. 여기까지 왔네요.
더불어 참조할만한 블로그글이 한국어도 없고 영어도 없어서. 정리 차원에서 이 포스팅을 작성하게 되었구요.

제가 이 서비스를 막상 써보니. 좋은점은 이런것 같습니다.

• 서비스 사용법을 안다는 가정하에. 관리형 서비스라 초기 Task 셋팅이 쉽다
• 복제 작업에 필요한 필수 요소들을 어느정도 제어할 수 있다
• 복제 계층에 대한 클러스터 구성이 쉽다

3줄 요약했으니 마치도록 하겠습니다.

그럼 끝!