HA & Failover 와 MaxScale

데이터베이스를 제대로 활용하는 방법에 대한 고민을 접하고 다음의 글이 개발자분들에게 DB 를 선정하고 사용하는 출발점에서 조금이나마 도움이 되는 포스팅을 해 보는 시도중에 하나입니다.

 

"최대한 무중단으로 서비스가 운영되어야 하는데요"

"데이터베이스가 장애가 발생하여 중간에 멈추면 어떡합니까"

"로드밸런서 별도로 두어야 한다고요 ?"

"애플리케이션에서 별도로 셋팅을 하여야 했다고요 ?"

 

MariaDB OLTP 데이터베이스

MariaDB 는 가장 널리 쓰이는 OLTP 성격과 데이터웨어하우스 솔루션과 같은 분석용 OLAP 성격의 데이터베이스가 있습니다. 

OLTP 는 기본적으로 ACID 와 동시성의 문제, 즉 쇼핑몰에서 지금 바로 들어오고 있는 주문요청이나 수많은 상점들에서 카드결제 처리가 일어나는 건을 지연없이 처리해 낼 수 있는 능력에 포커싱이 맞추어져 있습니다. 이러한 처리가 지연되고 늦어진다면 일상생활에서 불편한 점들이 생각보다 많은 곳에서 일어날 것입니다. 아침 지하철에 교통카드를 대고 통과하려는 순간에 띡 소리 이후 항상 5초 이상을 기다리고 서야 통과할 수 있다고 생각하면 피부에 와 닿을 것 입니다. 그래서 이러한 건은 초각을 다투는 성능을 얼마나 잘 처리하느냐 그리고 수많은 개찰구에서 일어나는 건들이 서로의 간섭이 최소화된 상태에서 모두 다 잘 처리해 내는 것이 주요한 포인트가 됩니다. 이러한 성격의 목적에 맞추어져 설계되고 만들어진 데이터베이스 타입이 OLTP 성이라고 생각하시면 쉽습니다. 

 

동시에 같은 데이터를 쓰고 읽고를 처리해야 하는 숙명

이러한 OLTP 는 ACID 에 충실하고 데이터 일관성 등에 문제가 없어야 합니다. 하지만 이를 만족시키기가 그렇게 쉽지만은 않습니다. 위 요건에 충실하면 충실할 수록 많은 개발자나 서비스 기획자들이 원하는 동시접속자 즉 동시성의 문제가 대두되기 때문입니다. 그래서 이는 전통적인 RDB 의 숙명으로 오랜 동안 남아 있습니다.

 

예를 들어 쓰기가 짧은 시간안에 이루어지는 경우가 있고 약간 길게 걸릴 때가 있습니다. 읽기가 쓰기 시작 시점 이전인가 쓰는 동안인가 쓴 직후인가 그리고 더하여 읽기는 쓰기 시작 시점 이전부터 쓰는 동안의 어느시점 동안 지속되거나 그리고 쓰는 동안의 어느시점 부터 읽기 시작하여 중간에 마쳐지는 경우 등, 몇 가지 경우만을 살짝 꼬아서 복잡하게 하면 이게 쉬운 문제가 아니라는 것을 인지할 수 있습니다. 일단 직전 문장이 한번에 읽어지고 이해가 안 되어 다시 또 다시 읽어야만 한다면 뭔가 좀 복잡하구나 느낄 것입니다. 제 설명이 부족한 것일 수도 있으니 굳이 이해하려 하지 마시고 일단 지금은 지나치셔도 된답니다. 나중에 기회가 되면 다른 글로 내용을 담아 볼 수 있도록 하겠습니다. 

 

 

전통적인 쓰기의 한계 그리고 MaxScale 의 ReadScale 시도

바로 위의 문제로 인해 전통적인 RDB 의 제약요소가 되는데, 여튼 저 복잡한 걸 그래도 네트워크를 건너 뛰며 여러대의 DB 로 쉽게 구성하지 못하고, 결국은 하나의 DB 서버에서만 쓰기가 가능한 형태가 됩니다. 이를 우회하기 위한 몇몇 방법과 솔루션이 시도되었지만 완벽하지는 않고 제각기 나름대로의 취약점을 갖고 있습니다. 바로 이 제약요소로 인해 쓰기는 DB 서버 한대의 capacity 에 제약되는 경우가 많았습니다. 그런 와중에 쓰기를 확장할 수 없는 상황에서, 읽기를 적당히 확장하려는 시도가 계속되어져 왔지요. 그런 시도중에 하나가 MariaDB 가 많은 리소스를 들여 개발해 오고 개선해 오고 있는 "데이터베이스 운용에 필요한 기능들이 탑재된 데이터베이스 전용 프록시" 인 MaxScale 입니다. 이 MaxScale 에서 가장 근본적이고 중요한 몇가지 기능을 쉽게 풀어 설명해 보고자 합니다.

 

 

