최근 물리적인 서버 A를 옮기는 작업을 하였다.
서버 A는 클라우드 서버로 이미 이관 작업을 거쳤기 때문에 옮기더라도 큰 사이드 이펙트가 발생하지 않을 것이라고 자만했다.

A 를 옮기고 나서 Web Service 내의 특정 도메인에서 위 에러가 발생 하였다.
에러를 지속적을 follow 한 결과, 서버 A 내에 DNS 서버가 존재했고 이러한 서버 A를 옮기자 도메인을 인식하지 못하는 문제가 발생한 것이다.
이 때 문제 발생시 나는 이해가 되지 않았다.
일반적으로 DNS 서버를 이중화 하여 놓기에 서버 A의 DNS 서버가 다운 되더라도 이중화 된 DNS 서버가 동작하여 위의 문제가 발생하지 않았어야 하기 때문이다.
문제 발생 이유는 이중화가 되어있는 줄 알았던 DNS 서버가 이중화가 되어있지 않았기 때문이었다.
이번 일을 계기로 이중화 작업을 더욱 철저히 하며, 추가적으로 이중화에 대한 기본적인 개념 자체도 학습을 하고자 한다.
이중화란 단어 뜻 그대로 장비를 2개 놓는 것이다.
2개 놓는 이유는 성능적인 이유도 있지만, 이번 글에서 중점적으로 다루고 있는 하나의 서버의 상태가 불능일 때 이를 커버할 수 있는 서버를 두기 위함이다.
이를 통해서 서비스의 지속성을 보장할 수 있다.
하드웨어는 부하가 걸리거나, 물리적인 문제가 생길 수 있는 변수가 너무나 많기에 장비를 이중화 시켜서 한쪽 장비가 다운되면 자동으로 반대쪽 장비가 동작하도록 하는게 일반적이다.

이중화는 일반적으로 2가지 구조로 운영된다.
Active-Active이는 동일한 두 시스템을 같이 운영하는 형태이다.
하나의 시스템에 장애가 생기면 장애가 발생하지 않은 나머지 하나의 시스템으로만 가동하게 된다.
이 때 장점은 처리 가능한 전체 용량이 증가하며, 단점은 장애 발생시 전체 용량이 절반으로 줄어들기에 서비스가 정상적으로 작동하지 않을 수 있으며, 동시성을 처리하기 어렵다는 것이다.
이는 부하 분산 등의 목적으로 주로 활용되며, 서비스 단위를 나누어서 분산한다.

Active-Active는 L4 스위치 등의 Load Balancing을 통해 기능 또는 성격에 따라 1번 또는 2번 서버로 나누어서 처리하도록 구성한다.
대부분 웹 서버는 L4 스위치 Server Load Balancing으로 구성하고, DB 서버는 Oriacle Real Application Cluster를 활용한다.
Active-Standby이는 동일한 두 시스템을 만들어두되, 운영은 하나의 시스템으로 한다.
운영 시스템(Active System)에 장애가 발생할 경우, 다른 시스템(Standby System)으로 즉시 전환한다.
이 때 단점은 Standby System으로 인해 자원의 비효율성이 발생할 수 있다는 것이다.
이는 즉각적인 장애 대처를 위해 구성된다.

Active-Standby는 Cluster Heartbeat 등을 통해서 시스템의 정상 상태를 주기적으로 체킹하고, 특이사항이 발생하는 경우 Standby Server로 서비스를 전환한다.