목표 : 서버 이중화 종류에 대해 설명할 수 있다.
VM 환경에서는 상용 서버에 대해 이중화 이상을 적용하는 것이 바람직하다.
하나의 서버가 죽더라도 다른 서버가 적절히 실행되어 서비스가 중단이 없어야 하기 때문이다.
그 종류는 사실 다양하다.
API 서버의 경우, 부하 분산 등을 생각해 Active-Active 구조로 설정될 수 있지만, Active-standby나, master-slave 구조를 가지는 것도 많다.
그럼 이런 종류들에 대해 정리해 보도록하자.
Active-Active 구조
Active 서버의 기준은 현재 정상 동작하고 있는가? 이다.
부하를 분산시켜 줄 수 있는 L4 스위치 등 LoadBalancer가 있고, Active 서버에 요청을 적절히 분배한다.
따라서 부하에 따라, Active 서버의 갯수를 늘리며, Scale-Out을 시킬 수도 있다.
2대 이상으로 구성된 Active-Active 구조에서는 한 서버가 장애가 나더라도, 지속 운영이 가능하고 Down되는 시간이 없다.
매우 좋아보이지만, 특정 상황에서는 쉽지 않은 경우도 있다.
예를 들면, DB 서버의 경우, 지원하는 DBMS도 적고, Active-Active 상황이다 보니, 그만큼 스토리지에 대해서 병목 현상이 발생할 수 있다
Active-Standby 구조
Standby 서버의 기준은 Active 서버를 대신할 수 있는가? 이다.
Active 중이던 서버가 장애가 발생하는 등, 어떤 이벤트가 발생했을 때 Active 서버 대신해서 Request를 받아 낸다.
보통, Application의 HeartBeat를 측정하는 솔루션이 있어서, 이벤트 발생 시, Active서버를 전환시키거나 수동으로 처리하는 경우가 많다.
예를 들면 DB 서버가 있다고 하자.
사용하고자 하는 DBMS가 Active-Active를 지원하지 않아서, Storage를 공유하는 2대의 DB 서버는 Active-Standby로 구성되었다.
그럼 특정 솔루션에서는 Active 서버의 상태를 확인하다가 장애가 났을 때(failover), Standby 서버로 전환해준다. (수초에서 수분 소요될 수 있음)
전환되는 시간이 소요되어, 그 시간동안은 이슈인 상황이지만 그래도 에러 상황을 빠르게 복구시킬 수 있다.
또한 standby 서버에는 실제로 요청이 들어오는 경우가 거의 없으므로, Active 서버만 동작하기 때문에 동기화에 큰 무리가 따르지 않는다.
Master-Slave 구조
이번엔 조금 다른 개념으로 넘어왔다.
Master 서버의 기준은 CUD가 가능하다는 것이다. 그에 비해, Slave 서버는 Read가 가능하다.
역할이 달라지는 것이며, 그에 따라 트래픽이 분산될 수 있다.
Master는 데이터 동시성이 아주 높은 트랜잭션을 담당하고, Slave는 데이터 동시성이 꼭 필요없는 경우에 읽기 전용으로 데이터를 가져온다.
Master가 Slave에게 데이터를 알려주는 구조는 다음과 같다.
- Master DB에 Data가 변경될 시, Master DB에 반영
- 변경 이력을 Binary Log로 저장
- Slave DB에게 이벤트 전송
- Slave IO Thread에서 이벤트를 받고, Binary Log를 Slave DB 각각의 Relay Log에 저장
- Slave SQL Thread에서 Relay Log를 읽어 Slave DB 업데이트
- 읽기 처리 시, Slave DB를 사용
다만, 데이터가 들어오는 양이 많아진다면, Master가 Slave에게 알려주기 전에 SELECT 요청이 들어올 수 있다.
이를 복제 지연이라고 하며, 이럴 때는 임시로 Master에게도 Select Query가 가능하도록 만들어 주기도 한다.
Wrap Up
결국 서버의 역할을 용어를 통해 분리한 것이였다.
위 개념을 잘알아두고, 서버 세팅 시에 잘 이해할 수 있도록 하자.