PolarDB 아키텍처 세부: Low-latency Replication

이 글에서는 PolarDB 아키텍처 세부: Low-latency Replication에 대해서 설명합니다. 

• Issues of Conventional Streaming Replication
• Optimization Method 1: Replicate Only the Metadata of WAL Records
• Optimization Method 3: Optimize the Log Apply of DDL Locks

Issues of Conventional Streaming Replication

---

 

Shared-nothing 아키텍처의 경우 로그를 복제하는데 많은 네트워크 부하가 걸립니다. 

관련해서 일반적인 Shared-nothing 환경에서 다음과 같이 진행 될 수 있습니다.

• 로그 동기화 링크의 I/O 부하가 많고 대량의 데이터가 네트워크를 통해 전송됩니다.
• 읽기 전용 노드가 I/O 바인딩 워크로드 또는 CPU 바인딩 워크로드를 처리할 때 페이지를 읽고 버퍼 풀의 페이지를 저속으로 수정합니다.
• 파일 및 데이터 관련 DDL 작업이 특정 개체에 대한 잠금을 획득하려고 시도하면 차단 예외가 발생할 수 있습니다. 그 결과 작업이 저속으로 실행됩니다.
• 읽기 전용 노드가 동시성이 높은 쿼리를 처리하는 경우, 트랜잭션 스냅샷이 저속으로 생성됩니다. 다음 그림은 자세한 내용을 보여줍니다.

• 기본 노드는 로컬 파일 시스템에 WAL 레코드를 씁니다.
• 기본 노드의 WAL 송신자 프로세스는 WAL 레코드를 읽고 읽기 전용 노드로 보냅니다.
• 읽기 전용 노드의 WAL 리시버 프로세스는 WAL 레코드를 수신하여 읽기 전용 노드의 로컬 파일 시스템에 씁니다.
• 읽기 전용 노드는 WAL 레코드를 읽고, 업데이트된 페이지를 버퍼 풀에 쓴 다음 메모리에 WAL 레코드를 적용합니다.
• 기본 노드는 WAL 레코드를 공유 스토리지로 플러시합니다.

전체 경로가 길고 읽기 전용 노드의 지연 시간이 길어집니다. 이로 인해 읽기/쓰기 분할 링크를 통한 읽기 부하와 쓰기 부하 간에 불균형이 발생할 수 있습니다.

 

Optimization Method 1: Replicate Only the Metadata of WAL Records

---

읽기 전용 노드는 공유 스토리지에서 WAL 레코드를 읽을 수 있습니다. 따라서 기본 노드는 WAL 레코드의 페이로드를 제거하고 WAL 레코드의 메타데이터만 읽기 전용 노드로 보낼 수 있습니다. 이렇게 하면 네트워크 전송에 대한 부하가 줄어들고 critical path의 I/O 부하가 줄어듭니다. 다음 그림에서 자세한 내용을 확인할 수 있습니다.

 

• 각 WAL 레코드는 헤더, 페이지 ID, 페이로드의 세 부분으로 구성됩니다. 헤더와 페이지 ID는 WAL 레코드의 메타데이터를 구성합니다.
• 기본 노드는 WAL 레코드의 메타데이터만 읽기 전용 노드에 복제합니다.
• 읽기 전용 노드는 WAL 레코드의 메타데이터를 기반으로 공유 스토리지에서 WAL 레코드를 읽습니다.

 

이 최적화 방법은 기본 노드와 읽기 전용 노드 간에 전송해야 하는 데이터의 양을 크게 줄여줍니다. 다음 그림과 같이 전송해야 하는 데이터의 양이 98% 감소합니다.

 

Optimization Method 2: Optimize the Log Apply of WAL Records

---

