1. Group Replication Background

MySQL 5.7 레퍼런스 번역 

fault-tolerant system 을 구축하는 가장 쉬운 방법은 여러 여유있는 컴포넌트들을 이용하여 시스템을 구축하는 방식이다. 즉, 다른말로 하면, 컴포넌트 중 특정 한개가 동작하지 못한다 하더라도 전체 시스템을 운영하는데에 문제가 없다는 의미이다. 이것은 전체적으로 차원이 다른 시스템의 구축이기 때문에 높은 수준의 목표가 된다. 구체적으로 말하면, 리플리케이션으로 구성된 DBMS는 한대가 아닌 여러 서버에 대해 유지 보수 관리를 해야 한다. 더 나아가, 여러 서버들을 하나의 시스템으로 구축하여  데이터를 파티셔닝하기 위한 시나리오를 사용하여 네트웍을 통한 데이터 분산 파티셔닝을 해야 한다. 또한, 구축하면서 발생할 수 있는 분산 시스템의 고질적인 문제도 처리해야 한다. 

그래서, 궁극적으로는 여러 서버에 분산된 데이터를 일관되고 간단한게 관리하여 하나의 논리적인 시스템으로 보이게 구성해야 한다. 즉, 여러 서버가 한대의 서버인 것처럼 모든 변경 사항에 대한 데이터가 일관되게 적용되게 구성해야 한다. 이는 가 데이터베이스의 상태가 전환될때에도 마찬가지로 그래야 한다. 또한, 하나 하나의 서버는 물리적으로 분리된 서버로 운영될 수 있어야 한다. 

MySQL Group Replication은 서버 간의 강력한 조정을 통해 분산 상태 머신에 대한 리플리케이션을 가능하게 제공한다. 각각 서버는 동일한 그룹에 속할 때 자동으로 조정된다. 그리고 그룹은 자동으로 Primary 선택을 하게 될 때 한대만 Pirmary 모드로 운영하게 할 수도 있다. 즉, 하나의 서버만 수정 작업을 할 수 있다는 것이다. 좀 더 숙련된 사용자들은 하나의 그룹을 Multi-Primary 모드로 설정하여 사용하게 할 수도 있다. 이 모드는 여러 서버가 동시에 DML 작업을 받아서 처리할 수 있는 모드이다. 물론 이와 같은 모드의 경우 동시성에 대한 문제는 가지고 있다. 

특정 시점에 그룹 내의 모든 서버에 대한 정보를 확인할 수 있는 서비스를 built-in group 멤버쉽 서비스라고 한다. 만약, 하나의 서버가 그룹에서 빠지게 되면, 해당 정보는 바로 수정되어 view를 통해 다른 서버들에 제공된다. 때때로 서버는 이유없이 그룹에서 빠지게 될 수 있는데, 이때는 내부의 장애 감지 시스템이 동작하여 바로 해당 정보를 수정하고, 다른 그룹내의 서버들에게 해당 정보를 전달하게 된다. 위 모든 작업은 자동으로 진행된다. 

트랜잭션을 커밋하려면 그룹내의 서버들 모두가 글로벌 트랜잭션 순서에 따라 커밋하는 것을 동의해야 한다. 트랜잭션을 커밋하거나 롤백하는 것은 각 서버별로 수행되지만, 모든 서버가 동일한 결정을 내려야 한다. 네트워크의 문제 때문에 구성원의 합의 가 쉽게 결정되지 못하게 되면, 문제가 해결될 때 까지 트랜잭션 작업의 종료는 이뤄지지 않는다. 이를 위해 built-in, automatic, split-brain 보호 매커니즘이 존재한다. 

이 모든 것은 내부에서 제공되는 그룹 통신 프로토콜에 의해 제공된다. 프로토콜 내부에는 failure detection 기능, 그룹 멤버쉽 서비스, safe and completely ordered message delivery 서비스가 제공된다. 이 모든 기능들은 데이터가 서버 그룹 전체에 일관되게 유지될 수 있도록 돕는데 그 이유가 있다. 이 기술의 핵심은 Paxos 알고리즘 구현에 있으며, 이것은 그룹 통신 시스템 엔진의 역할을 한다. 

1. Replication Technologies 

MySQL Group Replication에 대해 자세히 설명하기 전에 여기에서는 몇가지 배경 개념과 어떻게 동작하는지에 대해 간략히 소개한다. 이는 그룹 복제에 필요한 것을 이해하고 고전적인 비동기 MySQL 복제와 그룹 복제 사이의 차이점을 이해하는데 도움이 되는 몇가지 정보를 제공한다. 

1.1 Primary-Secondary Replication 

