고가용성 정리 [1]

서비스의 고가용성을 유지하기 위해서 대부분의 서비스에서는 여러 대의 서버를 활용하는데 하나의 서버를 활용할때와 다르게 2개 이상의 서버가 존재하는 시점부터는 트래픽을 누가 어떻게 분배할 것인가에 대한 고민이 생기게 된다.

이 때 사용하는 것이 로드 밸런서인데 이름에서 알 수 있듯이 트래픽을 균형있게 잘 나누어주는 역할을 담당하게 된다.

우선 로드 밸런서를 활용하는 몇 가지 패턴을 확인해보자.

 

일반적인 로드 밸런싱

가장 많이 사용하는 방식은 TCP 기반으로 동작하는 로드 밸런서이다. 클라이언트는 로드 밸런서의 public IP 주소로 연결 요청을 보내고 로드 밸런서는 어떤 서버 인스턴스를 사용할 지 결정한 뒤 해당 요청을 포워딩 해주게 된다. 이 때는 port, protocol 과 같은 기본적인 TCP 정보를 기반으로 대상을 선정한다. 로드 밸런서가 서버와 클라이언트 사이 통신에 적극적으로 개입하는 시점은 이렇게 첫 연결 요청 부분이고 이후에는 그냥 거쳐가는 정도로만 개입하게 된다. 컨테이너 환경 속에서의 로드 밸런싱이나 여러 클라우드 서비스에서 제공하는 로드 밸런서가 이런 방식으로 동작하고 있다.

Global Server Load Balancing (GSLB)

GSLB는 좀 더 상위 레벨에서 동작하는 로드 밸런싱 방식이라고 볼 수 있다. 예를 들어 여러 데이터 센터에 서버가 존재한다면 그 중 하나를 선택해서 사용할 수 있도록 만들어 준다.

GSLB 는 크게 보면 다음과 같은 순서로 동작한다.

1. Global Load Balancer 에 IP 주소를 물어본다.
2. 1번에서 받은 IP 주소에 요청한다.

즉 어떻게 보면 로드 밸런서 앞에 또 다른 로드 밸런서가 있는 구조라고 할 수 있다. 이런 GSLB가 필요한 규모의 서비스인 경우라면 2번 과정에서 얻은 IP 주소는 또 다른 로드 밸런서 (앞서 본 일반적인 로드밸런서의 형태) 의 것인 경우가 대부분이다. 이렇게 되면 2번 과정 이후에 일반적인 로드밸런서과 클라이언트가 통신하기 위한 과정이 연달아 일어나게 된다.

 

GSLB 의 실제 동작은 DNS에 의존하는 경우가 많다. 클라이언트가 특정 도메인에 요청하면 DNS resolution 과정을 거쳐 그에 해당하는 IP 주소를 반환하는 것이다. 필요하다면 어떤 IP 를 반환할 지에 서비스 특성에 맞는 알고리즘을 첨가해 더 효과적으로 트래픽을 관리할 수 있다. GSLB는 DNS에 의존적이기 때문에 이를 사용하는 시점에 클라이언트가 서버와 통신할 때 부가적인 지연시간이 추가된다는 점도 알아두면 좋다.

 

GSLB 를 사용하면 클라우드, 온프레미스와 같은 다양한 곳으로 트래픽을 분산시킬 수 있다는 장점이 생긴다.

L7 로드 밸런싱

L7 로드 밸런싱은 말 그대로 Layer 7, 대부분의 경우 HTTP 정보를 기반으로 수행하는 로드 밸런싱을 말한다. 많이 사용하는 요소로는 HTTP method, Content-Type 등이 있다.

또한 URI 정보도 활용할 수 있기 때문에 API versioning 을 URI 에 포함하고 있다면 이를 확인해서 그에 맞는 적절한 서비스로 트래픽을 포워딩 해줄 수 있다. 이렇게 하면 강제 업데이트가 불가능한 상황 속에서 좀 더 유연하게 서비스를 운영해 갈 수 있다. 예를 들어 예전 버전의 서버를 해당 버전 사용자 수에 맞춰 스케일링 할 수 있다.

AWS 의 Application Load Balancer

