서버에 트래픽이 많아지면 더 좋은 CPU와 램을 쓰면 되는거 아닐까? (Scale Up vs. Scale Out, Load Balancing)

1. 소개

AWS로 트래픽이 늘어나는 상황을 가정해 배포를 하다 보니 자연스럽게 로드밸런싱을 사용했었습니다.  예제들을 따라하다 보면 방법론에 치우칠 때가 있는데 왜 하게 되는지 잘 모르는 것 같아서 로드밸런싱이 어떤 건지 설정하는 법 이상의 "왜"에 대해 고민을 해보고 싶었습니다. 로드밸런싱에 대해 고민하다보니까 MSA를 사용하는 많은 이유들이 있겠지만 "이런 이유에서 나중에는 MSA까지 쓰고 싶어지지 않았을까?" 라는 생각이 드는 부분도 생기는 군요. 확실히 요즘은 글로 표현을 하는게 개인적으로 공부도 더 하게 되고 좀 더 깊게 파보게 되는 것 같습니다. 하나씩 풀어가 보겠습니다. 

 

*본 포스트는 사용법에 대해서 다루지 않으려고 합니다. 혹시 필요하신 분들을 위해 사용법은 도움 받은 링크들로 대체하였습니다. 

AWS: Application Load Balancer 시작하기

AWS강의실 : 13 Elastic Load Balancer

Inpa Dev님: ELB(Elastic Load Balancer) 구성 & 사용법 가이드

수강했던 FastCampus 강의

2. Scale Up 보다 Scale Out

 

아무래도 로드 밸런싱을 하는 타이밍을 생각한다면 점차 서버에 트래픽 부하가 늘어날 타이밍입니다. 모놀리식 구조의 하나의 서버라고 생각하면 서버의 가용성을 늘려가야 하는데 이때 선택해야 하는게 Scale-Up 아니면 Scale-Out입니다. 

 

언뜻 보면 Scale-Up이 더 직관적일 수도 있습니다. Computing Power가 부족하니 스팩을 올려야 한다. 사실 클라우드 생태계로 들어오면서 온프로미스 환경보다 스케일업이 쉬울 수 있습니다. AWS에서는 AMI를 통해 환경을 복사하여 스팩이 좋은 환경으로 갈아탈 수도 있습니다. 

 

그러나 스팩의 향상에는 상한선이 있고 올라갈수록 가격도 천정부지로 높아집니다. 용량이든 성능이든 신기술일수록 가격도 비싸지니까요. 사실 트래픽이 많아 진거라면 CPU 성능이 더 나아 질 필요가 있을까요? Scale-Out이 더 현실적인 이유는 GPU의 인기와도 같습니다. 더 나은 연산이 아니라 더 많은 연산을 필요로 하는 것이니까요. 더 많은 연산이라면 스팩보다 같은 스팩의 일꾼이 많아지면 훨씬 저렴하게 늘어난 트래픽에 대응할 수 있습니다. 트래픽이 늘어난다면 일단 좋은 서버가 보다 많은 서버가 필요합니다. 

 

 

문제는 하드용량을 더 끼우는게 아니라 새로운 서버가 생기는 것이다 보니 새 서버는 기존 서버와 주소가 달라 라우팅을 해주어야 합니다. 이 라우팅 작업을 해주는 것이 로드 밸런싱이고 덕분에 성능의 한계에 부딧히지 않고 합리적인 비용으로 서비스를 키워갈 수 있습니다. 

 

3. 로드 밸런싱 알고리즘의 종류

대표적인 로드 밸런싱 알고리즘의 종류를 정리해 보았습니다.

 

A. 라운드 로빈 (Round Robin) & 가중 라운드 로빈(Weighted Round Robin)

 

왼쪽) Round Robin 오른쪽) Weighted Round Robin

 

우리말로 하면 '수건 돌리기' 입니다. 클라이언트의 요청을 서버당 한번씩 돌아가며 순차적으로 분배하는 방식입니다. 모든 서버의 스팩이 비슷하거나 동일할 때 권장되며 가장 많이 사용하는 방식입니다. 서버의 스팩이 다른 경우 "가중치"를 두어 특정 횟수만큼 특정 서버에 더 많은 트래픽을 보낸 후 다음차례의 서버로 넘어가게 됩니다. 

 

B. 최소 연결 (Least Connection) & 최소 응답시간 (Least Response Time)

왼쪽) Least Connection 오른쪽) Least Response Time

라운드 로빈의 경우 서버의 '현재 상황'을 고려하지 않습니다. 이 알고리즘들은 현재 여유가 있는 서버로 트래픽을 보내주기 위해서 사용되고 최소 연결의 경우 요청 들어온 시점에 가장 적은 연결이 있는 서버에 최소 응답시간 알고리즘의 경우는 가장 적은 연결 수와 더불어 가장 짧은 응답시간을 보내준 서버에 우선적으로 요청을 나누어 줍니다. 

 

C. 해싱 (Hashing Method)

