🫓

DB 다중화와 Replication(MySQL편)

생성일

2023/05/08

태그

MySQL

infra

Structure

목차

배경

최근에 학습 중인 ‘가상 면접 사례로 배우는 대규모 시스템 설계 기초’ 도서에서는 매 챕터, 매 계층마다 ‘다중화’를 강조합니다. 이는 대규모 시스템 구조에서 장애에 가장 취약한 SPOF(Single Point of Failure)를 방지하기 위함인데요, 하나의 서버에서 장애가 발생할 경우 모든 서비스에 장애가 발생하는 것을 막기 위함입니다. 또한 하나의 서버에서 모든 요청을 처리하게 되므로 트래픽이 몰릴 경우 병목 현상이 생겨 성능을 제대로 발휘할 수 없다는 문제점도 있습니다. 이러한 문제를 해결하기 위해 DB 계층의 다중화는 항상 언급되는 부분이었고, 저희 모락 서비스에서도 미처 대응하지 못한 지점이었기때문에 데이터베이스 다중화를 학습해보고 그 중에서도 레플리케이션에 대해 적용해 보기로 하였습니다.

DB 다중화

MySQL 에서 서버를 다중화하는 방법은 크게 Clustering 과 Replication 이 있습니다.

Clustering

MySQL 에서 지원하는 클러스터링은 Shared-Nothing Architecture 구조를 가지며 각각의 서버가 모두 독립적으로 운영되고 수평적인 계층을 가집니다.

이에 따라 하나의 서버에서 장애 시에 대응이 쉽고 병목 현상이 발생할 우려가 적다는 장점이 있습니다. 하지만 독립적으로 구성된 여러 서버에서 데이터가 변경될 시 모든 서버에서 데이터가 동기화가 되어야 합니다. 이로 인해 여러 노드들 간의 데이터를 동기화하는 시간이 필요하여 쓰기 성능이 비교적 좋지 않고 장애가 전파된 경우 처리가 까다로울 수 있다는 한계가 있습니다.

Replication

복제는 한 서버의 데이터를 복제하여 다른 서버로 동기화하는 것을 의미하는데요, 클러스터링과 다른 점은 수직적인 계층을 가집니다.

원본 데이터가 저장되어 있는 서버를 source 서버, 복제된 데이터가 저장되어 있는 서버를 replica 서버라고 합니다. 이에 따라 복제되는 방향도 source 서버에서 replica 서버로 단방향으로 흐르게 되어 동기화가 클러스터링보다 빠르고, 정합성 관리도 상대적으로 편하다고 할 수 있습니다.

과거에는 Master-Slave 로 불렸지만 사회적 통념상 slave 라는 단어 사용을 억제하기 위해 Source-Replica 또는 Primary-Secondary 를 사용하는 추세입니다. 이에 따라 해당 포스트 및 레플리케이션 코드에서는 Source-Replica 라는 단어를 사용합니다.

Replication 목적

•

가용성(availability)

◦

replica 서버 중 하나에 장애가 발생하더라도 가동중인 replica 서버에서 데이터를 가져와 대응이 가능하므로 계속 서비스를 할 수 있습니다.

◦

만약 source 서버가 다운되었을 때에는 replica 서버 중 하나가 새로운 source 서버가 되어 쓰기 연산을 처리합니다. 이 때 승격된 서버에 보관된 데이터가 최신 상태가 아닐 시를 대비하여 사전에 복구 스크립트를 지속적으로 업데이트하고, 장애 발생 시 스크립트를 수행하여 최대한 데이터 손실이 없게끔 대비해야 합니다.

•

안정성(reliability)

◦

데이터베이스 서버 가운데 일부가 파괴되어도 다른 서버에 동기화된 데이터가 보존되어 있으므로 데이터를 보존할 수 있습니다. 다만 개발자의 실수로 source 서버의 모든 데이터를 삭제하는 연산이 발생할 경우, 모든 서버에서 삭제 상태로 동기화가 진행될 수 있기때문에 독립적인 서버에 데이터를 주기적으로 백업해야 합니다.

•

더 나은 성능

◦

쓰기 연산은 source 서버로만 전달되고, 읽기 연산은 replica 서버들로 분산되기때문에, 병렬로 처리될 수 있는 쿼리의 수가 늘어납니다. 그리고 비교적 오래 걸리는 쓰기 연산으로 인해 트래픽이 집중될 때 발생할 수 있는 병목 현상을 완화할 수 있습니다. 다만 서비스 특성상 쓰기 연산이 자주 발생하는 상황이라면 동기화 작업으로 인해 오히려 성능이 저하될 수 있으므로 서비스 특성에 맞추어 설계를 해야합니다.

