대규모 시스템 설계를 위한 노트시리즈(2) - 로드밸런서 & DB다중화

yimo22·2023년 1월 18일
0

지난 이야기

앞서 본 설계에서 사용자는 웹 서버에 바로 연결된다. 웹 서버가 다운되면 사용자는 웹 사이트에 접속할 수 없다. 또한 너무 많은 사용자가 접속하여 웹 서버가 한계상황에 도달하게 되면 응답속도가 느려지거나 서버 접속이 불가능해질 수도 있다. 이런 문제를 해결하는 데는 부하 분산기 또는 로드밸런서(Load Balance)를 도입하는 것이 최선이다.


로드밸런서의 사용

로드밸런서는 부하 분산 집합(Load Balancing Set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.

위의 그림에서 처럼, 사용자는 로드밸런서의 공개 IP 주소로 접속한다. (즉, 클라이언트는 웹서버로 직접 접근하지 않는다는 것을 의미한다!) 더 나아가 서버간 통신에는 사설 IP주소(Private IP address) 가 이용될 수도 있다. 사설 IP 주소는 같은 네트워크에 속한 서버 사이의 통신에만 쓰일 수 있는 IP 주소로, 인터넷을 통해서는 접속할 수 없어 보안성이 뛰어나다는 특징을 갖는다. 이때, 로드밸런서는 웹 서버와 통신을 하기 위해 사설주소를 사용한다.

즉, 장애에 대하여 복구할 수 있는 문제를 해소할 수 있으며, 웹 계층의 가용성은 향상된다.

예를 들어, 서버1이 다운되면 모든 트래픽이 서버2로 전송된다. 따라서 웹 사이트의 전체가 다운되는 일을 방지한다. 추가로, 부하를 더욱 낮추기 위해서 새로운 서버를 추가할 수도 있다. 하지만 웹서버의 추가에는 막대한 인적 비용과 경제적 비용이 들기 때문에 트래픽을 고려한 적합한 전략을 세워 서버의 증축을 시행해야한다.

언틋보기에, 웹 서비스계층은 괜찮아 보이는데 데이터 계층에서 지연이 발생한다. 현재 설계안에서는 1개의 DB 서버 뿐이고, 이를 여러대의 WS와 연동되어 있다. 또한 장애의 자동복구나 다중화를 지원하는 구성은 아니다. 데이터 베이스 다중화는 이런 문제를 해결하는 보편적인 기술이다.


DB 다중화

사실 DB 다중화가 무엇인지 정확하게 감이 잡히지 않아 약간의 구글링을 해봤다.
링크텍스트

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

라고 한다. (자세한 내용은 링크 참조)
즉, 쓰기연산은 주 DB서버에서만 (마스터) 처리하며 읽기 연산은 보조 DB서버에서 (Slave) 처리하여 DB의 다중화를 이루겠다는 것이 컨셉이다. 이렇게 write/read 연산을 나누는 이유는 Write 하는 연산이 read 하는 연산보다 훨씬 높은 cost를 요구하기 때문이다.

위의 그림은 DB의 다중화를 구현한 다이어 그램이다.

WebServerSet (복수의 WebServer) 는 master-slave 구조의 DB 중, 부DB 로만 Read 요청을 하며 주DB로는 write 연산만 요청된다.

주 DB와 부DB는 서로 다중화 되어 주기적인 dirty-check를 통한 update를 시행하여 데이터를 처리한다. 위와같은 구조를 통해서 데이터베이스를 다중화하면 아래와 같은 이득이 있다.

  • 더 나은 성능
    Master-Slave 모델에서 모든 데이터 변경 연산은 master 서버에서만 처리하며 데이터의 읽기 연산은 Slave 서버에서만 처리한다. 이로인해 병렬로 처리할 수 있는 query 문이 증가하여 성능이 좋아진다.
  • 안정성
    천재지변 등의 이유로 DB서버 가운데 일부가 파괴되어도 데이터는 보존된다. Master-Slave 의 구조로 인한 여러 DB들을 지리학적 거리(geometric distance)를 두어 다중화 시킬수 있기 떄문이다.
  • 가용성
    데이터를 여러 지역에 복제해 둠으로써, 하나의 DB서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있게 된다.

이런 시스템 설계는 다음의 두 상황을 대처할 수 있다.

  • 부 서버가 1대 뿐인데 다운된 경우, 읽기 연산은 한시적으로 모두 주 DB로 전달되어 처리된다. 또한 즉시 새로운 부 DB가 장애서버를 대처할 수 있다.

  • 주 DB가 장애로 다운된 경우, 한대의 부 DB가 새로운 주 DB가 된다. 이때 모든 DB연산은 일시적으로 새로운 주 서버상에서 수행된다. 그리고 이후에 새로운 부 DB가 추가될 것이다.

    • 사실 부DB가 주DB로 대체되는 과정(Promotion) 은 상당히 복잡하다. 부DB에 저장된 데이터가 최신의 데이터가 아닐 수 있기 떄문이다. 최신이 아닌 Data는 복구 스크립트를 통해서 최신화 해야 한다.
    • 추가로 다중 마스터(Multi-Masters) 나 원형 다중화(Circular Replication) 방식을 도입하면 이런 상황에 대처가 될 수 있다. (하단의 링크 참조)
    • 링크텍스트
    • 링크텍스트

요약

  • 로드밸런서를 사용하면, WebServer의 다중화를 이루어 내어 가용성을 높일 수 있다.
  • DB의 다중화를 사용하여 DB의 성능을 확보하고 장애를 유연하게 대처할 수 있다.
profile
Viva La Vida!

0개의 댓글