공부저장소

📘 SyncMon

고가용성 클러스터링

SyncMon은 실시간 모니터링 서비스이므로, SyncMon 서버가 중단될 경우 모니터링 공백이 발생하고 운영에 큰 영향을 줄 수 있습니다.

따라서 서비스 중단을 최소화하기 위해 고가용성(HA, High Availability) 클러스터링 구성을 적용합니다.

고가용성 클러스터링이란, 운영 중인 서버에 장애가 발생하더라도 대기 중인 백업 서버가 즉시 서비스를 인계받아 전체 서비스가 중단되지 않도록 구성하는 방식입니다.

적용 가능한 방식

고가용성 구성을 위한 방식은 대표적으로 다음 3가지가 있습니다.

  • Nginx + Keepalived (L7 방식)

    애플리케이션 계층에서 Nginx를 로드 밸런서로 사용하고, Keepalived를 통해 장애 발생 시 가상 IP(VIP)를 정상 서버로 전환하는 방식입니다. HTTP/HTTPS 기반 서비스에 적합합니다.

  • AWS 로드 밸런싱

    AWS의 Elastic Load Balancing(ELB)을 이용하여 여러 인스턴스로 트래픽을 분산하고, 장애 발생 시 정상 인스턴스로 자동 전환하는 방식입니다. AWS 환경에서 높은 가용성을 유지하는 데 적합합니다.

  • L4 로드 밸런서

    네트워크 계층에서 TCP/UDP 기반으로 트래픽을 분산하는 방식입니다. 서버 상태를 기반으로 장애 발생 시 다른 서버로 요청을 전달할 수 있습니다.

적용 방식

현재 회사 환경에서는 Nginx + Keepalived (L7 방식) 을 사용합니다.

다만, 이번 구성은 DB까지 포함한 전체 시스템의 고가용성 구성이 아니라, 웹/애플리케이션 서버 영역에 대한 고가용성 클러스터링입니다.

즉, 이번 구성의 목적은 다음과 같습니다.

  • 클라이언트가 접속하는 웹 서비스의 가용성 확보
  • SyncMon 애플리케이션 서버 장애 시 대기 서버로 신속한 전환
  • 장애 발생 시에도 모니터링 서비스의 진입점과 애플리케이션 실행 환경 유지

DB 구성에 대한 전제

본 구성은 DB가 외부 서버에 별도로 구성되어 있다는 것을 전제로 합니다.

따라서 203, 204 서버에 대한 고가용성 구성은 웹 서버 및 애플리케이션 서버(SyncMon) 이중화를 대상으로 하며, DB는 별도의 영역에서 관리됩니다.

또한 DB는 서비스 전체 안정성을 위해 별도의 DB 고가용성 클러스터링 또는 이중화 구성을 적용해야 합니다.

즉, 본 문서에서 설명하는 내용은 웹/애플리케이션 서버 고가용성에 대한 내용이며, DB 고가용성은 별도 구성 항목으로 분리하여 관리합니다.

Nginx + Keepalived 기반 고가용성 클러스터링

구성 개요

두 서버(203, 204)에 동일한 SyncMon 실행 환경을 구성합니다.

  • 203 서버: Active(MASTER)
  • 204 서버: Standby(BACKUP)

두 서버 모두 Nginx와 SyncMon 애플리케이션을 실행할 수 있는 동일한 환경으로 구성하며, Keepalived는 두 서버 사이에서 VIP(Virtual IP) 를 관리합니다.

클라이언트는 실제 서버 IP가 아니라 VIP로 접속하게 되며, 평상시에는 203 서버가 해당 VIP를 보유합니다.

만약 203 서버에 장애가 발생하면 Keepalived가 VIP를 204 서버로 이전하여, 204 서버가 즉시 서비스를 이어받습니다.

설정 과정

1. Nginx와 Keepalived 설치

먼저, 두 서버(203, 204)에 Nginx와 Keepalived를 설치합니다.

  • Nginx: 클라이언트 요청을 처리하는 웹 서버 역할
  • Keepalived: VIP를 관리하고 장애 발생 시 서버 전환을 수행하는 역할