MySQL 에서 두 방식의 차이

InnoDB 스토리지는 다중화의 기본값으로 레플리케이션을 지원하고 있고, 앞서 언급한 클러스터링 구조를 적용하기 위해서는 InnoDB 대신 NDB Cluster 스토리지 엔진을 사용해야 합니다. NDB Cluster 스토리지 엔진도 레플리케이션을 지원하지만 트랜잭션 격리 수준 등 기본적인 스토리지 엔진으로써의 차이가 존재합니다(ndb cluster vs innodb engines). 복제 방식 또한 레플리케이션은 쓰기 연산이 끝나고 데이터를 복제하는 시점에서 비동기 방식으로 메인 쓰레드의 응답 지연속도를 줄일 수 있지만 클러스터링 방식은 모든 데이터 서버에 동기화를 진행한 뒤 비로소 연산이 끝나기때문에 응답 지연속도에서도 차이가 있습니다. 이에 따라 빠른 응답 속도와 MySQL 8 기본 스토리지 엔진인 InnoDB 를 기본값으로 사용할 수 있는 Replication 을 사용하기로 결정하였습니다.

동작 원리

Replication 을 학습하면서 어떻게 복제를 하는지가 가장 궁금했었습니다. 결론부터 말하자면, source 서버와 replica 서버가 커넥션을 맺은 상태에서 이벤트 방식처럼 동작하여 특정 시점 이후의 데이터 변경점을 바이너리 로그로 읽어와 변경점을 적용하는 것입니다. 각 스텝을 그림으로 표현하면 다음과 같습니다.

source 서버에서 insert, update, delete 와 같은 모든 쓰기 연산을 바이너리 로그로 기록합니다. 이는 따로 설정을 해주지 않아도 기본적으로 MySQL 에서 지원합니다.

replica 서버를 source 서버에 복제 목적으로 연결을 맺습니다. 이 때, 보안을 위해 source 서버에서는 복제용 user 를 만들어 해당 user name 과 비밀번호로 연결이 가능합니다. 연결은 TCP/IP 기반의 MySQL 복제 프로토콜을 이용하여 연결을 맺습니다.

연결이 맺어졌다면 source 서버와 replica 서버의 스키마 및 데이터 동기화가 필요합니다. 나중에 자세히 알아보겠지만, 쓰기 연산의 특정 시점을 pos(Position) 값으로 확인하는데, 스키마가 맞지 않다면 pos 값이 일치해도 복제가 되지 않고 에러를 반환합니다. 보통 mysqldump 와 같은 툴을 사용하거나 데이터 파일을 바로 카피하는 방법으로 데이터 동기화를 할 수 있습니다.

연결을 맺은 후 source 서버에 쓰기 연산이 커밋이 되면 pos 값이 변하고 바이너리 로그가 변경됩니다.

바이너리 로그 포지션이 기록되면 복제 프로세스가 시작되는데요, 비동기 방식으로 새로운 쓰레드에서 이전 pos 값과 비교해 변경 이벤트에 대한 로그를 읽습니다. 이벤트를 읽을 때 바이너리 로그 파일에 잠금을 걸고, 읽기 작업이 끝나면 잠금을 해제하는 로직입니다.

replica 서버의 I/O 쓰레드에서 변경점에 대한 로그를 수신하고 이를 릴레이 로그 파일에 저장합니다.

저장이 완료되면 replica 서버의 새로운 쓰레드에서 릴레이 로그에 저장되어 있는 변경점을 적용합니다. 이 때 데이터 정합성을 위해, source 서버에서 발생한 쿼리 순서와 같은 순서로 replica 서버에도 적용이 됩니다.

동작 원리는 다소 복잡하지만, DB 차원에서 레플리케이션 관련 대부분의 작업들을 지원하고 있기때문에 호스트 서버, user 등만 커스텀하면 간단하게 적용이 가능합니다. 다만 설계 관점에서 source 와 replica 서버를 어떻게 구성할 것인지에 대해 고민해 보았고, 서비스 특성상 쓰기 연산이 몰리지 않는 점과 추후 확장을 고려하여 한 대의 source 서버와 두 대의 replica 서버로 구성하였습니다.

설정

테스트 환경

레플리케이션 적용 테스트는 도커를 이용하여 포트로 서버를 나누었습니다. 서버 장애를 고려하여 세 대의 서버가 모두 다른 인스턴스에 있는게 가장 이상적이지만, 테스트인 점과 가용 자원을 고려하여 도커로 진행하였습니다.

