Application Migration Service용 Linux 소스 서버의 복제 지연 또는 백로그 문제를 해결하려면 어떻게 해야 할까요?

9분 분량
0

AWS Application Migration Service를 사용하여 데이터를 복제할 때 Linux 소스 서버에 지연 또는 백로그가 발생합니다.

간략한 설명

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

  • 네트워크 업링크 속도 및 대역폭 가용성: 소스 서버와 복제 서버 간의 네트워크 연결 속도는 복제 성능에 상당한 영향을 미칠 수 있습니다. 연결 속도가 느리면 복제 프로세스가 완료되지 않을 수 있습니다. 또한 제한된 대역폭은 주어진 시간에 복제할 수 있는 데이터의 양을 제한합니다.
  • 복제 중 디스크 변경 사항: 복제 프로세스 중에 소스 서버가 계속해서 새 데이터를 디스크에 쓸 수도 있습니다. 소스 서버에서 쓰는 새 데이터의 양이 급증하면 데이터가 누적되어 상당한 백로그가 생성됩니다. 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 대역폭이 낮은 복제 서버 인스턴스 유형은 복제 성능 문제를 야기합니다.

해결 방법

지연의 근본적인 원인을 확인하려면 먼저 소스 서버에서 검사를 수행합니다. 그런 다음 스테이징 영역에서 검사를 수행합니다.

소스 서버 검사

소스 서버가 부팅되어 실행 중인지 확인합니다.

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

원본 서버가 지역 Application Migration Service API 엔드포인트 및 복제 서버와 SSL 연결을 설정할 수 있는지 확인합니다.

원본 서버와 Application Migration Service API 엔드포인트 간의 어느 시점에서도 SSL 인증서를 가로채서 변경하지 않았는지 확인합니다. 또한 원본 서버와 복제 서버 사이에서 SSL 인증서를 가로채서 변경하지 않았는지 확인합니다. 이 작업을 수행하려면 다음 명령을 실행합니다.

# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443
# echo -n | openssl s_client -connect <replication server IP>:1500

참고:다음 활성 TCP 연결 확인 섹션에 나열된 명령을 사용하여 복제 서버의 IP 주소를 찾을 수 있습니다.

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

다음 명령을 실행하여 실행 중인 AWS Replication Agent 서비스를 나열합니다.

# ps -u aws-replication

다음 출력은 실행해야 하는 AWS Replication Agent 프로세스를 보여줍니다.

 PID  TTY TIME    CMD
 30878 ? 00:00:00 update_onprem_v
 30879 ? 00:00:00 run_linux_migra
 30880 ? 00:00:00 tailer
 30881 ? 00:04:45 java
 30902 ? 00:00:01 tailer
 30904 ? 00:00:00 run_linux_migra
 30905 ? 00:00:10 update_onprem_v
 31023 ? 00:00:00 tail

활성 TCP 연결 확인

다음 명령을 실행하여 TCP 포트 1500에서 복제 서버와 5개의 활성 TCP 연결이 설정되어 있는지 확인합니다.

# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'

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

tcp6       0      0 172.31.1.39:54814       172.31.0.82:1500        ESTABLISHED 30881/java          
tcp6       0      0 172.31.1.39:54828       172.31.0.82:1500        ESTABLISHED 30881/java          
tcp6       0      0 172.31.1.39:54832       172.31.0.82:1500        ESTABLISHED 30881/java          
tcp6       0      0 172.31.1.39:54812       172.31.0.82:1500        ESTABLISHED 30881/java          
tcp6       0      0 172.31.1.39:54800       172.31.0.82:1500        ESTABLISHED 30881/java

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

AWS Replication Agent는 한 번에 하나의 CPU 코어에서 작동하는 단일 스레드 프로세스입니다. AWS Replication Agent가 실행되는 코어의 CPU 사용률이 높으면 데이터 복제 속도가 느려집니다.

  1. 다음 명령을 실행한 후 출력을 검토하여 다음 사항을 확인합니다.
  • AWS Replication Agent의 프로세스 ID.
  • 에이전트를 실행 중인 CPU 코어(psr로 표시).
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm

# mpstat -P <psr column value> 3
  1. 그런 다음 식별된 CPU 코어의 CPU 사용률을 확인합니다.

소스 서버의 디스크 성능 확인

소스 디스크의 읽기 처리량(rMB/s)이 낮으면 읽고 복제되는 데이터가 줄어듭니다. I/O 깊이(avgqu-sz)I/O 대기(await) 지표의 증가를 기록해 두세요. sar 또는 iostat 도구를 사용하여 디스크 읽기 처리량을 측정할 수 있습니다.

# iostat -myx 3
# sar -dp 2

소스 서버에서 쓰기 작업이 급증하지 않았는지 확인