고전적인 MySQL Replication은 단순한 Primary-Secondary 방식의 리플리케이션을 제공한다. 즉, 하나의 마스터 서버와 한 대 이상의 슬레이브 서버를 구성할 수 있게 해주었다. 마스터 서버에서는 트랜잭션을 실행하고 커밋한 후 해당 작업을 로그에 쌓으면 슬레이브 서버에서는 대부분 비동기적인 방식으로 해당 로그를 가져가서 슬레이브 서버에서 재 실행하는 구조로 데이터의 일관성을 맞추었다. 이것은 Shared-nothing 시스템으로 모든 서버는 기본적으로 동일한 데이터의 복제본을 가지고있다. 

Semi-리플리케이션의 경우 위 작업이 반-동기적으로 실행된다. 커밋이 실행될 때, 슬레이브 서버에 해당 로그가 저장되었는지 확인받고, ack를 받아 커밋을 완료하는 구조를 말한다. 이때 모든 슬레이브 서버에서 답을 받지 않고, 어떤 서버든 1대의 서버에서 먼저 오면 바로 완료 된다. 

1.2 Group replication 

Group Replication은 fault-tolerant 시스템을 구축하는데 사용할 수 있는 기술이다. 리플리케이션 그룹은 물리 서버들의 모음이다. 이 물리 서버들은 서로간에 메세지를 주고 받는 형태로 상호 작용을 통해 운영된다. 통신 레벨에서는 메세지 내용과 그 메세지들의 순서에 맞게 전달하는 것을 보장해주는 시스템이 구축되어있다. 이것은 매우 강력한 기능으로 이 기능을 이용하여 성능좋은 시스템을 구축할 수 있다. 

MySQL Group Replication은 이러한 속성과 통신 레이어를 기반으로 구축되어 Multi-Master 시스템을 구축할 수 있게 구성하였다. 본질적으로 Replication 그룹은 여러 서버로 구성되며, 그룹의 각 서버는 트랜잭션을 독립적으로 실행할 수 있다. 하지만, 모든 RW 트랜잭션은 그룹내의 승인이 있어야지만 완료가 가능하다. 읽기 전용의 트랜잭션은 승인을 받을 필요가 없이 바로 종료가 가능하다. 즉, 모든 서버가 동일한 순서로 트랜잭션을 수신하여 실행한다는 것을 의미한다. 이를 통해 Group Replication은 그룹 내에서 일관성을 유지한다. 

하지만, 서로 다른 서버에 동시에 실행되는 트랜잭션 간의 충돌이 발생할 수 있다. 이런 충돌은 인증이라는 프로세스를 통해 검사하여 감지하게 된다. 감지 한 후 먼저 커밋을 시도한 트랜잭션을 실행하고 두번째 커밋을 시도한 트랜잭션을 롤백함으로서 일관성을 유지한다. 

마지막으로 Group replication은 shared-nothing 리플리케이션으로 각 서버는 모두 자체 데이터 복사본을 가지고 있다. 

2. Group Replication Use Cases 

Group Replication을 사용하면 여러 서버에 데이터를 일관되게 관리하여 장애에 문제 없는 시스템을 구축할 수 있다. 즉, 몇몇 서버들이 장애가 발생하여 운영치 못하더래도 전체 서비스 입장에서는 문제가 없다는 것이다. 전체 그룹내에서 서버 장애가 발생하면 장애난 서버를 분리하여 제거할 수 있다는 것이다. 그리고, 해당 내역은 운영중인 그룹내의 다른 서버들에게 상태가 전달된다. 또한, 하나의 서버가 그룹내에 투입될 때도 자동으로 해당 장비가 최신의 데이터를 유지할 수 있도록 복구 절차가 구현되어있다. 즉, 서버에 대한 페일 오버는 필요 없고, 여러 서버에서 동시에 DML이 발생함으로서 특정 서버에 오류가 발생하더라도 작업에는 문제 없게 할 수 있다. 즉, 어떤 상황에서도 DBMS를 계속 사용할 수 있게 구현할 수 있다. 

그룹에 포함된 서버가 문제가 발생하면 DBMS 서비스 내에서는 문제가 되지 않지만, 연결된 클라이언트는 다른 서버로 재연결하거나 해서 장애 조치가 되어야 한다. 이와 같은 작업은 Group Replication 내부에서 처리할만한 일이 아니다. 이것은 커넥터나 로드 밸런서 등 커넥션을 관리하는 미들웨어가 처리해야 하는 일이다. 

2.1 Examples of Use Case Scenarios

다음과 같은 경우에 구성하여 사용할 수 있다. 

-- Elastic Replication 

서버의 수를 동적으로 늘리거나 줄이는 일이 필요한 서비스에 사용할 수 있다. 예를 들어 클라우드 용 데이터베이스 서비스에 사용이 가능하다. 

-- Highly Available Shards 

