반동기 복제가 필요한 이유는 무엇입니까?

안녕하세요 여러분. Vladislav Rodin님이 연락을 주셨습니다. 저는 현재 OTUS에서 소프트웨어 아키텍처 및 고스트레스 소프트웨어 아키텍처 과정을 가르치고 있습니다. 새로운 강의 시작을 기대하며 "고부하 아키텍트" 저는 여러분과 공유하고 싶은 독창적인 자료의 짧은 글을 쓰기로 결정했습니다.

소개

HDD는 초당 약 400~700개의 작업만 수행할 수 있다는 사실(고부하 시스템의 일반적인 rps와 비교할 수 없음)로 인해 기존 디스크 데이터베이스는 아키텍처의 병목 현상이 발생합니다. 따라서 이 스토리지의 확장 패턴에 특별한 주의를 기울여야 합니다.

현재 데이터베이스 확장 패턴에는 복제와 샤딩이라는 2가지 패턴이 있습니다. 샤딩을 사용하면 쓰기 작업을 확장할 수 있으며 결과적으로 클러스터의 서버당 쓰기당 rps를 줄일 수 있습니다. 복제를 사용하면 동일한 작업을 수행할 수 있지만 읽기 작업이 필요합니다. 이 기사에서 다루는 것은 바로 이 패턴입니다.

복제

매우 높은 수준에서 복제를 살펴보면 간단합니다. 서버가 하나 있고 여기에 데이터가 있으면 이 서버는 더 이상 이 데이터를 읽는 로드를 처리할 수 없습니다. 서버를 몇 대 더 추가하고 모든 서버에서 데이터를 동기화하면 사용자는 클러스터의 모든 서버에서 읽을 수 있습니다.

명백한 단순성에도 불구하고 이 체계의 다양한 구현을 분류하기 위한 몇 가지 옵션이 있습니다.

• 클러스터의 역할별(마스터-마스터 또는 마스터-슬레이브)
• 전송된 객체별(행 기반, 명령문 기반 또는 혼합)
• 노드 동기화 메커니즘에 따르면

오늘 우리는 포인트 3을 다룰 것입니다.

트랜잭션 커밋은 어떻게 발생합니까?

이 주제는 복제와 직접적인 관련이 없으므로 별도의 기사를 작성할 수 있지만 트랜잭션 커밋 메커니즘을 이해하지 않고서는 더 읽어도 소용이 없으므로 가장 기본적인 사항을 상기시켜 드리겠습니다. 트랜잭션 커밋은 3단계로 발생합니다.

1. 데이터베이스 로그에 트랜잭션을 기록합니다.
2. 데이터베이스 엔진에서 트랜잭션을 사용합니다.
3. 트랜잭션이 성공적으로 적용되었다는 확인을 클라이언트에 반환합니다.

다른 데이터베이스에서는 이 알고리즘에 미묘한 차이가 있을 수 있습니다. 예를 들어 MySQL 데이터베이스의 InnoDB 엔진에는 2개의 로그가 있습니다. 하나는 복제용(바이너리 로그)이고 다른 하나는 ACID 유지용(실행 취소/다시 실행 로그)이며, PostgreSQL에서는 두 기능을 모두 수행하는 하나의 로그가 있습니다(미리 쓰기 로그 = WAL). 그러나 위에 제시된 것은 그러한 뉘앙스를 고려하지 않는 일반적인 개념입니다.

동기식(동기화) 복제

수신된 변경 사항을 트랜잭션 커밋 알고리즘에 복제하는 논리를 추가해 보겠습니다.

1. 데이터베이스 로그에 트랜잭션을 기록합니다.
2. 데이터베이스 엔진에서 트랜잭션을 사용합니다.
3. 모든 복제본에 데이터를 보내는 중입니다.
4. 모든 복제본으로부터 트랜잭션이 완료되었다는 확인을 받습니다.
5. 트랜잭션이 성공적으로 적용되었다는 확인을 클라이언트에 반환합니다.

이 접근 방식을 사용하면 다음과 같은 여러 가지 단점이 있습니다.

• 클라이언트는 변경 사항이 모든 복제본에 적용될 때까지 기다립니다.
• 클러스터의 노드 수가 증가하면 쓰기 작업이 성공할 가능성이 줄어듭니다.

첫 번째 요점으로 모든 것이 다소 명확하다면 두 번째 요점에 대한 이유를 설명할 가치가 있습니다. 동기 복제 중에 하나 이상의 노드로부터 응답을 받지 못하면 트랜잭션을 롤백합니다. 따라서 클러스터의 노드 수를 늘리면 쓰기 작업이 실패할 가능성이 높아집니다.

