로드밸런서

다수의 클라이언트가 서버에 접속하게 되면 과부하가 오게 된다. 과부하로 인해 서버가 원활한 서비스를 제공하지 못하는 경우를 해결하기 위해 크게 서버의 하드웨어를 업그레이드하는 방법과 서버의 갯수를 늘리는 방법, 두가지 선택을 할 수 있다.

1. Scale-Up

Scale-Up은 물리적으로 서버의 사양을 높이는 하드웨어적인 방법이다. 서버의 수를 늘리지 않고 프로그램 구현에 있어 변화가 필요 없다는 장점이 있다. 하지만 서버의 사양을 높이는데엔 굉장히 높은 비용이 들고, 하드웨어의 업그레이드엔 한계있다는 큰 단점이 있다. 또한 사양을 늘린만큼 클라이언트의 요청이 더욱 많아진다면, 서버에 발생하는 부하는 여전히 해결하지 못한 상황이 된다.

2. Scale-Out

Scale-Out은 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법이다. 많은 요청이 오더라도 여러대의 서버가 나눠서 처리를 하기 때문에 서버의 사양을 높이지 않고도 비교적 저렴한 방법으로 부하를 처리할 수 있다.

Scale-Out 방법인 여러대의 서버로 부하를 처리하는 경우, 클라이언트로부터 온 요청을 여러 서버 중 어느 서버에 보내서 처리해야할지 요청을 여러 서버에 나눠 처리할 수 있도록 교통정리를 해줄 역할이 필요하다. 이 역할을 하는게 바로 로드 밸런서이고, 여러 서버에 교통정리를 해주는 기술 혹은 프로그램을 로드 밸런싱이라고 부른다.

로드 밸런서의 종류

• L2 : 데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱 한다.

• L3 : 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱 한다.

• L4 : 전송 계층에서 IP 주소와 Port를 바탕으로 로드 밸런싱 한다.

• L7 : 응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱 한다. (예시 : 엔드포인트)

오토스케일링

AWS 오토스케일링 기반으로 작성됨

서버의 부하가 심해져 제대로 된 서비스를 제공하지 못하는 순간이 오지 않도록, 계속 지켜보다 부하가 일정 수치를 넘기면 서버를 증설한 뒤 연결시키는 방법이 있지만 쉽지 않다. 개발자가 직접 라이브로 지켜보며 수동으로 서버를 증설해야 한다면 너무나 번거롭고 갑작스럽게 발생한 문제에 대처하기도 한계가 있다.

오토스케일링은 Scale-Out 방식으로 서버를 증설할 때 자동으로 서버(리소스)를 관리해주는 기능이다. 클라이언트의 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가하고 반대로 처리 요구량이 줄어들면 리소스를 감소시켜 적절한 분산 환경을 만들어준다.

장점

• 동적 스케일링
  Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다는 점이다. 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업 할 수 있다.

• 로드 밸런싱
  Auto Scaling은 리소스를 동적으로 스케일업 혹은 스케일다운 한다. 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있어 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리 할 수 있다.

• 타겟 트래킹
  사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다.

• 헬스 체크와 서버 플릿 관리
  Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체 한다.

다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합을 AWS는 서버 플릿(Fleet)이라고 한다. Auto Scaling은 적정 수준의 서버 플릿 용량을 유지하는 데도 도움을 준다. 예를 들어, 어떤 기업의 애플리케이션이 6대의 EC2 서버에서 실행 중일 때 6대 서버에 대한 헬스 체크 상태를 모니터링 하다가 특정 서버에 문제가 생기면 즉시 대응 조치를 할 수 있다. 한 대 또는 그 이상의 서버가 다운 되면 Auto Scaling은 6대의 서버 인스턴스 처리 용량을 유지하기 위해 부족한 만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지한다.

활용

Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스다. EC2 Auto Scaling은 오직 EC2 서버라는 리소스만 대상으로 한다.

시작 템플릿(Launch Configuration)

Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야 한다. 이는 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있다. 만약 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있다. 시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷한다. 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성한다.

Auto Scaling 그룹 생성

Auto Scaling 그룹은 스케일 업 및 스케일 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있다. 따라서 Auto Scaling 그룹을 생성하기 위해서는 스케일링 정책 및 유형에 대해서 잘 숙지하고 있어야 한다.

Scaling 유형

• 인스턴스 레벨 유지
  기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정할 수 있다.

• 수동 스케일링
  기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제 해야 한다. 해당 방식은 추천하지 않는 방식이다.

• 일정별 스케일링
  예측 스케일링 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋다. 예를 들어 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가하면 된다.

• 동적 스케일링
  수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의한다. 이 방식은 CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정한다. 예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식이다. 이와 같은 스케일링 정책을 정의 할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 한다.