AWS Auto Scaling & Load Balancer(오토 스케일링과 로드 벨런서)

 

혹시 "그 게임"을 하는 사람들이 있는가? 2030들의 추억을 책임졌던, 혹은 지금도 많은(?)사람들이 하고 있는 "그 게임" 말이다. "그 게임"의 특징은 방학시즌에 유저가 미친듯이 폭증한다는것 이다. 아래의 표는 구글트렌스를 활용하여 '그 게임'의 관심도(검색률)을 기록한 것이다. 물결이 상승치듯 올라갔다가 내려갔다를 반복하고 있는것을 확인할 수 있다.

 

 

뜬금없이 공부하다말고 왜 게임이야기를 했을까? 우리는 개발자, 혹은 IT직군이니 프로(?)마인드를 가지고 고민해보자. 검색량이 증가한다는것은 곧 서비스를 이용하는 사람들이 많아진다는 의미고 급작스러운 수요증가는 서버의 마비를 일으키지 않을까? 라는 고민에 충분히 도달할 수 있다. 이런 상황을 가장 손쉽게 해결하는 방법은 별거없다. 그냥 돈 많이 써서 서버를 잔뜩 증설하면 된다. 

 

라고 하면 아마 사장님이 등짝을 엄청나게 쎄게 때리실 수 도 있으니 이런 방법은 잠시 접어두자. 단순 서버를 증설하면 거기에 따른 기기값, 설치, 운용, 보안, 유지 등등 회사측에서는 정~말 싫을것이다. 설령 서버를 증설한다고 가정해 보자, 그러면 새로운 서버를 만들것 인지, 아니면 기존 서버의 용량을 키울것인지, 지금 들어오는 고객이 계속 유지가 되는지 이 기기가 낭비되지는 않는지, 트레픽이 병목현상이 일어나지 않는지 등등 을 고민해 봐야 한다. 회사의 입장에서는 정말 번거로운 일 일 것이다. 이런것을 사용자가 설정한 만큼 "자동"으로 해 주는 기능이 있으면 어떨까? 이 기능이 바로 Auto Scaling이다.

 

즉 Auto Scaling은 ELB(Elastic Load Balancing)에 연결된 EC2를 트레픽의 흐름에 맞게 늘리기도 하고 줄이기도 한다. 유저의 수가 적을때는 서비스 비용을 아낄 수 있으며 유저가 갑자기 많이 들어올 때는 서버 과부화를 막을 수 있다. 많고 적음에 대한 기준은 AWS에서 자체적으로 설정할 수 있다.

 

Auto Scaling에 대한 설정 프로세스는 아래와 같다. 먼저 1)서버를 세팅하고 세팅된 서버와 2)똑같은 이미지(마치 스넵샷과 같다.)를 생성한다. 이 후 시작 템플릿(이미지 + 서버용량 등 AWS의 환경설정까지 포함)을 생성한다. 이 후 디폴트 값을 설정한 후 대상 그룹을 생성하고 ALB(Application Load Balancer)를 생성한 후, Auto Scaling 그룹을 생성하여 ALB을 통하여 디폴드값과 시작템플릿까지 연결한다.

 

이 그림은 Load Balancing에 대해 눈에 보기 쉽도록 도식화 한 것이다.(이 도식에서 뭔가 익숙함이 느껴진다면 네트워크를 잘 아는 사람일 것이다. enable configure terminal..어쩌고 저쩌고...)

 

기본적으로 Load Balancer는 수많은 트레픽들을 감당하기 위해서 여러대의 서버로 트레픽을 분산시켜주는 개념이라고 할 수 있다. 종류는 크게 2가지로 L4 Load Balancing(Classic Load Balancer)과 L7 Load Balancing(ALB)있다

 

OSI7에 관한건 여기를 클릭해 읽어보자.

 

L4 Load Balancing 로드벨런서로 트레픽을 보낼때 트레픽 자체의 형태(data, IP address, port 등)에서 IP address와 port만 확인하고 이 트레픽을 다른 서버로 옮겨준다. 별 다른 데이터 검증 등이 없기에 빠르고 싸며, 방향만 바꿔주기에 매우 단순하다. 이런 장점이 자잘한것 하나하나 분산을 시키게 된다면 Microservice와 같은 서비스에서는 조금 사용하기가 애매하다고 할 수 있다.

 

L7 Load Balancing은 데이터를 하나하나 다 확인해 본 후 A라는 데이터는 A에, B라는 데이터는 B로 보내는 의사결정을 할 수 있다. L4의 장점이 L7의 단점이 되고, L7의 장점이 L4의 단점이 된다.