AWS load balancers deep dive-AWSKRUG

1. AWS Load Balancers
2019-05-11
AWSKRUG - syha

2. 0. 들어가기에 앞서
AWS managed service인 ELB의 내부는 Black box 영역 입니다.
발표 내용의 대부분은 AWS 공식 매뉴얼에 한쪽 귀퉁이에 있거나
AWS Case를 통해 확인한 내용입니다.
따라서, 정확한 내용일 수도, 아닐 수도 있습니다.

3. 0. 들어가기에 앞서
L4 Layer에서는 IP, Port based의 Routing 처리
L7 Layer에서는 IP, Port, packet based의 Routing 처리

4. 1. Load Balancer 비교
CLB ALB NLB
Protocols HTTP/HTTPS TCP/TLS HTTP/HTTPS TCP/TLS
TCP connection Connection pool 1:1 connection connection pool 1:1 flow/connection
Idle timeout Idle timeout (default 60s) 350 Sec RST
Routing algorithm Least outstanding Round Robin Round Robin Flow hash
SSL/TLS Yes No Yes Yes
SNI(Server Name
Indication)
No Yes No
Static IP No - Dynamic IP No - Dynamic IP Yes - EIP
Sticky session Yes No Yes No
multiple ports on the
same instance
No Yes Yes

5. 1. Load Balancer 비교
CLB ALB NLB
Protocols HTTP/HTTPS TCP/TLS HTTP/HTTPS TCP/TLS
WebSockets No Yes Yes
Lambda as targets No Yes No
Delete protection No Yes Yes
Native HTTP/2 No Yes No
Preserve Source IP No No Yes
TAG-based IAM
Permission
No Yes Yes
Slow Start No Yes No
User Authentication No Yes No

6. 1. Load Balancer 비교
CLB ALB NLB
Protocols HTTP/HTTPS TCP/TLS HTTP/HTTPS TCP/TLS
Redirects No Yes No
Fixed response No Yes No
Custom security
policies
Yes No No
Support WAF No Yes No
Fail Open No Yes Yes
Cross AZ Traffic 비
용 발생
No No Yes
Security Group Yes Yes No
Container Support No Yes Yes

7. NLB :
- 높은 처리량, 낮은 대기시간, 즉각적인 응답성을 요구하는 TCP 트래픽을 로드 밸런싱 할 때
- 트래픽이 갑작스럽고 변동이 심한 패턴을 가지는 워크로드일 경우
- 외부에 노출될 고정IP가 필요로 할 때
- ECS 등 Container 기반 동적 포트의 L4 작업이 요구 될 때
ALB :
- HTTP/HTTPS 트래픽의 고급 요청 라우팅이 필요할 때
- ECS 등 Container 기반 동적 포트의 L7 작업이 요구 될 때
- Front에 WAF를 두거나 혹은 backend로 lambda를 선택하고자 할 때
CLB :
- EC2-Classic platform 에서 계속 동작되는 EC2를 단일 지점에서 로드밸런싱 해야 될 때
- 보안정책으로 Custom Security Policy를 만들어야 할 때
ELB 제품군 세부 비교 URL : https://aws.amazon.com/ko/elasticloadbalancing/details/#compare
1. Load Balancer 선택 기준

8. 2. Load Balancer 구조(예상)
AWS의 Load Balancer의 구조는 Black box
Request flow TCP connection and HTTP
Client
A zone
C zone
Load Balancer
A zone
C zone
Backend
Traffic Traffic

9. 3. CLB의 SurgeQueueLength
Request Spike -> SurgeQueueLength Max 1024 -> SpillOver -> ELB_5xx
A zone
C zone
Load Balancer Backend
Client
ELB_5xx

10. CLB TCP Listener 에서는 왜 SurgeQueueLength 가 자주 발생?
3. CLB의 SurgeQueueLength
A zone
C zone
Load Balancer Backend
SYN_SENT SYN_RCV
ESTABLISHED
ESTABLISHED
SYN
SYN, ACK
ACK
Traffic

