[발표자료]Elastic Load Balancing로 트래픽 분산해보기

이번 DevelopersIO Korea Online 에서 첫번째 세션으로 Elastic Load Balancing으로 트래픽 분산해보기라는 주제로 발표를 했는데요

그때 발표한 자료와 자료만 붙이면 조금 아쉬운 감이 있어 설명을 조금 첨가해 작성해 보았습니다. ^^

PPT

Elastic Compute Service(EC2)

처음 AWS를 이용하게 되시면 눈에 들어오는 서비스입니다. Elastic Compute Service EC2라고 하죠

처음 EC2 한대로 서비스를 만들어 운영했을 때 어떤 문제가 있을까요? 처음은 괜찮습니다. 하지만 어느 정도 시간이 지나 트래픽이 증가하게 된다면?

Scale Up

그때 가장 처음 떠올리는 게 EC2의 Computing power를 늘리는 Scale Up이죠

하지만 이 방법도 문제가 있죠

가장 큰 문제는 업그레이드 도중 서비스가 중단된다는 것입니다.

그럼 어떻게 해결해야 할까요?

Scale Out

여기서 도입해볼 만한 방법으로 Scale Out이 있습니다. EC2 한대의 Computing Power를 늘리는 게 아닌 여러 대의 EC2 Instance를 세워 해결하는 방법입니다.

그럼 여기서 여러 대의 EC2 Instance에 어떻게 트래픽을 분산할까요?

Elastic Load Balancing

그 방법으로 Elastic Load Balancing이 있습니다.

이번에는 Classic Load Balancer를 통해 어떤 서비스인지 알아보겠습니다.

처음 생성 단계인데요. 7단계로 나누어져 있습니다.

여기에서는 3가지 단계에 대해서 자세히 살펴보도록 하겠습니다. 각 단계의 자세한 내용은 PPT에 나와 있습니다. 참고해주세요!

Define Load Balancer(로드 밸런서 정의)

처음 설정입니다. AWS에서 제공하는 가상의 네트워크인 VPC를 설정합니다. 그리고 트래픽을 분산할 대상인 EC2 Instance를 위치시킬 서브 네트워크인 Subnet을 설정하게 됩니다.

Listener 구성의 의미는

• Load Balancer

Protocol	Path
HTTPS	443

외부에서 Load Balancer에 접속할때 사용할 Protocol과Path

• Instance

Protocol	Path
HTTP	80

Load Balancer에서 대상(EC2 Instance)에 접속할때 사용할 Protocol과Path

입니다.

Configure Health Check(상태 검사 구성)

HealthCheck란? 무엇일까요

만약 트래픽을 분산할 대상인(EC2 Instance)에 문제가 있다면 트래픽을 분산해서는 안 되겠죠

Load Balancer에서 트래픽을 분산할 대상인 EC2 Instance에 상태를 확인하고 트래픽을 분산할지 하지 않을지 정하는 단계라고 생각하시면 됩니다.

그에 따라 Health Check를 할 때 접속할

Protocol	Port	Path
HTTP	80	/path

Protocol과 Port 그리고 Path를 설정하게 됩니다.

Advanced Details 설정을 살펴보겠습니다. Health Check의 30초 설정은 30초 간격으로 Health Check를 하겠다는 의미입니다.

Response Timeout의 5초 설정은 5초 안에 Health Check를 수행하겠다는 의미이며

그에 따라 Unhealth Threshold에 설정한 숫자만큼 실패했을 때에는 트래픽 분산 대상에서 제외

하지만 Healthy Threshold에 설정한 숫자 안에 Health Check에 성공했을 때에는 다시 트래픽 분산대상으로 선택됩니다.

Add EC2 Instance

마지막으로 설정하는 Add EC2 Instance는 간단하게

선택할 대상을 선택하는 선택 창과 두 개의 옵션으로 이루어져 있습니다.

각 옵션에 대해서 살펴보겠습니다.

Connection Draining

만약 트래픽을 분산하고 있는 대상인 EC2 Instance에 문제가 생겼다고 생각해 봅시다. 그런데 그 EC2 Instance에는 현재 요청된 작업이 있다면 어떻게 해야 할까요? 바로 트래픽 분산 대상에서 제거하기에는 문제가 있습니다. 이 옵션을 통해 현재 EC2 Instance가 트래픽 분산 대상에서 제외되어야 한다고 해도 처리되는 작업이 끝나거나 또는 옵션에서 설정한 시간이 지났을 때 대상에서 제외되게 하는 효과를 누릴 수 있습니다.

