기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
연결 관리
애플리케이션에 대한 수요가 증가하면 프런트엔드 트래픽도 증가합니다. 일반적인 시나리오에서는 이러한 수신 트래픽 폭증을 처리하기 위해 애플리케이션 계층에서 자동 크기 조정을 설정합니다. 그 결과 애플리케이션 티어 크기가 자동으로 조정되기 시작하고 트래픽 증가에 맞춰 더 많은 애플리케이션 서버(인스턴스)가 추가됩니다. 모든 애플리케이션 서버에는 데이터베이스 연결 풀 설정이 사전 구성되어 있기 때문에 데이터베이스의 수신 연결 수는 새로 배포된 인스턴스에 비례하여 증가합니다.
예를 들어, 애플리케이션 서버 20개를 각각 200개의 데이터베이스 연결로 구성하면 총 4,000개의 데이터베이스 연결이 열립니다. 애플리케이션 풀이 최대 200개 인스턴스까지 스케일 업되는 경우(예: 사용량이 많은 시간) 총 연결 수는 40,000개에 달합니다. 일반적인 워크로드에서는 이러한 연결 대부분이 유휴 상태일 가능성이 높습니다. 그러나 연결이 급증하면 Amazon Aurora MySQL 호환 버전 데이터베이스의 크기 조정 능력이 제한될 수 있습니다. 이는 유휴 연결이라도 메모리와 파일 설명자 등의 기타 서버 리소스를 소비하기 때문입니다. Aurora MySQL 호환은 일반적으로 동일한 수의 연결을 유지하기 위해 MySQL Community Edition보다 적은 메모리를 사용합니다. 그러나 유휴 연결의 메모리 사용량은 여전히 0이 아닙니다.
구성 변수
max_connections와 max_connect_errors라는 두 가지 주요 서버 구성 변수를 사용하여 데이터베이스에 허용되는 수신 연결 수를 제어할 수 있습니다.
구성 변수 max_connections
구성 변수 max_connections는 각 MySQL 인스턴스의 데이터베이스 연결 수를 제한합니다. 가장 좋은 방법은 각 데이터베이스 인스턴스에서 열 것으로 예상되는 최대 연결 수보다 약간 높게 설정하는 것입니다.
performance_schema도 활성화한 경우 max_connections 설정에 특히 주의하세요. 성능 스키마 메모리 구조는 max_connections를 포함한 서버 구성 변수에 따라 자동으로 크기가 조정됩니다. 변수를 높게 설정할수록 성능 스키마가 사용하는 메모리가 많아집니다. 극단적인 경우에는 크기가 작은 인스턴스 유형에서 메모리 부족 문제가 발생할 수 있습니다. Performance Insights를 활성화하면 Performance Schema가 자동으로 활성화됩니다.
구성 변수 max_connect_errors
구성 변수 max_connect_errors는 특정 클라이언트 호스트에서 허용되는 연속적인 중단 연결 요청 수를 결정합니다. 클라이언트 호스트의 연속 연결 실패 횟수가 지정된 횟수를 초과할 경우 서버는 해당 연결을 차단합니다. 해당 클라이언트에서 연결을 계속 시도하면 오류가 발생합니다.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
"호스트가 차단됨" 오류가 발생하는 경우 max_connect_errors 변수 값을 늘리지 마십시오. 대신 aborted_connects 상태 변수와 host_cache 테이블에서 서버의 진단 카운터를 조사합니다. 수집된 정보를 사용하여 연결 문제가 발생하는 클라이언트를 식별하고 수정합니다. 또한 skip_name_resolve가 1(기본값)로 설정된 경우 이 파라미터는 아무런 효과가 없습니다.
다음에 대한 자세한 내용은 MySQL 참조 설명서를 참조하세요.
연결 풀링 구현
규모 조정 이벤트로 인해 애플리케이션 서버가 더 추가될 수 있으며, 이로 인해 DB 서버가 완전히 로드된 활성 연결 수를 초과할 수 있습니다. 애플리케이션 서버와 데이터베이스 사이에 연결 풀이나 프록시 계층을 추가하면 깔때기 역할을 하여 데이터베이스의 총 연결 수가 줄어듭니다. 프록시의 주요 목적은 멀티플렉싱을 통해 데이터베이스 연결을 재사용하는 것입니다.
한쪽에서는 프록시가 제어된 수의 연결을 사용하여 데이터베이스에 연결됩니다. 다른 쪽에서는 프록시가 애플리케이션 연결을 수락합니다. 또한 쿼리 캐싱, 연결 버퍼링, 쿼리 다시 작성 및 라우팅, 로드 밸런싱과 같은 추가 기능을 제공합니다. 데이터베이스에 대한 최대 연결 수를 완전히 로드된 수 이하로 유지하도록 연결 풀 계층을 구성해야 합니다. Amazon RDS 프록시
Aurora MySQL 호환과 함께 사용할 수 있는 다음과 같은 타사 프록시를 탐색할 수도 있습니다.
연결 폭풍 피하기
데이터베이스가 과부하되거나 복제본이 기본 노드보다 너무 뒤처지는 경우 연결 풀이 어떻게 작동하는지 고려하세요. 프록시 서버 또는 연결 풀을 구성할 때 기본 하드웨어 또는 스토리지 문제 또는 DB 리소스 제약으로 인한 느린 데이터베이스 응답을 기준으로 전체 연결 풀을 재설정하지 않도록 합니다.
갑자기 수백 개의 연결을 시작하면 데이터베이스에 대한 많은 수의 새 연결 요청이 동시에 시작되므로 연결 폭풍이 발생합니다. 폭풍은 리소스를 많이 소모합니다. MySQL에서 새 데이터베이스 연결을 만드는 것은 백엔드가 초기 핸드셰이크를 위해 여러 네트워크 패킷을 교환하고, 새 프로세스를 생성하고, 메모리를 할당하고, 인증을 처리하는 등의 작업을 수행하기 때문에 비용이 많이 드는 작업입니다. 짧은 시간 내에 많은 요청을 받으면 데이터베이스가 응답하지 않는 것처럼 보일 수 있습니다.
MySQL에는 이러한 연결 요청 급증을 방지하는 메커니즘이 있습니다. back_log 변수는 MySQL이 새 요청에 대한 응답을 잠시 중단하기 전에 잠시 동안 누적될 수 있는 요청 수로 설정할 수 있습니다. 이 값은 연결 처리 스레드에 의해 적용되며, 이 스레드 자체가 연결 폭풍으로 인해 과부하될 수 있습니다. 자세한 내용은 MySQL 참조 매뉴얼
데이터베이스 속도가 느릴 때 연결이 재설정되도록 구성된 경우 주기가 반복해서 시작됩니다. 마찬가지로, 하루 중 특정 시간(예: 주식 시장이 열리는 시간)에 데이터베이스 트래픽이 갑자기 증가할 것으로 예상되는 경우, 높은 트래픽 부하가 시작되는 동시에 많은 연결을 열려고 하지 않도록 연결 풀을 예열합니다.
