이중화
단일 자원(장비)으로만 서비스를 하는 경우, 해당 자원에 문제가 생기는 경우 서비스가 중단 된다.
서비스의 중단은 대부분의 서비스에 매우 치명적이며, 따라서 지금은 이런 서비스 중단을 대비하기 위해 자원을 "이중화" 하는 것이 기본으로 받아들여지고 있다.
여기서 "이중화"란, 자원을 2개씩 구성하여 하나의 자원에 문제가 생기더라도 다른 하나의 자원으로 중단없이 계속해서 서비스가 이루어지도록 하는 것을 말한다.
완전한 이중화를 위해서는 서비스 전체에서 사용되는 모든 자원의 이중화에 대한 고민이 필요하지만, 오늘은 그 중에서 가장 기본이라고 할 수 있는 서버 이중화, 그 중에서도 "active-standby" 에 대해 이야기 해보려고 한다.
"active-active" & "activce-standby"
서버를 이중화 하는 방법은 크게 보면 "active-active" 와 "active-standby"(= "active-passive") 2가지라고 할 수 있다.
"active-active"는 2개의 자원이 동시에 서비스(active) 되는 것을 말한다. 로드밸런서라고하는 장비가 앞단에서 트래픽을 받으면 그 트래픽을 2개의 서버에 균일하게 나누어주고, 2개의 서버가 전달받은 요청들을 처리하게 된다.
반면, "active-standby" 는 말 그대로 하나의 서버가 대기(standby) 상태에 있음을 뜻한다. 아키텍쳐 상 로드밸런서와 2개의 서버로 구성되는 것은 "active-active"와 동일하지만, 하나의 서버는 서비스 되지 않고 대기하며 하나의 서버로만 트래픽을 처리한다.
헬스체크(health check)
로드밸런서는 각각의 서버에게 "health check" 라고 해서, 정상적으로 서비스할 수 있는 상태인지를 확인하는 요청을 보내게 된다. 이 때 응답이 없거나, "unhealthy" 한 응답이 돌아오는 경우 로드밸런서는 해당 서버가 문제가 있다고 판단하게 된다. (종종 서버가 정상상태여도 일시적으로 unhealthy 한 응답이 돌아올 수 있으므로, 보통은 'x분 내 y번 unhealthy' 와 같은 기준을 정해둔다.)
서버가 "unhealthy" 하다고 판단하면, 로드밸런서는 해당 서버로의 트래픽을 차단한다. 이 때, "active-active" 의 경우 이미 "active"한 다른 하나의 서버가 존재하므로 그대로 중단없이 서비스가 유지된다. "active-standby" 의 경우 대기(standby)하고 있던 다른 하나의 서버가 "active" 상태로 변경되며 로드밸런서가 해당 서버로 트래픽을 전달하게 된다.
"active-active" vs. "active-standby"
그렇다면 어떤 방식으로 이중화 하는 것이 더 좋을까? 대부분의 경우, "active-active" 방식이 더 효율적이다.
우선, "active-active"가 "active-standby" 보다 "가용성"(서비스가 정상적으로 사용 가능한 정도) 측면에서 유리하다.
"active-active" 의 경우 이미 2개의 서버가 모두 "active" 상태이기 때문에, 한 쪽 서버가 다운되더라도 트래픽만 차단하면 별다른 전환 작업(failover)이 필요하지 않다. 하지만, "active-standby"는 한 쪽 서버가 "standby" 상태이므로, 이 서버를 "active" 상태로 전환시켜줄 필요가 있다. 이 전환 작업의 시간에 따라 서비스에 일시적인 중단(down time)이 발생할 수 있다.
또한, 비용 측면에서도 "active-active" 가 유리하다.
"active-active"의 경우를 생각해보면 평소 각각의 서버들이 50%, 50%의 트래픽을 받고 있었을 것이다. 이 트래픽의 양을 쉽게 50, 50이라고 가정한다면, 각 서버들은 보통 75~100 정도(1.5~2배) 트래픽을 감당할 수 있는 스펙을 가지고 있었을 것이다. 100, 100 으로 구성한다고 가정한다면 하나의 서버가 사라지더라도 다른 하나의 서버로 어느정도 커버가 가능하며, 이 때의 비용은 200이다.
반면, "active-standby"의 경우에는 하나의 서버가 100%의 트래픽을 받고 있었을 것이고 이 서버의 스펙은 150~200 정도가 되어야 한다. 전환되었을 때를 가정하면 standby 서버의 스펙은 최소 100은 되어야 하는데, 그러면 이 때의 비용은 250~300 으로 상대적으로 더 비싸다.
또한 서버 인메모리 캐시 등 "warm-up" 이 필요한 경우를 고려해봐도 "active-active" 는 이미 각 서버에 반 정도의 캐시가 존재하고 있기 때문에 나머지 반절의 추가 작업만이 필요하지만, "active-standby"는 대기 중이었던 서버에는 아무런 정보도 존재하지 않으므로 완전히 처음부터 "warm-up" 작업이 필요하다.
(이 경우는 "active" 서버와 "standby" 서버를 지속적으로 전환해줌으로써 해결할 수 있긴 하다. 다음 편에 후술.)
Why "active-standby"?
하지만, 그럼에도 불구하고 "active-standby" 를 이용하게 되는 경우들이 있다.
"active-standby" 는 네트워크 측면에서 더 단순하다. 사실 "active-standby"는 두 서버 간의 "로드밸런싱"이 필요하지 않다. 즉 로드밸런서가 없어도 무관하다. 장애 인지 및 트래픽 전환의 용이성을 위해 LB 를 두고 사용하는 경우가 많긴 하지만, LB 없이 라우터만 두고 트래픽을 전달해도 된다.
또한, 애초에 트래픽이 분산되어 전달되지 않으므로 네트워크 문제를 추적할 때 한 쪽만 확인하면 되기 때문에 더 쉽고 편하다.
하지만, 최근에는 여러 도구들이나 인프라 서비스의 발전으로 "active-active" 자원을 구성하는 것도, 이렇게 구성된 두 자원을 모니터링하고 점검하는 것도 그다지 어렵지 않다. 즉, 이것만으로는 "active-standby" 를 선택할 충분한 이유가 되지 못한다.
그렇다면 언제, 왜 "active-standby" 를 이용하게 될까?
동시성 이슈
"active-active" 는 2개 이상의 서버가 동시에 요청을 처리하며, 이 경우 동시성 이슈가 발생할 수 있다. 이런 동시성 이슈를 해결하기 위한 다양한 방법이 존재하지만, "active-standby" 구조는 이런 이슈를 근본적으로 해결한다. 서버가 하나 밖에 없기 때문에 동시성 이슈가 애초에 발생하지 않기 때문이다.
따라서, 동시성에 대해 엄밀하고 정밀한 제어가 필요한 경우, "active-standby" 구조로 서버를 구성하는 것을 고려해볼만 하다.
How "active-standby"?
그렇다면 "active-standby" 서버는 어떻게 구성할 수 있을까?
이 내용은 다음 포스트에 이어서 적어보겠다.