•

공통

◦

MySQL 8

◦

호스트는 private IP 인 192.168.45.23

◦

동일한 서브넷 네트워크 대역

◦

OS는 Oracle Linux Server 8.6 (저장된 명령어가 거의 없습니다.)

•

source 서버

◦

외부 포트는 13306, 내부 포트는 3306

•

replica 서버

◦

두 대의 서버가 각각 외부 포트 13307, 13308

Source 서버 설정

CREATE DATABASE morak;
SQL
복사

먼저 사용할 DB 를 만들고, replica 에서 복제할 때 필요한 사용자를 만들겠습니다.

CREATE USER 'morak-replication'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'morak-replication'@'%';
SQL
복사

복제용 사용자를 만들고, replica 에서의 복제 권한을 부여했습니다.

일반적으로 사용하던 사용자 생성 명령어와는 다르게 WITH mysql_native_password 가 추가되었는데요, 서버 통신간 보안 연결을 위해 MySQL 5.8 부터 해당 플러그인을 사용하는 인증 방식으로 변경되었다고 합니다. 설정을 해주지 않으면 Last_IO_Error: error connecting to master 'morak-replication@192.168.45.23:13306' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. 다음과 같은 에러가 발생합니다.

사회적 통념상 Master-Slave 라는 단어 사용을 억제하고, MySQL 에서도 변화를 위해 slave 라는 명령어가 deprecated 된 것도 있는데요, 아직 권한 부여 파트에서는 해당 부분을 변경하지 못한 것 같습니다.

이제 /etc/my.cnf 설정 파일에 레플리케이션 관련 설정을 추가하겠습니다.

도커 라이브러리의 MySQL 8 이미지를 사용하는 경우 os 는 “Oracle Linux Server 8.6” 이고, 해당 os 는 vim 명령어가 없습니다. 그래서 설정 파일을 수정하려고 할 때 bash: vi: command not found 에러가 발생하였습니다. 이에 따라 microdnf install vim 으로 명령어를 다운로드한 후 vim 명령어를 사용하였습니다.

[mysqld]
server-id = 1
log-bin = morak-bin
binlog_format = ROW
sync_binlog = 1
binlog_expire_logs_seconds = 259200 
binlog_do_db = morak
Plain Text
복사

•

server-id

◦

같은 토폴로지(네트워크 망)내에서 유일한 값이어야 합니다.

•

log-bin

◦

바이너리 로그 파일명을 지정할 수 있습니다. 만약 지정하지 않는다면 호스트 장비명-bin 형태로 저장됩니다.

•

binlog_format

◦

바이너리 로그에 저장되는 포맷을 지정할 수 있고 STATEMENT, ROW, MIXED 등 세 개의 값을 가질 수 있습니다.

◦

STATEMENT 는 쓰여진 SQL 문을 저장하는 방식이고, 로그의 크기가 상대적으로 작다는 장점이 있습니다.

◦

ROW 는 변경되는 row 데이터를 저장하는 방식이고 데이터 정합성에 있어서 유리합니다. InnoDB 의 기본값입니다.

◦

Mixed 는 STATEMENT 와 ROW 의 장점을 합쳐 데이터 정합성이 요구되는 데이터에는 ROW 방식을, 이외에는 STATEMENT 방식으로 저장합니다. 장점이 많지만, STATEMENT 방식과 ROW 방식이 혼재되어 있어 호환성에 문제가 있을 수 있다고 합니다. (공식 문서-Mixed Binary Logging Format)

•

sync_binlog

◦

기본값인 0 또는 1로 설정될 경우, 매 바이너리 로그 커밋시에 동기화합니다.

•

binlog_expire_logs_seconds

◦

deprecate 된 expire_logs_days 을 대신하여 바이너리 로그 파일 만료 기한을 설정할 수 있습니다.

•

binlog_do_db

◦

레플리케이션을 진행할 데이터베이스를 지정할 수 있습니다.

도커를 재시작한 뒤, source 서버의 bash 로 mysql 에 접속하여 상태를 확인해보겠습니다.

SHOW MASTER STATUS;
SQL
복사

변경 이벤트를 적용할 바이너리 파일인 File 과 변경 지점인 Position 이 잘 적용된 것을 확인할 수 있습니다. 이제 replica 서버에서 나머지 설정을 해보도록 하겠습니다.

Replica 서버 설정

[mysqld]
server-id = 2
Plain Text
복사

