본문 바로가기
MySQL HA & DR/Group Replication

9.7 Group Replication Performance

by 모모레 2017. 4. 15.

1. Fine Tuning the Group Communication Thread

Group Communication Thread (GCT)는 Group Replication Plugin이 로드되는 동안 루프에서 실행된다. GCT는 그룹 및 플러그인에서 메시지를 수신하고 멤버들의 최소 정족 수 및 실패 감지 관련 작업을 처리하고 일부 활성 메시지를 보내며 서버 / 그룹과 주고받는 트랜잭션을 처리한다. GCT는 대기열에 들어오는 메시지를 기다린다. 메시지가 없으면 GCT가 대기한다. 이 대기 시간을 좀 더 길게 (활성 대기 상태로) 설정하면 실제로 잠자기 상태가 되기 전에 어떤 경우에는 도움이 될 수 있다. 이는 운영 체제가 프로세서에서 GCT를 전환하고 컨텍스트 전환을 수행하기위한 대안이기 때문이다.


GCT가 활성 대기 상태가 되도록 강제하려면 group_replication_poll_spin_loops 옵션을 설정하여 사용하면 된다. GCT 루프는 구성된 메시지 수와 관련이 없으며 다음 메시지의 큐를 실제로 폴링하기 전에 수행합니다.


다음과 같이 설정이 가능하다. 


mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;


2. Message Compression

네트워크 대역폭에 병목 현상이 있다고 판단되는 경우 메시지 압축은 그룹 통신 수준에서 최대 30-40 %의 처리량 향상을 제공 할 수 있다. 이것은 부하가 많은 서버 그룹에서 특히 중요하다.



그룹에 있는 N 명의 참여자 간의 상호 연결의 TCP peer-to-peer 특성으로 인해 보낸 사람은 동일한 양의 데이터를 N 번 전송한다. 또한 바이너리 로그는 높은 압축 비율을 나타낼 수 있다 (위 표 참조). 따라서 압축이 대용량 트랜잭션을 포함하는 작업 부하에 대해 강력한 기능이 된다.


압축은 데이터가 Group Communication Thread로 넘겨지기 전에 Group Communiation Engine 레벨에서 발생하므로 MySQL 사용자 세션 스레드의 컨텍스트 내에서 발생한다. 트랜잭션 페이로드는 그룹에 전송되기 전에 압축되어 수신 될 때 압축 해제 될 수 있니다. 압축은 조건부이며 구성된 임계 값에 따라 다르다. 기본적으로 압축은 사용 가능하다.


또한 그룹의 모든 서버가 함께 작동 할 수 있도록 압축이 활성화되어 있어야한다는 요구 사항은 없다. 구성원은 메시지를 받으면 메시지 봉투가 압축되어 있는지 여부를 확인한다. 필요한 경우 멤버는 상위 계층으로 전달하기 전에 트랜잭션의 압축을 푼다. 


사용 된 압축 알고리즘은 LZ4이다. 압축은 기본적으로 임계 값이 1M Byte로 설정되어 있다. 바이트 단위의 압축 임계 값은 기본값보다 큰 값으로 설정 될 수 있다. 이 경우 임계 값보다 큰 페이로드가있는 트랜잭션만 압축된다. 아래는 압축 임계 값을 설정하는 방법의 예이다.


STOP GROUP_REPLICATION;

SET GLOBAL group_replication_compression_threshold= 2097152;

START GROUP_REPLICATION;


위 예제는 압축 임계 값을 2MB로 설정한 것이다 트랜잭션이 2MB보다 큰 페이로드, 예를 들어, 2MB보다 큰 바이너리 로그 트랜잭션 항목과 같은 복제 메시지를 생성하면 압축된다. 압축을 하지 않게 비활성화 하려면 해당 값을 0으로 설정하면 된다. 


3. Flow Control

Group Replication은 그룹의 대다수 구성원이 트랜잭션을 수신하고 동시에 전송 된 모든 트랜잭션 사이의 상대 순서에 동의 한 후에 만 트랜잭션을 커밋하도록 한다.


이 방법은 그룹에 대한 총 쓰기 수가 그룹의 구성원의 쓰기 용량을 초과하지 않는 경우에 효과적이다. 일부 구성원의 쓰기 처리량이 다른 구성원보다 적을 수 있다.  (특히 작성자보다 적을 경우 해당 구성원은 작성자보다 뒤처질 수 있다).


그룹에 뒤쳐져 있는 일부 회원을 갖는 것은 문제가 될 수 있는데, 특히 그러한 서버에서 읽기가 발생하여 서비스에 제공되면 최신 데이터를 보여주지 못할 수도 있다. 특정 서버가 지연되는 이유에 따라 그룹의 다른 서버들이 느린 서버의 잠재적인 데이터 전송 요청을 수행 할 수 있도록 복제 컨텍스트를 저장해야 할 수도 있다.


그러나 Replication Protocol에는 빠른 구성원과 느린 구성원간에 적용되는 트랜잭션 측면에서 너무 많은 거리를 두지 않는 메커니즘이 있습니다. 이를 흐름 제어 메커니즘이라고합니다. 몇 가지 목표를 다룬다.


1. 서버 간의 버퍼링 및 비동기 해제가 가능한 작은 문제를 만들기에 충분하도록 서버들을 가까이 둔다. 


