SPOF (Single Point of Failure)란?
SPOF란 단일 장애점으로 장애가 전체 시스템 기능을 저해시키는 시스템 컴포넌트를 나타내는 용어입니다.
정말 다양한 시스템 컴포넌트들이 SPOF가 될 수 있지만 단순하게 서버 혹은 DB 차원에서 SPOF가 될 수 있는 경우를 알아봅시다.
단일 서버 혹은 단일 데이터베이스가 SPOF가 될 수 있습니다.
가장 단순한 백엔드 형태는 아래와 같은 단일 서버와 단일 데이터베이스 형태입니다.
당연히 API 서버의 장애가 발생하면 전체 시스템 장애로 이어지고 Database 서버의 장애가 발생하면 역시 전체 시스템 장애로 이어지게 됩니다.
그래서 이러한 구조에서 API 서버와 Database 서버는 SPOF가 될 수 있습니다.
그렇다면 SPOF를 방지하는 방법은 무엇이 있을까요?
이중화를 통해 SPOF를 방지할 수 있습니다.
아래와 같이 API 서버와 Database 서버를 이중화 한다면 하나의 API 서버 혹은 Database 서버가 장애가 발생하더라도 전체 시스템 장애로 이어지지 않습니다.
최대한 단순하게 설명하기 위해 API 서버와 Database 서버를 예로 들었지만 SPOF는 이외에도 다양한 시스템 컴포넌트들이 될 수 있습니다.
만약 트래픽을 분산하는 로드 밸런서가 하나라면? 로드 밸런서가 SPOF가 될 수 있습니다.
네트워크 장비인 스위치 혹은 라우터가 하나라면? 스위치 혹은 라우터 역시 SPOF가 될 수 있습니다.
이번 포스팅에서는 DB에 초점을 맞추어 DB Replication에 대해 알아보려고 합니다.
DB Replication이 필요한 이유
DB Replication은 말 그대로 DB를 복제하는 것입니다.
데이터베이스의 HA(High Availability, 고가용성)을 확보하기 위해 DB Replication을 활용할 수 있습니다.
고가용성이란 높은 사용 가능성으로 시스템, 서비스, 애플리케이션이 장애 없이 지속적으로 운영가능한 능력을 의미합니다.
DB Replication에서 중요한 점은 동기화입니다.
여러 개의 서버 간 데이터 동기화가 되어야 어느 서버와 DB connection을 맺던 항상 동일한 결과를 보장할 수 있습니다.
이를 위해 Master DB에서의 변경 사항이 Slave DB로 반영이 되어야 합니다.
MySQL Replication
MySQL에서 Replication을 구현하는 방식에 대해 알아봅시다.
MySQL을 예시로 살펴본다면 innoDB 기준으로 Binary Log Replication이 물리적 복제에 해당합니다.
Binary Log는 MySQL에서 발생하는 모든 변경 사항이 기록된 파일입니다.
Master DB에서 발생한 변경 사항을 Binary Log에 기록하고 이 내용을 Slave DB에게 전달하는 방식이 Binary Log Replication입니다.
MySQL의 복제 아키텍처는 다음과 같습니다.
- Master DB에서 발생한 변경 사항이 binary log에 기록된다.
- Replication I/O 쓰레드는 binary log dump에게 로그 정보를 받으면 릴레이 로그를 생성한다.
- Replication SQL 쓰레드는 릴레이 로그를 보고 SQL 구문을 실행한다.
MySQL 복제 타입
복제 타입은 바이너리 로그 파일 위치 기반 복제와 글로벌 트랜잭션 ID 기반 복제로 나뉩니다.
1. 바이너리 로그 파일 위치 기반
바이너리 로그 파일 위치 기반은 다음과 같은 방식으로 동작합니다.
- Slave DB에서 Master DB의 바이너리 로그 파일 이름과 위치를 통해 복제를 진행한다.
- Slave DB가 자신이 지금까지 복제한 위치 정보를 전달한다.
- 각 MySQL 서버들은 고유한 식별자를 가지고 있고 바이너리 로그에 저장할 때 이 정보를 함께 저장한다.
그런데 바이너리 로그 파일 위치 기반 방식은 Master DB에 장애가 발생하여 Slave DB가 Master DB로 승격될 때 문제가 발생합니다.
우선 각 DB 서버마다 바이너리 로그 파일 명과 이벤트의 위치가 같다는 보장이 없습니다.
복제를 처음 구축할 때 어느 이벤트부터 동기화를 수행할 것인지 정할 수 있기도 하고 각 DB마다 개별적인 트랜잭션이 발생할 수도 있기 때문에 DB 서버마다 동일한 이벤트의 위치가 다를 수 있는 것입니다.
아래 그림에서 Slave DB의 source는 지금까지 복제한 Master DB의 바이너리 로그 이름과 위치를 나타내고 replica는 자신의 바이너리 로그 이름과 위치를 나타냅니다.
Slave DB A는 완전히 동기화가 되어 있고 Master DB와 같은 이벤트를 가리키는 위치가 다른 것을 확인할 수 있습니다.
Slave DB A는 부분 동기화가 되어 있고 Master DB와 같은 이벤트를 가리키는 위치가 다른 것을 확인할 수 있습니다.
이 상태에서 Master DB가 장애가 발생해 완전 동기화가 되어있던 Slave DB A가 Master DB로 승격되었다고 합시다.
binary log 파일 이름도 달라졌고 위치 또한 달라지게 되었습니다.
기존에 완전 동기화가 아직 되지 않았던 Slave DB B 서버의 경우 Master DB 서버의 바이너리 로그 파일 이름도 달라졌고 위치도 달라졌기 때문에 어느 부분부터 동기화를 진행해야 할 지 모르게 됩니다.
2. GTID
이를 방지하기 위해 GTID (Global Transaction ID) 방식을 사용할 수 있습니다.
GTID는 모든 DB 서버에서 고유한 값이기 때문에 로그 파일 위치를 참조할 필요가 없습니다.
그냥 모든 DB 서버에서 고유하기 때문에 어떠한 Slave DB가 Master로 승격되더라도 자신이 지금부터 복제해야 하는 위치를 정확히 알 수 있습니다.
MySQL 복제 포맷
복제 포맷은 바이너리 로그에 저장되는 형태를 의미합니다.
SQL문을 저장하는 Statement 방식과 변경된 데이터를 저장하는 Row 방식으로 나뉩니다.
1. Statement
Statement 방식은 SQL문을 저장하기 때문에 감사를 할 때 무엇을 했는지 확실하게 알 수 있다는 장점이 있지만 매번 달라지는(비결정적) 쿼리가 실행되었을 때 Master DB와 Slave DB 간의 데이터가 달라질 수 있습니다.
예를 들어 CURTIME() 같은 시간 함수나 RAND()와 같은 랜덤 함수를 사용할 경우 이 SQL 구문을 그대로 복제하기 때문에 Master DB와 Slave DB 간의 데이터가 달라질 수 있습니다.
2. Row
ROW 기반은 SQL 구문 자체를 저장하지 않고 변경된 데이터 자체를 저장하기 때문에 비결정적 쿼리가 실행되더라도 데이터 일관성을 유지할 수 있습니다.
3. Mixed
기본적으로 Statement 방식을 사용하지만 비결정적 쿼리처럼 안전하게 복제되지 않을 때는 Row 방식을 사용합니다.
MySQL 복제 동기화 방식
1. 비동기 복제
Master DB 서버가 Slave DB 서버로 변경 이벤트를 보낸 뒤 확인하지 않습니다.
Slave DB가 Master DB로 승격될 경우 수행하지 못 한 트랜잭션을 직접 확인해야 합니다.
2. 반동기 복제
Master DB 서버에서 각 트랜잭션을 바이너리 로그에 기록하고 스토리지에 커밋한 뒤 이벤트를 전송합니다.
MySQL 복제 토폴로지
1. 싱글 레플리카
WAS는 Master DB에 write 연산과 read 연산을 하고 Slave DB에는 읽기 연산만 하는 구조입니다.
2. 멀티 레플리카
하나의 Master DB에 2개 이상 Slave DB가 연결된 구조입니다.
3. 듀얼 소스
두 DB 모두 읽기, 쓰기 연산이 가능하고 서로 Master이자 Slave인 구조입니다.
출처
https://blog.seongjun.kr/single-point-of-failure/
https://waterfogsw.tistory.com/55
https://www.youtube.com/watch?v=7DwxuWyCNHA
https://jongmin92.github.io/2019/11/13/Database/mysql-replication/
'공부 > Database' 카테고리의 다른 글
| [PostgreSQL] postgres GIN 인덱스 (1) | 2025.02.21 |
|---|---|
| [postgreSQL] RAG 시스템에서 hybrid search 구현 (키워드 검색 + 유사도 검색) (0) | 2025.02.19 |
| [PostgreSQL] postgres SCAN 종류 (Bitmap SCAN) (0) | 2025.02.12 |
| [PostgreSQL] PostgreSQL Full Text Search (0) | 2025.02.03 |
| [redis] node.js 환경에서 redis 분산 락 구현하기 (0) | 2025.01.10 |