산업이 급속도로 발달함에 따라 발생하는 데이터의 양은 증가하고 있으며, 코로나19의 영향으로 인한 언택트 문화 확산으로 데이터 트래픽이 폭발적으로 늘어났습니다. 데이터 트래픽이 최근 2년간 약 2.5배 급증한 상황에서 기업은 데이터베이스를 단순 수집, 저장용으로 이용하는 것을 넘어 대고객 서비스를 위한 서비스의 지속성이 중요하게 되었습니다. 즉, 서비스가 죽지 않고 계속 살아있는 ‘고가용성’의 고려는 필수적이라고 할 수 있습니다.
데이터베이스를 사용하면서 서버가 중단되는 현상이나 재해가 일어나 서버가 멈추는 경우가 발생할 수 있습니다. 이와 같이 예기치 않은 상황으로 서비스가 다운되면 서비스가 중단되고, 데이터가 손실될 수 있습니다. 서비스가 단 1~2분 중단되더라도 기업에 미치는 영향은 금전적 손실과 더불어 장기적인 관점에서 회사의 명성과 영업권 그리고 고객 충성도까지 영향을 끼칠 수 있습니다. 또한, 서비스를 사용하는 사용자와 발생하는 데이터가 점점 많아지는 추세에서 하나의 데이터베이스 서버로 서비스를 운용하는 것은 상당한 부하가 발생할 수 있습니다.
따라서 이에 대한 상황에 대비하기 위한 고가용성 유지가 필요합니다. 대비할 수 있는 방법은 다양하게 존재하지만 여러 해결방법 중 이번 아티클에서는 서비스지연을 줄이고, 다양한 장애 상황에 대비하기 위해 모든 정보가 모든 데이터 리소스 간에 실시간으로 동일하게 유지되도록 데이터를 복제하는 ‘Replication’, 데이터베이스 복제에 대해 설명하도록 하겠습니다.
이 아티클의 콘텐츠는 ‘Replication’이 무엇인지에 대해 설명하고 Replication에는 어떤 종류가 있으며 각각의 장점과 단점은 무엇인지에 대해 설명하는 순서로 이루어져 있습니다.
Replication
Replication이란 ‘복제’라는 의미를 가지고 있습니다. 말 그대로 데이터를 복제하여 데이터 안정성을 보장하는 콘셉트입니다. 리플리케이션은 두 개 이상의 데이터베이스 시스템을 ‘Master’ 서버와 ‘Slave’ 서버로 나눠서 동일한 데이터를 저장합니다.
Master 서버는 원본 서버를 의미하며 Primary, Main, Source 서버라고도 불립니다. Slave 서버는 Master 서버 내 데이터를 복제한 서버이고, Stanby, Secondary, Replica 서버라고도 불립니다. 본 아티클에서는 원본 서버를 Master 서버, 복제 서버를 Slave 서버라고 명칭 하겠습니다.
원본 서버인 Master 서버에서는 주로 데이터의 삽입(Insert), 수정(Update), 삭제(Delete)가 이루어지고 데이터 변경이 진행될 때마다 복제 서버인 Slave 서버에 변경된 데이터가 실시간으로 복제되기 때문에 Slave 서버는 Master 서버와 동일한 데이터를 갖게 됩니다. 이는 데이터베이스 내 장애가 발생하여 복구할 때 데이터 손실을 최소화시켜줍니다. 또한 Slave 서버는 Master 서버로 승격할 수 있기 때문에 장애 발생 시 Slave 서버가 Master 서버를 대체하여 데이터 복구가 가능합니다.
Replication을 구축해야 하는 이유
Replication 서버를 구축하게 되는 이유는 아래와 같이 나눌 수 있습니다.
- 고가용성
- Master 서버에 장애가 발생했을 경우, Slave 서버를 Master 서버로 승격하여(Failover) 사용자가 서비스 중단 없이 데이터를 질의하거나 업데이트할 수 있도록 예기치 못한 장애상황에 빠르게 대처할 수 있습니다.
- 서버 부하 감소
- 하나의 서버에서만 SQL 쿼리를 수행하면 부하가 생기게 됩니다. 하지만 여러 대의 Slave 서버를 구축하여 SQL 쿼리의 수행을 분산시켜 데이터베이스의 부하를 줄일 수 있습니다. 이는 액세스 비용을 낮추고 분산 시스템 성능을 향상합니다.
- 데이터 백업
- 리플리케이션을 구축하지 않아도 데이터 백업은 필수적입니다. 데이터 백업 시 실시간으로 서비스를 제공하고 있는 하나의 Master 서버에 대해 백업을 수행한다면, 실시간 서비스에 영향을 줄 수 있습니다. 따라서 Slave 서버를 따로 구축하여 해당 서버에서 복제를 통한 백업을 진행한다면 좀 더 안전한 백업이 가능합니다.
- 데이터의 다양한 활용성
- 단순 트랜잭션 수행이 아닌, 데이터 분석을 위한 쿼리는 단순 조회 쿼리보다 무겁고, 다량의 데이터를 조회하는 특성을 가지고 있습니다. 분석을 위한 Slave 서버를 따로 구축하여 실 서비스에 영향을 끼치지 않고 데이터 분석이 가능합니다.
- SQL 수행 시 SELECT 쿼리문을 활용하여 데이터를 조회하는 비중이 높습니다. 데이터를 수정하는 행위보다 조회(SELECT)하는 명령은 데이터베이스의 과부하를 더 일으킵니다. 이를 위해 Slave 서버를 읽기 전용, Master 서버에서는 데이터 삽입/삭제 전용으로 분리하여 구축한다면 데이터베이스의 과부하를 줄여 서비스를 좀 더 안정적으로 제공할 수 있습니다.
- 데이터 지리적 분산
- 서비스를 제공하는 애플리케이션 서버와 데이터베이스 서버의 거리가 멀어진다면, 서비스 응답 속도가 느려집니다. 이를 방지하기 위해 Slave 서버를 애플리케이션에 가까이 두어 서비스 응답 속도를 개선할 수 있습니다. 이런 특징은 다양한 나라에서 서비스를 제공하는 경우 각 나라에서 서비스를 사용하는 사용자에게 질 좋은 서비스 경험을 제공할 수 있게 됩니다.
- DR-재해 복구
- 데이터베이스에 재해가 발생하여 데이터 손실이 발생하기 전 데이터를 미리 복제하여 백업을 한다면, 예기치 못한 장애 상황의 데이터 복구에 대비를 할 수 있습니다.
Replication 구축 시 고려해야 할 점
데이터베이스 Replication을 구축함에 있어 장점도 많지만 고려해야할 점도 존재합니다. 아래와 같은 사항을 고려하여 Replication 서버를 구축해야 합니다.
- 보장할 수 없는 데이터 정합성
- Slave 서버는 Master 서버를 복사하는 서버입니다. 복사 중 Slave 서버가 Master 서버의 실시간 쿼리 처리량을 따라가지 못하는 경우가 발생한다면, 데이터 정합성을 보장한다고 할 수 없습니다.
- Binary Log File 관리
- Master 서버에서는 Binary Log가 무분별하게 쌓이는 것을 막기 위해 데이터 보관 주기를 설정합니다. 하지만 Master 서버에서 Binary Log File을 삭제했을 경우 Slave 서버에서 자동적으로 삭제되지 않기 때문에 각 서버가 보관하고 있는 Binary Log가 달라질 수 있습니다.
- Slave 서버 구축에 대한 비용 발생
- Slave 서버를 별도로 구성하기 위해서 비용 발생은 필수적입니다. 또한 관리해야 하는 서버의 범위가 넓어지며, 이를 위한 전담 전문 인력이 필요하기 때문에 서버 구축에 대한 비용 발생을 고려해야 합니다.
Replication 종류
Replication은 물리적 복제(Physical Replication)와 논리적 복제(Logical Replication) 방법으로 나눌 수 있습니다. 각 복제 종류에 따른 특징과 장단점에 대해서 좀 더 자세히 설명하겠습니다.
[물리적 복제]
물리적 복제는 데이터의 변경이력 파일인 로그파일(redo/wal)을 Slave 서버로 전달하여 복제하는 원리입니다. 전달된 로그파일에 있는 데이터 변경 이력을 토대로 블록 안의 데이터를 변경합니다. 이런 방식의 물리적 복제는 아래와 같은 두 종류로 수행될 수 있습니다.
1. Block Copy Replication
- 완성된 로그 파일 자체를 Slave 서버로 전달하는 형태이며, Recovery를 통해 Replication을 수행
- 로그 파일이 정해진 크기를 다 채운 후 새 파일이 생성되어야 기존의 로그 파일이 전달됨
- 로그 파일이 채워지는 동안 Master 서버와 Slave 서버 간의 데이터 지연 발생 가능성이 존재
- 비동기식 Replication에 활용
2. Streaming Replication
- 데이터베이스 클러스터 수준에서 데이터를 복제
- Slave 서버는 로그파일을 기다리지 않고, record 단위 복제 수행
- 일반적으로 논리적 Replication보다 빠르며, 많이 사용되는 복제 방식
물리적 복제는 위에서 살펴본 바와 같이 데이터 전체를 복제하는 형식이기 때문에 아래와 같은 여러 단점이 존재합니다.
<물리적 복제의 단점>
- 동종 환경에서만 복제
- 바이트 단위로 전송하여 복제하기 때문에 Master 서버와 Slave 서버가 동일한 버전의 플랫폼이어야 하기 때문에 이기종 환경에서 복제가 불가능합니다.
- 데이터베이스 작업 전체 복사로 인한 한계
- 모든 데이터 변경 이력이 복제되어 필요한 데이터에 대해서 부분 복제가 불가능합니다.
- 데이터 타입이 변경이 불가능합니다.
- 모든 데이터베이스 작업이 복제되기 때문에 네트워크 사용량이 높습니다.
- 복제되는 DB는 읽기 전용 이어야 함(write 작업 불가능)
- 서버의 물리적 위치가 가까워야 함
[논리적 복제]
논리적 복제는 Master 서버에서 Slave 서버로 SQL 쿼리문을 전달하여 변경 내용을 복제하는 프로세스입니다. 논리적 복제는 데이터베이스의 여러 복사본을 만들고 유지 관리하기 위한 강력한 도구로 재해 복구, 확장, 데이터 마이그레이션 등 다양한 용도로 사용할 수 있습니다. 논리적 복제는 물리적 복제와는 다른 아래와 같은 특장점을 가지고 있습니다.
- 이기종 환경에서 복제 가능
- 데이터 전체의 바이트 단위가 아닌 SQL 수행문으로 전달되기 때문에 복제하려는 서버의 플랫폼이 다른 버전이더라도 복제가 가능합니다.
- 다른 스키마(시퀀스, 인덱스 등)에 영향을 받지 않고 복제가 가능합니다.
- 서로 다른 소스의 데이터를 하나의 DW, DM으로 통합이 가능합니다.
- 부분 복제 가능
- 실제 쿼리문에 조건을 걸어 복제할 수 있기 때문에 필요한 테이블 및 행에 대해서만 복제가 가능합니다.
- 필터링된 변경사항만 복제되기 때문에 네트워크 사용량이 적습니다.
- 복제되는 서버에서 DDL, DML 등 쓰기 작업 가능
- 지리적 위치에서 데이터 동기화 가능
- 광역 네트워크, 저대역폭 네트워크에서 작동할 수 있기 때문에 물리적으로 거리가 먼 서버간 복제가 가능합니다.
결론
이번 아티클에서는 Database Replication이 무엇이며 사용하는 이유와 유의점까지 알아보았습니다.
적절한 Replication의 활용은 시스템 장애를 예방할 수 있고, 대응할 수 있습니다. Replication은 물리적, 논리적 복제로 나누어지는데 물리적 복제의 특징에 따라서 대규모 복제와 백업을 위한 복제가 필요할 때에는 물리적 복제를 활용하고, 세분화된 복제와 여러 개의 이기종 시스템을 하나의 데이터베이스로 병합하는 경우는 논리적 복제를 활용하는 것이 적합합니다. 독자에게 상황에 맞는 Replication을 구축한다면 데이터베이스를 안정적으로 사용할 수 있게 될 것입니다.
비트나인의 AgensSQL은 데이터 Replication 기술을 구현할 수 있습니다. AgensSQL의 Replication을 통해 데이터베이스를 운영하는데 유연성과 확장성을 제공받을 수 있습니다.
<References>
https://newsroom.koscom.co.kr/29107?print=pdf
https://www.jumpmind.com/blog/blog/data-trends/advantage-of-logical-replication/
https://www.youtube.com/watch?v=OvSzLjkMmQo&feature=sharec
글 : 김성희 대리 ( 비트나인 컨설팅팀 )
'DBMS > 활용 사례' 카테고리의 다른 글
| RDB와 GDB 융합을 통한 다양한 시각화 사례 (0) | 2023.09.04 |
|---|---|
| GDB&Cypher 소개 (0) | 2023.09.04 |
| AGE에서 Cypher로 발생시킨 그래프 탐색 (2) | 2023.09.03 |
| 가장 인기 있는 5가지 그래프 DB 쿼리 언어 (0) | 2023.09.03 |
| 그래프 기반 고객 행동 데이터 모델링 및 분석 방법론 (0) | 2023.09.03 |