ELB를 이용한 분산 서비스 구성

Contents

웹 서비스를 만들려고 한다. Nginx와 PHP기반이며, Mysql 데이터베이스를 사용할 계획이다. 상당히 많은 유저의 접근이 예상되는데, 특히 주말에는 평일보다 2배 이상의 요청이 몰릴 것으로 예상 된다.

이상 아래의 요구 사항들을 만족해야 한다.

1. 유저의 요청을 분산할 수 있어야 한다.
2. 높은 수준의 가용성이 필요하다. LB를 구성하면, 인스턴스 하나에 문제가 생기더라도 다른 인스턴스를 이용해서 서비스가 가능하다. 따라서 기본적인 가용성을 가진다고 할 수 있다. 하지만 내가 원하는 건 더 높은 수준의 가용성이다. 즉 어느 한 네트워크 구간에 문제가 생기더라도 서비스에 문제가 없어야 한다.
3. 유저 요구에 따라서 탄력적으로 컴퓨팅 자원을 할당할 수 있어야 한다. Scale-in, scale-out이 자유로워야 한다.
4. AWS를 기반으로 한다.

유저요청을 분산처리하는 일반적인 방법은 L4 스위치를 붙이는 거다. TCP패킷을 제어하는 것으로 유저의 요청을 분산할 수 있다. 물론 나는 스위치를 붙이진 않을 거다.

대신 AWS에서 제공하는 ELB를 이용해서 요청을 분산하기로 했다. ELB는 소프트웨어 기반의 로드 밸런싱 서비스로 트래픽을 분산하고 가용성을 높이기 위해서 사용하는 서비스다.

1. 가용성 : L4 스위치를 이용해서 부하를 분산한다고 가정해보자. HA 시스템을 구성하려면 2대의 L4 스위치를 이용해서 구성해야 한다. 구성도 복잡할 뿐더러 상당한 관리 비용이 추가 된다. ELB를 이용하면, 관리에 드는 노력을 AWS에 맡길 수 있다.
2. 확장성 : 트래픽이 늘어날 경우 자동으로 대역폭을 확보할 수 있어야 한다. 이 과정 역시 자동으로 이루어진다. 유저는 사용한 만큼만 비용을 지불하면 된다.

AWS에서 제공하는 RDS를 이용해서 구성한다. ELB를 이용해서 유저의 요청을 탄력적으로 처리하도록 구성했기 때문에, 데이터베이스 역시 요청이 증가함에 따라 탄력적으로 대응할 수 있어야 한다.

RDS의 read only replica를 이용해서 늘어나는 유저의 요청에 대응하도록 한다. Read only replica는 읽는 작업을 분산해서 처리하는 용도로 사용할 수 있다. 쓰기 작업에 대해서는 분산을 할 수가 없다. 하지만 대부분의 웹 서비스가 "읽는 작업"이 많다는 것을 감안하면 큰 문제는 아니라고 할 수 있다.

가용성은 Multi-AZ로 확보한다. AWS Management Console에서 DB 인스턴스를 시작할 때 Multi-AZ Deployment를 선택할 수 있다. Multi-AZ를 선택하면 "다중 AZ(Availability Zone) 동기 / 복제" 구성을 할 수 있다. RDS는 DB 인스턴스에 대해서 하나의 복제본을 다른 AZ에 프로비저닝을 한다. 만약 현재 가동중인 인스턴스에 문제가 생기면, 복제된 인스턴스가 자동으로 서비스를 개시한다. 이러한 모든 과정이 자동으로 이루어진다.

지금까지의 내용을 정리하면, 대략 아래와 같은 그림으로 정리할 수 있다.

• 3개의 웹서버로 요청을 처리한다.
• ELB를 이용해서 웹서버의 요청을 분산했다.
• Mysql은 read only replica를 만들어서 읽기 요청을 분산하도록 했다.

웹 서버는 인터넷에 직접 연결되지 않으므로 EIP를 가질 필요가 없다. 이 구성에서 인터넷 접점은 ELB이므로, ELB에 IP를 할당해야 할 것이다.

그러나 ELB에는 EIP를 할당할 수 없다. 대신 도메인 이름이 할당되는데, 이 도메인이름을 CNAME에 등록하는 것으로 ELB 서비스를 사용할 수 있다. CNAME 설정관련 내용은 using domain names with elb문서를 참고하자.

특별히 노가다를 좋아하는 체질이거나 한번쯤 ELB 같은 시스템을 만들어보고 싶다 하면 만들어보자. Haproxy를 이용한 ELB 문서를 참고한다.

이 구성은 적당한 수준의 확장성과 적당한 수준의 가용성을 보장한다. 아래의 몇 가지 방법을 이용하면 좀 더 견고한 구성을 할 수 있다. 여기에서는 개선사항을 개략적으로 설명한다. 이들 개선사항을 반영한 구조는 따로 문서를 만들 계획이다.

유저 요청의 증가와 감소에 따라서 웹서버를 자동으로 추가하거나 삭제할 수 있다면 효율적인 운용이 가능할 것이다. Auto scaling을 이용하면 EC2 인스턴스의 상태에 따라서 자동으로 추가 및 삭제가 가능하다. 예를 들자면 EC2 인스턴스의 지연시간을 지속적으로 모니터링 하다가 일정 기준을 초과하면, 인스턴스를 추가 하도록 규칙을 정할 수 있다.

이런 규칙을 정하려면 "모니터링 솔류션"이 필요하다. Cloudwatch를 이용하거나 혹은 Zabbix등으로 직접 구축해서 사용할 수 있다. Zabbix로 직접 구축할 경우, 인스턴스의 CPU, 메모리, 응답지연등을 모니터링 하다가 임계치를 초과하면 AWS API를 이용해서 인스턴스를 만들면 된다.

AWS의 region은 보통 두 개 이상의 zone으로 구성이 된다. 이들 zone은 물리적으로 독립된 환경을 가지고 있다. 예를 들어 zone-a와 zone-b루 구성된 aws region이 있다고 가정해보자. 어떤 이유로 zone-a에 문제가 생기더라도 zone-b는 영향을 받지 않고 작동을 할 수 있다. (지진같은 국가 규모의 재앙이라면 region 자체가 사용 불능이 될 수 있긴 하겠다.)

Zone이 물리적으로 분리되지만 논리적으로(네트워크로) 연동된다. 그러므로 웹서버를 zone에 분산해서 배치한 후 ELB로 묶어서 서비스하는게 가능하다. 이처럼 zone은 논리적으로 연결돼서 가용성을 높일 수 있는 구조를 가지기 때문에 Availability zone(가용성 zone) 이라고 부른다. 이렇게 구성하면, 한쪽 zone에 문제가 생겨도 서비스를 가용상태로 유지할 수 있다.