IP나 URL주소를 해싱알고리즘을 통해 랜덤한 번호를 뽑아 로드 밸런싱 합니다. 해싱 알고리즘은 동일한 IP 주소에 대하여 동일한 서버로 보내주는것을 보장하기 때문에 Sticky Session을 사용할때 알고리즘으로 쓸 수 있습니다. 세션 클러스터링이 안된 경우에만 사용을 권장합니다.

 

D. 랜덤 (Random)

랜덤 방식은 말 그대로 랜덤하게 서버에 보내주는 방식입니다. 이때, 매 요청마다 랜덤하게 보내줄 수도 있고 요청 범위도 랜덤하게 정해서 특정 요청 횟수만큼 보낸 후 다음 랜덤 서버로 보내는 방법도 있습니다. 

 

+. AWS에서 사용가능한 알고리즘

 

온프레미스로 로드밸런싱을 구성한다면 커스텀하게 알고리즘을 사용할 수 있겠지만 클라우드 환경에서는 제공해주는 알고리즘을 선택하여 사용할 수 있습니다. AWS ELB(Elastic Load Balance)들에서 기본적으로 쓰이는 알고리즘도 RR(Round Robin)입니다. AWS는 RR과 LOR(Least Oustanding Request - 최소 연결과 비슷), WR(Weighted Random)을 공식문서에서 지원하는데 다른 내용에서 보면 RR과 LOR만 지원하는 것 같습니다. (공식문서: AWS: Target groups for Your Application Load Balancers , 솔루션 업체의 고객지원 답변: Bespin Global)

 

+. Spring Cloud의 Load Balancer를 쓸 경우 Round Robin과 Random방식을 지원한다고 합니다. (인프런: 로드밸런싱-전략을-바꿀려면-어떻게-해야하나요? )

 

4. AWS ELB의 대표적인 로드발란서 서비스 : NLB(L4 스위치), ALB(L7 스위치)

 

AWS를 통해서 클라우드 서비스를 쓰고 있지만 온프레미스 레벨에서 쓰이던 하드웨어나 소프트웨어입니다. 로드발란싱은 대표적인 L4, L7스위치의 기능이었고 이런 기능들을 AWS는 ELB의 기능들로 제공하고 있습니다. 대표적으로 L4 스위치(Network Load Balancer), L7 스위치 (Application Load Balancer)의 기능들을 제공하고 있습니다. 또한 L3 스위칭(라우팅)을 응용한 Gateway Load Balancer를 통해 가상 어플라이언스같이 특정 IP를 거치도록하여 보안등을 강화할 수 있는 LB 서비스를 제공합니다. 

 

스위치란 네트워크의 장치들을 연결하고 패킷을 주고 받을수 있도록 하는 장치 입니다. 네트워크 통신에서 패킷을 전달하거나 주소(MAC, IP.. etc.)를 찾기 위해 쓰입니다. 스위치는 대표적으로 L2, L3, L4, L7 스위치가 있습니다. L1~L3스위치의 경우 하드웨어로 구성되고 L4는 섞여 있으며 L7은 보통 소프트웨어로 이루어져 있습니다. (L5, L6은 보통 L7에서 처리합니다.) 

 

A. L1 스위치 (물리계층, 전기신호, 리피터)

 

받은 패킷을 단순히 연결된 모든 장치에 보냅니다. 사용 하드웨어는 연결 거리가 길어지는 상황에서 약한 신호를 살리기 위한 리피터 또는 여러 장비로 보내주기 위한 허브가 있습니다. 

 

B. L2 스위치 (데이터 링크 계층, MAC, 스위치)

 

이 스위치는 특정 MAC주소에 패킷을 보내 주기 위해서 사용합니다. 주로 내부망에서 패킷의 타켓이 되는 컴퓨터나 서버를 찾기 위해 사용되고 타겟의 MAC주소를 알아내기 위해 ARP 요청을 합니다. ARP요청을 하면 내부망 '모든 기기'에 하나씩 받은 IP 주소를 가지고 주인인지 물어봐서 일치하는 MAC 주소를 패킷을 보낼 수 있게 알아내 줍니다. 사용장치는 하드웨어방식인 스위치와 소프트웨어 방식인 브리지가 있습니다.

 

C. L3 스위치 (네트워크 계층, IP, 라우터)

내부망을 넘어 네트워크간 통신을 위해 사용되며 사용자가 설정해 놓은 '라우팅 테이블'을 보고 가야할 내부망을 찾아 갑니다. 경로는 라우터가 최적화 해서 가며 AWS에서 VPC설정을 할때도 그렇지만 라우팅 테이블에 IP를 등록해 있지 않으면 현재의 서브넷 외의 다른 서브넷과 소통이 불가능 합니다. 사용 하드웨어는 라우터입니다. 

 

D. L4 스위치(전송계층, TCP, 네트워크 로드 밸런서)

 