11. ALB는 SurgeQueueLength 가 없을까요?
- RejectecConnectionCount Metric은 CLB의 SurgeQueueLength Metric 을 대체
- LB가 정상적인 Target 과의 라우팅 요청 연결을 설정할 수 없어 거부 된 연결 수
- LB의 최대 연결 수에 도달하여 거부된 연결 수
3. Load Balancer의 SurgeQueueLength
URL :
https://www.slideshare.net/AmazonWebSer
vices/application-load-balancer-and-the-
integration-with-autoscaling-and-ecs-
popup-loft-tlv-2017

12. 4. Load Balancer의 Health check
TCP Listener / HTTP Listener Health Check
TCP : SYN -> SYN/ACK -> 세션 종료
HTTP : Connection pool과 다른 connection을 맺어 HTTP 상태코드 체크/ Backend의 KeepAlive에 따라 세션 유지

13. 4. Load Balancer의 Health check
Unhealthy Hosts의 Min 값과 Max 값이 다르다!?

14. 4. Load Balancer의 Health check
결론 ELB의 Unhealthy hosts 는 Min 값으로 모니터링하고,
ELB node의 상태는 Sample data를 참고만 한다.

15. 5. Load Balancer의 Scale OUT/IN
기본적으로 CLB와 ALB의 Scaling은
CPU Utilization, Network Traffic In/Out 에 의해 결정
A zone과 C zone에 동시에 Scaling이 적용
NLB는 단순히 백엔드로 트래픽을 전달만 해서,
리소스가 거의 사용되지 않으며, 이론적으로 Scaling이 필요 없음

16. 5. Load Balancer의 Scale UP/DOWN
몰라요

17. 6. Load Balancer의 Unbalancing
50%
25%
25%

18. 7. Load Balancer의 일반적인 질문
질문 답변 비고
Backend 에서 확인해 보니 ELB와의 커넥션이 SYN_RCV
connections 으로 표기 됩니다.
CLB TCP Listener 에서 좀더 빨리 세션을 맺기 위해 pre-opening
connection 을 하기 위함임으로 정상 입니다.
Client 가 504 Gateway Timeout을 수신했습니다.
$ time telnet URL 80
Backend connection idle timeout이 ELB Time out 보다 큰지 확인 합니다.
항상 SurgeQueueLength가 1~2 정도가 존재합니다.
CLB TCP Listener 일 경우 connection proxying time 으로 항상 발생할 수
있습니다.
NLB에서 RST(resets) 를 Client와 Target 에 보냅니다.
NLB는 350초 이상 아무런 통신 없이 세션을 유지할 때 RST신호를 보냅니
다. 만약 회피하고 싶으면 Backend에서는 Keep Alive를 사용하지 않고
Client 요청을 즉시 끝내거나, 350초 이전에 Ack를 보내게끔 설정.
ELB Access log에 request 내용이 표시되지 않습니다.
LB Log는 end to end connection이 성공해야만 남습니다. 혹은 request,
response_processing_time에 -1 값이 들어왔는지 확인 합니다.
RequestCount 가 Backend의 access log 보다 낮습니다.
Listener 의 종류에 따라 HTTP request count 일 수도 TCP connections
count 일 수도 있습니다.
즉 HTTP Listener는 등록된 인스턴스의 HTTP 오류 응답을 포함한 수신 및
라우팅 요청 수를 표기 하며, TCP Listener일 경우 등록된 인스턴스에 대한
연결 수를 의미 합니다.

19. 7. Load Balancer의 일반적인 질문
질문 답변 비고
Client 에서 항상 같은 ELB(IP)에 접근합니다. Client DNS caching 을 확인해 보아야 합니다.
Backend 의 특정 EC2만 CPU 사용률이 높습니다. 해당 EC2가 ELB에서만 접근할 수 있는지 확인합니다.(예, Security Group)
트래픽을 분산 시키는 Routing algorithm이 뭡니까? 두 가지를 봐야하는데, Front 단과 Backend 단을 확인해야 합니다. Front 는
DNS에서 결정이되며, Backend 는 ELB 종류와 Listener 종류에 따라 결정
됩니다.
Backend 혹은 Target 에서 응답은 하지만 ELB Health Check
에 대해서는 실패 합니다.
$ telnet xxx.xxx.xxx.xxx port 명령을 통해 확인합니다.
$ curl -vIg 명령을 통해 HTTP response code 를 확인합니다.
Load Balancer의 IP가 변경되었습니다. ALB, CLB에서는 Scale Up/Down 에 의해 변경될 수 있습니다.
어떻게 ELB의 전체 IP를 확인할 수 있습니까? $ dig +short ELB_DNS_name
어떻게 방화벽에서 Load Balancer의 IP를 whitelist 로 추가할
수 있습니까?
NLB를 사용하여 EIP로 고정 시키거나, 내부 ELB의 경우 subnet 을 작게 만
들어서 ELB가 최소한의 IP만 할당 받을 수 있게 한 다음 방화벽에서 범위로
열어줍니다.

