데이터베이스 레플리케이션 (Database Replication)

복제 지연과 읽기 일관성 문제

비동기 복제에서는 소스와 레플리카 사이에 복제 지연(replication lag)이 존재한다. 평소에는 밀리초 수준이지만, 대량 배치 작업이나 레플리카의 부하에 따라 수 초에서 수 분까지 벌어질 수 있다. 이때 대표적으로 다음 문제가 생긴다.

• 내가 쓴 글이 안 보이는 문제. 사용자가 글을 저장(소스에 쓰기)한 직후 목록을 조회(레플리카에서 읽기)하면 방금 쓴 글이 없는 것처럼 보인다. 자신의 쓰기 읽기(read-your-writes) 일관성이 깨진 것이다.
• 시간이 거꾸로 가는 문제. 지연이 서로 다른 레플리카를 번갈아 읽으면 새 데이터를 봤다가 다시 옛 데이터를 보게 된다. 단조 읽기(monotonic reads)가 깨진 경우다.

대응 방법으로는 쓰기 직후 일정 시간 동안 해당 사용자의 읽기를 소스로 보내는 방법, 세션을 특정 레플리카에 고정하는 방법, 최신성이 중요한 조회(결제 내역, 방금 수정한 프로필 등)는 아예 소스에서 읽도록 라우팅을 나누는 방법이 쓰인다. 어떤 조회가 최신성을 요구하고 어떤 조회가 약간의 지연을 허용하는지 구분하는 것이 설계의 핵심이다.

페일오버

소스에 장애가 나면 레플리카 중 하나를 새 소스로 승격(promotion)하는 페일오버(failover)를 수행한다. 절차는 장애 감지, 가장 최신 데이터를 가진 레플리카 선정, 승격, 애플리케이션과 나머지 레플리카가 새 소스를 바라보도록 전환하는 순서로 진행된다. 단순해 보이지만 함정이 많다.

• 비동기 복제였다면 옛 소스에는 커밋됐지만 레플리카에는 도달하지 못한 트랜잭션이 유실될 수 있다.
• 옛 소스가 죽은 것이 아니라 네트워크만 끊겼던 경우, 복구 후 소스가 두 대가 되는 스플릿 브레인(split brain)이 발생해 데이터가 갈라질 수 있다.
• 장애 감지 타임아웃을 너무 짧게 잡으면 일시적 부하를 장애로 오판해 불필요한 페일오버가 반복된다.

그래서 실무에서는 수동 페일오버를 택하거나, 자동화하더라도 옛 소스를 확실히 격리(fencing)하는 장치를 함께 둔다. 페일오버를 감안하면 레플리카는 읽기 분산 장치이자 동시에 고가용성(High Availability)을 위한 대기 서버인 셈이다.

면접에서 이렇게 물어본다

• 레플리케이션을 도입하는 목적을 읽기 분산과 가용성 관점에서 설명해 보라.
• 동기, 반동기, 비동기 복제의 차이와 각각의 트레이드오프는 무엇인가.
• 사용자가 글을 저장한 직후 목록에 글이 안 보이는 현상의 원인과 해결책을 말해 보라.
• 소스 장애 시 페일오버 과정에서 생길 수 있는 문제를 아는 대로 설명해 보라.
• 레플리케이션으로 해결되지 않는 확장 문제는 무엇이고, 그때는 무엇을 검토해야 하는가.