Classic Load Balancer 마이그레이션 - Elastic Load Balancing
마이그레이션의 이점마이그레이션 마법사복사 유틸리티 마이그레이션수동 마이그레이션

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Classic Load Balancer 마이그레이션

Elastic Load Balancing은 다음 유형의 로드 밸런서를 지원합니다. Application Load Balancers, Network Load Balancers, 게이트웨이이 로드 밸런서 및 Classic Load Balancer 각 로드 밸런서 유형의 다양한 기능에 대한 자세한 내용은 Elastic Load Balancing 기능을 참조하세요.

VPC의 기존 Classic Load Balancer를 Application Load Balancer 또는 Network Load Balancer로 마이그레이션하도록 선택할 수도 있습니다.

Classic Load Balancer에서 마이그레이션할 때의 이점

각 유형의 로드 밸런서에는 고유한 기능, 함수 및 구성이 있습니다. 가장 적합한 로드 밸런서를 결정하는 데 도움이 되도록 각 로드 밸런서의 이점을 검토합니다.

Application Load Balancer

Classic Load Balancer 대신 Application Load Balancer를 사용하면 다음과 같은 이점이 있습니다.

지원:

  • 경로 조건, 호스트 조건 및 HTTP 헤더 조건.

  • 요청을 한 URL에서 다른 URL로 리디렉션하고 요청을 단일 EC2 인스턴스의 여러 애플리케이션으로 라우팅.

  • 사용자 지정 HTTP 응답을 반환.

  • IP 주소별로 대상을 등록하고 Lambda 함수를 대상으로 등록. 로드 밸런서의 VPC 외부 대상을 포함.

  • 기업 또는 소셜 자격 증명을 통한 사용자 인증.

  • Amazon Elastic Container Service(Amazon ECS) 컨테이너식 애플리케이션.

  • 각 서비스의 상태를 독립적으로 모니터링.

액세스 로그는 추가 정보를 포함하며 압축된 형식으로 저장됩니다.

전반적으로 개선된 로드 밸런서 성능.

Network Load Balancer

Classic Load Balancer 대신 Network Load Balancer를 사용하면 다음과 같은 이점이 있습니다.

지원:

  • 로드 밸런서에 대해 활성화된 서브넷당 하나의 탄력적 IP 주소를 할당할 수 있는 고정 IP 주소.

  • 로드 밸런서의 VPC 외부 대상을 포함하여 IP 주소로 대상을 등록.

  • 단일 EC2 인스턴스의 여러 애플리케이션으로 요청을 라우팅.

  • Amazon Elastic Container Service(Amazon ECS) 컨테이너식 애플리케이션.

  • 각 서비스의 상태를 독립적으로 모니터링.

일시적 워크로드를 처리하고 초당 수백만 개의 요청으로 확장할 수 있습니다.

마이그레이션 마법사를 사용하여 마이그레이션

마이그레이션 마법사는 사용자의 Classic Load Balancer 구성을 사용하여 동등한 Application Load Balancer 또는 Network Load Balancer를 생성합니다. 다른 방법에 비해 Classic Load Balancer를 마이그레이션하는 데 필요한 시간과 노력이 줄어듭니다.

참고

마법사는 새 로드 밸런서를 생성합니다. 기존 Classic Load Balancer를 Application Load Balancer 또는 Network Load Balancer로 변환하지 않습니다. 트래픽을 새로 생성된 로드 밸런서로 수동으로 리디렉션해야 합니다.

제한 사항

  • 새 로드 밸런서의 이름은 동일한 리전에서 동일한 유형의 기존 로드 밸런서와 같을 수 없습니다.

  • Classic Load Balancer에 키에 aws: 접두사가 포함된 태그가 있는 경우 해당 태그는 마이그레이션되지 않습니다.

Application Load Balancer로 마이그레이션하는 경우

  • Classic Load Balancer에 서브넷이 하나만 있는 경우 두 번째 서브넷을 지정해야 합니다.

  • Classic Load Balancer에 TCP 상태 확인을 사용하는 HTTP/HTTPS 리스너가 있는 경우 상태 확인 프로토콜이 HTTP로 업데이트되고 경로가 ‘/’로 설정됩니다.

  • Classic Load Balancer에 사용자 지정 또는 지원되지 않는 보안 정책을 사용하는 HTTPS 리스너가 있는 경우 마이그레이션 마법사는 새 로드 밸런서 유형에 기본 보안 정책을 사용합니다.