20. 7. Load Balancer의 일반적인 질문
질문 답변 비고
SSL을 설정하였으나 익스플로러 창에 자물쇠가 안되는 경우 $ curl -vI https://Domain
Host header 값(200)을 확인
Domain name 과 server’s certificate 와 매칭이 안될 경우 $ openssl s_client -connect LB_DNS:443 -showcerts
명령을 통해 인증서의 subject 를 확인
No matching cipher on the client Load Balancer의 Security Policy를 확인하여 지원하는 암호화 제품군과
protocol version을 확인 합니다.
ALB 하위 target group에서 모든 Backend Instance의 상태 실
패되었는데 통신이 왜 되나요?
Fail open 정책으로 ALB, NLB 가 구성되어 있기에 이러한 일이 발생합니다.
이는 LB의 특성임으로 문제가 되지 않으며, 관리를 위해 Health check 정책
수정을 권고 합니다.

21. 8. 부록 ELB Pre-warming
항목 예제 설명 비고
ELB DNS name ELB.ap-northeast-
1.elb.amazonaws.com
ELB DNS name
Start date for elevated traffic patterns 2018.07.16 00:00 AM UTC 트래픽의 시작 일시 UTC 기준
End date for elevated traffic patterns 2018.07.16 05:00 AM UTC 트래픽의 종료 일시 UTC 기준
Traffic delta or request rate expected at surge(in
requests per second)
500 to 1,000 in 1 sec 초당 요청 건수
Average amount of data passing through the ELB per
request/response pair(In Bytes):
50 Kbytes 요청과 응답의 총 사이즈
Rate of traffic increase 1000% 평시 대비 트래픽 증가율
Are keep-alives used on the back-end? Yes or No keep alive 설정 여부
Percent of traffic using SSL termination on the ELB 100% or 0% SSL 처리 여부

22. 8. 부록 ELB Pre-warming
항목 예제 설명 비고
Number of AZ’s that will be used for this event/load
balancer
3 ELB에서 트래픽을 분산하고 있는 가
용 영역 갯수
Is the back-end scaled to event/spike levels?
If no, how many and what type of instances and when
will they be scaled?
Yes or [No]
[No일 경우 Backend Instance
Type 및 증가 계획]
Auto Scaling의 확장하는 기준(정책)
혹은 Manual로 추가될 EC2 Instance
유형과 갯수
Use-case description Ticket sales are being prepared
for the event.
Pre-warming 이 필요한 이유
Traffic pattern description Gradual increase (점진적 증가)
Radical increase (급진적 증가)
Maintain traffic during event
time(이벤트 시간동안 트래픽 유지)
Increase temporary traffic(일시적
인 트래픽 증가)
트래픽 패턴 설명

23. 8. 참고 자료
오픈 소스 TLS 구현 인 s2n을 소개합니다.
https://aws.amazon.com/ko/blogs/security/introducing-s2n-a-new-open-source-tls-implementation/
네트워크로드 균형 조정기의 TLS 종단
https://aws.amazon.com/ko/blogs/aws/new-tls-termination-for-network-load-balancers/
응용 프로그램로드 밸런서가 SNI를 사용하여 스마트 선택으로 다중 TLS 인증서 지원
https://aws.amazon.com/ko/blogs/aws/new-application-load-balancer-sni/
Elastic Load Balancing: Deep Dive and Best Practices
https://www.slideshare.net/AmazonWebServices/repeat-1-elastic-load-balancing-deep-dive-and-best-practices-net404r1-aws-reinvent-
2018

24. 감사합니다.
“포로리야~
박수 좀…”