replica 서버의 설정 파일에는 크게 적용할 부분은 없고 server-id 만 유일하게 만들어 주었습니다. 이제 mysql 서버에 접속하여 source 서버와의 레플리케이션 연결 설정을 진행하겠습니다.

RESET REPLICA;

CHANGE MASTER TO
MASTER_HOST='192.168.45.23',
MASTER_PORT=13306,
MASTER_USER='morak-replication',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='morak-bin.000003',
MASTER_LOG_POS=157;
SQL
복사

비록 master 네이밍은 남아있지만 연결 명령어 부분에서는 slave 대신 replica 를 사용할 수 있습니다. reset replica 로 설정을 초기화한 뒤 연결에 필요한 설정을 하였습니다.

•

MASTER_HOST, MASTER_PORT

◦

source 서버의 ip 와 mysql 포트입니다.

•

MASTER_USER, MASTER_PASSWORD

◦

source 서버에서 생성한 복제용 사용자 정보입니다.

•

MASTER_LOG_FILE, MASTER_LOG_POS

◦

source 서버에서 master 상태로 확인한 값입니다.

START REPLICA;

SHOW REPLICA STATUS\G;
SQL
복사

START REPLICA; 명령어로 연결을 시작할 수 있습니다. 그리고 아래의 명령어로 replica 서버의 레플리케이션의 상태를 확인해보면!

에러없이 잘 연결된 것을 확인할 수 있습니다.

이 때 레플리케이션 연결을 끊고 싶다면, STOP REPLICA; 명령어로 끊을 수 있습니다.

개선해볼 점

레플리케이션을 적용하여 서버 장애시 가용성을 높이고, 지속적인 동기화로 데이터 손실을 최대한 방지해 보았습니다. 또한 쓰기 서버와 읽기 서버를 나누어 성능 측면도 개선해 보았습니다. 하지만 현재 상태에서 개선할 점도 분명합니다.

Replication Lag

source 서버에 변경된 시점과 replica 서버에 적용된 시점 사이에, 복제 렉으로 알려져있는 데이터 동기화 지연이 있을 수 있습니다. 이러한 지연의 원인으로는 네트워크 지연, 서버 부하, 복제 사이즈와 같은 요인이 있을 수 있습니다. 또한 복제 시 수행되는 replica 서버의 SQL 쓰레드는 싱글 쓰레드입니다. 이로 인해 쓰기 요청이 한번에 많이 들어올 경우 조회 처리까지 해야 하는 replica 서버에 부하가 올 수 있습니다. 이러한 문제들로 인해 지연이 심할 경우 동기화는 비동기 방식으로 처리되기때문에 source 서버에서는 응답이 나간 상태이고, 아직 동기화되지 않은 데이터에 대해 조회 요청이 들어온다면 정합성 문제가 발생할 수 있습니다. 이에 따라 서버 가용률을 확인하고, 복제 사이즈를 적절하게 선택해야 할 것 같습니다.

예외 핸들링

테스트를 하면서도 애를 많이 먹은 부분인데, 예외에 대해 인지하기가 다소 어려웠습니다. 보통 sql 문에서 예외가 발생하면 에러 로그가 나오지만 레플리케이션 연결 시, 또는 복제 시에 발생하는 예외에 대해 status 명령문으로 확인해야만 에러를 인지할 수 있었습니다. 이에 따라 예외가 발생한 것을 모니터링할 수 있는 조치가 반드시 필요해 보입니다.

정합성 문제

아무래도 가장 관심을 갖고 지켜봐야 할 문제가 아닐까 싶습니다. 현재는 매 커밋마다 데이터를 동기화하지만 이 방식은 성능상 한계가 있습니다. 이에 따라 커밋 스케쥴을 변경한다면 앞서 언급한 복제 렉 뿐만 아니라 성능상 문제가 없어도 정합성 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해 MySQL 에서는 Semi-Sync Replication 을 Plug-in 방식으로 지원하여 비동기의 한계를 다소 완화할 수 있습니다. 이외에도 캐시 서버를 이용하여 정합성 문제를 해결하는 방법도 생각해 보았습니다. NPE 를 방지하기 위해, 새로 생성한 데이터에 대해서는 source 서버에서 데이터를 캐시 서버에 푸시하고, 해당 데이터에 대한 조회 요청이 발생한다면 캐시 서버를 먼저 확인하는 방식으로 latency 로 인해 발생하는 정합성 문제를 해결할 수 있을 것 같습니다.

지금까지 레플리케이션에 대한 MySQL 에서의 설정들과 한계점을 살펴 보았고, 다음 포스팅에서는 앱 서버에서의 설정을 알아보도록 하겠습니다.