Network Load Balancer로 마이그레이션하는 경우

  • 다음 인스턴스 유형은 새 대상 그룹에 등록되지 않습니다. C1, CC1, CC2, CG1, CG2, CR1, CS1, G1, G2, HI1, HS1, M1, M2, M3, T1

  • Classic Load Balancer의 특정 상태 확인 설정은 새 대상 그룹으로 이전할 수 없습니다. 이러한 경우는 마이그레이션 마법사의 요약 섹션에 변경 사항으로 표시됩니다.

  • Classic Load Balancer에 SSL 리스너가 있는 경우 마이그레이션 마법사는 SSL 리스너의 인증서 및 보안 정책을 사용하여 TLS 리스너를 생성합니다.

마이그레이션 마법사를 사용하여 Classic Load Balancer를 마이그레이션하려면

  1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

  2. 탐색 창의 로드 밸런싱(Load Balancing) 아래에서 로드 밸런서(Load Balancers)를 선택합니다.

  3. 마이그레이션하려는 Classic Load Balancer를 선택합니다.

  4. 로드 밸런서 세부 정보 섹션에서 마이그레이션 마법사 시작을 선택합니다.

  5. Application Load Balancer로 마이그레이션 또는 Network Load Balancer로 마이그레이션을 선택하여 마이그레이션 마법사를 엽니다.

  6. 새 로드 밸런서 이름 지정 아래에서 로드 밸런서 이름에 새 로드 밸런서의 이름을 입력합니다.

  7. 새 대상 그룹 이름 지정 및 대상 검토에서 대상 그룹 이름에 새 대상 그룹의 이름을 입력합니다.

  8. (선택 사항) 대상에서 새 대상 그룹에 등록할 대상 인스턴스를 검토할 수 있습니다.

  9. (선택 사항) 태그 검토에서 새 로드 밸런서에 적용될 태그를 검토할 수 있습니다.

  10. Application Load Balancer 요약 또는 Network Load Balancer 요약에서 마이그레이션 마법사가 할당한 구성 옵션을 검토하고 확인합니다.

  11. 구성 요약이 만족스러우면 Application Load Balancer 생성 또는 Network Load Balancer 생성을 선택하여 마이그레이션을 시작합니다.

로드 밸런서 복사 유틸리티를 사용하여 마이그레이션

로드 밸런서 복사 유틸리티는 AWS GitHub 페이지의 Elastic Load Balancing Tools 리포지토리 내에서 사용할 수 있습니다.

리소스

로드 밸런서를 수동으로 마이그레이션

다음 정보는 VPC의 기존 Classic Load Balancer를 기반으로 새 Application Load Balancer 또는 Network Load Balancer를 수동으로 생성하기 위한 일반적인 지침을 제공합니다. AWS Management Console, AWS CLI또는 AWS SDK를 사용하여 마이그레이션할 수 있습니다. 자세한 내용은 Elastic Load Balancing 시작하기 단원을 참조하십시오.

마이그레이션 프로세스를 완료한 후 새 로드 밸런서의 기능을 활용할 수 있습니다.

1단계: 새 로드 밸런서 생성

마이그레이션할 Classic Load Balancer와 동등한 구성으로 로드 밸런서를 생성합니다.

  1. Classic Load Balancer와 동일한 체계(인터넷 경계 또는 내부), 서브넷 및 보안 그룹으로 새 로드 밸런서를 생성합니다.

  2. Classic Load Balancer와 동일한 상태 확인 설정으로 로드 밸런서에 대한 하나의 대상 그룹을 생성합니다.

  3. 다음 중 하나를 수행하십시오.

    • Classic Load Balancer가 Auto Scaling 그룹에 연결된 경우, 대상 그룹을 Auto Scaling 그룹에 연결합니다. 이렇게 하면 Auto Scaling 인스턴스가 대상 그룹에도 등록됩니다.

    • EC2 인스턴스를 대상 그룹에 등록합니다.

  4. 요청을 대상 그룹에 전달하는 기본 규칙이 있는 하나 이상의 리스너를 생성합니다. HTTPS 리스너를 생성하는 경우 Classic Load Balancer에 대해 지정한 것과 동일한 인증서를 지정할 수 있습니다. 기본 보안 정책을 사용하는 것이 좋습니다.

  5. Classic Load Balancer에 태그가 있는 경우 해당 태그를 검토하고 새 로드 밸런서에 관련 태그를 추가합니다.

