Database Replication(DBMS)
WAS는 영속화된 데이터의 조회, 수정을 위해 DB를 통해 Disk에 저장된 데이터를 필요로 한다. Memory 상에서 일어나는 Applicaiton 로직에 비해 Disk I/O 작업과 TCP/IP Network 통신을 필요로 하는 DB 접근은 매우 느리다. 따라서 WAS의 성능은 DB와의 Transaction 속도에 의해 결정되는 경우가 많다. 따라서 DB의 성능을 올리면 전체 Backend 서버의 성능을 올릴 수 있다. 이를 위해 DB System의 구조를 다중화하여 요청을 분산하고, Master와 Slaver를 나누어 조회와 수정을 나누어 요청을 분산하면 높은 가용성을 제공하는 서버를 구성할 수 있다.
하나의 DB 서버만 존재하는 경우 DB 서버에 장애가 발생하면 전체 시스템에 장애가 나는 SPOF 문제가 발생한다. DB Replicatoin을 통해 DB를 다중화하여 한 DB에 장애가 발생해도 다른 DB에서 요청을 이어서 처리할 수 있게 한다면 보다 신뢰성있는 서버를 구성할 수 있다.
일반적으로 데이터를 조작(Command)하는 요청을 수행하는 Master DB와 조회(Query) 요청을 수행하는 Slave(Replica) DB를 두어 요청을 분산하여 처리한다. 현재 프로젝트의 규모에서 하나의 Master와 Replica를 두어 구성할 경우 충분한 가용성과 신뢰성을 얻을 수 있을 것으로 판단한다. 그러나 Replica가 1개인 현재 상황에서 모든 조작을 Master, 모든 조회를 Replica로 나눌 경우 Master DB의 경우 현저히 적은 요청을 처리하게 되어 자원이 낭비되며, Replica에 과도한 요청이 주어진다. 따라서 Master와 Replica에 조회 요청을 분산하고 조작 요청을 Master로만 보내는 구성을 하였다.
MySQL에서는 NDB Cluster engine 환경에서만 Synchronous 방식의 replication을 지원한다.
master에서의 transaction은 독립적으로 적용. master에서 dump thread가 변경된 정보를 담은 binlog를 slave로 전송. slave의 IO thread에서 이를 받아 master에 transaction 요청.
slave의 IO thead에는 relay log가 존재한다. relay log는 queue의 일종으로 수행할 요청들을 담아 순차적으로 적용한다.
기본적으로 MySQL에서 적용된 Replication 설정이다.
asynchronous와 유사하나 master가 slave의 relay log에 binlog가 등록되었음을 확인(ACK)한 경우 transaction을 완료한다(모든 slave의 ack을 기다리지는 않고 필요한 개수(설정 가능)의 ack를 받으면 transaction을 종료한다).
MySQL에서는 After sync 방식과 After Commit 방식이 있다.
-
After sync(default)
slave의 ack을 받은 이후 master의 transaction을 commit한다.
slave의 ack를 받지 않으면 master도 commit하지 않기 때문에 데이터의 정합성 문제 상대적으로 After Commit에 비해 발생할 가능성이 작다.
-
After Commit
slave의 ack과 상관 없이 일단 master의 transaction을 commit한다.
- 발생 가능 문제
- slave와 통신에서 문제가 발생하여 ack를 보내지 않아도 master는 commit되어 데이터가 수정되기 때문에 데이터의 정합성 문제가 발생할 수 있다.
- 발생 가능 문제
즉, 수행할 transaction에 관한 정보가 하나 이상의 slave로 정확히 전송되었음을 보장한다. 하지만 실제 동작이 정상적으로 완료되었는지 까지는 보장하지 않는다. slave의 ack을 대기하다가 설정된 timeout이 발생할 경우 Master DB는 계속 asynchronous로 동작한다.
default choice since MySQL 5.7.7, and it has many advantages. The row changes are logged in the binary log, and it does not require context information. This removes the impact of non-deterministic queries.
binary log에 실제 변경된 row에 관한 정보가 기록된다. 쿼리가 slave에서 실행될 필요가 없다.
- 장점
- Performance improvements with high concurrency queries containing few row changes → 쿼리의 결과로 변경된 row 수가 적을 경우 slave에서의 연산이 줄어듦으로 연산 속도 향상
- Significant data-consistency improvement → 이미 실행한 쿼리의 결과를 기록하므로 데이터의 정합성을 지키기 쉽다
- 단점
- Network traffic can be significantly larger if you have queries that modify a large number of rows → 쿼리를 전송하는 게 아니라 변경된 row를 전송하므로 많은 네트워크 트래픽 발생
- It’s more difficult to audit the changes on the database
- Row-based replication can be slower than statement-based replication in some cases → 특정 조건에서는 statement based보다 느릴 수 있다. 예를 들어 변경되는 row가 많거나 slow query인 경우
the SQL query itself is written to the binary log. For example, the exact same INSERT/UPDATE/DELETE statements are executed by the slave.
즉, binary log에 쿼리 자체가 기록되고 이 쿼리가 slave에서 실행된다.
- 장점
- Auditing the database is much easier as the actual statements are logged in the binary log → 쿼리가 slave에서 직접 수행되므로 audit 기록이 상세하게 기록된다. 변경된 row를 전송할 경우는 실제로 어떤 수정 과정에 의해 일어난 결과인지 slave에서는 기록할 수 없다.
- Less data is transferred over the wire → 결과가 아니라 쿼리를 기록하므로 data 전송 양이 작다.
- 단점
- Non-deterministic queries can create actual havoc in the slave environment → slave 측에서 쿼리 결과가 비결정적이다.
- There might be a performance disadvantage, with some queries using statement-based replication (INSERT based on SELECT) → 특정 조건의 경우 master, slave에서 중복으로 실행되면 비효율적인 쿼리가 존재한다.
- Statement-based replication is slower due to SQL optimizing and execution → 쿼리를 직접 실행하므로 SQL 최적화와 실행 과정을 수반하기 때문에 속도가 느리다.
현실적인 대응을 위해서는 Spring Application 단에서는 Master, Slave 두 Url만 등록하고 각 Url 요청이 들어오면 Reverse Proxy를 통해 DB System측에서 적절한 Load balancing과 Fail over가 이뤄져야 할 것이다. Spring Application 단에서 fail over 관련 처리를 하는 것 DB System의 구성을 Application에서 전부 알고 있어야 하며, DB System에서 의도한 바와 다르게 동작할 수 있기 때문에 지양해야 할 것으로 보인다.