Mysql db replication / spring multi db source config

[ecsimsw]

• Mysql이 제공하는 Replication 방식과 각 장단점
• 프로젝트에서 비동기 복제 방식을 사용한 이유와 정합성 문제 고민
• Mysql 에서 비동기 Statement Based Replication 설정 방법
• Spring 에서 여러 DB source를 정의하고 transaction readOnly 옵션으로 target source 를 분기할 수 있는 설정

[ecsimsw]

DB 데이터 백업과 부하 분산

Mysql db replication

• Mysql 의 복제 방식은 '동기', '비동기', '반동기'가 대표적이다.
• 동기 : 한 노드에 요청된 쿼리를 트랜잭션 내에서 다른 노드들까지 전파.
• 비동기 : 마스터에서 수행된 쿼리나 변경 값을 로그로 저장하고 worker thread에서 전달, Slave에선 이를 기록해두었다가 slave thread에서 반영
• 반동기 : 한 개 이상의 노드에서 전파 성공 시 트랜잭션 커밋, 나머지 노드는 비동기 복제

비동기 복제

• Picup에선 비동기 방식으로 복제한다.
• 프로젝트에선 데이터 정합성이 생기는 경우는 사진을 삭제했는데 여전히 보인다거나 생성했는데 사진이 안보이는 상황이 가장 대표적이다. 이는 새로고침으로 해결되기에 그렇게 심각한 문제가 아니라고 생각했다.
• 그보다 동기식은 DB 처리 속도가 느려지고 트랜잭션의 생명주기가 길어진다. 또 노드 중 하나라도 에러나 다른 상태를 갖게된다면 트랜잭션 전체에 예외가 된다.

• 이런 문제들이 현재로선 비동기식의 정합성 시간 차이보다 더 심각한 문제라고 생각했다.

  비동기 복제의 정합성 문제

1. 읽기 요청 과다 : slave db에 읽기 요청이 워낙 많아 처리 성능 자체가 떨어지고 sync 도 밀리는 경우이다. 이런 경우 slave db 를 scale up 하거나, slave db 자체를 증설하여 요청을 분산 할 수 있겠다.
2. 쓰기 요청 과다 : mater db 의 쓰기량이 워낙 많아 동기화에 문제가 생기는 경우이다. 기본적으로 Msql에선 Sync를 위해 단일 스레드를 사용하는데, Mysql 5.6 부터 추가된 Multi-Threaded Replication Slaves 을 사용해서 복제를 위한 worker 스레드를 증설하는 것이 도움이 된다
3. 너무 느린 Sync : slave db 에서 Sync 를 처리하는 시간 자체가 느린 경우를 말한다. 그 시간 동안 정합성 문제가 생긴다. Row Based Replication 으로 바꿔, Master 노드의 쓰기 쿼리 전부 대신 변경된 Row만 동기화하는 것으로 복제 방식을 변경하여 속도를 비교한다.

트랜잭션 종류에 따라 DataSource 분기

• Slave DB를 읽기 전용을 사용하여 DB 요청을 분산하고, 부하를 낮춘다.
• Transactional의 readOnly 옵션에 따라 사용할 DataSource를 달리한다.
• readOnly 가 true이면, 해당 트랜잭션에선 읽기 전용으로 생각하여 Slave db를, readOnly 가 false이면, Master db를 액세스한다.
• DataSource를 라우팅 방식을 결정하는 AbstractRoutingDataSource에 TransactionSynchronizationManager 를 사용하여 현재 트랜잭션의 readOnly 여부를 확인하는 식으로 구현할 수 있다.

  class RoutingDataSource extends AbstractRoutingDataSource {
  @Override
  protected Object determineCurrentLookupKey() {
      var isReadOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
      if (isReadOnly) {
          return SLAVE;
      }
      return MASTER;
  }
  }

LazyConnectionDataSourceProxy

• Spring은 default 로 Transactional이 시작되는 시점부터 DataSource 를 미리 정해둔다.
• 이런 경우 실제로 쿼리가 발생하지 않는 트랜잭션에서도 커넥션을 필요로 하게 만들고, 실제 쿼리가 필요한 범위보다 앞서 DB 커넥션을 요구하기에 커넥션 점유도 늘어난다.
• LazyConnectionDataSourceProxy 를 사용하면 쿼리가 필요한 시점까지 Connection 요구를 늦출 수 있다. 또 DataSource를 결정하는 routing 방식을 커스텀하여 참조할 커넥션 결정 방식을 정의할 수 있다.

  public DataSource dataSource() {
  var determinedDataSource = new AbstractRoutingDataSource() {
  };
  return new LazyConnectionDataSourceProxy(determinedDataSource);
  }

DataSource와 DB Connection의 관계

• DataSource는 DB Connection 획득 방법을 정의한 인터페이스다.
• 예를 들어 커넥션을 얻는 방법으로 '이미 만들어둔 커넥션에서 사용 중이지 않은 커넥션을 반환한다'는 규칙을 갖도록하면 그게 커넥션 풀이 된다.
• 여러 커넥션 풀을 코드 변경없이, 사용법을 사용하지 않고 사용할 수 있는 것도 이 DataSource 덕분이다.
• 개발자는 그저 DataSource에게 커넥션을 요청하면, 구현체에 정의된 동작 방식으로 커넥션을 얻게된다.

  public interface DataSource  extends CommonDataSource, Wrapper {
  Connection getConnection() throws SQLException;

RDS의 읽기 전용 복제

• AWS RDS의 읽기 전용 복제를 사용하면 동일 리전, 또는 외부 리전에 하나 이상의 RDS 읽기 전용 사본을 만들 수 있다.
• 같은 리전 안에서의 복제 시 네트워크 비용이 발생하지 않지만, 서로 리전이 다른 경우에는 복제를 위한 네트워크 비용이 발생한다.
• 앞선 Picup의 방식처럼 부하 분산과 데이터 백업을 위해 사용할 수도 있고, 리전을 보다 가깝게하여 읽기 성능을 개선할 수도 있을 것이다.
• 쉽게 Master db로 승격할 수 있어, 데이터 마이그레이션에도 사용하기 용이하다.
• 이는 비동기식 복제로 동작한다.

RDS의 다중 AZ 배포

• 기존 RDS 인스턴스와 다른 가용 영역에 RDS 인스턴스를 배포하여 가용성을 높인다.
• 이는 Master-Slave가 아닌, Active-StandBy 형태로 장애 발생 시 Failover로 StandBy 노드가 사용된다.
• StandBy db로의 전환은 DNS를 사용한다. DNS TTL에 따라 장애 발생 시 대응 속도가 달라진다.
• 이는 동기식 복제로 동작한다.

RDS 재난 대비

• 이 둘은 독립적인 배포 방식이 아니다. 2018년부터 읽기 전용 복제와 다중 AZ를 결합하여 사용하는 것을 지원한다.
• 우선 읽기 전용 복제 수를 조절하여 부하 분산 또는 리전을 넓힌다.
• 읽기 전용 복제만으론 결국 Master에 문제 발생 시 서비스 전체의 문제로 발생하게 된다.
• 재난 시 읽기 전용 노드를 승격시켜 새로운 Master db로 사용하는 것으로 풀이할 수 있다.
• 또는 애초에 다중 AZ 배포를 사용하여 StandBy를 만들어 두고, Master db의 헬스 체크에 문제가 발생하는 경우, DNS 질의 시 StandBy를 응답하여 서비스를 이어갈 수 있도록 한다.