*단순 요약 번역한 글입니다. *
proxySQL 을 사용하여 고가용성 Mysql 클러스터 설정
공식문서에 정의된것 처럼, ProxySQL 은 mysql과 forks(percona server 및 mariaDB)를 위한
high performance, high availablility, 프로토콜 인식 proxy 입니다. 이름에서 알수 있듯이 ProxySQL 은 백엔드 Mysql 클러스터로 들어오는 트래픽을 프록시 합니다. ProxySQL 은 DBA 를 위해, DBA 에 의해 개발되었으므로 들어오는 트래픽을 proxy 전달에만 국한하지는 않는다. ProxySQL 은 DBA 가 읽기/쓰기 분할, 멀티플랙싱, 쿼리 캐싱 등과 같은 다양한 기능을 통해 일상적인 문제를 쉽게 해결하여 Mysql 클러스터의 high availablility 와 scalability 를 제공할 수 있도록 도와 줍니다.
여기에서 ProxySQL 기능이 MySql 클러스터를 high availablility 로 만드는데 어떻게 도움이 되는지를 알아보겠다. 우리는 주로 아키텍처를 설계하기 위해 주로 ProxySQL 의 주어진 기느에 초점을 맞출 것이다.
- Multiplexing
- Read/Write split
- Load balancing with hostgroup weights
Multiplexing
대용량 트래픽 애플리케이션을 확장하는 경우, mysql의 max connections limits 문제인 경우가 있다. Mysql 의 max connections limits 은 서버의 사용가능 리소스에 의해 결정되므로 조정할 수없다. 조절한다 해도 성능이 저하 될 수 있다.
이문제를 해결하기 위해 애플리케이션 서버와 mysql 서버간의 연결 풀링을 활성화하는 프록시를 도입합니다.
ProxySQL 은 스레드 풀을 사용하여 백엔드 서버에 연결하는 멀티플렉싱 기능을 제공합니다. 따라서 요청이 완료될 때마다 ProxySQL 의 호스트 그룹 관리자는 연결을 다시 사용할 수 있는지 확인합니다. Multiplexing 을 사용하면 수천개의 연결 요청을 수백개의 백엔드 연결로 확장할 수 있습니다.
우리가 ProxySQL 을 도입하면 다음과 같은 모양이 됩니다.
위 아키텍처의 문제
애플케이션이 더많은 트래픽을 제공하기 위해 서버를 확장하기 전까지는 위 아키텍처는 잘 동작할 것입니다. 결국 ProxySQL 리소스 제한에 도달하게 될것이고, 위의 토폴로지에서 새연결이 필요할때마다 네트워크의 ProxySQL 에 연결해야 하므로 각 데이터베이스의 연결에 대한 대기기간은 늘어납니다. ProxySQL 는 서버에 가깝게 유지하는 것이 좋으며, 실제로 로컬로 실행하는 것이 좋습니다. 애플리케이션 서버에서 ProxySQL 를 실행하는 경우 아키텍처는 다음과 유사합니다.
Query Caching
ProxySQL 은 기본적으로 쿼리 캐싱 매커니즘을 제공합니다. 프록시에 쿼리 규칙을 추가하여 캐시할 쿼리 유형과 시간을 알릴 수 있습니다. ProxySQL 은 캐시할 수 있는 쿼리를 더 잘 결정할 수 있도록 많은 통계를 제공합니다. 아래 쿼리를 실행하면 ProxySQL 이 실행한 쿼리 패턴 목록과 쿼리가 실행 된 횟수 및 소요 된 시간의 합계가 제공됩니다.
SELECT count_star, sum_time, hostgroup, digest, digest_text FROM stats_mysql_query_digest_reset ORDER BY sum_time DESC;캐시 할 쿼리가 식별되면 캐시 ttl 을 사용하여 쿼리 규칙을 추가하여 주어진 쿼리 패턴 또는 쿼리 다이제스트에 대한 쿼리 캐싱을 적용할 수 있습니다.
INSERT INTO mysql_query_rules (active, digest, cache_ttl, apply) VALUES (1, '0xE8930CB2CC9E68D7', 2000,1);로컬에서 실행되는 프록시 인스턴스와 쿼리 캐싱을 사용하면 캐시 된 쿼리를 실행하기 위해 백엔드 서버에 연결되지 않고 결과가 메모리 캐시에 반환됩니다.
Why do we need a centralized ProxySQL instance?
로컬에서 각각 네트워크를 연결하게 되면, 해커에게 더많은 허점을 노출하여 보안 위험이 더 높아진다. 적절한 보항느로 구성된 하나의 ProxySQL 인스턴스 위에 모든 백엔드 서버를 유지하는것이 좋으며 로컬에서 실행되는 모든 ProxySQL 인스턴스는 중앙 집중식 프록시 서버에 연결해야 합니다.
중앙 집중식 ProxySQL 인스턴스의 백엔드 서버에서 실행 된 모든 쿼리에 대한 쿼리 통계를 집계했기 때문에 매트릭에도 도움이 됩니다. 또한 중앙 집중식 프록시를 사용하여 백엔드 서버로의 연결을 제한하며 향후 애플리케이션 확장에 도움이 됩니다.
Single Point of Failure!!
중앙집중식 ProxySQL 이 실행되면 아키텍처에 단일 실패지점이 있는 홉이 도입됩니다. 중앙집중식 프록시가 다운되면 전체 애플리케이션이 DB에 연결할 수 없다. 아키텍처에 SPoF 가 있는경우 일반적으로 잘못된 설계로 간주됩니다. 이를 해결하기 위해 Read / Write 분할 기능을 활용할 수 있습니다. ProxySQL 에서 각 밴엔드 서버는 호스트 구룹간에 분류 될 수 있으며 각 그룹에서 트래픽라우팅을 위해 각 백엔드 서버에 가중치를 할당 할 수 있습니다. 이기능을 사용하면 두개의 중앙집중식 ProxySQL 인스턴스를 실행할 수 있습니다.
위의 아키텍처에서 볼수 있듯이 로컬에서 실해되는 모든 ProxySQL 인스턴스는 99% 쓰기 트래픽을 중앙집중식 ProxySQL 인스턴스에 라우팅하도록 구성하고, 1% 쓰기 트래픽을 다른 중앙집중식 ProxySQL 서버에 할당합니다. 이경우 하나가 다운되면 해당 프록시가 차단되도 전체트래픽이 다른 중앙집중식 ProxySQL 인스턴스에 할당됩니다.
Conclusion
ProxySQL 서버 아키텍처의 몇가지 모범사례를 정의했습니다. 소규모 애플리케이션의 경우 이 아키텍처는 과도하지만 트레이드오프를 통해 애플리케이션의 요구에 따라 고유한 디자인을 설계 할 수 있습니다. 매우 높은 로드를 제공하고 높은 SLA 를 가져야 한다면 이상적인 아키텍처로 보입니다.