또한 두 서버에는 동일한 SyncMon 애플리케이션이 배포되어 있어야 하며, 동일한 설정 파일 및 실행 환경을 유지해야 합니다.

2. Keepalived 설정

203 서버(MASTER)

203 서버의 keepalived.conf 파일은 다음과 같이 설정합니다.

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass your_password
    }
    virtual_ipaddress {
        192.168.0.100
    }
}

204 서버(BACKUP)

204 서버는 state BACKUP으로 설정하고, 203보다 낮은 우선순위를 부여합니다.

예:

  • state BACKUP
  • priority 90

이렇게 하면 평상시에는 203 서버가 VIP를 유지하고, 203 서버 장애 시 204 서버가 VIP를 승계하게 됩니다.

3. Nginx 구성 파일 설정

두 서버의 Nginx 설정은 동일하게 유지해야 합니다.

즉, 203과 204 모두 동일한 프론트엔드 리소스 및 SyncMon 애플리케이션 요청을 처리할 수 있어야 합니다.

4. SyncMon 애플리케이션 및 Agent 실행 환경 구성

두 서버 모두 SyncMon 애플리케이션이 실행 가능한 상태로 구성되어 있어야 합니다.

특히 SyncMon에는 모니터링을 수행하는 agent가 포함되어 있으므로, 장애 전환 시 agent 역시 정상적으로 동작할 수 있어야 합니다.

이를 위해 서버 전환 시 자동으로 agent를 시작하는 트리거를 함께 구성합니다.

즉, 204 서버가 BACKUP 상태에서 MASTER 상태로 승격될 경우, 해당 이벤트를 감지하여 SyncMon agent를 자동 실행하도록 설정합니다.

이 구성을 통해 203 서버 장애 시 다음이 가능해집니다.

  • VIP 전환
  • 웹 서비스 전환
  • SyncMon 애플리케이션 서비스 전환
  • agent 자동 기동

5. Keepalived 서비스 시작

두 서버에서 Keepalived를 실행하여 VIP가 정상적으로 생성되도록 합니다.

이후 Keepalived가 서버 상태를 지속적으로 모니터링하며, 필요 시 VIP를 다른 서버로 전환합니다.

동작 방식

정상 동작 시

  • 203 서버가 MASTER로 동작하며 VIP를 보유합니다.
  • 클라이언트 요청은 VIP를 통해 203 서버의 Nginx로 전달됩니다.
  • 203 서버에서 SyncMon 애플리케이션과 agent가 동작합니다.
  • 204 서버는 BACKUP 상태로 대기합니다.

장애 발생 시

  • Keepalived가 203 서버의 상태를 모니터링하다가 장애를 감지합니다.
  • 장애가 발생하면 VIP를 204 서버로 자동 전환합니다.
  • 204 서버가 MASTER 역할을 인계받아 Nginx 요청을 처리합니다.
  • 동시에 전환 트리거에 의해 SyncMon agent가 자동으로 시작됩니다.
  • 이에 따라 SyncMon 서비스가 204 서버에서 계속 동작하게 됩니다.

복구 시

  • 203 서버가 복구되면 다시 BACKUP 또는 MASTER로 재편입될 수 있습니다.
  • 운영 정책에 따라 원래의 마스터-백업 구조로 복원할 수 있습니다.

정리

본 고가용성 클러스터링 구성은 웹/애플리케이션 서버 영역에 대한 고가용성 확보를 목적으로 합니다.

즉, 이번 구성의 핵심은 다음과 같습니다.

  • 203/204 서버 이중화
  • Keepalived 기반 VIP 전환
  • Nginx 기반 웹 서비스 지속성 확보
  • SyncMon 애플리케이션의 장애 전환
  • 서버 전환 시 agent 자동 실행

단, DB는 외부 서버에 별도로 존재하며, DB 자체의 고가용성은 별도의 클러스터링 또는 이중화 구성으로 관리해야 합니다.

따라서 본 문서는 웹/애플리케이션 서버 HA 구성에 대한 설명이며, DB HA는 별도 항목으로 분리하여 설계합니다.

참고