애플리케이션 마이그레이션 서비스를 사용할 때 나타나는 Windows 소스 서버의 복제 지연 시간이나 백로그 문제를 해결하려면 어떻게 해야 하나요?

7분 분량

AWS 애플리케이션 마이그레이션 서비스를 사용해 데이터를 복제할 때 Windows 소스 서버에 지연 시간이나 백로그가 발생합니다.

간략한 설명

소스 서버에서 대상 서버로 데이터를 복제할 때 복제 지연 시간과 백로그가 발생하는 요인은 다음과 같습니다.

네트워크 업링크 속도 및 대역폭 가용성: 소스 서버와 복제 서버 간 네트워크 연결 속도는 복제 성능에 상당한 영향을 미칩니다. 연결 속도가 느리면 복제 프로세스가 완료되지 않을 수 있습니다. 또한 대역폭이 제한되면 주어진 시간 내에 복제할 수 있는 데이터의 양도 제한됩니다.
복제 중 디스크 변경 사항: 복제 프로세스 중에 소스 서버는 디스크에 새 데이터를 계속 쓸 수 있습니다. 소스 서버가 쓰는 새 데이터의 양이 급증하면 데이터가 누적되어 상당한 백로그가 발생합니다. AWS Replication Agent를 초기 동기화를 할 때 이 백로그를 전송해야 합니다. 백로그가 클수록 데이터 복제를 완료하는 데 시간이 더 오래 걸립니다.
스토리지 디스크의 I/O 속도: 복제 프로세스 중에 AWS Replication Agent는 디스크의 스토리지 블록을 읽고 데이터를 복제 서버로 전송합니다. 그러나 원본 서버 디스크에서 읽기 대기 시간이 오래 걸리면 데이터 복제의 속도와 효율성에 영향을 미칠 수 있습니다. 디스크가 느리면 지연이 발생하고 디스크가 빠르면 복제 속도가 향상됩니다.
소스 서버 로드: 소스 서버의 리소스 경합으로 인해 CPU 사용률, 메모리 소비, I/O 대기, 기타 리소스 제약이 늘어날 수 있습니다. 예를 들어 CPU 사용률이 높으면 복제 병목 현상이 발생할 수 있습니다. AWS Replication Agent와 다른 프로세스 간에 CPU 리소스를 할당할 때 시스템이 어려움을 겪기 때문입니다. 마찬가지로 메모리를 많이 사용하면 시스템에서 메모리 페이지를 디스크로 교체할 수 있습니다. 이로 인해 I/O 대기 시간이 늘어나고 복제 프로세스가 느려집니다.
프로비저닝이 부족한 복제 리소스: 처리량과 IOPS가 낮은 Amazon Elastic Block Store(Amazon EBS) 볼륨을 준비하면 읽기와 쓰기 지연 시간이 길어지고 대기열 길이가 길어질 수 있습니다. 이 같은 문제는 복제 성능에 영향을 줍니다. 또한 네트워크 처리량이 낮고 Amazon EBS 대역폭이 낮은 복제 서버 인스턴스 유형은 복제 성능 문제로 이어집니다.

해결 방법

지연 시간이 생기는 원인을 알아보려면 먼저 소스 서버를 검사합니다. 그 다음 준비 영역을 확인합니다.

소스 서버 검사

소스 서버가 부팅되어 실행 중인지 확인

마이그레이션 할 소스 서버가 부팅되어 실행 중인지 확인합니다.

AWS Replication Agent 프로세스가 실행 중인지 확인

PowerShell에서 다음 명령을 실행하여 실행 중인 AWS Replication Agent 서비스 목록을 확인합니다.

get-service | where-object name -like “*AWSR*”

다음 출력에서 실행되는 기본 서비스를 확인할 수 있습니다. 기본 AWSReplicationService가 실행 중인지 확인합니다.

PS C:\Users\Administrator> get-service | where-object name -like “*AWSR*”

Status   Name               DisplayName
------   ----               -----------
Running  AwsReplicationD... AwsReplicationDriverLogger
Running  AwsReplicationL... AwsReplicationLogger
Stopped  AwsReplicationP... AwsReplicationPostConvertService
Running  AwsReplicationS... AwsReplicationService
Running  AwsReplicationV... AwsReplicationVolumeUpdaterService

또는 Windows + R을 눌러 services.msc를 입력한 후 Enter키를 누릅니다. AWSReplicationService가 실행 중인지 확인합니다.

활성 TCP 연결 확인