소스 서버의 쓰기 작업이 급증하면 복제 지연이 증가할 수 있습니다. 이러한 증가는 AWS Replication Agent가 기록된 모든 데이터를 복제 서버로 플러시할 때까지 계속됩니다. iostat 테스트를 정기적으로 실행하여 워크로드 변화에 따른 I/O 로드를 확인합니다. 쓰기 처리량(wMB/s) 이 사용 가능한 네트워크 처리량을 초과하면 복제 지연이 나타납니다.

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

원본 서버에서 스테이징 영역 서브넷으로의 복제 속도 및 사용 가능한 대역폭을 확인합니다.

  1. 대상 AWS 리전에서 게시 AMI CE-ssl-speedtest를 사용하여 테스트 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 시작합니다. EC2 인스턴스는 복제 서버와 동일한 인스턴스 유형이어야 합니다.

  2. 소스 서버의 복제 설정에 사용된 서브넷과 동일한 서브넷을 선택합니다.

  3. 보안 그룹이 TCP 포트 1500 인바운드 액세스를 허용하는지 확인합니다.

  4. 소스 서버에서 다음 예와 같이 SpeedTest CLI를 구성합니다.

# cd /tmp
# git clone https://github.com/librespeed/speedtest-cli.git
# cd speedtest-cli/
# ls -l
# ./build.sh
# cat << EOF >> ./servers.json
[
  {
    "id": 1,
    "name": "PHP Backend",
    "server": "https://<test server private IP>:1500/speedtest/",
    "dlURL": "/garbage.php",
    "ulURL": "/empty.php",
    "pingURL": "/empty.php"
  }
 ]
EOF

**참고:**위 예시에서는 테스트 서버의 IP 주소를 바꿔야 합니다. 테스트 서버의 퍼블릭 IP를 속도 테스트에 사용하는 경우 “pingURL” 줄 뒤에 **“getIpURL”: "/getIP.php“**를 포함하세요.

  1. 다음 예와 같이 LibreSpeed CLI를 실행하여 복제 속도를 테스트합니다.
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple
Ping: 11.00 ms Jitter: 0.00 ms
Download rate: 503.84 Mbps
Upload rate: 493.56 Mbps

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

소스 서버가 비정상적으로 종료된 경우 AWS Replication Agent는 서버가 재부팅된 후 모든 디스크를 재스캔합니다. AWS Replication Agent는 디스크를 다시 읽으며, 재스캔이 완료될 때까지 지연이 계속 증가합니다. 자세한 내용은 재부팅 시 재스캔 금지를 지원하는 Windows 및 Linux 운영 체제는 무엇입니까?를 참조하세요.

커널 업그레이드 확인

소스 서버에서 커널을 업그레이드하고 서버를 재부팅하면 AWS Replication Agent가 실행되지 않습니다. 실행 중인 커널 버전은 에이전트 설치 중에 AWS Replication Agent 드라이버가 컴파일된 커널 버전과 일치합니다.

다음 명령을 실행하여 실행 중인 커널 버전이 AWS Replication Agent 드라이버가 컴파일된 커널 버전과 일치하는지 확인합니다.

$ uname -r
$ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko

참고: vermagic은 커널 드라이버가 컴파일된 커널 버전을 확인하는 데 사용됩니다.

TCP 포트 1500이 아웃바운드로 차단되지 않았는지 확인

TCP 포트 1500이 소스 서버에서 복제 서버로의 아웃바운드로 차단되지 않았는지 확인하세요.

MGN 에이전트 로그 검토

TCP 포트 1500의 복제 서버와의 연결 문제가 있는지 MGN 에이전트 로그를 검사합니다. 또한 잦은 연결 손실을 나타내는 복제 불규칙성이 있는지 확인합니다. 이러한 문제를 식별한 후 네트워크 토폴로지를 검토하여 추가로 조사합니다.

중간 디바이스의 MTU가 낮지 않은지 확인

복제 경로의 중간 디바이스 중 MTU가 더 낮은 것이 없는지 확인합니다. MTU가 낮으면 복제 속도가 느려지고 프로세스가 지연됩니다. 복제 경로 전체에서 일관된 MTU 크기를 유지하는 것이 가장 좋습니다. 경로에 있는 디바이스의 MTU가 낮으면 해당 디바이스를 업데이트하거나 상위 MTU 디바이스로 교체하세요.

**참고:**퍼블릭 인터넷을 통해 복제하는 경우 MTU가 1500인지 확인하세요. 1500은 인터넷 게이트웨이, 피어링 및 VPN이 지원하는 최대값입니다. 점보 프레임은 Amazon Virtual Private Cloud(VPC) 또는 AWS Direct Connect 내에서만 작동하며 자체 제한이 있습니다. 자세한 내용은 다음을 참조하세요.

