데이터베이스 전용 Proxy 인 MaxScale 을 통한 데이터 일관성 읽기

 

 

MaxScale 을 통한 데이터 일관성 읽기 (Slave Lag 를 회피한 읽기 수행)

 

Binlog 읽기를 통한 복제는 과부하시 Slave Lag 현상이 발생할 수 있습니다

이는 Replica 복제서버의 데이터가 최신 데이터를 반영하지 못한채로 읽기가 수행되면서 생기는 불일치 입니다. Mission Critical 한 서비스 그리고 금융과 같이 데이터 값의 일관성이 매우 중요한 시스템에서는 매우 치명적으로 여겨집니다.

 

다음은 일반적인 1 마스터 2 슬레이브 복제 구성입니다. 쓰고서 즉각 읽기가 발생할 때 만약 복제 Lag 가 발생한다면 그리고 해당건 데이터의 쓰기 복제가 Replica2에 반영되지 않은 상태라면 기대하는 올바른 데이터가 아닌 과거의 데이터 값 또는 존재하지 않음으로 결과를 받을 수 있습니다. 즉 은행에 입금 직후 데이터를 읽었는데 아직 덜 반영된 서버에서 읽음으로써 입금액이 반영되지 않은 예금액을 볼 수 있는 개연성이 있다라는 것입니다. Binlog 파일을 쓰고 이를 복제(Asynchronous)해서 반영하는 형태의 아키텍처에서의 한계점이라고 할 수 있습니다.

 

 

 

 

 

[Casual Reads]

이를 위한 기능이 데이터베이스 전용 Proxy 인 MaxScale 에 있습니다. 기본적으로 GTID 로 복제지연이 얼마나 발생하는지를 체크하는데, 이를 통해 Lag 를 인지하고 읽기 트렌잭션을 Lag 가 해소되고 난 후 Replicas 에서 읽거나 아니면 Primary 로 보내 수행하므로써 데이터 일관성을 보장하는 것입니다. 이는 아래에서 설명하는 변수설정 부분을 참고하시면 되겠습니다.

 

MariaDB 는 온라인 문서를 작성하고 유지하고 관리하기 위해 많은 리소스를 쓰고 있습니다. 다만 한국 사용자들에게 영어라는 장벽 때문에 널리 읽혀지지 않는 부분이 있습니다. 여기에서는 좀 더 쉬운 이해를 위해 아래 그림과 원문에서 필요한 부분을 발췌하고 추가 설명을 통해 전달 드리고자 합니다.

 

읽기 / 쓰기 분할 라우터 (readwritesplit)는 하나 이상의 복제본 서버간에 읽기 전용 쿼리의 부하를 분산합니다. 복제 서버가 비동기식 MariaDB 복제를 사용하는 경우 복제(Replica 또는 Slave) 서버의 데이터가 때때로 마스터(Primary) 서버보다 뒤처질 수 있습니다. 이 경우 복제 서버에서 실행되는 읽기 전용 쿼리가 인과적으로 일관된 방식으로 실행되지 않으면 오래된 결과(*원하지 않는 결과 : Primary 는 반영되었으나 Replicas 에는 반영이 완료되지 않은 데이터) 를 사용자에게 반환할 가능성이 있습니다. 인과적 일관성은 상호 의존적인 작업을 모든 서버에서 동일한 순서로 수행하여 일관성을 유지하도록 하는 행위입니다.

 

이를 방지하기 위해 읽기 / 쓰기 분할 라우터를 구성하고 "인과적 읽기"를 활성화하여 읽기 전용 쿼리에 대한 인과적 일관성을 보장 할 수 있습니다. 인과 관계 읽기가 활성화되면 읽기 / 쓰기 분할 라우터는 이전에 주 서버에서 실행된 모든 쓰기 문이 해당 특정 복제본 서버에 완전히 복제되고 적용된 후에 부하 분산된 읽기 전용 쿼리가 복제본 서버에서 실행되도록 합니다.

Source 및 더 많은 내용 보기 :

mariadb.com/docs/solutions/maxscale/routers/readwritesplit/ensure-causal-consistency-maxscale-read-write-split-router/

 

 

 

데이터베이스 전용 Proxy 인 MaxScale 을 사용

 

[필요설정내용]

이는 MaxScale 과 MariaDB Servers(Back-end) 모두에 설정 추가가 필요합니다.

1. MaxScale 설정파일(maxscale.cnf)에서 

[split-router]

type = service

router = readwritesplit

...

causal_reads = local

causal_reads_timeout = 15

 

casual_reads 의 모드는 local / global / fast 가 있으며 서비스의 성격에 따라 읽기 성능과 데이터 일관성 보장하는 수준에서 각각의 장단점이 있으므로 충분히 검토하여 선택하여 사용할 수 있습니다. 

 

local    : 커넥션 단위 데이터 일관성 보장
              casual_reads_timeout 동안 복제서버가 마스터(Primary)로 부터 쓰기복제완료를 기다렸다 읽음

global : 다른 커넥션까지 포함하는 글로벌 일관성보장

              좀 더 넓은 범위의 일관성을 제공하므로 위 local 에 비해서는 추가적인 성능지연이 발생함

fast     : 복제서버들이 마스터(Primary)로 부터 쓰기 복제를 완료하지 못한 경우 마스터(Primary) 에서 바로 읽기를 수행     

              casual_reads_timeout 은 의미 없으며 적용되지 않음 (복제서버가 쓰기복제를 하는 것을 기다리지 않음)

 

2. MariaDB 서버 설정파일(my.cnf)에서

[mariadb]  

...

session_track_system_variables=last_gtid

 

 

다만, 실제 사용시 사전에 부하 테스트를 거쳐서 전후를 비교하여 적용하는 것이 좋습니다. 위 설정은 데이터 읽기 일관성을 보장하지만 반대급부로 마스터(Primary)서버가 더 많은 Workloads 를 처리해야 한다는 것을 의미하기도 합니다. Slave Lag 가 발생하는 것은 여러가지 이유에 의해서 발생할 수 있습니다. 그 중에 주요한 것이 전체 Workloads 증가라면 마스터(Primary)도 그만큼 부하가 증가하는 것이고 이에 더해 SELECT 읽기도 일부분 처리한다는 것을 의미하기에 적용시에는 이러한 시나리오까지도 고려하여 종합적인 판단 후 사용하는 것을 권장합니다. 

calebpro.tistory.com/633