05/19 ACM, ALB 실습

ALB으로 만들어 뒀던 web01과 web02로 부하분산을 해보자

테스트를 위해 각 페이지를 구분할 수 있게 수정한다. 배포 단계에서는 같은 게 맞음

 

 

 

이걸 하는 이유는 HTTPS 프로토콜을 사용할 때 필요한 TLS 인증서를 만드는 과정이다.

이 것으로 전송 간 데이터를 암호화하는 것

 

 

 

내 서브 도메인들도 인증서가 적용되게 *로 모두 적용시킴

 

내가 적은 도메인들이 진짜 내꺼인지 확인해보는 것으로 DNS 검증함

 

CNAME 레코드를 만들어 검증함

검증 완료 후 발급 됨

 

 

ELB 실습

1. Classic Load Balancer

 

• 계층: L4 + 간단한 L7
• 특징:
  • 예전 로드밸런서 (Deprecated)
  • 단순한 라운드로빈 방식
  • 기능이 제한적 (ALB/NLB에 비해)

 

 

여기에 TLS 인증 넣고 인스턴스 2개를 포함 시킴

80과 443을 리스닝 하고 있게 설정

 

결과

 

 

 

 

라운드 로빈으로 번갈아가면서 나옴

 

하지만 HTTPS 로 접속히 안전하지 않은 페이지라고 뜸

이걸 해결하기 위해 라우트53에서 별칭을 통해 바꿔 줘야함 지금 도메인
https://my-clb-1950010621.ap-northeast-2.elb.amazonaws.com/

이거지만 설정한건 *.zere2dev.my로 해줘야함

인증서에서는 *.zere2dev.my로 기대하고 있

여기서 ALB도 이걸 사용해서 하는데 둘 다 HTTP 프로토콜 즉 7계층으로 LB 수행해서 그럼

 

인증서 오류가 발생하지 않음

 

2. Network Load Balancer

 

• 계층: L4 (전송 계층)
• 특징:
  • 초고속, 초저지연 처리
  • 수백만 TPS 가능
  • 정적 IP 제공
  • TLS 종료 가능 (L4지만 TLS 오프로드도 가능)

여기에 대상 그룹으로 인스턴스를 추가해줘야 한다.

이것도 CLB와 ALB/NLB 와의 차이 중 하나이다.

 

대상 그룹으로 한 번에 관리할 수 있는 것

여기에 ALB도 넣을 수 있는데 이건 트래픽을 분산하고 또 LB로 분산할 수 있게 만들어주는 것이다.

추가적으로 CLB랑은 다르게 포트로 대상그룹을 만드는데

이렇게 하면 하나의 인스턴스가 여러 LB와 연결 될 수 있어 유연하다.

 

외부 트래픽이 NLB로 오는 동안 인터넷을 통하니 TLS로 암호화된 채로 이동시키고

AWS 내부에서 이동할 때는 평문으로 통신해도 됨

그렇기에 NLB가 받을 때는 TLS로 리스닝하고

인스턴스에게는 80포트 리스닝하게 설정할 수 있

 

 

큰차이는 없지만

아까는 HTTPS 를 리스너로 추가했지만

NLB는 4계층이니 TCP, UDP, TLS 이렇게 표현되어 있고 https 는 TLS를 선택해야함(암호화된 전송프로토콜)

동일하게 별칭 설정해줌

CLB와는 다르게 리소스 맵을 보면 프로비저닝 시간이 더 걸림 -> 초기 헬스체크가 시간이 걸림

 

현재 대상그룹의 헬스체크에서 비정상 뜨는 현상 발생

 

Application Load Balancer

 

• 계층: L7 (애플리케이션 계층)
• 특징:
  • 경로 기반, 호스트 기반 라우팅 가능
  • HTTP/HTTPS 전용
  • 쿠키 기반 세션 유지 가능 (스티키 세션)
  • WebSocket, HTTP/2 지원

 

 

 

HTTPS 만 리스닝하고 그걸 80 리스닝 하고 있는 대상 그룹으로 넘겨주기

 

 

 

ALB에 추가로 적용할 수 있는 서비스

• Amazon CloudFront: ALB를 오리진으로 CDN을 만들 수 있다.
• WAF: 웹 공격을 방어하는 L7 보안 서비스이다.(조건기반 차단 가능)
• Global Accelerator: 전 세계 트래픽을 AWS 글로벌 네트워크를 통해 가장 빠른 경로로 라우팅 해줌
  • ALB를 대상으로 등록
  • 사용자 요청은 GA의 Anycast IP를 통해 지리적으로 최적의 리전에 위치한 ALB로 전달해준
  • -> 지연속도 최소화, 멀티리전 ALB 지원

 

정상 작동함

 

밸런싱 해주는 방식을 대상 그룹에서 변경할 수 있음

최소 미해결 요청이 주로 쓰임

하나의 요청은 큰 요청이 가고 다른 건 가벼운 요청이 가는 등 두 서버의 상태가 다를 수 있어서
단순이 라운드 로빈으로 분배하는 건 비효율적일 수 있음

 

대상 그룹의 전달이 Blue Green을 가중치를 줘 제어할 수 있다.

이렇게 하면 새로 배포한 인스턴스의 비중을 낮춰 잘 동작하는지 확인할 수 있고 점차 그 비중을 높일 수 있다.

 

다음은 Auto Scaling에 대해서 실습해보겠다.