2. 그룹 내 다른 워크로드 또는 더 많은 쓰기용 서버 투입과 같은 변화 조건에 신속하게 적응할 수 있도록 한다. 


3. 각 회원에게 사용 가능한 쓰기 용량을 공정하게 분배하도록 한다.


4. 리소스를 낭비하지 않도록 엄격하게 필요한 것보다 더 많은 처리량을 줄이지 않도록 한다.


Group Replication의 설계를 고려할 때, 두 가지 작업 큐의 의 작업량을 결정할 수 있습니다. 2가지 큐는 하나는  인증 큐, 또 하나는 Binary Log Applier 큐이다.  이러한 큐 중 하나의 크기가 사용자 정의 임계 값을 초과 할 때마다 작업량을 조절하는 메커니즘이 동작하게 된다. 설정하는 것은 단지 2가지 뿐이다. 하나는 certifier 또는 applier 레벨 아니면 양쪽에서에서 흐름제어를 할지 여부, 두번째는  각 큐의 임계치를 얼마로 할것인지에 대한 값정보. 


흐름 제어 메커니즘은 다음과 같은 두가지 기본 동작 원리에 따라 진행된다. 


1. 모든 구성 서버들의 처리량과 큐 사이즈에 대한 정보를 수집, 이 정보를 가지고 각 서버가 처리할 수 있는 최대 쓰기 처리량을 짐작할 수 있다. 


2. 매 순간마다 모든 구성 서버들이 적정량의 작업을 진행하도록 조절


3.1 Probes and Statistics 


모니터링 메커니즘은 각 구성원이 Work Queue 및 처리량에 대한 정보를 수집하기 위해 일련의 프로브를 배치하도록하여 작동한다. 그런 다음 해당 정보를 그룹에 주기적으로 전파하여 해당 데이터를 다른 구성원과 공유한다.


이러한 프로브는 플러그인 스택 전체에 분산되어 있으며 다음과 같은 메트릭을 설정하고 있다. 


-- certifier queue 크기 

-- replication applier queue 크기

-- 인증된 전체 트랜잭션 갯수 

-- 구성 서버들마다 가지고 있는 값으로 외부에서 실행된 트랜잭션을 적용하는 총 수 

-- 내부에서 실행된 트랜잭션의 총 수 


구성원이 다른 구성원의 통계가 포함 된 메시지를 받으면 마지막 모니터링 기간에 인증, 적용 및 로컬로 실행 된 트랜잭션 수에 대한 추가 메트릭을 계산한다.


모니터링 데이터는 그룹의 다른 구성원 서버들과 주기적으로 공유된다. 모니터링 기간은 다른 구성원이 현재 쓰기 요청을 결정할 수있을만큼 충분히 높아야 한다. 하지만 해당 데이터는 그룹 대역폭에 거의 영향을 미치지 않는다.  정보는 1 초마다 공유되며 이 기간은 두 가지 문제를 해결하기에 충분하다.


3.2 Group Replication Throttling


그룹의 모든 서버에서 수집 된 메트릭을 기반으로 작업량 조절 메커니즘이 시작되어 멤버가 새 트랜잭션을 실행 / 커밋 할 수있는 속도를 제한할지 여부를 결정한다.


따라서 모든 구성원으로부터 얻은 메트릭은 각 구성원의 용량을 계산하는 기준이 된다. 즉, 구성원이 가진 큐 (certification 또는 applier thread)가 큰 경우 새 트랜잭션을 실행할 수있는 용량은 가장 최근에 적용되거나 인증된 항목에 가까울 것이다. 


그룹의 모든 구성원 중 가장 낮은 용량이 그룹의 실제 용량을 결정한다. 그리고, 로컬 트랜잭션 수는 얼마나 많은 구성원이 글을 쓰고 있는지,  사용 가능한 용량을 몇 명의 구성원과 공유해야 하는지에 따라 결정된다. 


즉, 모든 구성원은 사용 가능한 용량, 즉 다음 기간 동안 안전하게 발급 할 수있는 트랜잭션 수를 기반으로 쓰기 할당량을 설정한다. 쓰기 할당량은 certifier 또는 binary log applier의 큐 크기가 사용자 정의 임계 값을 초과하는 경우 제한 메커니즘에 의해 조절된다. 


할당량은 가장 최근 기간에 지연된 트랜잭션 수에 따라 줄어들게 되는데, 일반적으로문제가 발생하면 10% 정도 작업량을 줄인다. 이후에 임계치에 초과하여 큐의 사이즈를 증가시키고자 할 때에도 갑자기 증가하는 것을 막기위해  현재사이즈이 10%로 작업량을 증가시킨다. 


현재  작업량 조절 메커니즘은 할당량 이하의 트랜잭션에 불이익을 주지 않지만 모니터링 기간이 끝날 때까지 트랜잭션을 초과하는 트랜잭션을 지연시킨다. 결과적으로 할당량이 쓰기 요청에 대해 매우 작으면 일부 트랜잭션은 모니터링 기간에 가까운 대기 시간을 가질 수 있다.

'MySQL HA & DR > Group Replication' 카테고리의 다른 글

9.6 bservability  (0) 2017.04.15
9.5 Distributed Recovery  (0) 2017.04.05
9.4 Data Definition Statements  (0) 2017.04.05
9.3 Data Manipulation Statements  (0) 2017.03.29
9.2 The Group  (0) 2017.03.29