MySQL의 로드 밸런싱이란 무엇입니까?-MySQL 튜토리얼-php.cn

MySQL에서 로드 밸런싱은 데이터베이스 쿼리 요청을 할당하여 데이터베이스 시스템 성능을 향상시키는 목적을 달성하기 위해 여러 MySQL 서버를 클러스터로 구성하는 것을 의미합니다. MySQL 로드 밸런싱은 단일 데이터베이스가 많은 수의 요청을 처리할 때 병목 현상 문제를 해결하는 동시에 여러 서버에 요청을 균등하게 분산하여 데이터베이스 시스템의 성능을 향상시키는 목적을 달성합니다. 데이터베이스 시스템의 가용성을 향상시킵니다. 서버 중 하나가 실패하면 다른 서버가 계속해서 요청을 처리할 수 있으므로 서비스 연속성이 보장됩니다.

MySQL의 로드 밸런싱이란 무엇입니까?

이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.

MySQL 로드 밸런싱이란 무엇입니까?

MySQL 로드 밸런싱은 여러 MySQL 서버를 클러스터로 구성하고 데이터베이스 쿼리 요청을 할당하여 데이터베이스 시스템의 성능을 향상시키는 것을 의미합니다. 로드 밸런싱은 고가용성, 확장성 및 로드 밸런싱을 가능하게 합니다.

로드 밸런싱의 기본 아이디어는 간단합니다. 서버 클러스터에서 로드를 최대한 평균화하는 것입니다. 이 아이디어를 바탕으로 우리의 일반적인 접근 방식은 서버 프런트 엔드에 로드 밸런서를 설정하는 것입니다. 로드 밸런서의 역할은 요청된 연결을 가장 유휴 상태인 사용 가능한 서버로 라우팅하는 것입니다.

그림 1은 대규모 웹사이트 로드 밸런싱 설정을 보여줍니다. 하나는 HTTP 트래픽을 담당하고 다른 하나는 MySQL 액세스를 담당합니다.

图 1 典型的读密集型网站负载均衡架构

MySQL 로드 밸런싱이 필요한 이유는 무엇입니까?

MySQL 로드 밸런싱은 단일 데이터베이스가 많은 양의 요청을 처리할 때 병목 현상을 해결하는 것입니다. 요청을 여러 서버에 균등하게 분배함으로써 데이터베이스 시스템의 성능을 향상시킬 수 있습니다. 동시에 로드 밸런싱은 데이터베이스 시스템의 가용성을 향상시킬 수 있으며, 서버 중 하나에 장애가 발생하면 다른 서버가 계속해서 요청을 처리하여 서비스 연속성을 보장할 수 있습니다.

로드 밸런싱에는 5가지 공통 목적이 있습니다:

확장성. 로드 밸런싱은 읽기와 쓰기가 분리될 때 대기 데이터베이스에서 데이터를 읽는 것과 같은 특정 확장에 유용합니다.
효율성. 로드 밸런싱은 요청이 라우팅되는 위치를 제어할 수 있어 리소스를 보다 효율적으로 사용하는 데 도움이 됩니다.
가용성. 유연한 로드 밸런싱 솔루션은 서비스 가용성을 크게 향상시킬 수 있습니다.
투명성. 클라이언트는 로드 밸런서가 존재하는지 알 필요가 없으며 로드 밸런서 뒤에 있는 머신 수도 알 필요가 없습니다. 클라이언트에게 제공되는 것은 투명한 서버입니다.
일관성. 애플리케이션이 상태 저장(데이터베이스 트랜잭션, 웹 사이트 세션 등)인 경우 로드 밸런서는 상태 손실을 방지하기 위해 관련 쿼리를 동일한 서버로 지정할 수 있습니다.

MySQL 로드 밸런싱 구현 방법

로드 밸런싱 구현에는 일반적으로 직접 연결과 미들웨어 도입의 두 가지 방법이 있습니다.

1 직접 연결

어떤 사람들은 로드 밸런싱이 애플리케이션과 MySQL 서버 사이에 직접 구성하는 것이라고 생각하지만 실제로 이것이 유일한 로드 밸런싱 방법은 아닙니다. 다음으로 일반적인 애플리케이션 직접 연결 방법 및 관련 주의 사항에 대해 설명합니다.

1.1 복제된 읽기-쓰기 분리

