요즘 솔루션SI회사에서 일하면서 공부를 병행하고있다. 아무래도 금융관련 프로젝트밖에 없으니까 신기술보다는 좀더 lowLevel의 기술이 많이 눈에 들어오는편이다(실무에 적용하거나 관련이 있는공부를 많이하기때문) 요새 주로공부하는게 서버(하드웨어포함) / 네트워크 위주로 공부하다 보면서 검색하던 와중에 로드벨런서의 세션처리 관련하여 좋은 글을 가져와본다.
출처 : 네이버 D2
-----------------------------------------------------------------------------------
대용량 서비스를 운영하려면 부하 분산은 필수입니다. 대용량 트래픽을 장애 없이 처리하려면 여러 대의 서버에 적절히 트래픽을 분배해야 합니다. 기존에는 세션 서버를 위한 로드밸런서로 DNS와 L4를 이용했으나 여러 가지 제약이 있어 네이버의 요구 사항을 충족하는 로드밸런서를 직접 개발하게 되었습니다.
이 글에서는 로드밸런서 개발 동기와 아키텍처를 살펴보겠습니다.
기존 로드밸런서의 제약 사항
DNS(Domain Name System)
DNS는 도메인 이름을 IP 주소로 변환하는 기술이다. 하나의 도메인 이름을 라운드로빈(Round Robin) 방식으로 여러 개의 IP 주소로 변환한다면 이것만으로도 쉽게 부하 분산이 가능하다.
그러나 여기에는 두 가지 단점이 있다.
첫째, 대부분의 클라이언트에서는 DNS 서버의 부하를 줄이고 성능을 향상하기 위해 일정 시간 동안 캐싱하기 때문에 부하 분산이 균등하게 되지 않는다.
둘째, 특정 서버에 장애가 발생하더라도 장애 여부가 감지되지 않아 서비스에서 해당 서버를 제거할 수 없다. 이것을 보완하기 위해 health check로 장애를 감지하여 DNS 서버에서 제거할 수 있지만, 모든 DNS 서버에 적용되는 데에 상당히 시간이 소요될 뿐만 아니라 클라이언트의 캐싱 때문에 서비스에서 바로 제거되지는 않는다.
L4
L4는 IP 주소와 포트를 기반으로 로드밸런싱하는 고가의 하드웨어로, 웬만한 서비스에서는 이것만으로도 부하 분산을 처리하기에 충분하다.
여기에서 주의해야 할 점은 L4는 VIP(virtual IP) 단위로만 로드밸런싱하기 때문에 반드시 하나의 VIP에 연결된 서버의 수가 비슷해야 한다는 것이다. 만일 서버 중 몇 대에 문제가 생긴다면 동일한 VIP에 연결된 다른 서버 역시 연달아 부하가 발생하여 더욱 심각한 문제가 발생할 수 있다.
또한 L4의 스펙상 최대 세션 수는 존재하나 세션을 맺는 시나리오에 따라 최대 성능이 다르기 때문에 최대 세션 용량에 도달하지 않았음에도 추가로 세션을 연결할 수 없는 문제가 발생하기도 한다.
마지막으로 통신사 장애 등으로 세션이 비정상적으로 종료된 경우 세션 서버에서는 클라이언트와 세션이 종료되고 정상적으로 다시 연결되었지만, L4에서는 세션 종료처리가 제대로 되지 않아 두 개의 세션을 동시에 유지하고 있어 L4의 한계 용량을 초과한 적도 있다.
개발 요구 사항
그동안의 경험을 통해 장애 대응에 필요한 기능과 운영 중 개선이 필요하다고 느꼈던 사항을 정리하면 다음과 같다.
클라이언트 접속 제한
세션 서버에 장애가 발생하면, 클라이언트는 로드밸런서에 접속할 때 새로 정의된 프로토콜을 이용한다. 새로 정의된 프로토콜은 세션 서버와 통신을 제한하여 장애 대응 시간을 줄일 수 있다.
세션 서버가 비정상적인 상황에서 클라이언트가 지속적으로 접속을 시도한다면 통신사의 네트워크 용량을 초과하여 심각한 문제를 일으킬 수 있다. 기존에는 응답 시간을 최소화하기 위해서 세션 서버와 세션을 항상 유지하려고 최대한 노력했으나 망 부하라는 부작용이 발생했다. 그래서 현재는 로드밸런서와 통신이 되지 않으면 클라이언트 자체적으로 재접속 타이머가 동작하여 망 부하를 최소화하고 있다.
L4 증설 시점 예측
최대 세션 수를 예측할 수 있으며, 앞으로 사용자가 늘어날 것에 대비하여 사전에 세션 서버를 증설할 수 있어야 한다. L4는 일반적으로 세션 유지가 필요하지 않은 웹 서버나 세션 수가 적은 서버의 트래픽 분산에 주로 사용한다. 앞에서 설명한 것처럼 L4의 스펙상 최대 세션 수는 존재하지만, 세션을 맺는 시나리오에 따라 최대 성능이 다르기 때문에 정확한 성능을 알려면 직접 테스트해야 한다. 그러나 수천만 세션을 직접 테스트하기란 현실적으로 불가능하다. 그래서 실제로 문제가 발생하고 나서야 L4 최대 용량이 얼마인지 정확히 파악할 수 있다. 이런 이유로 서비스의 최대 세션 수를 예측할 수 있고 장애 발생 시 아는 범위 내에서 대처할 수 있는 로드밸런서를 개발하고 싶었다.
서버 단위 로드밸런스
특정 서버에 부하가 몰리는 것을 막기 위해서는 VIP 단위가 아닌 세션 서버 단위의 로드밸런싱 기능이 필요하다. 그러나 운영을 하다 보면 VIP당 서버 수를 항상 동일하게 유지하는 것이 쉽지 않다. 그래서 서버 단위로 로드밸런싱을 하려고 한다.
다양한 로드밸런싱 알고리즘
상황에 따라 적절한 로드밸런싱 알고리즘을 사용한다. 가장 간단한 방법으로는 가용한 모든 서버에 라운드로빈으로 로드밸런싱하는 것이다. 이런 경우 서버 재시작 등으로 인하여 세션 수의 불균형이 발생하면 다시 고르게 분배되는 데 상당한 시간이 소요된다. 그러나 Weight Least Connection 등의 알고리즘을 사용하여 세션 수가 적은 서버에 가중치를 두어 트래픽을 분산한다면 세션 수의 불균형이 발생하더라도 금방 고르게 세션이 분산되므로 세션 서버의 배포 등의 작업을 쉽게 할 수 있다.
그렇다고 해서 무조건 그 서버에 트래픽을 몰아주면 해당 서버의 순간 TPS(transaction per second)가 높아 그대로 장애로 직결될 수 있음을 기억해야 한다.
세션 서버 배포 시간 단축
불필요한 세션 서버를 서비스에서 빠르게 제거할 수 있어야 한다. DNS에서 VIP를 삭제하여도 클라이언트에서 VIP 주소를 캐싱하고 있다면 몇 달이 지나도록 서버에 트래픽이 계속해서 유입될 수 있다. 따라서 서비스에서 제거하려고 DNS에서 세션 서버를 제거해도 세션 서버의 세션이 모두 끊어지기 전까지는 서비스에서 제거할 수 없다. 이런 DNS를 사용하지 않고 직접 개발한 로드밸런서를 통해 세션 서버의 주소를 요청한다면 이 문제는 해결할 수 있다.
전체적인 구조도
로드밸런서를 구성하는 모듈의 역할은 다음과 같다. 다양한 분산 알고리즘을 가진 조회 서버(lookup server)와 세션 서버를 관리하는 서버 매니저(server manager)로 나눌 수 있다. 그리고 세션 서버의 목록을 저장하기 위해 ZooKeeper를 사용했고, 세션 수 등을 비롯한 세션 서버 정보를 저장하기 위해 다양한 컬렉션을 제공하는 Redis를 사용했다. 그리고 단말과 1:1 세션을 맺고 있는 세션 서버가 있다.
각 모듈의 기능에 대해 좀 더 알아보면 다음과 같다.
그림 1 서버 구조도
클라이언트
클라이언트는 세션 서버 주소를 얻기 위해 조회 서버에 접속하여, 접속 가능한 세션 서버의 주소를 가져온다. 세션 서버의 주소를 정상적으로 수신하면 해당 세션 서버로 연결을 요청한다. 이 때 발생할 수 있는 상황은 크게 세 가지가 있다.
첫째, 모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 재접속을 시도한다.
둘째, 단말의 네트워크가 비정상이거나 통신사의 장애로 네트워크가 정상적으로 동작하지 않아 조회 서버와 통신하는 것조차 불가능하다면 클라이언트는 자체적으로 타이머를 두어 네트워크 부하를 최소화한다. 이런 경우 응답 시간 최소화보다는 네트워크 망 부하 최소화를 위해서 모든 클라이언트들의 타이머 값이 서로 다르도록 백오프 알고리즘을 통해 타이머 값을 설정한다.
백오프 알고리즘은 GCM(Google Cloud Messaging for Android)에서 사용되고 있는 알고리즘을 참고했다. 기준이 되는 백오프 타임이 있고 이는 최대 백오프 타임(MAX_BACKOFF_MS)을 초과하기 전까지는 두 배씩 증가한다. 실제 클라이언트에서 조회 서버에 접속하기 위해 재시도할 때마다 적용되는 백오프 타임은 기준이 되는 백오프 타임에 일정 수식을 사용하여 구한다.
Random sRandom = new Random();
int backoffTimeMs = getBackoff();
int nextAttempt = backoffTimeMs / 2 + sRandom.nextInt(backoffTimeMs);
setAlarmManager(nextAttempt); // 실제 적용된 백오프 타임
if (backoffTimeMs < MAX_BACKOFF_MS) {
setBackoff(backoffTimeMs * 2); // 다음 백오프 타임을 구하기 위한 currentBackoffTime set
}
셋째, 정상적으로 세션 서버의 주소를 수신하여 세션 서버에 접속을 시도하더라도 접속이 원활하지 않을 수 있다. 이런 경우 일정 횟수 이상 재접속을 시도해도 세션 서버와 접속이 되지 않으면 해당 세션 서버에 장애가 발생했다고 판단한다.
이런 비정상적인 경우 처음부터 로직을 다시 수행해야 하므로 비용이 많이 든다. 이런 비용을 줄이기 위해서 조회 서버로부터 두 개의 세션 서버 주소를 받고 첫 번째 세션 서버에 접속되지 않는다면 두 번째 세션 서버 주소(Alternative IP)에 접속을 시도하여 비용을 최소화한다.
세션 서버
세션 서버에 추가된 기능은 주기적으로 세션 수를 서버 매니저에게 알려주는 기능과 서버 매니저의 L7 health check 요청에 응답하는 기능이다.
서버 매니저로부터 주기적으로 유입되는 health check 요청을 적절히 처리하여 세션 서버의 정상 동작 여부를 알려준다. 서버 매니저는 일정 시간 동안 health check에 실패하면 해당 세션 서버를 서버 목록에서 제거하기 때문에 자신의 상태를 정확히 전달해야 한다. 응답할 때 자신의 현재 세션 수를 서버 매니저에게 알려준다.
조회 서버
DNS 역할을 하는 Lookup 프로토콜 제공
클라이언트가 요청할 때 어떤 세션 서버에 접속해야 하는지 알려 주는 기능을 제공하며, 세션 서버의 배포 등으로 인하여 서버 목록이 변경된 경우 서버 매니저로부터 새로운 서버 목록을 수신하여 업데이트한다.
분배 알고리즘 변경
서버 매니저를 통해서 운영 중에 부하 분산 알고리즘을 변경할 수 있으며, 라운드로빈이나 세션 수를 고려한 Weight Least Connection 등 다양한 부하 분산 알고리즘을 사용할 수 있다. 현재 기본으로 사용하고 있는 Weight Least Connection 알고리즘은 세션 서버의 세션 수를 고려하여 세션 수가 적은 서버에 부하 분산 시 우선순위를 준다.
복수 지역(multi region) 지원
클라이언트가 보낸 MCC(mobile country code, 모바일 국가 코드)를 기반으로 지역을 선택하여 어떤 세션 서버에 접속해야 하는지 알려 준다. MCC와 지역 매핑 정보는 서버 매니저를 통해서 운영 중 동적으로 변경할 수 있다.
높은 TPS
서비스별로 수천만 명의 사용자가 Lookup 프로토콜을 요청하기 때문에 기존 L4만큼의 높은 처리량이 요구된다. Java 비동기-네트워크 프레임워크인 Netty를 이용하여 구현했으며, Lookup 인스턴스당 약 20,000TPS 이상의 트래픽을 처리할 수 있다.
암호화
클라이언트와 주고받는 모든 패킷은 암호화해서 보안을 강화했다.
서버 매니저
복수 서비스, 복수 지역 지원
한 세트의 서버 매니저는 여러 개의 서비스를, 그리고 각 서비스는 여러 지역을 지원한다. 예를 들면 LINE이라는 서비스와 그 아래의 Korea, China 등 다양한 지역을 지원한다. 지역별로 다른 세션 서버 그룹을 구성한 경우도 지원하고, 굳이 지역을 구분할 필요 없는 서비스는 Common으로 정의된 공통 세션 서버 그룹으로 처리한다.
만약 특정 지역의 모든 서버에 장애가 발생하면 다른 지역의 서버 그룹에서 해당 지역을 처리할 수 있도록 지역 페일오버(failover)도 가능하다.
서비스별 알고리즘 적용 가능
서비스별로 다른 분배 알고리즘을 적용할 수 있다. ZooKeeper는 서비스별로 분배 알고리즘을 관리한다. 알고리즘이 변경되면 조회 서버로 변경된 알고리즘을 전달한다.
세션 서버 정보 관리
서버 매니저(master)에서 주기적으로 세션 서버에 세션 수를 요청한다. 응답받은 세션 수를 Redis에 저장하고, 서버 매니저(slave)들은 Redis를 주기적으로 가져가 데이터를 동기화한다. 모든 서버 매니저는 세션 서버 정보를 가지고 있으며, 조회 서버가 서버 정보를 요청하면 자신의 데이터를 기반으로 서버 정보를 전달한다.
주기적인 health check
서버 매니저(master)는 운영 중인 모든 세션 서버에 주기적으로 health check 요청을 보낸다. 일정 횟수 이상 health check에 실패하면 ZooKeeper에 저장된 해당 서버의 상태를 suspended로 변경하고, 조회 서버에게 해당 서버를 서비스에서 제거하라고 알린다.
ZooKeeper에 저장하는 세션 서버의 상태는 다음과 같다.
그림 2 세션 서버 상태도
- shutdown: 세션 서버의 인스턴스가 종료된 상태 또는 정상적으로 서비스할 수 없는 상태
- starting: 세션 서버를 시작하고 있는 상태
- standby: 세션 서버가 정상적인 상태이나 아직 서비스에 투입 전이라 클라이언트의 접속이 없는 상태
- running: 세션 서버가 정상적이고 서비스에 투입하여 정상적으로 운영 중인 상태
- suspending: 세션 서버가 오동작하여 서비스에서 제거하고 있는 상태
- suspended: 세션 서버가 오동작하여 잠시 서비스에 투입하지 않은 상태
- resuming: 세션 서버가 정상적이어서 다시 서비스에 투입하고 있는 상태
- shuttingdown: 세션 서버가 종료하고 있는 상태
위의 여러 가지 상태 중 조회 서버에게 세션 서버가 서비스 중이라고 알려 주는 상태는 running 상태이고, 그 외의 상태는 모두 서비스에 아직 투입 전이라고 알려 준다. 현재 모든 상태가 구현되지는 않았다. 운영에 무리가 없는 상태까지 구현해서 오픈하고, 추후 확장 가능성을 열어 놓은 상태이다.
HA 구성
서버 매니저는 최소 두 대 이상(한 대의 master와 한 대 이상의 slave)으로 구성된다. master의 역할은 세션 서버의 health check와 ZooKeeper에 세션 서버의 상태 업데이트이다. 그리고 지역이나 세션 서버의 목록이 변경되면 조회 서버에게 알려 주는 역할을 한다.
slave의 역할은 ZooKeeper와 Redis의 데이터를 지속적으로 동기화하여, 조회 서버의 지속적인 요청에 응답하는 것이다.
장애 대응 시나리오
로드밸런서를 개발하게 된 가장 큰 동기는 장애에 유연하게 대응하는 로드밸런서의 필요성이었다. 통신사에 일시적으로 장애가 발생하여 수천만 사용자의 세션이 끊어지면 장애 시간 동안 단말이 지속적으로 재접속을 요청하여 트래픽이 평소 대비 100배 이상 급증하고 그로 인해 망 용량 초과가 발생한다. 그리고 장애에서 복구 완료 후에는 단말이 일시적으로 접속을 요청하여 서버 용량 초과가 발생한다. 이와 같은 장애가 발생했을 때 이를 처리할 수 있는 로드밸런서 개발이 목표였다.
구조를 설계할 때 일부 모듈의 장애가 전체 장애로 이어지지 않게 하기 위해 최대한 노력했고, 통신사 장애 및 IDC 등의 장애가 발생해도 망 부하를 최소화하고 더 쉽게 장애에 대응할 수 있게 설계했다. 각 모듈에 장애가 발생했을 때 어떻게 처리하는지 알아보자.
그림 3 장애 대응 시나리오
1. 세션 서버 장애 시
세션 서버의 장애는 주기적으로 health check를 하는 서버 매니저가 가장 먼저 감지한다. health check에 실패하면 서버 매니저는 변경된 세션 서버 목록을 조회 서버에 다시 전달한다. 조회 서버는 새로 받은 서버 목록으로 로드밸런싱한다.
클라이언트는 연결되어 있던 세션 서버와의 세션이 끊어지면 두 번째 세션 서버(alternative IP)에 접속을 요청한다. 두 번째 세션 서버도 접속되지 않으면 조회 서버에 새로운 세션 서버의 주소를 요청한다.
모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 하나도 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 조회 서버에 재접속을 시도한다.
2. 조회 서버 장애 시
조회 서버 중 일부에 장애가 발생해도 총 조회 서버의 서버 용량이 초과하지 않는 한 정상으로 동작한다.
조회 서버 전체에 장애가 발생하면 클라이언트는 백오프 타임 후에 재접속을 시도한다. 실제로 약 100만 개의 실제 세션으로 테스트를 진행해 보았는데, 조회 서버가 평소에 요청받는 만큼의 세션이 세션 서버에서 감소하고, 조회 서버 복구 직후에는 클라이언트가 백오프 주기에 따라 동작하며 일시적으로 요청량이 증가한다. 테스트 결과 10분 정도의 전체 장애가 발생했을 때 20분 이내에 모든 세션이 복구 완료된다.
3. 서버 매니저 장애 시
서버 매니저(master)에 장애가 발생하면 slave 중 하나가 master로 전환된다. 서버 매니저(master)가 ZooKeeper에 특정 znode를 ephemeral node로 생성하고, slave는 그 znode를 지속적으로 모니터링한다. 해당 znode가 사라지면 서버 매니저(master)가 비정상이라고 판단하여, slave 중 하나가 master로 전환하는 형태로 구현했다.
서버 매니저 전체에 장애가 발생하면 조회 서버는 실시간 세션 서버의 세션 수를 알 수가 없다. 이런 경우 조회 서버는 일시적으로 분배 알고리즘을 라운드로빈으로 동작한다. 서버 매니저 장애가 해결되면 다시 Weight Least Connection으로 동작한다.
마치며
지금까지 DNS와 L4라는 부하 분산 기술을 소개하고, 세션 서버를 위한 로드밸런서를 개발하게 된 배경, 전체적인 구성도, 그리고 모듈별 기능과 장애 시 대응 시나리오를 소개했다. 어느 정도 성능이 필요한 데이터 저장소는 지난 2년 동안 운영하며 장애를 일으키지 않은 Redis를, 서버 정보 관리 등의 분산 데이터 동기화가 필요한 부분에는 ZooKeeper를 사용하고, 단말의 높은 트래픽을 처리하기 위해서는 Netty를 사용했다. 추후 개발이나 아키텍처 구성 시 이러한 기술이 도움이 되길 바란다.
