[AWS] 로드밸런싱 알아보기
비전공자도 이해할 수 있는 로드밸런싱
저는 주로 안드로이드와 IOS앱을 개발하기때문에 주변에 클라이언트 개발자분들이 많습니다. 저를 포함해서 클라이언트 위주로만 하다보면 서버쪽 이해에 어려움을 간간히 느끼게되는것같습니다. 다른분들은 조금 더 이해가 쉬었으면 하여 최대한 그림위주로 블로깅을 해보았습니다.
로드밸런싱이 필요한 이유
로드밸런싱을 쓰지 않는다면 우리는 각 EC2 인스턴스에 고정된 아이피를 부여해야합니다. 문제는 하나의 인스턴스에 하나의 도메인만 연결할 수 밖에 없는데 버에서 많은 사람들이 몰린다면 서버의 사양을 올리는 스케일업 서버의 개수를 늘리는 스케일아웃을 고려해야합니다. 스케일업 경우 인스턴스를 업데이트하는동안 서비스를 할 수 없습니다. 스케일아웃을 한다면 서버가 늘어날때마다 도메인이 새로 필요합니다.
로드밸런싱은 위 그림처럼 한곳의 엔드포인트로 들어오는 트래픽을 각 인스턴스에 분산시켜줍니다. 이러한 로드밸런싱은 크게 클래식 로드밸런서와 어플리케이션 로드밸런서 두가지로 나눌 수 있습니다.
로드밸런서의 종류
로드밸런서는 레이어4계층에서 작동하는 클래식 로드밸런서와 레이어7계층에서 작동하는 애플리케이션 로드 밸런서가 있습니다. 조금 쉽게 풀어 이야기하면 레이어 4계층은 라우터 스위치등 물리적인 하드웨어 영역이기때문에 데이터를 변경/수정 할 수 없고 레이어 7계층은 애플리케이션 계층이기때문에 포트나 헤더등이 수정 가능하다정도만 이해해도 충분합니다.
클래식 로드 밸런서(ELB)
먼저 타겟그룹이란 EC2 인스턴스를 오토스케일링 할 수 있는 단위로 사용됩니다. 클래식 로드밸런서의 단점은 서버의 기본주소가 바뀌면 로드밸런서를 새로 생성해야하며 하나의 주소에 하나의 대상그룹으로 보내게됩니다. 또한 레이어 4계층에서 작동하기때문에 데이터를 수정, 변경할 수 없기때문에 포트나 헤더를 변경할 수 없습니다.
이러한 구조의 문제점은 서버의 구성이 비대해지고 마이크로 아키텍쳐를 구성하기 어렵습니다. 또한 회원모듈을 처리하는 인스턴스와 쇼핑모듈을 인스턴스가 따로 존재한다면 2개의 로드밸런서가 필요하고 비용도 2배로 들어가게됩니다.
애플리케이션 로드 밸런서(ALB)
반면 ALB는 패스나 포트등에 따라 다른 대상그룹으로 맵핑할 수 있습니다. 특히 포트단위로 연결해줄 수 있는것은 도커컨테이너 환경에서 아주 유용하게 작동할 수 있고 하나의 대상그룹에 더 많은 컨테이너를 넣어 비용을 최적화할 수 있습니다. 뿐만 아니라 대상을 EC2 인스턴스, 람다, IP로도 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메세지를 작성할 수 있기때문에 마이크로아키텍쳐를 구성하기에 좋습니다.
로드밸런싱 용어설명
상태확인
로드밸런서에는 상태확인을 할 수 있습니다. 상태확인은 대상그룹에 원하는 경로와 포트를 설정하여 정상적으로 원하는 HTTP 응답이 오는지 확인하게해줍니다. 만약 정상적으로 응답이 오지 않는 인스턴스가 있다면 비정상상태의 인스턴스를 제외한 다른 인스턴스로만 트래픽을 분산합니다.
대상그룹
대상그룹 혹은 타겟그룹은 일반적으로 오토스케일링을 위한 단위입니다. 각각의 대상그룹에 있는 인스턴스들은 정의된 상태검사를 수행합니다.
ALB를 위한 용어설명
이전 클래식 로드밸런서는 단순한 형태이기때문에 요청을 어느 대상그룹으로 보낼지정도만 알면 되지만 애플리케이션 로드밸런서는 다소 복잡합니다. 각각의 포트에따라 다르게 구성할 수 있으며 동일한 포트라도 패스등에 따라 다르게 분기할 수 있습니다. ALB에 추가되는 용어에 대해 알아보겠습니다.
리스너와 룰
ALB에는 리스너를 포트와 프로토콜별로 분기처리할 수 있습니다. 하단에 있는 룰은 패스별 혹은 AWS_ARN별로 다른 분기를 처리할 수 있습니다.
마치며
용어로만 배우면 항상 어려운게 많아 최대한 이미지를 많이 활용하였습니다. 조금이라도 이해에 도움이 되었으면 좋겠습니다. 로드밸런서는 VPC 설정이 필수적이므로 헷갈린신다면 이전에 작성한 VPC글과 함께 보시면 더 좋습니다.
