[금융 IT] Global Server Load Balancing

한강섭·2025년 11월 6일

금융 IT

목록 보기
8/8
post-thumbnail

썸네일 출처: https://redisgate.jp/redis/network/load_balancing.php

기사를 보던 중 GSLB에 대한 내용이 있길래 정리해보고자 한다.

지능적 DNS

DNS 서비스의 발전된 형태


한마디로 정의하자면 특정 지역에 집중되는 트래픽을 분산하는 DNS 기반의 로드 밸런싱이다.

DNS 서비스는 도메인 이름을 IP 주소로 변환하는 일을 하는 서비스다. 하나의 도메인 주소에 대해서 여러 개의 IP주소를 넘겨줄 수 있는데, 이 기능을 이용해서 가용성 구성과 로드 밸런싱 기능을 수행할 수 있다. 하지만 가용성과 로드 밸런싱이 본 기능은 아니라서, 이런 목적으로 사용하기에는 한계가 있고 이를 해결한 것이 GSLB다.

밑에 그림은 위 : DNS, 아래 GSLB 로
DNS는 라운드로빈 방식이기 때문에 비효율적인 연결도 많이 보인다.
GSLB는 위치 기반으로 해당 지역을 서비스하는 서버로 연결한다. (일부 기능)

사진 출처: https://www.joinc.co.kr/w/man/12/GSLB

어떻게?

조건에 맞게 연결


GSLB는 기존 DNS의 단순한 IP 반환 방식을 넘어서, 헬스 체크와 지능적인 라우팅 정책을 결합한 방식으로 동작한다.

사용자가 도메인을 요청하면 GSLB는 여러 조건을 실시간으로 판단한다. 각 데이터센터의 서버 상태가 정상인지, 현재 부하는 어느 정도인지, 사용자와의 지리적 거리는 얼마나 되는지, 네트워크 지연시간은 어떤지 등을 종합적으로 고려해서 최적의 IP 주소를 선택해 반환한다.

일반 DNS는 미리 설정된 IP 목록을 순서대로 반환하는 단순 Round Robin 방식이라 서버 장애 여부를 알 수 없다. 반면 GSLB는 실시간으로 서버 상태를 모니터링하기 때문에 장애가 발생한 서버는 자동으로 제외하고, TTL을 짧게 설정해서 빠르게 장애 전환이 가능하다.

SH수협은행의 경우를 예로 들면, 잠실 센터와 용인 센터가 모두 액티브 상태로 운영되면서 평상시에는 두 센터에 트래픽을 적절히 분산한다. 만약 잠실 센터에 장애가 발생하면 용인 센터로만 트래픽을 전달하고, 부하가 급증하면 여유있는 센터로 더 많은 트래픽을 할당하는 식이다.

사진 출처 : https://www.samsungsds.com/kr/network-gslb/gslb.html

데이터 일관성은?

한계와 이를 보완하기 위한 노력


액티브-액티브 구성에서 가장 중요한 문제는 바로 데이터 일관성이다. 두 개의 센터가 동시에 트래픽을 처리하는데, 각 센터의 데이터베이스가 서로 다른 상태라면 큰 문제가 발생할 수 있다.

금융권에서는 이를 해결하기 위해 주로 실시간 데이터 복제 기술을 사용한다. 한 센터에서 발생한 트랜잭션을 다른 센터로 즉시 동기화하는 방식이다. 이때 양방향 복제(Bidirectional Replication)를 사용해서 어느 센터에서 데이터 변경이 발생하든 실시간으로 반영되도록 한다.

하지만 완벽한 실시간 동기화는 사실상 불가능하고, 네트워크 지연으로 인한 시간차가 항상 존재한다. 이를 해결하기 위해 세션 어피니티(Session Affinity) 정책을 사용하기도 한다. 특정 사용자는 세션이 유지되는 동안 같은 센터로 계속 연결되도록 하는 것이다. 이렇게 하면 같은 사용자의 연속된 요청이 서로 다른 데이터 상태를 보는 문제를 줄일 수 있다.

또한 데이터베이스 레벨에서 충돌 해결(Conflict Resolution) 정책을 미리 정의해둔다. 동시에 같은 데이터를 수정하는 경우 어떤 센터의 데이터를 우선할지, 타임스탬프 기준으로 최신 데이터를 선택할지 등의 규칙을 명확히 해야 한다.

생각해볼 점들


DNS 캐싱 문제

GSLB가 아무리 빠르게 장애를 감지하고 IP를 변경해도, 사용자의 로컬 DNS 캐시나 ISP의 DNS 캐시에 이전 IP가 남아있다면 여전히 장애 서버로 접속을 시도하게 된다. 이를 해결하기 위해 TTL 값을 짧게 설정할 수 있는데 성능과 trade-off 될 수 있다.

모니터링과 알람

두개의 센터를 실시간으로 모니터링하고, 트래픽 분산 상태를 지속적으로 확인해야 한다. 한쪽 센터에 트래픽이 편중되거나, 응답 시간이 느려지거나, 에러율이 높아지는 등의 이상 징후를 빠르게 감지할 수 있는 체계가 필요하다. 기사에서 언급된 제니퍼 같은 APM 도구가 바로 이런 역할이다.

보안 정책의 이중 관리

방화벽 규칙, DDOS 방어, 침입 탐지 시스템 등 모든 보안 정책이 두 센터에서 동일하게 적용되어야 한다. 한쪽 센터의 보안 설정이 느슨하면 약점이 될 수 있다.

결론


GSLB는 단순히 트래픽을 분산하는 기술을 넘어서, 현대 금융 서비스의 무중단 운영을 가능하게 하는 핵심 인프라다.

SH수협은행이 잠실과 용인에 액티브-액티브 구성을 도입한 것은 단순한 기술 도입이 아니라, 고객에게 끊김 없는 서비스를 제공하겠다는 의지의 표현이다. 한 센터에 문제가 생기더라도 고객은 인터넷뱅킹을 계속 사용할 수 있고, 평상시에도 두 센터에 부하가 분산되어 더 안정적인 성능을 경험할 수 있다.

하지만 GSLB는 만능 해결책이 아니다. 데이터 일관성 유지, DNS 캐싱 문제, 높은 인프라 비용, 복잡한 운영 관리 등 고려해야 할 점이 많다. 특히 금융권처럼 데이터 정합성이 중요한 영역에서는 더욱 신중한 설계와 운영이 필요하다.

결국 GSLB는 고가용성과 성능 최적화라는 두 마리 토끼를 잡기 위한 선택이고, 그 선택에는 비용과 복잡도라는 대가가 따른다. 하지만 24시간 멈출 수 없는 금융 서비스에서 이는 선택이 아닌 필수가 되어가고 있다. 디지털 전환이 가속화되면서 GSLB 같은 인프라 기술의 중요성은 앞으로 더욱 커질 것이다.

profile
기록하고 공유하는 개발자

0개의 댓글