박종훈 기술블로그

사용자 수에 따른 규모 확장성 (2) – 데이터베이스 다중화

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - System Design Interview

1장 사용자 수에 따른 규모 확장성 : 어떻게 수백만 사용자를 지원하는 시스템을 설계할 것인가.


데이터베이스 다중화

많은 데이터베이스 관리 시스템이 다중화를 지원한다.

보통은 서버 사이에 주(master)-부(slave) 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식을 사용한다.

쓰기 연산(write operation)은 마스터에서만 지원한다.
부 데이터베이스는 주 데이터베이스로부터 그 사본을 전달받으며, 읽기 연산(read operation)만을 지원한다.

대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높다. 따라서 일반적으로 부 데이터베이스의 수가 주 데이터베이스의 수보다 많다.

database replication

데이터베이스 다중화의 이점

- 더 나은 성능
모든 데이터 변경 연산은 주 데이터베이스로만 전달되는 반면
읽기 연산은 부 데이터베이스 서버들로 분산된다. 병렬로 처리될 수 있는 질의(query)의 수가 늘어나므로 성능이 좋아진다.

- 안정성
데이터베이스 서버 가운데 일부가 파괴되어도 데이터는 보존될 수 있다.

- 가용성
데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있게 된다.

데이터 베이스 서버 가운데 하나가 다운되면 무슨일이 벌어지는가?

부 서버가 다운되었을 경우

- 부 서버가 한 대 뿐인 경우 : 읽기 연산은 한시적으로 모두 주 데이터베이스로 전달되고 새로운 부 데이터베이스 서버가 장애 서버를 대체

- 부 서버가 여러대인 경우 : 읽기 연산은 나머지 부 데이터베이스 서버들로 분산됨 새로운 부 데이터베이스 서버가 장애 서버를 대체

주 서버가 다운되었을 경우

- 부 서버가 한 대 뿐인 경우 : 부 데이터베이스 서버가 새로운 주 서버가 될 것이며, 모든 연산은 일시적으로 새로운 주 서버상에서 수행된다. 그리고 새로운 부 서버가 추가될 것이다.

- 부 서버가 여러대일 경우 : 부 데이터 서버중 하나가 새로운 주 데이터 서버가 될 것이며, 나머지 부 데이터베이스 서버들은 새로운 주 데이터베이스 서버에서 데이터를 복제하여 적용한다. 그리고 새로운 부 서버가 추가될 것이다.

* production 환경에서는 부 서버에 보관된 데이터가 최신 상태가 아닐 경우도 고려해야 한다. 없는 데이터는 복구 스크립트를 돌려서 추가해야 한다

* 다중 마스터나 원형 다중화 방식을 도입하면 이런 상황에 대처하는데 도움이 된다고 한다. (하지만 복잡도가 올라감. 책에서도 언급만 나와있음)

여기까지의 시스템 구성도

system architecture

이런 구성일 경우 서버 입장에서 각각의 데이터베이스에 대한 접속 정보를 알아야 하는 문제가 있다.

  • 서버가 추가/변경 되었을 경우 해당 정보에 대해서 알려줄 수 있는 방법이 필요, 이로 인해 Database 변경시 애플리케이션 서버 재시작이 필요할 수 있음
  • 필요하다면 Database를 위한 Load Balancer 나 Database Proxy 를 고려해볼 수 있음.