EC2 Linux 인스턴스의 인스턴스 유형을 변경하기 전에 어떤 단계를 수행해야 합니까?

최종 업데이트 날짜: 2021년 9월 13일

시스템에 현재 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 사용할 수 있는 것보다 많은 CPU 또는 메모리가 필요합니다. 전환이 성공적으로 이루어지도록 하려면 인스턴스 크기를 조정하기 전에 어떤 단계를 수행해야 합니까?

간략한 설명

EC2 Linux 인스턴스의 인스턴스 유형 변경으로 다음을 변경할 수 있습니다.

  • CPU 코어 수
  • RAM의 양
  • 할당된 인스턴스 스토어 공간의 양
  • Amazon Elastic Block Store(Amazon EBS) 최적화
  • 향상된 네트워킹
  • GPU 코어
  • FPGA
  • 기계 학습 액셀러레이터

참고: 인스턴스 및 데이터의 백업을 유지하는 것이 가장 좋습니다. 인프라를 변경하기 전에 AMI를 생성하거나 EBS 볼륨의 스냅샷을 생성하는 것이 좋습니다.

해결 방법

인스턴스 유형 또는 인스턴스 패밀리를 변경하기 전에 현재 인스턴스 유형과 새 인스턴스 유형이 호환되는지 확인합니다. 다음은 인스턴스 유형을 변경할 때 호환성 문제를 야기하는 일반적인 문제입니다. 호환성 문제의 전체 목록은 인스턴스 유형 변경 관련 호환성을 참조하세요.

호환성을 확인한 후 Amazon EBS 지원 인스턴스의 인스턴스 유형을 변경할 수 있습니다.

인스턴스 중지

인스턴스 유형을 변경하기 전에 인스턴스를 중지해야 합니다. 인스턴스를 중지하기 전에 다음을 이해해야 합니다.

  • 사용하는 인스턴스가 인스턴스 스토어 지원이거나 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스 중지 시 데이터가 손실됩니다. 하나의 인스턴스 스토어 지원 인스턴스에서 다른 인스턴스 스토어 지원 인스턴스로 이동하는 경우 인스턴스 스토어 지원 인스턴스를 마이그레이션해야 합니다. 자세한 내용은 인스턴스 스토어 지원 인스턴스 마이그레이션을 참조하세요.
  • 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인 경우 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 인스턴스를 시작한 경우 인스턴스가 AWS Auto Scaling 그룹의 일부일 수 있습니다. 이 시나리오에서 인스턴스 종료는 Auto Scaling 그룹에 대한 인스턴스 확장 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스를 제거합니다.
  • 탄력적 IP 주소를 사용하지 않는 경우 인스턴스를 중지했다가 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 가장 좋습니다. Route 53를 사용하는 경우 퍼블릭 IP가 변경될 때 Route 53 DNS 레코드를 업데이트해야 할 수 있습니다.

향상된 네트워킹

향상된 네트워킹을 지원하는 인스턴스로 변환하는 경우 현재 인스턴스에서 필요한 드라이버를 설치하고 향상된 네트워킹을 활성화합니다. 자세한 내용은 Linux에서의 향상된 네트워킹을 참조하세요.

니트로 기반 인스턴스 유형

인스턴스를 니트로 기반 인스턴스 유형으로 변경하려는 경우 다음을 수행합니다.

  • 인스턴스에 NVMe 및 ENA 모듈이 설치되어 있는지 확인합니다.
  • /etc/fstab에 나열된 블록 디바이스가 NVMe 블록 디바이스 이름(/dev/nvme1, /dev/nvme2 등)과 호환되는지 확인합니다.
  • Amazon Elastic Block Store(EBS) 볼륨은 이러한 인스턴스 유형에 NVMe 디바이스로 공개되고, 중지/시작 이벤트에서 디바이스 이름이 변경됩니다. 볼륨 불일치를 방지하려면 파일 시스템 UUID 또는 레이블을 사용하여 파일 시스템을 탑재합니다.

이러한 검사를 자동화하려면 NitroInstanceChecks 스크립트를 실행합니다. 자세한 내용은 인스턴스 유형을 Nitro 기반 인스턴스 유형으로 변경한 후 Linux 인스턴스가 부팅되지 않는 이유는 무엇입니까?를 참조하세요. NitroInstanceChecks 스크립트 실행 섹션의 지침을 따릅니다.

스크립트를 실행하여 필요한 모든 업데이트를 수행한 후 /etc/udev/rules.d/70-persistent-net.rulesDRIVERS 항목이 ? 또는 ENA로 설정되어 있는지 확인합니다.

텍스트 편집기를 사용하여 파일에 액세스합니다. 다음 예제에서는 vi 편집기를 사용합니다.

vi /etc/udev/rules.d/70-persistent-net.rules

올바른 항목은 다음과 같이 표시됩니다.

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0

현재 세대 인스턴스에서의 네트워킹

현재 세대 인스턴스는 Virtual Private Cloud(VPC)에서만 시작됩니다. 현재 인스턴스가 EC2-Classic 인스턴스인 경우 VPC의 Linux 인스턴스로 인스턴스를 마이그레이션합니다.

EC2 아키텍처 혼합

인스턴스의 소스 AMI가 특정 아키텍처용으로 빌드된 경우 동일한 아키텍처의 인스턴스 유형을 생성하도록 제한됩니다. 특정 아키텍처용으로 빌드된 AMI의 예로는 32비트(i386), 64비트(x86_64) 또는 64비트 ARM(arm64) 등이 있습니다. 인스턴스가 mac1 인스턴스 유형에 대해 생성된 AMI를 실행 중인 경우에도 마찬가지입니다. 인스턴스 유형 간에는 이러한 이미지를 이동할 수 없습니다.