이 방법에서는 가장 큰 문제 중 하나인 더티 데이터가 발생하기 쉽습니다. 일반적인 예는 사용자가 블로그 게시물에 댓글을 달고 페이지를 다시 로드했지만 새 댓글이 표시되지 않는 경우입니다.

물론 더티 데이터 문제 때문에 읽기-쓰기 분리를 버릴 수는 없습니다. 실제로 많은 애플리케이션의 경우 더티 데이터에 대한 허용치가 상대적으로 높을 수 있으며, 이 방법은 이번에 과감하게 도입될 수 있습니다.

더티 데이터에 대한 내성이 낮은 애플리케이션의 경우 읽기와 쓰기를 어떻게 분리해야 할까요? 다음에는 읽기와 쓰기 분리를 더욱 차별화해 보겠습니다. 언제든지 자신에게 맞는 전략을 찾을 수 있을 거라 믿습니다.

1) 쿼리 분리 기반

어플리케이션에 더티 데이터를 허용할 수 없는 소수의 데이터만 있는 경우 더티 데이터를 허용할 수 없는 모든 읽기 및 쓰기를 마스터에 할당할 수 있습니다. 다른 읽기 쿼리는 슬레이브에 할당됩니다. 이 전략은 구현하기 쉽지만 더티 데이터를 허용하는 쿼리가 거의 없으면 대기 데이터베이스를 효과적으로 사용하지 못할 가능성이 높습니다.

2) 더티 데이터 기반 분리

이는 쿼리 기반 분리 전략이 약간 개선된 것입니다. 대기 데이터가 최신인지 확인하기 위해 애플리케이션에서 복제 대기 시간을 확인하는 등 일부 추가 작업이 필요합니다. 많은 보고 애플리케이션이 이 전략을 사용할 수 있습니다. 야간에 로드된 데이터를 대기 데이터베이스 인터페이스에 복사하기만 하면 되며 기본 데이터베이스를 완전히 따라잡았는지 여부는 신경 쓰지 않습니다.

3) 세션 분리 기반

이 전략은 더티 데이터 분리 전략보다 더 깊습니다. 사용자가 데이터를 수정했는지 여부를 확인합니다. 사용자는 다른 사용자의 최신 데이터를 볼 필요가 없으며 자신의 업데이트만 볼 수 있습니다.

구체적으로, 사용자가 업데이트를 했는지 여부를 나타내기 위해 세션 레이어에 플래그 비트를 설정할 수 있습니다. 일단 사용자가 업데이트를 하면 사용자의 쿼리는 일정 기간 동안 기본 데이터베이스로 전달됩니다.

이 전략은 단순성과 효율성 사이의 적절한 절충안으로 더욱 권장되는 전략입니다.

물론, 충분히 생각한다면 세션 기반 분리 전략과 복제 지연 모니터링 전략을 결합할 수 있습니다. 사용자가 10초 전에 데이터를 업데이트했고, 대기 데이터베이스의 지연이 모두 5초 이내인 경우, 대기 데이터베이스에서 데이터를 대담하게 읽을 수 있습니다. 전체 세션에 대해 동일한 대기 데이터베이스를 선택해야 한다는 점에 유의해야 합니다. 그렇지 않으면 여러 대기 데이터베이스의 지연이 일관되지 않으면 사용자에게 문제가 발생할 수 있습니다.

4) 글로벌 버전/세션 분리 기준

메인 데이터베이스의 로그 좌표를 기록하고 대기 데이터베이스의 복사된 좌표와 비교하여 대기 데이터베이스의 데이터 업데이트 여부를 확인합니다. 애플리케이션이 쓰기 작업을 지시하면 트랜잭션을 커밋한 후 SHOW MASTER STATUS 작업을 수행한 다음 마스터 로그 좌표를 수정된 개체 또는 세션의 버전 번호로 캐시에 저장합니다. 애플리케이션이 대기 데이터베이스에 연결되면 SHOW SLAVE STATUS를 실행하고 대기 데이터베이스의 좌표를 캐시의 버전 번호와 비교합니다. 대기 데이터베이스가 기본 데이터베이스 기록 지점보다 최신인 경우 대기 데이터베이스가 해당 데이터를 업데이트했으며 안심하고 사용할 수 있음을 의미합니다.

실제로 많은 읽기-쓰기 분리 전략에서는 읽기 쿼리 할당을 결정하기 위해 복제 지연 시간 모니터링이 필요합니다. 그러나 SHOW SLAVE STATUS로 얻은 Seconds_behind_master 컬럼의 값은 지연을 정확하게 나타내지 않는다는 점에 유의해야 한다. Percona Toolkit의 pt-heartbeat 도구를 사용하여 대기 시간을 더 잘 모니터링할 수 있습니다.