TCP 포트 1500의 복제 서버에 활성 TCP 연결이 5개인지 확인합니다.

다음 명령을 실행합니다.

C:\Users\Administrator>netstat -an | find "1500"

명령 출력에서 활성 연결을 확인합니다.

TCP    172.31.82.135:50929    <Replicator Instance IP>:1500    ESTABLISHED
TCP    172.31.82.135:50930    <Replicator Instance IP>:1500    ESTABLISHED
TCP    172.31.82.135:50931    <Replicator Instance IP>:1500    ESTABLISHED
TCP    172.31.82.135:50933    <Replicator Instance IP>:1500    ESTABLISHED
TCP    172.31.82.135:50934    <Replicator Instance IP>:1500    ESTABLISHED

Windows 리소스 모니터를 사용해 소스 서버의 성능 확인

AWS Replication Agent는 한 번에 CPU 코어 한 개에서 작동합니다. AWS Replication Agent를 실행 중인 코어의 CPU 사용률이 높으면 데이터 복제가 느려집니다. CPU 사용률을 확인하려면 다음 단계를 따르세요.

다음 방법 중 하나를 사용해 Windows 리소스 모니터를 시작합니다.

작업 관리자의 성능 탭에서 리소스 모니터 열기를 선택합니다.
제어판에서 관리 도구, 리소스 모니터를 선택합니다.
명령줄이나 PowerShell에서 resmon.exe를 실행합니다.
Windows 아이콘을 선택하고 resmon.exe를 입력합니다.

AWS Replication Agent를 실행 중인 CPU 코어의 CPU 사용률을 확인합니다.

해당 코어에서 CPU 사용률이 높으면 CPU에서 소비량이 가장 많은 프로세스가 무엇인지 확인합니다.
에이전트는 CPU를 최소 5% 사용합니다. 에이전트가 데이터를 복제하는 데 사용할 수 있는 CPU가 충분한지 확인합니다.

소스 서버의 디스크 성능을 확인합니다.

쓰기(B/초)와 응답 시간 지표를 확인합니다.

디스크 활동에서 해당 지표를 확인할 수 있습니다. 소스 디스크의 읽기 처리량이 낮으면 에이전트가 읽고 복제하는 데이터 양이 줄어듭니다. 디스크 읽기 및 쓰기 지표가 증가하는지 확인합니다.

**참고:**복제된 데이터를 TCP 포트 1500을 통해 전송하는 데 필요한 대역폭은 해당 소스 서버의 쓰기 속도에 따라 정해집니다. 대역폭은 최소한 복제된 원본 컴퓨터의 평균 쓰기 속도를 모두 합한 것 이상으로 확보하는 것이 가장 좋습니다.

소스 서버에서 쓰기 작업이 급증했는지 확인합니다.

디스크 활동에서 쓰기 작업을 확인하려면 쓰기(B/sec)를 확인하세요.

워크로드가 변경되면 주기적으로 디스크 성능을 점검하여 I/O 로드를 결정합니다. 쓰기 처리량(MB/s)이 제공된 네트워크 처리량을 초과하면 복제 지연 시간이 발생합니다.

참고: 원본 서버부터 복제 서버까지 필요한 대역폭을 계산하려면 TCP 포트 1500에 필요한 대역폭 계산을 참고하세요.

원본 서버가 용량을 쓰기로 많이 사용하고 있고 쓰기 속도가 복제 속도보다 빠르면 백로그가 계속 늘어납니다.

소스 서버부터 준비 영역 서브넷까지 복제 속도 및 사용 가능한 대역폭 확인

속도 테스트를 실행하는 방법에 대한 자세한 내용은 SSL 연결 및 대역폭 테스트를 하려면 어떻게 해야 하나요?를 참고하세요.

소스 서버가 비정상적으로 종료되었는지 확인

소스 서버가 비정상적으로 종료된 경우 AWS Replication Agent에서는 서버가 재부팅된 후 모든 디스크를 재스캔합니다. AWS Replication Agent에서는 디스크를 다시 읽으며 재스캔이 완료될 때까지 지연 시간이 계속 증가합니다. 자세한 내용은 재부팅할 때 다시 스캔을 하지 않는 Windows와 Linux OS는 무엇인가요?를 참고하세요.

원본 컴퓨터가 어떻게 종료되었는지 확인하려면 다음 단계를 따르세요.

1.Windows + R을 누르고 eventvwr.ms를 입력한 후 Enter키를 누릅니다.

