

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

# Classic Load Balancer 마이그레이션


Elastic Load Balancing은 다음 유형의 로드 밸런서를 지원합니다. Application Load Balancers, Network Load Balancers, 게이트웨이이 로드 밸런서 및 Classic Load Balancer 각 로드 밸런서 유형의 다양한 기능에 대한 자세한 내용은 [Elastic Load Balancing 기능](https://aws.amazon.com/elasticloadbalancing/features/)을 참조하세요.

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

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

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

------
#### [ Application Load Balancer ]

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

지원:
+ [경로 조건](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#path-conditions), [호스트 조건](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#host-conditions) 및 [HTTP 헤더 조건](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#http-header-conditions).
+ 요청을 한 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/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.

1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.

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

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

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

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

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

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

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

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

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

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

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

**리소스**
+ [Elastic Load Balancing 도구](https://github.com/aws/elastic-load-balancing-tools)
+ [Classic Load Balancer에서 Application Load Balancer로 복사 유틸리티](https://github.com/aws/elastic-load-balancing-tools/tree/master/application-load-balancer-copy-utility)
+ [Classic Load Balancer에서 Network Load Balancer로 복사 유틸리티](https://github.com/aws/elastic-load-balancing-tools/tree/master/network-load-balancer-copy-utility)

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

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

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

### 수동 마이그레이션 프로세스


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

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

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

1. 다음 중 하나를 수행하십시오.
   + Classic Load Balancer가 Auto Scaling 그룹에 연결된 경우, 대상 그룹을 Auto Scaling 그룹에 연결합니다. 이렇게 하면 Auto Scaling 인스턴스가 대상 그룹에도 등록됩니다.
   + EC2 인스턴스를 대상 그룹에 등록합니다.

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

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

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

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

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

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

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

1. 모든 트래픽이 새 로드 밸런서로 전달될 때까지 계속 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` 리소스를 사용하는 CloudFormation 템플릿을 업데이트합니다.
+ Elastic Load Balancing API 버전 2012-06-01을 사용하는 코드를 버전 2015-12-01을 사용하도록 업데이트합니다.

**리소스**
+ *AWS CLI 명령 참조*의 [elbv2](https://docs.aws.amazon.com/cli/latest/reference/elbv2/index.html)
+ [Elastic Load Balancing API 참조 버전 2015-12-01](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/)
+ [Elastic Load Balancing의 ID 및 액세스 관리](load-balancer-authentication-access-control.md)
+ *Application Load Balancer 사용 설명서*의 [Application Load Balancer 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html#load-balancer-metrics-alb)
+ *Network Load Balancer 사용 설명서*의 [Network Load Balancer 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html#load-balancer-metrics-nlb)
+ *AWS CloudFormation 사용 설명서*의 [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html)

**4단계: 이전 로드 밸런서 삭제**  
다음을 수행하고 나면 이전 Classic Load Balancer를 삭제할 수 있습니다.
+ 모든 트래픽을 이전 로드 밸런서에서 새 로드 밸런서로 리디렉션
+ 이전 로드 밸런서로 라우팅된 모든 기존 요청을 완료

## 사용자의 Classic Load Balancer 생성 방지


사용자가 계정에서 Classic Load Balancer를 생성하지 못하도록 하는 IAM 정책을 생성할 수 있습니다.

[Elastic Load Balancing V2](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awselasticloadbalancingv2.html) 및 [Elastic Load Balancing V1](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awselasticloadbalancing.html) API는 모두 `CreateLoadBalancer` API 작업을 제공합니다. Classic Load Balancer를 생성할 때는 V1 API 작업을 사용하며 이 작업은 로드 밸런서와 리스너를 모두 생성합니다. Application Load Balancer, Network Load Balancer 또는 게이트웨이 로드 밸런서를 생성할 때는 V2 API 작업을 사용하며 이 작업은 로드 밸런서만 생성합니다. V2 API는 `CreateListener` 작업을 제공하며 로드 밸런서를 생성한 후 이 작업으로 리스너를 생성합니다.

다음 정책은 리스너 프로토콜이 지정된 경우 사용자의 로드 밸런서 생성 권한을 거부합니다. Classic Load Balancer를 생성할 때 하나 이상의 리스너를 구성해야 하므로 이 정책은 사용자가 Classic Load Balancer를 생성하지 못하도록 차단합니다. 다른 유형의 로드 밸런서를 생성하는 것은 차단하지 않습니다. 이러한 로드 밸런서와 해당 리스너를 생성하는 API 작업이 별도로 존재하기 때문입니다.

```
{
    "Version": "2012-10-17",		 	 	 
    "Effect": "Deny",
    "Action": "elasticloadbalancing:CreateLoadBalancer",
    "Resource": [
        "arn:aws:elasticloadbalancing:*:*:loadbalancer/*"
    ],
    "Condition": {
        "Null": {
            "elasticloadbalancing:ListenerProtocol": false
        }
    }
}
```