개발에 관하여 하고 싶은 이야기 : 파트 2 - 데이터베이스 다중화

파트 1에서는 웹 개발에 기본적으로 알아야 할 사항들과 서버 분산에 대해 다루었다.

파트 2에서는 데이터베이스 다중화를 다루어 보고자 한다.

앞서 설명했든 데이터베이스 다중화는 현대의 클라우드 시대에는 그 의미가 많이 퇴색될 수 있다.

 

데이터베이스 다중화는 프로덕션 레벨에 있는 시스템에는 반드시 필요한 부분이다.

 

데이터베이스 또한 완벽한 솔루션은 아니라서 각종 장애와 사용자 실수에 따른 문제가 필연적이고 시스템은 한번 프로덕션에 진입하면 멈출 수 없기에 다중화는 선택이 아닌 필수다.

필자는 아래와 같이 표현한다.

 

"하나의 시스템이 프로덕션 단계로 진입하여 하루 매출이 10억이라면, 그때부터 시스템은 코드덩어리가 아니라 사람과 같이 피가 흐르게 된다. 어떠한 경우도 멈출 수 없고 죽일 수도 없다."

 

이 지점에 들어간 시스템은 그 의미대로 성공한 시스템이고 시스템 Fail은 용납될 수 없다.

어떠한 경우라도 즉시 복구 될 수 있어야 하고, 장애를 제거하기 위한 막대한 비용을 투자해야 한다.

 

이제 데이터베이스 다중화에 대해 알아보자.

 

위키피디아에는 아래와 같이 정의되어 있다.

"많은 데이터베이스 관리 시스템이 다중화를 지원한다. 보동은 서버 사이에 주(Master)-부(Slave) 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식이다."

 

쓰기 연산은 주 서버만 지원하고 읽기 연산은 부 서버에서만 지원하게 된다.

 

그림은 아래와 같다.

 

 

즉, 모든 데이터는 하나의 DB에 적재되고 데이터의 구분, 또는 스키마에 따라 읽기 DB를 나누어 관리하게 된다.

 

이 부분에서 얻을 수 있는 이득은 아래와 같다.

1. 성능

2. 안정성

3. 가용성

 

이제 사용자는 읽기 연산을 부 서버에서 진행함으로 메인DB에 접속하는 부하를 분산하게 되므로 성능에 상당한 도움이 된다. 만약, 당신이 운영 레벨의 시스템을 한 번이라도 다루어본 적이 있다면 매번 발생하는 Table Lock과 이에 따라 수반되는 성능 저하 및 시스템 다운을 해결하기에 상당한 노력을 기울여야 했을 것이다.

 

필자는 대부분의 회사에서 쓰기-읽기 DB 구성을 사용한 경우를 보지 못 했다. 나름 이름 있는 유수의 기업도 이렇게 작업하지 않는다. 나름의 이유가 있지만 언젠가 이야기 하고, 여기서 이야기하고자 하는 것은 각종 Twick과 마술로 문제를 해결하려고 하지 말라는 것이다. 그런 방식은 단기간에 효과가 있을지 모르지만, 결국 문제의 해결은 구조를 변경하는 것 이외에는 특별한 방법이 없다. 아니라면 하드웨어에 매년 수억 또는 수십억을 써야 할 것이다.

 

 이제 DB는 분산되었고 주 서버가 다운되더라도 읽기 기능은 정상 동작하게 된다. 따라서 사용자가 접속하고 조회하는 부분에서 문제는 없게 된다. 즉, 시스템 다운까지는 막을 수 있으므로 안정성은 향상되었다고 볼 수 있겠다. 반대의 경우 훨씬 더 안정성이 높아졌다고 볼 수 있는데 읽기 DB가 분리되어 있으므로 하나의 읽기 DB가 다운되었더라도 시스템은 정상 작동 할 것이다.

 

마지막으로 위 2가지 모두 가용성을 향상하는 사항이므로 가용성도 향상되었다고 보겠다.

 

단, 한가지 중요한 사항이 있는데, 바로 복제가 실시간으로 이루어지지 않는다는 것이다.

우리가 데이터베이스 복제를 한다는 것은 특정 시점에 DB로그를 부 서버에 전달하여 부 서버에서 주 서버에 발생한 로그를 바탕으로 데이터를 생성하는 과정이 필요하다. 따라서 주 서버의 insert/update/delete에 따라 부 서버의 데이터 또한 갱신되어야 하는 것이다.

 

여기서 한 가지 짚고 넘어가야 할 사항이 있는데, 이러한 DB 다중화가 모든 시스템에 필요하지만 즉시성이 요구되는 시스템, 즉, ERP, CRM, 관리자 시스템 등은 주 서버를 사용하고 부 서버는 백업 용도로만 사용하게 된다.

 

위에서 표현한 시스템은 주로 커머스나 대량 트래픽이 발생하는 예매, 예약 시스템에서 주로 사용하게 된다.

 

내가 구축하고자 하는 시스템의 성향과 비즈니스에 따라 다소 차이가 있음을 인지하자.

 

이제 파트 1에서 설명한 내용과 데이터베이스 다중화가 구현된 시스템의 그림은 아래와 같다.

 

이제 위 그림의 과정을 아래와 같이 설명할 수 있다.

• 사용자는 DNS로부터 로드벨런서의 공개 IP 주소를 받는다.
• 사용자는 해당 IP주소를 사용해 로드밸런서에 접속한다.
• HTTP 요청은 서버 1이나 서버 2로 전달된다.
• 웹 서버는 사용자의 데이터를 부 DB서버에서 읽는다.
• 웹 서버는 데이터 변경 연산은 주 DB서버로 전달한다.

 

지금까지 데이터베이스 다중화에 대해 알아 보았다.

 

현대의 Managed Database, 이름 그대로 완전 관리 데이터베이스는 위 행위를 자동으로 지원해 주고 부하 분산에 대한 처리까지 자동으로 지원해 준다. 물론 개발자의 설정이 필요하지만, 해당 설정에 따라 완전 자동화를 지원해주고 있으므로 구축하고자 하는 시스템이 클라우드를 사용한다면 걱정하거나 고민할 필요가 없다. 단, 클라우드 환경에서 직접 가상머신을 생성하여 DB를 설치하고 운영하다면 여전히 인지해야 할 내용이 되겠다.

 

파트 3에서는 부하를 줄이고 응답성을 높이기 위한 캐시에 대해서 알아보자.

 

그럼 이만.