데이터베이스 전용 프록시인 MaxSacle 이름은

서비스를 운영할 때 앞단에는 많은 애플리케이션 서버들이 있는 경우가 많습니다. 이 애플리케이션 서버들과 데이터베이스 서버와의 중간에 마리아디비의 데이터베이스 전용 프록시인 MaxScale 이 있습니다. 참고로 마리아디비의 마리아(Maria)라는 이름은 마리아디비를 만든 몬티의 딸의 이름입니다. 그럼 Max 에 대한 궁금증도 있을 수 있겠습니다. 네 Max 라는 이름은 몬티의 아들 이름입니다. 아들 이름 Max 에 Scale 을 붙혔습니다. 네 확장이 가능한 그림을 그려 가는데 MaxScale 이 사용됩니다. 이 MaxScale 이 없다면 중요한 몇가지를 하기가 매우 어렵게 됩니다. 그것이 데이터베이스 전용 프록시인 MaxScale 이 주는 Benefit 입니다. 

 

 

1 Primary and 2 Replicas with MaxScale

부족한 그림 실력이지만, 때로는 수많은 말보다 아웃라인을 잘 담아낸 그림 한장이 전달력이 좋을 때가 있습니다. 특히나 아키텍처나 구성을 이야기할 때는 더욱 더 그런 것 같습니다. 아래는 거의 기본 구성으로 가고 있는 1 Primary and 2 Replicas 구성입니다. 

 

https://calebpro.tistory.com/627

자 여기서부터 위 그림 DB 서버 상단에 위치한 MaxScale 의 주요 기능입니다.

 

 

 - Scale / Load Balancing
이는 Read Scale 을 말 합니다. 일반적으로 쓰이고 있는 마리아디비는 Primary 서버만이 Write 가 가능합니다. Read Replica 를 계속 추가하여 Read 를 확장할 수 있습니다. 그렇다고 Read Replica 만 추가한다고 애플리케이션에서 바로 Read 를 Replica 로 할 수 있는 것이 아닙니다. 추가적인 설정이나 애플리케이션레벨에서의 추가적인 설정이 필요합니다. 복잡성이 많이 더해지지요. 이를 위해 MaxScale 을 사용합니다. 그러면 MaxScale 이 Read Scale 을 담당해 내 줍니다. 즉, 여러대의 Read Replica 에 골고루 Read 요청을 분산시켜 줄 수 있게 되는 것입니다. 애플리케이션 또는 추가적인 로드밸런서 등의 머리 아픈 설정을 건너 너 뛸 수 있습니다. 

 

 

- ReadWriteSplit
네 이는 MaxScale 이 Write 를 할 수 있는 Primary 서버와 Read 가능한 여러 Replica 서버들이 있을 때 어플리케이션들에서 들어오는 다양한 요청을 잘 간파하여, Write 요청은 Primary 로 보내고 Read 는 Read Replica 들로 골고루 분산시켜 주는 기능입니다. 어플리케이션 입장에서는 Write 는 Primary 를 향해 그리고 Read 는 Read Replica 들을 향하도록 별도 설정을 할 필요가 없다는 것을 의미합니다. 개발하는 입장에서 편리해 지는 것입니다.  

 

 

- HA (High Availability)

  이 를 위해 MaxScale 은 모든 데이터베이스 서버들을 모니터링 합니다. 특정서버에 장애가 생기는지를 계속적으로 체크하여 적시에 필요한 조치를 취하기 위합니다.

 

 

- Automatic-Failover

   Primary 서버가 심정지가 되어 더 이상 작동하지 않을 때 서비스가 중단됩니다. 유일하게 쓰기가 가능한 Primary 서버에 문제가 생겼을 때 가장 난감합니다. 이 때 이 상황이 모니터링 중에 감지되면 Read Replica 중 가장 유력한 후보를 하나 선정하여 쓰기가 가능한 Primary 로 삼습니다. 이러면 Read 만 가능하던 Replica 가 Write 가 가능한 Primary 역할을 시작합니다. 네 서비스가 계속 가능한 상태가 됩니다.

 

 

- Rejoin 입니다. 

  Primary 서버가 장애가 발생하여 다른 Read Replica 가 Primary 역할을 가져갔습니다. 시간이 지나 장애가 발생한 서버가 정상적으로 작동할 수 있게 된 경우 이를 Read Replica 의 하나로 구성하는 것입니다. 

 

 

 

위 Primary 와 Replica 간의 복제 방식은 추후에 별도의 주제로 나누어 세밀하게 다뤄 보도록 하겠습니다. 

- MariaDB SkySQL  MaxScale -