소스 서버의 복제 설정에서 네트워크 대역폭 제한이 꺼져 있는지 확인

소스 서버의 복제 설정에서 대역폭 제한을 꺼야 합니다.

소스 서버에서 대역폭 제한을 켜면 AWS Replication Agent의 데이터 전송 속도가 조절됩니다. 이로 인해 소스 서버에 백로그가 있는 경우 지연 증가가 지속적이거나 정체될 수 있습니다. 데이터 전송을 위해 일정하고 제한된 대역폭을 유지하려면 네트워크 대역폭 제한을 켜세요.

대역폭 제한을 확인하려면 다음 단계를 완료하세요.

  1. Application Migration Service console(Application Migration Service 콘솔)을 엽니다.

  2. Source servers(소스 서버)를 선택한 다음 소스 서버를 선택합니다.

  3. Replication settings(복제 설정) 탭을 선택합니다.

  4. Throttle network bandwidth(네트워크 대역폭 제한)이 켜져 있는 경우 전송률 조절 값이 데이터 복제에 필요한 대역폭과 같거나 그보다 큰지 확인하세요. 자세한 내용은 이전 섹션의 참고 사항인 소스 서버에서 쓰기 작업이 급증하지 않았는지 확인을 참조하세요.

스테이징 영역 리소스 검사

TCP 포트 1500이 인바운드로 차단되지 않았는지 확인

TCP 포트 1500이 복제 서버의 보안 그룹에서 인바운드로 차단되지 않았는지 확인하세요.

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

  1. Amazon EC2 console(Amazon EC2 콘솔)을 엽니다.

  2. 복제 인스턴스에 연결된 보안 그룹을 선택합니다.

  3. 연결된 보안 그룹에서 인바운드 TCP 포트 1500이 허용되는지 확인합니다.

NetworkIn CloudWatch 지표 확인

복제 서버의 NetworkIn Amazon CloudWatch 지표가 대역폭 한계에 가까워지면 제한이 발생할 수 있습니다. 제한을 사용하면 복제 속도가 느려지고 지연이 증가합니다. 필요한 대역폭을 처리할 수 있는 더 큰 인스턴스 유형으로 업그레이드하는 것을 고려해 보세요.

복제 서버 EBS 볼륨의 집계된 처리량 및 IOPS 확인

Amazon Elastic Block Store(Amazon EBS) 볼륨의 총 처리량 및 IOPS가 한도를 초과할 경우 복제 서버 성능이 제한될 수 있습니다. 제한이 발생하는 경우 복제 요구 사항을 수용하고 제한 없이 성능을 유지할 수 있는 복제 서버 인스턴스 유형으로 변경하세요. 복제 서버에는 현재 세대의 EBS에 최적화된 인스턴스 유형을 사용하는 것이 가장 좋습니다. EBS 최적화 처리량을 지원하지 않는 인스턴스에서는 네트워크 트래픽이 인스턴스와 EBS 볼륨 간의 트래픽과 경합을 벌입니다. EBS 최적화 인스턴스에서는 두 가지 유형의 트래픽이 별도로 유지됩니다. 복제 서버 네트워크 및 EBS CloudWatch 지표를 모니터링합니다. 자세한 내용은 다음을 참조하세요.

모든 복제 EBS 볼륨에 대한 지표 모니터링

복제 서버의 볼륨 쓰기 속도가 소스 서버의 변경 속도와 일치하지 않을 경우 지연 및 백로그가 누적됩니다. 복제 지연을 방지하려면 IOPS와 대역폭이 더 높은 더 빠른 볼륨 유형을 사용하세요. 최적의 성능 EBS 볼륨 성능을 위해서는 모든 복제 EBS 볼륨에 대한 CloudWatch 지표를 모니터링하는 것이 가장 좋습니다.

스냅샷에서 생성된 EBS 볼륨 확인

스냅샷에서 생성된 EBS 볼륨이 있는 복제 서버는 각 블록을 처음 액세스할 때 I/O 작업 지연 시간이 길어질 수 있습니다. 이러한 지연으로 인해 재스캔 프로세스가 완료될 때까지 지연 증가 또는 정체가 발생할 수 있습니다. 자세한 내용은 스냅샷에서 볼륨을 초기화할 때 성능 저하에 주의를 참조하세요.

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

소스 서버를 복제하려는 AWS 리전의 AWS 계정이 스냅샷 할당량 한도에 도달하지 않았는지 확인하세요. 다음 AWS 명령줄 인터페이스(AWS CLI) 명령을 사용하여 리전의 스냅샷 할당량에 도달했는지 확인하세요. 다음 예에서는 리전을 대상 AWS 리전으로 바꾸세요.

# 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)"

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

관련 정보

AWS Application Migration Service 사용 시 복제 병목 현상 식별

AWS 공식
AWS 공식업데이트됨 일 년 전