2.이벤트 뷰어에서 Windows 로그를 두 번 클릭하여 확장합니다.

시스템을 마우스 오른쪽 단추로 클릭합니다.
현재 로그 필터링을 선택합니다.

5.이벤트 소스 가까이에 있는 드롭다운 화살표를 클릭하고 USER32를 선택합니다.

**<All Event IDs>**필드에 1074를 입력하고 확인을 선택합니다. 이벤트 뷰어에 전원 끄기(종료) 및 재시작 종료 유형 이벤트 목록이 표시됩니다.
예상치 못한 컴퓨터 종료가 발생한 날짜와 시간을 보려면 에 6008을 입력합니다. <All Event IDs> 필드를 선택하고 확인을 선택합니다.

TCP 포트 1500에서 아웃바운드가 차단되었는지 확인

원본 서버에서 복제 서버로의 아웃바운드가 TCP 포트 1500에서 차단되었는지 확인합니다.
다음 예시와 같이 복제기 인스턴스 IP 주소에 Telnet이나 TNC를 실행할 수 있습니다.

CMD에서: Telnet <replication subnet IP address> 1500
PowerShell에서: TNC <replication subnet IP address> -port 1500

로컬 방화벽이 TCP 포트 443을 통해 원본 서버와 복제 서버 간의 연결을 허용하는지 확인합니다. OS 방화벽에서 연결을 허용하려면 다음 단계를 따르세요.

소스 서버에서 Windows 방화벽 콘솔을 엽니다.
콘솔 트리에서 아웃바운드 규칙 옵션을 선택합니다.
아웃바운드 규칙 테이블에서 원격 포트 - 1500 연결과 연관된 규칙을 선택합니다. 활성화 상태가 Yes로 되어 있는지 확인합니다.
규칙 활성화 상태가 No인 경우, 마우스 오른쪽 버튼을 클릭하고 규칙 활성화를 선택합니다.

TCP 포트 1500을 통한 트래픽을 허용하려면 회사 방화벽에서 이 연결을 허용해야 합니다.

참고: SSL 속도 테스트나 iperf 테스트를 실시할 수도 있습니다. 자세한 내용은 SSL 연결 및 대역폭 테스트를 하려면 어떻게 해야 하나요?를 참고하세요.

소스 서버의 복제 설정에서 대역폭 제한을 해제했는지 확인

소스 서버의 복제 설정에서 대역폭 제한 옵션을 해제합니다. 대역폭 제한 옵션을 해제하면 소스 서버에서 준비 영역 서브넷으로 데이터를 전송하기에 충분한 대역폭을 유지하는 데 도움이 됩니다.

소스 서버에서 대역폭 제한을 활성화하면 지속적이거나 정체된 지연 시간 증가가 발생합니다. 이는 대역폭을 제한함으로 인해 소스 서버에서 복제 서버로 복제되는 데이터를 제한하기 때문입니다.

대역폭 제한 옵션을 확인하려면 다음 단계를 따르세요.

애플리케이션 마이그레이션 서비스 콘솔을 엽니다.
설정에 있는 데이터 라우팅 및 제한에서 복제 템플릿을 선택합니다.
네트워크 대역폭 제한 옵션이 활성화되어 있는 경우, 해당 값을 확인하고 안내된 복제 속도와 비교합니다. 자세한 내용은 이전 섹션인 소스 서버부터 준비 영역 서브넷까지 복제 속도 및 사용 가능한 대역폭 확인을 참고하세요.

준비 영역 리소스 검사

TCP 포트 1500에서 인바운드가 차단되었는지 확인

복제 서버 보안 그룹에서 TCP 포트 1500이 인바운드 차단되지 않았는지 확인합니다.

**참고:**Amazon Elastic Compute Cloud(Amazon EC2) 콘솔에서 다음 단계를 완료해야 합니다.

Amazon EC2 콘솔을 엽니다.
복제기 인스턴스에 연결된 보안 그룹을 선택합니다.
연결된 보안 그룹에 인바운드 TCP 포트 1500이 허용되는지 확인합니다.

대상 리전의 스냅샷 할당량 확인

원본 서버를 복제하는 리전에서 AWS 계정이 스냅샷 할당량 한도에 도달했는지 확인합니다. 다음 AWS Command Line Interface(AWS CLI) 명령을 실행해 리전 스냅샷 할당량에 도달했는지 확인합니다. 다음 예시에서 리전을 원하는 대상 지역으로 바꾸세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하면 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value"  
# aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"