ALB
1 Application Load Balancer(ALB)
- Application Load Balancer는 주로 HTTP/HTTPS 트래픽을 처리하며 OSI 7계층에서 작동합니다.
- ALB는 웹소켓과 HTTP/2도 지원하며, URL, 헤더, 메소드 등을 기반으로 트래픽 라우팅 규칙을 설정할 수 있습니다.
- ALB는 사용자 세션을 특정 타겟에 고정시키는 스티키 세션 기능도 제공합니다.
1.1 listener
- Network Load Balancer에 하나 이상의 listener를 추가한다.
- listener는 설정된 프로토콜과 포트를 통해 클라이언트로부터 연결 요청을 확인하고 해당 요청을 타겟 그룹으로 포워딩한다.
1.1.1 Listener Rules
- Listener Rules는 Application Load Balancer(ALB)에서 클라이언트의 요청을 특정 타겟 그룹으로 라우팅하는 조건을 정의합니다.
- 각 리스너는 여러 개의 규칙을 가질 수 있으며, 규칙은 우선순위에 따라 평가됩니다.
- 첫 번째 일치하는 규칙이 트래픽 라우팅을 결정합니다.
- 규칙의 조건으로는 다음과 같은 요소를 포함할 수 있습니다:
- 호스트 헤더: 특정 도메인명에 대한 요청을 라우팅하는 데 사용됩니다.
- 경로: 요청 URL의 경로를 기반으로 라우팅할 수 있습니다. 예를 들어,
/images/*는 이미지 파일로의 요청을 특정 타겟 그룹으로 라우팅할 수 있습니다. - HTTP 메서드: GET, POST 등의 HTTP 메서드를 기준으로 라우팅합니다.
- 쿼리 문자열: 요청 URL의 쿼리 파라미터에 따라 라우팅할 수 있습니다.
- 소스 IP 주소: 특정 IP 주소 범위에서 오는 요청을 특정 타겟 그룹으로 라우팅할 수 있습니다.
- 리스너 규칙은 특정 조건을 만족하는 요청에 대해 트래픽을 어떤 타겟 그룹으로 보낼지를 결정하며, 이를 통해 트래픽 관리와 애플리케이션의 효율성을 높일 수 있습니다.
가중치 기반 라우팅 (Weight-Based Routing)
- ALB의 리스너 규칙에서는 하나의 규칙에 여러 타겟 그룹을 매핑할 수 있습니다.
- 이를 "가중치 기반 라우팅" 또는 "트래픽 분할"이라고 합니다.
- 주요 특징:
- 여러 타겟 그룹 지정: 한 규칙에서 둘 이상의 타겟 그룹을 지정할 수 있습니다.
- 가중치 할당: 각 타겟 그룹에 가중치를 할당하여 트래픽 분배 비율을 조절할 수 있습니다.
- 비율 기반 분배: 트래픽은 지정된 가중치에 비례하여 각 타겟 그룹으로 분배됩니다.
- 사용 사례:
- 블루/그린 배포: 새 버전의 애플리케이션을 점진적으로 도입할 때 유용합니다.
- A/B 테스팅: 다른 버전의 애플리케이션을 동시에 테스트할 수 있습니다.
- 카나리 릴리스: 소수의 사용자에게만 새 버전을 노출시켜 위험을 최소화할 수 있습니다.
1.2 Target Group
- Target Group은 Application Load Balancer(ALB)에서 트래픽을 분배할 대상을 정의하는 논리적인 그룹입니다.
- Target Group을 설정하면, ALB는 트래픽을 해당 그룹 내의 타겟으로 라우팅합니다.
1.2.1 타겟 유형
- EC2 인스턴스: Target Group에 포함될 수 있는 AWS의 가상 서버입니다. 여러 인스턴스를 그룹화하여 트래픽을 분산할 수 있습니다.
- IP 주소: 특정 IP 주소를 타겟으로 설정할 수 있습니다. 이를 통해 온프레미스 시스템이나 다른 클라우드 서비스와 통합할 수 있습니다.
- Lambda 함수: AWS Lambda와의 통합을 통해 서버리스 컴퓨팅 환경에서 코드를 실행할 수 있습니다. Lambda 함수를 타겟으로 설정하면, ALB가 요청을 Lambda 함수로 라우팅하여 필요한 작업을 수행합니다.
1.2.2 헬스 체크
- 헬스 체크는 Target Group에 등록된 타겟의 상태를 확인하기 위한 프로세스입니다. 헬스 체크를 통해 ALB는 타겟의 상태를 주기적으로 검사하여, 건강한 타겟에만 트래픽을 분배합니다.
- 헬스 체크는 HTTP, HTTPS, TCP, 또는 gRPC 프로토콜을 사용하여 설정할 수 있으며, 경로, 타임아웃, 재시도 횟수 등을 설정할 수 있습니다.
- 헬스 체크 상태: 각 타겟의 상태는 헬스 체크 결과에 따라 'Healthy', 'Unhealthy'로 구분됩니다. 'Unhealthy' 상태의 타겟에는 트래픽이 전달되지 않습니다.
1.2.3 리스너와의 통합
- 리스너는 ALB가 클라이언트 요청을 수신하는 구성 요소입니다. 리스너는 특정 프로토콜(예: HTTP, HTTPS)과 포트를 통해 요청을 수신하며, 이를 Target Group으로 포워딩합니다.
- 각 리스너는 하나 이상의 Target Group과 연결될 수 있으며, URL 경로, 호스트 헤더, HTTP 메서드 등 다양한 조건에 따라 트래픽을 라우팅하는 규칙을 설정할 수 있습니다.
2 ALB 생성하기
2.1 ALB 생성 시작
- AWS Management Console에 로그인합니다.
- EC2 대시보드로 이동합니다.
- 왼쪽 메뉴에서 "Load Balancers"를 선택합니다.
- "Create Load Balancer" 버튼을 클릭합니다.
2.2 ALB 유형 선택
![[Pasted image 20240719121337.png]]
- "Application Load Balancer"를 선택합니다.
- Application Load Balancer는 HTTP 및 HTTPS 트래픽을 처리하며, 고급 라우팅 및 가시성 기능을 제공합니다.
- "Create" 버튼 을 클릭하여 ALB 생성을 시작합니다.
2.3 Basic configuration 설정
- Load balancer name: ALB의 이름을 입력합니다.
- 예:
my-application-load-balancer
- 예:
- Scheme을 선택합니다.
- Internet-facing: 인터넷에서 접근 가능한 ALB를 생성합니다.
- Internal: 내부 네트워크에서만 접근 가능한 ALB를 생성합니다.
- IP 주소 유형을 선택합니다.
- IPv4 또는 Dualstack (IPv4 and IPv6) 중 하나를 선택합니다.
2.4 네트워크 맵핑 설정
- VPC를 선택합니다.
- 예:
vpc-xxxxxx
- 예:
- ALB가 사용할 서브넷을 선택합니다.
- 각 가용 영역(AZ)에 대해 서브넷을 선택합니다.
- 예:
subnet-xxxxxx
2.5 보안 그룹 설정
- ALB에 적용할 보안 그룹을 선택합니다.
- 기존 보안 그룹을 선택하거나 새로운 보안 그룹을 생성합니다.
- 예:
sg-xxxxxx
- 예:
2.6 리스너 및 라우팅 설정
- 리스너 설정
- ALB에 대한 리스너를 설정합니다.
- 기본적으로 HTTP (포트 80) 및 HTTPS (포트 443) 리스너를 추가합니다.
- HTTP 리스너: HTTP 요청을 수신합니다.
- HTTPS 리스너: HTTPS 요청을 수신하며, SSL 인증서를 필요로 합니다.
- 라우팅 설정
- 리스너에 대한 라우팅 규칙을 설정합니다.
- Target Group: 트래픽을 라우팅할 대상 그룹을 선택하거나 생성합니다.
- 대상 그룹 유형: 인스턴스, IP, Lambda 중 하나를 선택합니다.
- 헬스 체크 설정: 대상 그룹의 헬스 체크 설정을 구성합니다.
2.7 검토 및 생성
- 입력한 설정을 확인하고, 필요한 경우 수정합니다.
- "Create Load Balancer" 버튼을 클릭하여 ALB를 생성합니다.
3 비용
- Application Load Balancer(ALB)의 비용은 두 가지 주요 요소로 구성됩니다.
- 사용 시간과 Load Balancer Capacity Units(LCU)입니다.
- 아래는 각 요소에 대한 자세한 설명입니다.
3.1 사용 시간
- ALB의 실행 시간에 따라 시간당 요금이 부과됩니다.
- 시간당 요금은 지역에 따라 다르며, 대략 $0.0225 USD부터 시작합니다.
3.2 Load Balancer Capacity Units (LCU)
- LCU는 ALB의 용량을 측정하는 단위입니다.
- 각 LCU는 다음의 네 가지 차원에서 계산됩니다:
- 새로운 연결 수: 초당 새로 설정되는 연결 수.
- 활성 연결 수: 매 분당 평균 활성 연결 수.
- 처리된 데이터 양: 기가바이트 단위의 처리된 데이터 양.
- 규칙 평가: 평가된 규칙 수.
- LCU 사용에 따른 요금은 시간당 LCU 단위로 부과되며, 이 역시 지역에 따라 다를 수 있지만, 대략 $0.008 USD부터 시작합니다.
예시
- 예를 들어, ALB가 한 시간 동안 1000개의 새로운 연결을 설정하고, 평균 500개의 활성 연결을 유지하며, 1GB의 데이터를 처리하고, 10개의 규칙을 평가하는 경우, 해당 시간 동안의 LCU 사용량은
다음과 같이 계산됩니다:
- 새 연결: 1000 / 3000 (1 LCU당) = 0.33 LCU
- 활성 연결: 500 / 3000 (1 LCU당) = 0.17 LCU
- 처리된 데이터: 1GB / 1GB (1 LCU당) = 1 LCU
- 규칙 평가: 10 / 1000 (1 LCU당) = 0.01 LCU
- 총 LCU: 0.33 + 0.17 + 1 + 0.01 = 1.51 LCU
4 Sticky Sessions
4.1 정의 및 기능
- Sticky Sessions는 동일한 클라이언트가 여러 요청을 보낼 때, 그 요청을 동일한 백엔드 서버로 라우팅하는 기능입니다.
- ALB에서 Sticky Sessions는 클라이언트 세션을 특정 타겟에 고정시키기 위해 쿠키를 사용합니다.
- 이 기능은 세션 정보가 특정 서버에 저장되어 있어야 하는 상태 저장(stateful) 애플리케이션에 유용합니다.
4.2 작동 방식
- Balancer(ALB)에서 세션 일관성을 유지하기 위해 제공하는 두 가지 스티키 세션 기능 제공합니다.
- Duration-based stickiness
- Application-based stickiness
- 이 기능들은 클라이언트의 요청이 동일한 서버로 라우팅되도록 보장합니다.
- 두 방식의 주요 차이점과 작동 방식을 설명하겠습니다.
4.2.1 Duration-based stickiness
- 작동 방식
- Duration-based stickiness는 ALB가 자동으로 생성한 쿠키를 사용합니다.
- 이 쿠키의 이름은
AWSALB로 고정되어 있으며, 모든 타겟 그룹에서 동일한 이름을 사용합니다. - ALB는 처음 클라이언트의 요청을 받을 때, 선택된 타겟에 대한 정보를 암호화하여 쿠키로 저장하고, 이를 클라이언트에게 응답할 때 전달합니다.
- 클라이언트는 이후의 요청에 이 쿠키를 포함시키며, ALB는 이 쿠키를 확인하여 동일한 타겟으로 트래픽을 라우팅합니다.
- 이 쿠키는 7일의 기본 만료 시간을 가지며, 이 기간 동안 클라이언트의 모든 요청은 동일한 타겟으로 전송됩니다. 쿠키 만료 시간은 설정 가능하며, 1초에서 7일 사이로 설정할 수 있습니다.
- 특징
- 쿠키는 ALB에 의해 자동으로 생성 및 관리됩니다.
- 애플리케이션의 세션 쿠키가 필요하지 않으며, ALB가 쿠키를 통해 세션을 유지합니다.
- 모든 타겟 그룹에서 동일한 쿠키 이름(
AWSALB)을 사용하므로, 여러 계층의 ALB를 사용하는 경우 각 계층에서 Duration-based stickiness를 개별적으로 사용할 수 없습니다.
4.2.2 Application-based stickiness
- 작동 방식
- Application-based stickiness는 애플리케이션이 자체적으로 생성한 쿠키와 ALB가 생성한 애플리케이션 쿠키를 사용합니다.
- 애플리케이션 서버는 클라이언트에게 응답할 때 특정 이름의 쿠키를 설정합니다. 이 쿠키에는 애플리케이션에서 요구하는 커스텀 속성이 포함될 수 있습니다.
- ALB는 이 애플리케이션 쿠키를 수신하고, 이 쿠키와 일치하는 자체적인 암호화된 쿠키를 생성합니다. 이 ALB 쿠키는
AWSALBAPP라는 이름을 가집니다. - 이후의 요청에서 클라이언트는 애플리케이션이 생성한 쿠키와 ALB가 생성한 쿠키를 모두 포함해야 합니다. ALB는 이 쿠키를 기반으로 동일한 타겟으로 트래픽을 라우팅합니다.
- 쿠키의 만료 시간은 7일로 고정되어 있으며, 클라이언트가 새로운 요청을 보낼 때마다 쿠키 만료 시간이 갱신됩니다.
- 특징
- 애플리케이션이 자체적으로 쿠키를 생성하며, 이 쿠키는 커스텀 속성을 가질 수 있습니다.
- ALB는 이 애플리케이션 쿠키를 기반으로 자체 쿠키를 생성하여 세션을 유지합니다.
- 여러 계층의 ALB를 사용하는 경우, 각 계층에서 개별적인 Application-based stickiness를 사용할 수 있습니다.
- 각 타겟 그룹마다 개별적인 쿠키 이름을 설정해야 합니다.
- Application Load Balancer(ALB)에서 다음의 쿠키 이름은 예약되어 있으며, 커스텀 쿠키 이름으로 사용할 수 없습니다
- AWSALB: 기본적인 ALB 쿠키로, 로드 밸런서가 클라이언트를 특정 타겟에 연결하는 데 사용합니다.
- AWSALBAPP: Application-based stickiness에 사용되는 쿠키로, 애플리케이션이 생성한 쿠키와 연관되어 세션을 유지합니다
- AWSALBTG: 타겟 그룹 수준에서 사용되는 쿠키로, 클라이언트 ****요청을 특정 타겟 그룹으로 라우팅하는 데 사용됩니다.
4.3 설정 방법
- ALB의 Target Group 설정에서 Sticky Sessions를 활성화할 수 있습니다.
- 설정 시 쿠키의 만료 시간과 쿠키의 이름을 지정할 수 있습니다.
- 만료 시간이 설정된 경우, 세션은 쿠키 만료 후에도 동일한 서버로 라우팅되지 않을 수 있습니다.
4.4 장점과 고려 사항
- 장점: 상태 저장 애플리케이션의 경우, 사용자 경험을 일관되게 유지할 수 있으며, 세션 데이터를 여러 서버 간에 동기화할 필요가 줄어듭니다.
- 고려 사항: 특정 서버에 트래픽이 집중될 수 있어 서버의 부하가 비대칭적으로 분포될 수 있습니다. 따라서 서버 간의 균형 잡힌 부하 분산이 중요한 애플리케이션에는 신중하게 사용해야 합니다.
5 Cross-Zone Load Balancing
5.1 정의 및 기능
- Cross-Zone Load Balancing은 Application Load Balancer(ALB)에서 여러 가용 영역(AZ)에 걸쳐 트래픽을 균등하게 분배하는 기능입니다.
- 이 기능을 활성화하면, ALB는 리전 내의 모든 가용 영역에서 활성화된 타겟 인스턴스 간에 트래픽을 고르게 분배합니다.
- 이를 통해 특정 가용 영역의 타겟에 과도한 부하가 걸리는 것을 방지하고, 인프라의 전체적인 가용성을 향상시킬 수 있습니다.
5.2 작동 방식
- Cross-Zone Load Balancing이 활성화된 경우, ALB는 클라이언트의 요청을 모든 가용 영역에 있는 타겟에 고르게 분산합니다.
- 예를 들어, 3개의 가용 영역(AZ A, AZ B, AZ C)이 있고, 각 AZ에 2개의 타겟 인스턴스가 있는 경우, 모든 인스턴스는 전체 트래픽의 1/6씩을 처리하게 됩니다.
5.3 활성화 방법
- Cross-Zone Load Balancing은 기본적으로 ALB에서 활성화되어 있습니다.
- AWS Management Console, CLI 또는 SDK를 통해 설정을 확인하거나 변경할 수 있습니다.
5.4 장점과 고려 사항
- 장점
- 고가용성: 특정 가용 영역에 장애가 발생하더라도 다른 가용 영역의 타겟이 트래픽을 처리할 수 있어 서비스 중단을 최소화 할 수 있습니다.
- 부하 균등화: 모든 가용 영역에 걸쳐 트래픽이 균등하게 분배되어, 특정 인스턴스에 과부하가 걸리는 것을 방지합니다.
- 고려 사항
- 비용: Cross-Zone Load Balancing 기능이 활성화된 경우, 트래픽 전송 비용이 증가할 수 있습니다.
- 일부 트래픽 관리 정책에서는 가용 영역 간의 트래픽 분산을 신중하게 고려해야 할 수 있습니다.
6 ALB와 IP 주소 관리
6.1 ALB의 IP 주소 특성
- ALB(Application Load Balancer)는 고정 IP 주소를 제공하지 않습니다.
- ALB의 IP 주소 목록은 시간이 지남에 따라 변경될 수 있습니다.
- 이러한 특성으로 인해 일부 클라이언트나 네트워크 환경에서는 ALB 사용이 까다로울 수 있습니다.
6.2 Route 53과 ALB 통합
- ALB의 변동하는 IP 주소 특성 때문에, Route 53에서는 ALB를 위해 A 레코드 대신 ALIAS 레코드를 사용합니다.
- ALIAS 레코드는 ALB의 DNS 이름을 참조하므로, ALB의 IP 주소가 변경되어도 자동으로 최신 상태를 유지할 수 있습 니다.
- [[Route53]] 참고
6.3 고정 IP 주소의 필요성
- 보안이 엄격한 환경이나 오래된 디바이스를 사용하는 경우, 고정 IP 주소가 필요할 수 있습니다.
- 방화벽 규칙 설정 등에서 고정 IP 주소가 유용합니다.
6.4 ALB와 고정 IP 주소를 위한 대안
- Network Load Balancer (NLB) 사용:
- NLB는 가용 영역별로 고정 IP 주소를 제공합니다.
- 하지만 7계층(HTTP/HTTPS) 기능이 부족하다는 단점이 있습니다.
- AWS Global Accelerator 활용:
- AWS Global Accelerator를 사용하면 고정 IP 주소를 얻을 수 있습니다.
- 이 고정 IP 주소를 ALB나 NLB와 연결하여 사용할 수 있습니다.
- NLB와 ALB 조합:
- NLB를 ALB 앞에 배치하는 방식으로 고정 IP와 7계층 기능을 모두 활용할 수 있습니다.
- 이 구성을 통해 고정 IP 주소의 이점과 ALB의 고급 라우팅 기능을 동시에 사용할 수 있습니다.