기존 로드밸런서의 제약 사항

DNS (Domain Name System)

DNS 는 도메인 이름을 IP로 변환하는 기술이다. 하나의 도메인 이름을 라운드 로빈 방식으로 여러 개의 IP 주소로 변환하여 쉽게 부하를 분산시킬 수 있다.

그러나 여기에는 두 가지 단점이 있다.

1. 대부분의 클라이언트에서는 DNS 서버의 부하를 줄이고 성능을 향상하기 위해 일정 시간 동안 캐싱하기 때문에 부하 분산이 균등하게 되지 않는다.

2. 특정 서버에 장애가 발생하더라도 장애 여부가 감지되지 않아 서비스에서 해당 서버를 제거할 수 없다.

: 이것을 보완하기 위해 `health check`로 장애를 감지하여 DNS 서버에서 제거할 수 있지만, 모든 DNS 서버에 적용되는 데에 상당히 시간이 소요될 뿐만 아니라 클라이언트의 캐싱 때문에 서비스에서 바로 제거되지는 않는다.

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 세션을 맺고 있는 세션 서버가 있다.

서버 구조도

클라이언트

클라이언트는 세션 서버 주소를 얻기 위해 조회 서버에 접속하여, 접속 가능한 세션 서버의 주소를 가져온다. 세션 서버의 주소를 정상적으로 수신하면 해당 세션 서버로 연결을 요청한다.
이때, 클라이언트가 매번 조회 서버에 질의하는 것은 아니다. 클라이언트 서비스가 종료되지 않았다면, 조회서버 질의 없이 최근에 접속했던 세션 서버로 곧바로 접속할 수 있다.

클라이언트 입장에서 보면 네트워크 비용이 증가한 건 사실이지만 지연은 무시할 정도로 미미하다.

그 정도의 비용을 치루더라도 서버 입장에서 얻는 이득이 더 크다. (글로벌에서 필수인 Multi region 지원 & 장애 시 region failover & 특정 IDC 등의 장애 시 수월한 대응)

이 때 발생할 수 있는 상황은 크게 세 가지가 있다.

첫째, 모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 재접속을 시도한다.

둘째, 단말의 네트워크가 비정상이거나 통신사의 장애로 네트워크가 정상적으로 동작하지 않아 조회 서버와 통신하는 것조차 불가능하다면, 클라이언트는 자체적으로 타이머를 두어 네트워크 부하를 최소화한다.

백오프 알고리즘

GCM(Google Cloud Messaging for Android)에서 사용되고 있는 알고리즘을 참고

기준이 되는 백오프 타임이 있고, 이는 최대 백오프 타임(MAX_BACKOFF_MS)을 초과하기 전까지는 두 배씩 증가한다.

셋째, 정상적으로 세션 서버의 주소를 수신하여 세션 서버에 접속을 시도하더라도 접속이 원활하지 않을 수 있다. 이런 경우 일정 횟수 이상 재접속을 시도해도 세션 서버와 접속이 되지 않으면 해당 세션 서버에 장애가 발생했다고 판단한다.

이런 비정상적인 경우 처음부터 로직을 다시 수행해야 하므로 비용이 많이 든다. 이런 비용을 줄이기 위해서 조회 서버로부터 두 개의 세션 서버 주소를 받고 첫 번째 세션 서버에 접속되지 않는다면 두 번째 세션 서버 주소(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에 저장하는 세션 서버의 상태

• shutdown: 세션 서버의 인스턴스가 종료된 상태 또는 정상적으로 서비스할 수 없는 상태
• starting: 세션 서버를 시작하고 있는 상태
• standby: 세션 서버가 정상적인 상태이나 아직 서비스에 투입 전이라 클라이언트의 접속이 없는 상태
• running: 세션 서버가 정상적이고 서비스에 투입하여 정상적으로 운영 중인 상태
• suspending: 세션 서버가 오동작하여 서비스에서 제거하고 있는 상태
• suspended: 세션 서버가 오동작하여 잠시 서비스에 투입하지 않은 상태
• resuming: 세션 서버가 정상적이어서 다시 서비스에 투입하고 있는 상태
• shuttingdown: 세션 서버가 종료하고 있는 상태

HA 구성

서버 매니저는 최소 두 대 이상(한 대의 master와 한 대 이상의 slave)으로 구성된다.

master의 역할은 세션 서버의 health check와 ZooKeeper에 세션 서버의 상태 업데이트이다. 그리고 지역이나 세션 서버의 목록이 변경되면 조회 서버에게 알려 주는 역할을 한다.

slave의 역할은 ZooKeeper와 Redis의 데이터를 지속적으로 동기화하여, 조회 서버의 지속적인 요청에 응답하는 것이다.

장애 대응 시나리오

기존의 로드밸런서를 사용했을 때 발생하는 장애에 유연하게 대응하기 위해 새로운 로드밸런서를 설계하는 것이다.

통신사에 일시적으로 장애가 발생하여 수천만 사용자의 세션이 끊어지면 장애 시간 동안 단말이 지속적으로 재접속을 요청하여 트래픽이 평소 대비 100배 이상 급증하고 그로 인해 망 용량 초과가 발생한다. 그리고 장애에서 복구 완료 후에는 단말이 일시적으로 접속을 요청하여 서버 용량 초과가 발생한다. 이와 같은 장애가 발생했을 때 이를 처리할 수 있는 로드밸런서 개발이 목표이다.

구조를 설계할 때 일부 모듈의 장애가 전체 장애로 이어지지 않게 하는 것이 관건이다.

1. 세션 서버 장애 시

세션 서버의 장애는 주기적으로 health check를 하는 서버 매니저가 가장 먼저 감지한다. health check에 실패하면 서버 매니저는 변경된 세션 서버 목록을 조회 서버에 다시 전달한다. 조회 서버는 새로 받은 서버 목록으로 로드밸런싱한다.

모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 하나도 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 조회 서버에 재접속을 시도한다.

2. 조회 서버 장애 시

조회 서버 중 일부에 장애가 발생해도 총 조회 서버의 서버 용량이 초과하지 않는 한 정상으로 동작한다.
조회 서버 전체에 장애가 발생하면 클라이언트는 백오프 타임 후에 재접속을 시도한다.

실제로 약 100만 개의 실제 세션으로 테스트를 진행하였을 때, 조회 서버가 평소에 요청받는 만큼의 세션이 세션 서버에서 감소하고, 조회 서버 복구 직후에는 클라이언트가 백오프 주기에 따라 동작하며 일시적으로 요청량이 증가하는 모습을 볼 수 있다. 테스트 결과 10분 정도의 전체 장애가 발생했을 때 20분 이내에 모든 세션이 복구 완료된다.

3. 서버 매니저 장애 시

서버 매니저(master)에 장애가 발생하면 slave 중 하나가 master로 전환된다. 서버 매니저(master)가 ZooKeeper에 특정 znode를 ephemeral node로 생성하고, slave는 그 znode를 지속적으로 모니터링한다. 해당 znode가 사라지면 서버 매니저(master)가 비정상이라고 판단하여, slave 중 하나가 master로 전환하는 형태로 구현 가능하다.

서버 매니저 전체에 장애가 발생하면 조회 서버는 실시간 세션 서버의 세션 수를 알 수가 없다. 이런 경우 조회 서버는 일시적으로 분배 알고리즘을 라운드로빈으로 동작한다. 서버 매니저 장애가 해결되면 다시 Weight Least Connection으로 동작한다.