2단계: 새 로드 밸런서로 점진적으로 트래픽 리디렉션

인스턴스를 새 로드 밸런서에 등록한 후에는 이전 로드 밸런서에서 새 로드 밸런서로 트래픽 리디렉션 프로세스를 시작할 수 있습니다. 이를 통해 애플리케이션 가용성에 미치는 위험을 최소화하면서 새 로드 밸런서를 테스트할 수 있습니다.

새 로드 밸런서에 트래픽을 점진적으로 리디렉션하려면

  1. 새 로드 밸런서의 DNS 이름을 인터넷에 연결된 웹 브라우저의 주소 필드에 붙여 넣습니다. 모든 것이 잘 작동하는 경우 브라우저에 애플리케이션 기본 페이지가 표시됩니다.

  2. 도메인 이름을 새 로드 밸런서와 연결하는 새 DNS 레코드를 만듭니다. DNS 서비스가 가중을 지원하는 경우 새 DNS 레코드에서 가중치를 1로 지정하고 이전 로드 밸런서에 대한 기존 DNS 레코드에서 가중치를 9로 지정합니다. 이렇게 하면 새 로드 밸런서에 트래픽의 10%, 이전 로드 밸런서에 트래픽의 90%가 전송됩니다.

  3. 새 로드 밸런서를 모니터링하여 인스턴스에 대한 트래픽 및 라우팅 요청을 수신하는지 확인합니다.

    중요

    DNS 레코드의 TTL(time-to-live)은 60초입니다. 즉, 도메인 이름을 확인하는 DNS 서버는 해당 레코드 정보를 60초 동안 캐시에 보관합니다. 그동안 변경 내용이 전파됩니다. 따라서 이러한 DNS 서버는 이전 단계를 완료한 후 최대 60초 동안 이전 로드 밸런서에 트래픽을 계속 라우팅할 수 있습니다. 전파되는 동안 트래픽은 로드 밸런서에 전송될 수 있습니다.

  4. 모든 트래픽이 새 로드 밸런서로 전달될 때까지 계속 DNS 레코드의 가중치를 업데이트합니다. 완료되면 이전 로드 밸런서에 대한 DNS 레코드를 삭제할 수 있습니다.

3단계: 정책, 스크립트 및 코드 업데이트

Classic Load Balancer에서 Application Load Balancer 또는 Network Load Balancer로 마이그레이션하는 경우 다음을 수행해야 합니다.

  • API 버전 2012-06-01을 사용하는 IAM 정책을 버전 2015-12-01을 사용하도록 업데이트합니다.

  • AWS/ELB 네임스페이스의 CloudWatch 지표를 사용하는 프로세스를 AWS/ApplicationELB 또는 AWS/NetworkELB 네임스페이스의 지표를 사용하도록 업데이트합니다.

  • aws elb AWS CLI 명령을 사용하여 aws elbv2 AWS CLI 명령을 사용하는 스크립트를 업데이트합니다.

  • AWS::ElasticLoadBalancing::LoadBalancer 리소스를 사용하여 AWS::ElasticLoadBalancingV2 리소스를 사용하는 AWS CloudFormation 템플릿을 업데이트합니다.

  • Elastic Load Balancing API 버전 2012-06-01을 사용하는 코드를 버전 2015-12-01을 사용하도록 업데이트합니다.

리소스
4단계: 이전 로드 밸런서 삭제

다음을 수행하고 나면 이전 Classic Load Balancer를 삭제할 수 있습니다.

  • 모든 트래픽을 이전 로드 밸런서에서 새 로드 밸런서로 리디렉션

  • 이전 로드 밸런서로 라우팅된 모든 기존 요청을 완료