샤딩은 쓰기 스케일 아웃을 구현하는데 사용되는 고가용성 방법이다. Group Replication을 이용하여 각 샤드가 복제 그룹에 맵핑되는 고 가용성 샤드를 구현할 수 있다. 

-- Alternative to Master-Slave Replication 

2대 이상에서 쓰기를 지원하여 경합 지점을 줄이게 구성할 수 있다. 

-- Autonomic Systems

복제 프로토콜에 내장 된 자동화를 위해 MySQL 그룹 복제를 배포 할 수 있다. 

3. Group Replication Details 

Group Replication 내부에 구현된 서비스들에 대해서 간단히 알아보자. 

3.1 Failure Detection

Group Replication 내부에 어떤 서버가 문제가 있는지 확인하여 감지하는 기능이다. 즉, 해당 서버를 감지하면 어떤 서버가 고장난 것 같은지 의심하여 해당 서버에  대한 정보를 제공하는 분산 서비스이다. 이후에 그룹내에서 해당 서버가 고장난 것에 대해 동의한다는 결론에 도달하면 해당 서버를 그룹에서 제외하는 작업을 진행한다. 

먼저 서버에서 아무런 메세지가 발생하지 않으면 장애가 발생한게 아닌지 의심한다. 특정 기간 동안에 특정 서버로 부터 메세지를 받지 못하는 시간이 초과되면 의심이 시작되는 것이다. 

만약 특정 한대의 서버가 나머지 그룹내의 다른 서버들과 분리되면 특정 한대 서버의 입장에서는 다른 모든 서버가 실패한 것으로 의심한다. 이렇게 되면 다른 서버들과의 합의를 도출할 수 없기 때문에 해당 서버는 결과를 도출하여 완성하지 못한다. 그래서 그룹에서 제외된 서버는 단독으로 로컬 트랜잭션을 실행할 수 없다. 

3.2 Group Membership

MySQL Group Replication은 그룹 멤버쉽 서비스에 의존하여 운영된다. 이것은 플러그인 형태의 내부에 구현되어있다. 그룹 멤버쉽 서비스는 현재 그룹에 참여하는 서버들을 정의하고 온라인 상태 인지도 정의한다. 그리고 해당 정보는 모든 서버에서 view를 통해 확인이 가능하다. 그래서, 그룹 내의 모든 서버들은 해당 그룹의 서버들의 정보를 항상 최신으로 동일하게 제공받는다. 

서버들은 트랜잭션 커밋 여부 뿐 아니라 현재의 서버 상태를 보여주는 view 정보도 동의해야 한다. 그래서, 만약 새 서버가 그룹내에 포함되는데 모두 동의하면 그 때 부터 그룹 자체적으로 해당 서버를 통합하여 view를 변경하게 된다. 또한, 어떤 문제가 발생하여 서버가 그룹내에서 제외가 된다면, 해당 그룹은 동적으로 구성을 재배열 하고 해당 view 정보를 바로 수정한다. 

하지만, 하나의 서버가 자발적으로 그룹에서 제외되고 싶어한다면, 이때는 먼저 동적으로 그룹 정보를 재구성하는 작업을 먼저 진행한다. 이때는 모든 그룹내의 서버들이 변경되는 정보가 view에 투영되어야 하는지 아닌지 동의하는 절차가 진행된다. 하지만, 하나의 서버가 예기치 않게 중지되었다고 감지되어 퇴장되면, 장애 감지 메커니즘에 의해 그룹의 정보를 변경하자는 내용이 제안된다. 이때도 그룹내의 서버들의 동의가 필요하다. 만약 그룹내의 서버들이 합의에 도달할 수 없다면, 시스템은 동적으로 해당 정보를 변경할 수 없기 때문에 split-brain 상황을 막기위한 절차에 들어가게 된다. 

즉, 이것은 관리자의 수동 작업이 필요하다는 것을 의미한다. 

3.3 Fault-tolerance 

MySQL Group Replication은 Paxos 분산 알고리즘을 구현하여 서버 간 분산 조정을 제공합니다. 따라서 어느 정도의 가능한 수에 도달하여 결정을 내리기 위해서는 대다수의 서버가 활성화되어 있어야합니다. 그래서 시스템 자체의 전체 기능을 손상시키지 않으면서 각 서버의 장애를 받아 내기 위해서는 그룹리플리케이션 안에 구성된 서버의 수가 어느정도 되어야 한다. 그 수에 따라 받아 낼 수 있는 장애의 수가 결정된다. 식으로 표현하면 f를 장애를 가진 서버 수라고 하면 전체 서버 수 N = 2 xf +1 대가 되어야 한다. 

즉, 최소 3대가 되어야 한대 서버에 대한 장애를 아무런 문제 없이 받아 낼 수 있는 것이다. 

Group Size	Majority	Instant Failures Tolerated
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3