예를 들어 51%(정족수)와 같이 특정 비율의 노드에서만 확인을 기다릴 수 있습니까? 예, 가능합니다. 하지만 클래식 버전에서는 모든 노드의 확인이 필요합니다. 이는 클러스터에서 완전한 데이터 일관성을 보장할 수 있는 방법이며, 이는 이러한 복제 유형의 확실한 이점입니다.

비동기(async) 복제

이전 알고리즘을 수정해 보겠습니다. 우리는 "언젠가" 복제본에 데이터를 보내고 "언젠가 나중에" 변경 사항이 복제본에 적용됩니다.

1. 데이터베이스 로그에 트랜잭션을 기록합니다.
2. 데이터베이스 엔진에서 트랜잭션을 사용합니다.
3. 트랜잭션이 성공적으로 적용되었다는 확인을 클라이언트에 반환합니다.
4. 데이터를 복제본으로 보내고 변경 사항을 적용합니다.

이 접근 방식을 사용하면 클라이언트가 데이터가 복제본에 도달하고 커밋될 때까지 기다리지 않기 때문에 클러스터가 빠르게 작동한다는 사실로 이어집니다.

그러나 데이터를 "언젠가 나중에" 복제본에 덤프하는 조건은 트랜잭션 손실로 이어질 수 있으며, 데이터가 복제될 시간이 없었다면 클라이언트에 대한 확인이 이루어지기 때문에 사용자가 확인한 트랜잭션 손실이 발생할 수 있습니다. 작업 성공에 대한 정보가 전송되었고 변경 사항이 도착한 노드가 HDD에 충돌하면 트랜잭션이 손실되어 매우 불쾌한 결과를 초래할 수 있습니다.

반동기식 복제

마지막으로 반동기 복제에 도달합니다. 이러한 유형의 복제는 잘 알려져 있지도 않고 흔하지도 않지만 동기식 복제와 비동기식 복제의 장점을 결합할 수 있기 때문에 상당한 관심을 끌고 있습니다.

이전의 두 가지 접근 방식을 결합해 보겠습니다. 클라이언트를 오랫동안 유지하지는 않지만 데이터를 복제해야 합니다.

1. 데이터베이스 로그에 트랜잭션을 기록합니다.
2. 데이터베이스 엔진에서 트랜잭션을 사용합니다.
3. 복제본으로 데이터를 보내는 중입니다.
4. 변경 사항이 수신되었다는 확인을 복제본으로부터 수신합니다("언젠가" 적용됨).
5. 트랜잭션이 성공적으로 적용되었다는 확인을 클라이언트에 반환합니다.

이 알고리즘을 사용하면 변경 사항을 수신하는 노드와 복제 노드가 모두 실패한 경우에만 트랜잭션 손실이 발생합니다. 그러한 실패 가능성은 낮은 것으로 간주되며 이러한 위험은 허용됩니다.

그러나 이 접근 방식을 사용하면 가상 읽기가 발생할 위험이 있습니다. 다음 시나리오를 상상해 봅시다. 4단계에서 어떤 복제본으로부터도 확인을 받지 못했습니다. 우리는 이 거래를 롤백해야 하며 클라이언트에게 확인 메시지를 반환해서는 안 됩니다. 데이터가 2단계에서 적용되었으므로 2단계 종료와 트랜잭션 롤백 사이에 시간 간격이 있습니다. 이 기간 동안 병렬 트랜잭션은 데이터베이스에 있어서는 안 되는 변경 사항을 볼 수 있습니다.

무손실 반동기화 복제

조금만 생각해 보면 알고리즘의 단계를 반대로 바꾸어 이 시나리오에서 팬텀 읽기 문제를 해결할 수 있습니다.

1. 데이터베이스 로그에 트랜잭션을 기록합니다.
2. 복제본 데이터를 보내는 중입니다.
3. 변경 사항이 수신되었다는 확인을 복제본으로부터 수신합니다("언젠가" 적용됨).
4. 데이터베이스 엔진에서 트랜잭션을 사용합니다.
5. 트랜잭션이 성공적으로 적용되었다는 확인을 클라이언트에 반환합니다.

이제 복제된 경우에만 변경 사항을 커밋합니다.

출력

항상 그렇듯이 이상적인 솔루션은 없으며 각각 고유한 장점과 단점이 있고 다양한 종류의 문제를 해결하는 데 적합한 일련의 솔루션이 있습니다. 이는 복제된 데이터베이스의 데이터를 동기화하기 위한 메커니즘을 선택할 때에도 마찬가지입니다. 반동기 복제의 일련의 장점은 낮은 보급률에도 불구하고 주목할 만한 가치가 있다고 간주될 만큼 충분히 견고하고 흥미롭습니다.

그게 다야. 에서 만나요 강의!

출처 : habr.com