IP 주소를 토대로 이전의 로드밸런싱 알고리즘을 사용하여 로드밸런싱을 합니다. 또한 내부망과 외부망의 경계가 되어 L4스위치에 공인 IP를 가지게 하여 IP주소를 필요시 걸러 낼 수 있습니다. L3 스위치 까지는 외부와의 통신을 위해 필요했다면 L4 스위치를 사용시 외부 IP(공인 IP)와  내부 IP(사설 IP)로 나누어 라우팅을 L4스위치 까지만 받아서 검증 후 내부 사설망으로 보낼 수 있습니다. 이때 포트번호를 이용하여 특정 서비스나 서버로 라우팅이 가능 합니다. (상세: 네트워크 엔지니어 환영님: L4스위치 쉽게 이해하기 #1)

 

E. L7 스위치(어플리케이션 계층, HTTP - URL, 어플리케이션 로드밸런서)

 

 

L7 레벨의 프로토콜을 로드 밸런싱 할수 있고 대표적으로는 HTTP/HTTPS를 로드밸런싱 합니다. 어플리케이션 레벨의 패킷(Payload)까지 분석을 하므로 더 세밀한 수준의 보안 및 분석이 가능합니다. L7 스위치는 L3, L4스위치의 기능을 포용하며 L4의 부하분산 기능 외에 L7레벨의 프로토콜의 데이터까지 확인하여 트래픽을 관리할 수 있습니다.

 

+. 어떤 로드밸런서를 사용하여야 할까. 

 

스위칭은 분기점이라는 특성을 이용해서 보안이나 통신등의 기능을 소프트웨어나 하드웨어적으로 만들어 놓은 장치 또는 소프트웨어 인 듯 합니다. 이런 관점에서 고수준인 로드 밸런싱은 보면 점점 세분화 되는 L7 스위치를 사용하는게 합리적이라고 볼 수도있지만 각 레벨의 패킷을 분석하는 것도 시간과 자원이 들게 됩니다. 보안이나 HTTP요청까지 분석이 불필요하다면 L4 스위치만 사용해도 될 수도 있고 AWS의 Gateway Load Balancer 처럼 각 스위치의 기능으로 무언가를 더 하려면 다른 레벨의 스위치를 이용할수도 있으니 상황과 목적에 맞게 사용해야 합니다 

 

 

5. 결론

온프레미스에서 클라우드 서비스로 넘어오면서 편리함을 선택한 대신 알고리즘 선택의 자유도가 줄었습니다. 그러나 다행히 하나에 알고리즘에 치우친게 아니라서 자주 쓰이고 효과적인 알고리즘 위주로 서비스가 구성되어있어서 기호와 상황에 따라 사용을 할 수 있을 것 같습니다. 또한, AWS 서비스에서 HTTP로 외부 요청을 받는 경우 보안을 위해 L7을 두지만 내부 통신만 하는 경우는 비용도 절감할 수 있는 L4를 쓸수도 있겠다고 생각했습니다. 

 

이렇게 로드밸런싱을 하다보면 요청이 늘어날때마다 필요한 부분이 아닌 모놀리식 서버 전체를 증설해야 하는데 API 게이트웨이에 대해서도 공부하다 보니 요청을 URL에 따라 특정 서버나 로드밸런서로 보낼 수 있습니다. 그러면 점점 전체 서버를 증설하는 비용을 감당하기 보다 필요한 서버만 증설하는 게 합리적이지 않을까 하는 생각이 들었습니다. 어쩌면 이런 고민이 MSA를 통해 서비스 단위로 서버를 관리하게 된 계기일 수도 있겠습니다.

 

 

출처:

2장

넥스트 이노베이션: 로드밸런서 로드밸랜서 L4 Load Balancer

AWS: Elastic Laod Blacner의 작동방식

AWS: Target groups for Your Application Load Balancers

AWS: Application Load Balancer 시작하기

Having님: [Network] 로드밸런서(LB)-정의,역할,로드밸런싱 알고리즘, 종류

개발 아카이브님: Cookie/ Session - sticky session/ session clustering 

Bespin Global: [AWS] ALB 작동 방식 설정방법 

Open Genius: Types of Load Balancing Algorithms 

Simplified Learning : Load Balancing Algorithms

After Academy: What is Load Balancing? How does it work?

Server Tombak: What Is Load Balancer?

 

3장

NET DREAM님: L2주소와 L3 주소 통신(ARP)

일기장님 : OSI 7계층 장비(리피터, 허브, 브리지, 스위치, 라우터)

미식한고독가님: OSI7Layer와 L1, L2, L3, L4, L7 스위치

CloudFlare: 네트워크 스위치란

Biz & Block 님: 스위치(L1, L2, L3, L4, L7 한번에 알고 싶은 사람?)

네트워크 엔지니어 환영님: L4스위치 쉽게 이해하기 #1

네트워크 엔지니어 환영님: L4/L7 로드밸런싱 쉽게 이해하기

Datanet: L7 스위치로 네트워크 활용도를 높여라

코드 연구소님: [네트워크] L4 스위치 L7스위치 차이, 스위치란? 로드 밸런서란?

Paralles: What Is an AWS Gateway Load Balancer and What Are Its Benefits?

 

사용법

AWS강의실 : 13 Elastic Load Balancer

Inpa Dev님: ELB(Elastic Load Balancer) 구성 & 사용법 가이드

인프런: 로드밸런싱-전략을-바꿀려면-어떻게-해야하나요?