기존 데이터베이스 시스템은 많은 수의 페이지를 읽고, 이 페이지에 WAL 레코드를 하나씩 적용한 다음, 업데이트된 페이지를 디스크에 플러시해야 합니다. Critical Path의 읽기 I/O 부하를 줄이기 위해 PolarDB는 컴퓨팅-스토리지 분리를 지원합니다. 읽기 전용 노드에서 쿼리하는 페이지가 읽기 전용 노드의 버퍼 풀에 도달할 수 없는 경우, I/O 로드가 생성되지 않고 LogIndex 레코드만 기록됩니다.

로그 적용 프로세스에서 수행되는 다음 I/O 작업은 세션 프로세스로 이전할 수 있습니다:

 

• 데이터 페이지 관련 I/O 작업
• WAL 레코드를 적용하기 위한 I/O 작업
• LogIndex 레코드를 기반으로 여러 버전의 페이지를 적용하기 위한 I/O 작업

 

다음 그림의 예시에서는 읽기 전용 노드의 로그 적용 프로세스가 페이지의 WAL 레코드 메타데이터를 적용하는 경우입니다:

 

• 메모리에서 페이지를 찾을 수 없는 경우, WAL 레코드를 매핑하는 LogIndex 레코드만 기록됩니다.
• 메모리에서 페이지에 도달할 수 있으면 해당 페이지가 오래된 것으로 표시되고 WAL 레코드를 매핑하는 LogIndex 레코드가 기록됩니다. Log Apply 프로세스는 이상으로 완료됩니다.
• 페이지를 읽기 위해 세션 프로세스를 시작하면 세션 프로세스가 페이지의 가장 최신 버전을 읽고 버퍼 풀에 씁니다. 그런 다음 세션 프로세스는 LogIndex 레코드를 매핑하는 WAL 레코드를 적용합니다.
• 주요 I/O 작업은 더 이상 단일 Log Apply 프로세스에서 실행되지 않습니다. 이러한 작업은 여러 사용자 프로세스로 오프로드됩니다.

 

이 최적화 방법은 로그 적용 지연 시간을 크게 줄이고 Amazon Aurora에 비해 로그 적용 속도를 30배까지 향상시킵니다.

 

Optimization Method 3: Optimize the Log Apply of DDL Locks

---

기본 노드가 테이블을 수정하기 위해 DROP TABLE과 같은 DDL 작업을 실행하면 기본 노드는 테이블에 대한 exclusive DDL 잠금을 획득합니다. 

Exclusive DDL 잠금은 WAL 레코드와 함께 읽기 전용 노드로 복제됩니다. 읽기 전용 노드는 WAL 레코드를 적용하여 테이블에 대한 독점 DDL 잠금을 획득합니다. 이렇게 하면 읽기 전용 노드가 테이블을 읽을 때 기본 노드에서 테이블을 삭제할 수 없습니다. 테이블의 복사본은 공유 스토리지에 하나만 저장됩니다.

읽기 전용 노드의 적용 프로세스가 exclusive DDL 잠금을 적용하는 경우, 읽기 전용 노드가 테이블에 대한 exclusive DDL 잠금을 획득하는 데 오랜 시간이 필요할 수 있습니다. 독점 DDL 잠금을 획득하는 작업을 다른 프로세스로 오프로드하여 로그 적용 프로세스의 중요 경로를 최적화할 수 있습니다.

이 최적화 방법은 읽기 전용 노드의 로그 적용 프로세스가 전용 DDL 잠금이 해제될 때까지 기다려야 하는 경우에도 로그 적용 프로세스의 critical path가 차단되지 않도록 보장합니다.

지금까지 소개한 세 가지 최적화 방법을 조합하면 복제 대기 시간을 크게 줄일 수 있으며 다음과 같은 이점이 있습니다:

 

• 읽기/쓰기 분할: 부하가 균형 있게 분산되어 PolarDB가 Oracle RAC에 필적하는 사용자 경험을 제공할 수 있습니다.
• 고가용성: 장애 조치에 필요한 시간이 단축됩니다.
• 안정성: 미래 페이지(Future Page) 수가 최소화되며 페이지 스냅샷을 생성할 필요성이 거의 없습니다.