1.2 DNS 이름 수정

일부 간단한 애플리케이션의 경우 다양한 목적으로 DNS를 생성할 수 있습니다. 가장 간단한 방법은 읽기 전용 서버(read.mysql-db.com)에 대한 DNS 이름 하나와 쓰기 작업을 담당하는 서버(write.mysql-db.com)에 대한 다른 DNS 이름을 갖는 것입니다. 대기 데이터베이스가 기본 데이터베이스를 따라갈 수 있는 경우 읽기 전용 DNS 이름이 대기 데이터베이스를 가리키고, 그렇지 않으면 기본 데이터베이스를 가리킵니다.

이 전략은 구현하기가 매우 쉽지만 DNS를 완전히 제어할 수 없다는 큰 문제가 있습니다.

DNS 변경은 즉시 적용되지 않으며 원자성도 아닙니다. DNS 변경 사항이 네트워크 전체 또는 네트워크 간에 전파되는 데 오랜 시간이 걸립니다.
DNS 데이터는 여러 곳에 캐시되며, 만료 시간은 필수가 아닌 권장 사항입니다.
수정된 DNS가 완전히 적용되려면 애플리케이션이나 서버를 다시 시작해야 할 수도 있습니다.

이 전략은 더 위험합니다. /etc/hosts 파일을 수정하여 DNS를 완전히 제어할 수 없는 문제를 피할 수 있더라도 여전히 이상적인 전략입니다.

1.3 IP 주소 전송

서버 간에 가상 주소를 전송하여 로드 밸런싱을 달성합니다. DNS를 수정하는 것과 비슷한 느낌인가요? 그러나 실제로는 완전히 다른 것입니다. IP 주소를 전송하면 DNS 이름이 변경되지 않은 상태로 유지됩니다. ARP 명령을 통해 IP 주소 변경이 로컬 네트워크에 신속하고 자동으로 통보되도록 할 수 있습니다(ARP에 대해서는 여기 참조).

보다 편리한 기술은 각 물리적 서버에 고정 IP 주소를 할당하는 것입니다. 이 IP 주소는 서버에 고정되어 있으며 절대 변경되지 않습니다. 그런 다음 각 논리적 "서비스"(컨테이너로 이해될 수 있음)에 대해 가상 IP 주소를 사용할 수 있습니다.

이렇게 하면 애플리케이션을 재구성하지 않고도 서버 간에 IP를 쉽게 전송할 수 있고 구현도 더 쉬워집니다.

2 미들웨어 소개

위 전략에서는 애플리케이션이 MySQL 서버에 연결되어 있다고 가정하지만 많은 로드 밸런싱에서는 네트워크 통신을 위한 프록시로 미들웨어를 도입합니다. 한쪽에서는 모든 통신을 수락하고 이러한 요청을 다른 쪽의 지정된 서버에 배포한 다음 실행 결과를 요청하는 시스템으로 다시 보냅니다. 그림 2는 이 아키텍처를 보여줍니다.
图 1：作为中间件的负载均衡器

2.1 로드 밸런서

로드 밸런싱 하드웨어와 소프트웨어는 많지만 MySQL 서버용으로 특별히 설계된 것은 거의 없습니다. 웹 서버는 일반적으로 로드 밸런싱이 더 잘 되어 있으므로 많은 범용 로드 밸런싱 장치는 HTTP를 지원하며 다른 용도로는 몇 가지 기본 기능만 갖습니다.

MySQL 연결은 일반적인 TCP/IP 연결이므로 MySQL에서 다목적 로드 밸런서를 사용할 수 있습니다. 그러나 MySQL 관련 기능이 부족하기 때문에 몇 가지 추가 제한 사항이 있습니다.

요청을 분산하면 로드 밸런싱이 제대로 이루어지지 않을 수 있습니다.
MySQL 세션에 대한 지원이 충분하지 않아 단일 HTTP 세션에서 MySQL 서버로 전송된 모든 연결 요청을 "수정"하는 방법을 모를 수 있습니다.
연결 풀링 및 장기 연결로 인해 로드 밸런서가 연결 요청을 배포하지 못할 수 있습니다.
MySQL 서버에서 상태 및 로드 검사를 제대로 수행할 수 없습니다.