Cross-Zone Load Balancing

Load Balancer를 생성하게 되면 여러분은 여러 Availability Zone이라는 여러 구역을 설정하게 됩니다.

아마 앞에서 VPC라는 가상의 네트워크와 서브 네트워크인 Subnet을 설정하시는 것을 보셨을 겁니다. 그때 설정한 Subnet이 위치하는 곳이 이 Availablity Zone이라고 생각하시면 됩니다.

그럼 Load Balancer에 60이라는 가상의 트래픽이 생겼다고 생각해 봅시다. 처음 Cross-Zone Load Balancing이라는 옵션이 켜져 있다면 현재 생성되어있는 EC2 Instance에 고르게 트래픽을 분산하게 됩니다.

하지만 꺼져 있다면 Load Balancer는 EC2 Instance의 숫자를 신경 쓰지 않습니다. 설정된 각 Availablity Zone에 고르게 트래픽을 분산하게 됩니다.

아 그리고 발표중에서는 말하지 않은 내용인데요 CLI를 이용했을 때는 이 옵션이 Off로 설정되기 때문에 주의해주세요.!

ClB VS ALB＆NLB

사실 현재 CLB보다는 AWS에서 ALB나 NLB의 사용을 권장하고 있습니다.

하지만 처음 공부하실 때는 CLB를 간단히 만져보시고 ELB에 대한 감을 잡으셨다면 ALB나 NLB를 이용하시는 걸 추천해 드립니다.

각 ELB의 차이점 또는 공통으로 설정되는 옵션에 관해서는 제품 비교를 참고해주세요!

Target group

먼저 기존 CLB와는 달리 ALB와 NLB에서는 Target Group을 통해 Target group내 대상에게 트래픽을 분산할 수 있습니다. 그리고 ALB의 경우에는 Lambda와 같은 서비리스 Service를 설정하실 수도 있습니다.

Rule

ALB의 경우 Rule을 통해 Path을 설정하여 Target Group에 맵핑하는 방법을 이용하실 수 도 있습니다. 그리고 Rule 설정을 통해 Cognito와 같은 AWS 인증 서비스를 ALB에 연결해 이용하실 수도 있습니다.

관심있으시다면 Application Load Balancer 탑재 인증을 통한 간편한 로그인 기능 출시기사를 참고해주세요!

Amazon EC2 Auto Scaling

ALB에 대해서 알아봤는데요 ALB에서 조금 아쉬운게 있죠 바로 트래픽을 분산할 대상을 미리 설정해야 한다는 건데요 그래서 마지막으로 자동으로 대상을 늘리거나 줄일수 있는 서비스를 소개해 드리겠습니다.

바로 Amazon EC2 Auto Scaling이라는 서비스 입니다.

하지만 서비스만 알려드리면 조금 아쉬울 것 같아서 간단한 샘플 구성도를 준비해 봤습니다. 한번 이 샘플 구성도에 맞춰 만들어 보시는 것도 재밌을 겁니다.

샘플 구성도

Amazon EC2 Auto Scaling은 트래픽에 맞춰 대상을 늘리거나 줄이거나 할 수 있습니다. 하지만 단순히 늘려봤자 의미 없죠.

그래서 Amazon Machine Image라는 서비스가 있습니다. 이 서비스를 이용해 미리 만들어 둔 설정을 Image로 만들고 이 Image를 Amazon EC2 Auto Scaling에 설정해 트래픽에 따라 대상을 늘리거나 줄일 수 있습니다.

그리고 마지막으로 현재 상황이 어떤지도 알아야겠죠 현재 트래픽을 분산할 대상이 생성되었나 또는 제거되었나 하는 상태를 Amazon Cloud Watch라는 서비스를 통해 받아보실 수 있으며 Amazon Simple Notification이라는 서비스를 통해 여러분들의 메일을 통해 알림을 받아 보실 수도 있습니다.

이상 소감!

정말 이번 Developers IO Korea를 준비하면서 이렇게 많은 분이 모여주실지 몰랐습니다. 이런 경험은 처음이라 많이 긴장을 했는데요 혹시 티가 났나요? 이번에는 이렇게 많이들 모여주셔서 감사하다는 생각밖에 할 수 없네요.

그리고 입문자 대상이라는 생각을 가지고 준비했는데 내용이 충분히 전달되었는지 잘 모르겠습니다. 다음번에는 조금 더 준비에 힘을 실어 좋은 내용으로 뵙도록 하겠습니다.!