최근 오프 소스 데이터베이스 사용 범위를 늘리고 있는 기업이 늘고 있습니다.
상용 데이터베이스 관련 비용 부담이 가장 큰 이유지만, 오픈 소스 데이터베이스가 이제는 상용 못지않다는 인식의 확산도 주요 배경입니다. 관련해 오픈 소스 데이터베이스 클러스터를 구성할 때 기업들이 신경을 많이 쓰는 부분은 고가용성 보장입니다.
오라클을 왜 쓰십니까? 하면 대부분 RAC(Real Application Cluster)에 대한 신뢰를 보이죠. 이만큼 데이터베이스에 있어 고가용성 보장은 민감합니다.
그렇다면 MySQL, MariaDB 등 두루 널리 쓰이는 데이터베이스 클러스터에 대한 고가용성 구성은 어떻게 할 것인가? 로드밸런싱에 답이 있습니다. 로드밸런서를 쓰는 이유는 고가용성 보장과 성능 극대화 때문입니다. 그렇다면 데이터베이스 클러스터 환경에 적용할 수 있는 로드밸런싱 옵션은 몇 가지나 될까요? 크게 세 가지입니다.
리버스 프록시
SQL 인지 프록시
애플리케이션 커넥터
세 가지 유형 중 어떤 것을 고를지는 기업의 마음입니다. 정확히 말하자면 클러스터 규모, 분산 위치, SLA, 구현 및 운영 역량 등 여러 가지 변수를 고려해 최선의 선택을 해야 합니다.
세 유형은 각각의 장단점이 분명합니다. 리버스 프록시의 경우 구성과 운영이 간단합니다. 패킷 라우팅 측면에서 로드밸런싱을 하므로 데이터베이스 서버에 손을 댈 일이 적습니다. 단점은 포트 기반의 헬스체크만 가능하다는 것입니다.
SQL 인지 프록시는 데이터베이스가 사용하는 프로토콜 수준에서 설정합니다. 따라서 데이터베이스 노드의 상태를 더 정밀하게 파악할 수 있습니다. 단점은 사내에 능력자가 있어야 한다는 것이죠. 아무래도 물리적 L4/L7 스위치를 쓰는 것에 비해 구성과 운영이 복잡합니다. 이는 구성의 간결함 그리고 인접 장비의 설정 최소화를 위해 기업 환경에서 소프트웨어 기반 오픈 소스 프록시 대신 상용 L4/L7 스위치 사용을 고려하는 이유이기도 합니다. 데이터베이스 노드가 물리적으로 여러 지역에 있는 데이터센터와 클라우드 서비스에 분산되어 있으면 복잡성이 더 커지는 것도 머리가 아플 수 있습니다.
애플리케이션 커넥터는 DBA가 접근하기 좋은 방식이 장점인 반면 대형 서비스 환경에서 SLA 보장 등이 어려울 수 있습니다.
이번 포스팅에서는 간단히 데이터베이스 클러스터 로드밸런싱 옵션을 살펴 보았습니다. 다음에 더 자세한 내용을 올려 보겠습니다.