2.2 로드 밸런싱 알고리즘

다음 연결을 수락하는 서버를 결정하는 데 사용되는 많은 알고리즘이 있습니다. 각 제조업체마다 고유한 알고리즘이 있으며 다음과 같은 일반적인 방법이 있습니다:

무작위 할당. 요청을 처리하기 위해 사용 가능한 서버 풀에서 서버가 무작위로 선택됩니다.
폴링. A, B, C, A, B, C와 같이 라운드 로빈 순서로 서버에 요청을 보냅니다.
해시. 연결의 소스 IP 주소는 해시되어 풀의 동일한 서버에 매핑됩니다.
가장 빠른 응답. 요청을 가장 빠르게 처리할 수 있는 서버에 연결을 할당합니다.
최소 연결 수. 활성 연결이 가장 적은 서버에 연결을 할당합니다.
무게. 고성능 기계가 더 많은 연결을 처리할 수 있도록 기계 성능 및 기타 조건에 따라 기계마다 다른 가중치가 구성됩니다.

위의 방법 중 가장 좋은 방법은 없으며 특정 작업 부하에 따라 가장 적합한 방법만 있습니다.

또한 즉시 처리를 위한 알고리즘만 설명합니다. 그러나 때로는 대기열 알고리즘을 사용하는 것이 더 효율적일 수도 있습니다. 예를 들어, 알고리즘은 주어진 데이터베이스 서버 동시성을 유지하여 한 번에 N개 이하의 활성 트랜잭션을 허용할 수 있습니다. 활성 트랜잭션이 너무 많으면 새 요청이 대기열에 추가되고 사용 가능한 서버 목록에서 이를 처리하게 됩니다.

2.3 하나의 기본 룸과 여러 백업 룸 간의 로드 밸런싱

가장 일반적인 복제 구조는 하나의 기본 데이터베이스와 여러 개의 대기 데이터베이스를 더한 것입니다. 이 아키텍처는 확장성이 좋지 않지만 몇 가지 방법을 통해 로드 밸런싱과 결합하여 더 나은 결과를 얻을 수 있습니다.

함수 파티션. 보고, 분석, 데이터 웨어하우징 및 전체 텍스트 인덱싱을 포함한 벤더 기능의 경우 단일 기능의 용량을 확장하기 위해 대기 데이터베이스 하나 또는 그룹을 구성하십시오.
대기 데이터베이스가 기본 데이터베이스와 일치하는지 확인하세요. 백업의 문제는 더러운 데이터입니다. 이를 위해 MASTER_POS_WAIT() 함수를 사용하여 대기 라이브러리가 메인 라이브러리에 설정된 동기화 지점을 따라잡을 때까지 메인 라이브러리의 작업을 차단할 수 있습니다. 또는 복제 하트비트를 사용하여 대기 시간을 확인할 수 있습니다.

우리는 애플리케이션 초기부터 알리바바 같은 아키텍처를 만들 생각을 할 수도 없고 해서도 안 됩니다. 가장 좋은 방법은 현재 애플리케이션에 분명히 필요한 것을 구현하고 빠른 성장을 위해 미리 계획을 세우는 것입니다.

또한 10K 또는 100K 동시성을 충족하는 성능에 대한 정확한 목표가 있는 것처럼 확장성에 대한 숫자 목표를 갖는 것이 합리적입니다. 이를 통해 관련 이론을 통해 애플리케이션에 직렬화 또는 상호 운용성과 같은 오버헤드 문제가 발생하는 것을 방지할 수 있습니다.

MySQL 확장 전략 측면에서 일반적인 애플리케이션이 매우 큰 크기로 성장하면 일반적으로 먼저 단일 서버에서 대기 데이터베이스가 있는 확장 아키텍처로 이동한 다음 데이터 샤딩 또는 기능적 파티셔닝으로 이동합니다. 여기서 우리는 "가능한 한 빨리 샤딩, 최대한 많이 샤딩"과 같은 조언을 옹호하지 않는다는 점에 유의해야 합니다. 실제로 샤딩은 복잡하고 비용이 많이 들며, 가장 중요한 것은 많은 애플리케이션에 샤딩이 전혀 필요하지 않을 수 있다는 것입니다. 샤딩에 많은 돈을 쓰기보다는 새로운 하드웨어와 새로운 MySQL 버전의 변화를 살펴보는 것이 더 좋습니다. 아마도 이러한 새로운 변화가 당신을 놀라게 할 것입니다.

요약