AWS 를 기반으로 한 인프라를 구축한 서비스라면 로드 밸런서로 ELB를 사용하게 된다. 

ELB 에는 여러가지 타입이 존재하지만 가장 많이 사용하는 것은 Application Load Balancer (ALB) 와 Network Load Balancer (NLB) 이다. 둘의 가장 큰 차이는 ALB는 L7 로드 밸런싱을 하고 NLB 는 L4 로드 밸런싱을 한다는 점이다.

 

ELB 는 하나 이상의 Availability Zone (AZ) 내에 미리 등록한 타깃 (EC2 instance 와 같은) 으로 트래픽을 분배해주는 역할을 담당한다. 이 때 앞서 살펴본 것과 같이 health check 를 통해 실제 서비스 가능한 타깃으로만 트래픽이 전달될 수 있도록 해서 고가용성을 유지하는데 도움을 준다.

 

ELB 중 ALB 타입을 가장 많이 사용하고 있기 때문에 우선 ALB에 대해 조금 더 자세히 알아보자.

 

ALB 의 구성요소

 

ALB 에는 리스너라는 구성요소가 존재하는데 리스너는 사용하는 프로토콜과 포트가 설정되어 있어 그에 맞는 리스너를 사용할 수 있도록 하고 있다. 또한 리스너에는 규칙을 정의할 수 있는데 이 규칙에 따라 리스너에 온 요청을 어떤 타깃그룹의 타깃에 전달할지를 결정하게 된다.

 

여기서 말하는 타깃 그룹은 하나 이상의 타깃을 포함하고 있는 그룹을 말한다. 해당 그룹에 헬스체크를 설정해둘 수도 있는데 이렇게 되면 그룹 내의 모든 타깃의 헬스체크를 수행한 뒤 그 전체적인 결과를 취합해 사용한다.

 

ALB 는 앞서 살펴본 로드 밸런싱 방식 중 L7 로드 밸런싱을 수행하는 로드 밸런서에 가깝다고 볼 수 있다.

따라서 리스너의 규칙에서 HTTP 와 관련된 여러가지 요소들을 활용해서 여러가지 조건들을 추가할 수 있다. 예를 들어 HTTP header 를 사용한다거나 query string 이나 cookie 를 활용할 수도 있다.

 

Fail-over

Fail-over 는 primary 시스템이 불능 상태에 들어갔을 때 이를 자동 혹은 수동으로 여분의 시스템으로 전환해주는 과정을 말한다. 이 과정을 통해 시스템에 실패가 발생했을 때 다운타임을 최소화하여 고가용성을 유지하는데 도움을 준다.

 

fail-over 에는 크게 다음 두 가지 타입이 있다.

 

active-passive

active 와 passive 서버가 존재하고 둘 사이에 heartbeat 를 주고 받는 패턴이다. 만약 heartbeat 이 정상적으로 전달되지 못하면 active 서버가 정상적으로 동작하지 못한다고 판단하여 passive 서버의 IP 주소가 대신해서 사용되어 서비스를 재개한다.

이 패턴에서 생기는 다운타임은 passive 서버가 cold standby 인지 hot standby 인지에 따라 달라진다. 만약 cold standby 상태라면 서버가 새롭게 뜨고 서비스 가능 상태가 될 때까지 시간이 필요하기 때문에 좀 더 긴 다운타임이 발생하게 된다.

 

active-active

active 상태의 두 서버를 유지하고 트래픽을 두 서버가 모두 받는 패턴이다. 이렇게 하면 트래픽을 나누어 받을 수 있다는 장점이 생긴다. 만약 두 서버가 모두 public 에 오픈된 상태라면 DNS가 두 서버의 IP 주소를 모두 알도록 해두어야 한다.

 

앞서 본 ELB 에서 health check 과 Auto Scaling Group 을 활용하면 fail-over 를 간단하게 구현해낼 수 있다.

ELB 는 타깃 그룹에 대한 liveness check 를 수행해주는데 만약 응답이 정상적이지 않다면 해당 인스턴스를 서비스에서 제외하고 새로운 인스턴스를 띄워 미리 지정한 인스턴스의 수를 유지해 서비스가 정상적으로 동작할 수 있도록 해준다.