View a markdown version of this page

구성 지침 - Amazon Aurora
RDS Proxy 설정애플리케이션, 프록시 및 데이터베이스 구성 조정데이터베이스 구성애플리케이션 구성

구성 지침

이 섹션에서는 RDS Proxy에서 사용할 수 있는 설정을 설명하고 애플리케이션 스택에서 구성을 정렬하는 모범 사례를 제공합니다. 다음은 Amazon RDS 및 Amazon Aurora에서 RDS Proxy를 사용하기 위한 결합된 지침입니다. 해당하는 경우 RDS별 및 Aurora별 메모가 별도로 명시됩니다.

달리 명시되지 않는 한, ‘데이터베이스’ 또는 ‘대상’이라는 용어는 Aurora 클러스터, Amazon RDS Multi-AZ DB 클러스터 또는 Amazon RDS 인스턴스를 나타냅니다.

RDS Proxy 설정

MaxConnectionsPercent

최소값 최대값 기본값
다음 중 작은 값(1, MaxIdleConnectionsPercent) 100 100

자세한 내용은 MaxConnectionsPercent 섹션을 참조하세요.

이 설정은 RDS Proxy가 대상 데이터베이스와 설정할 수 있는 연결 수를 데이터베이스에서 허용하는 최대 연결 수의 백분율로 제한합니다. 프록시는 필요에 따라 백엔드 연결을 열므로 특정 시점의 실제 연결 수가 구성된 최대값보다 적을 수 있습니다.

MaxConnectionsPercent 설정이 데이터베이스 연결 제한의 백분율인 경우 프록시의 연결 풀 크기는 데이터베이스 구성을 자동으로 따릅니다. 즉, 데이터베이스 인스턴스의 크기를 조정하거나 구성을 변경할 때마다 프록시를 재구성할 필요가 없습니다. 또한 암시적이든 명시적이든 데이터베이스 설정이 변경될 수 있는 시나리오를 알고 있어야 합니다.

  • 데이터베이스의 max_connections 파라미터 그룹에서 연결 제한(예: 파라미터)을 명시적으로 설정하지 않은 경우 Amazon RDS 및 Aurora는 데이터베이스 인스턴스 클래스를 기반으로 연결 제한을 자동으로 계산합니다. 따라서 데이터베이스 인스턴스를 확장할 때 암시적 연결 제한이 변경될 수 있으므로 프록시의 최대 풀 크기에 영향을 미칠 수 있습니다. 자세한 내용은 Amazon RDS 사용 설명서의 최대 데이터베이스 연결 수, Amazon Aurora 사용 설명서의 Aurora MySQL DB 인스턴스에 대한 최대 연결, Aurora PostgreSQL DB 인스턴스에 대한 최대 연결을 참조하세요.

  • Aurora Serverless v2 데이터베이스 인스턴스는 데이터베이스의 최대 ACU 구성을 기반으로 연결 제한을 결정합니다. 자세한 내용은 Amazon Aurora 사용 설명서의 Aurora Serverless v2의 최대 연결을 참조하세요.

모범 사례:

  • 기본 설정인 100%는 프록시를 통해 모든 트래픽을 수신하고 관리 액세스 또는 기타 클라이언트에 대한 헤드룸이 필요하지 않은 데이터베이스에 적합합니다.

  • 데이터베이스가 애플리케이션에서 직접 트래픽을 수신하고(프록시를 우회) 프록시가 모든 연결을 사용하지 않도록 하거나 데이터베이스 관리자의 직접 액세스와 같은 다른 목적으로 특정 수의 연결을 따로 설정하려는 경우이 설정을 줄입니다.

  • Aurora Global Database 클러스터에서 RDS Proxy를 사용하고 쓰기 전달이 활성화된 경우, 쓰기 전달에 할당된 할당량만큼 프록시의 MaxConnectionsPercent 값을 줄이세요. 자세한 내용은 Amazon Aurora 사용 설명서의 Aurora MySQL 및 Aurora PostgreSQL에서 쓰기 전달을 위한 구성 파라미터를 참조하세요. 이 권장 사항은 프록시가 글로벌 데이터베이스의 기본 리전 또는 보조 리전에서 클러스터를 제공하는지 여부를 적용합니다. 보조 클러스터를 기본 역할로 승격할 수 있으므로 전체 글로벌 토폴로지에서 프록시 설정을 일관되게 유지하는 것이 좋습니다. 기본 리전과 보조 리전을 제공하는 프록시에 비대칭 설정을 사용할 수 있지만 각 글로벌 장애 조치 또는 전환 후 이러한 설정을 조정해야 합니다.

  • 대상이 여러 프록시를 제공하는 경우 데이터베이스가 과도하게 구독되지 않도록 모든 프록시에서의 결합된 MaxConnectionsPercent 값이 100을 초과해서는 안 됩니다. 구성 및 관리를 간소화하려면 대상당 단일 프록시를 사용하는 것이 좋습니다. 특히 중복성을 위해 데이터베이스당 여러 프록시를 사용할 필요가 없습니다. 자세한 내용은 하나의 대상에 여러 프록시 사용 섹션을 참조하세요.

기본 MaxConnectionsPercent 설정을 사용하든 사용자 지정 값을 사용하든 허용된 연결 수와 피크 기간 동안 예상되는 최대 클라이언트 연결 수 사이에 최소 30%의 여유 공간을 유지합니다. 예제:

  • 프록시에 데이터베이스에 대해 구성된 연결 제한의 최대 50%가 필요하다고 생각되면 최소 1.3 * 50% = 65%의 MaxConnectionsPercent 설정을 사용합니다.

  • 기본 MaxConnectionsPercent 설정인 100을 사용하는 경우 데이터베이스 제한 자체가 충분한 헤드룸을 제공하는지 확인합니다.

이 추가 헤드룸은 예기치 않은 워크로드 급증 시 클라이언트 경험을 개선하고 RDS Proxy가 내부 인프라에서 열 관리 및 기타 목적으로 연결을 재배포하는 데 도움이 됩니다.

MaxConnectionsPercent를 최소 1의 값으로 설정할 수 있지만 인스턴스 유형에 따라 다음과 같은 최소값을 사용하는 것이 좋습니다.

  • db.t3.small: 100

  • db.t3.medium: 55

  • db.t3.large: 35

  • db.r3.large 이상: 20

MaxIdleConnectionsPercent

최소값 최대값 기본값(SQL Server) 기본값(기타 엔진)
(0) MaxConnectionsPercent MaxConnectionsPercent의 5% MaxConnectionsPercent의 50%

자세한 내용은 MaxIdleConnectionsPercent 섹션을 참조하세요.

이 설정은 RDS Proxy가 연결 풀에 유지하는 유휴 데이터베이스 연결 수를 데이터베이스에서 허용하는 최대 연결 수의 백분율로 제한합니다. 데이터베이스(백엔드) 연결은 5분 동안 연결에 아무런 활동이 없을 때 유휴 상태로 간주됩니다. 이 설정은 프록시와 백엔드 데이터베이스 간의 연결에 적용됩니다.

다음 사항에 유의하세요.

  • 이 설정은 풀의 유휴 연결 수를 제한하지만 프록시가 지정된 수의 유휴 연결을 유지하도록 강제하지는 않습니다. 클라이언트 활동이 매우 낮으면 실제 백엔드 데이터베이스 연결 수가 MaxIdleConnectionsPercent보다 적을 수 있습니다.

  • 연결은 프록시의 연결 풀에서 재사용할 수 있는 경우 유휴 상태로 계산됩니다. 고정된 연결은 다른 클라이언트에서 재사용할 수 없으므로 MaxIdleConnectionsPercent를 적용하기 위해 유휴 상태로 간주되지 않습니다. 고정에 대한 자세한 내용은 RDS 프록시 고정 방지 섹션을 참조하세요.

  • 데이터베이스 메타데이터에서 보고하는 유휴 연결 수는 일반적으로 RDS Proxy 지표에서 기록하는 유휴 연결 수보다 많습니다. 이는 프록시를 우회하는 직접 클라이언트 연결과 Amazon RDS 및 Aurora 자동화에서 사용하는 내부 연결 때문일 수 있습니다.

참고

프록시 계층에서 관찰되고 적용되는 연결 유휴 시간은 MySQL 프로세스 목록 또는 PostgreSQL의 활동 통계 테이블과 같은 데이터베이스 도구에서 보고된 유휴 시간과 다를 수 있습니다. RDS Proxy는 백엔드 연결을 가끔 ping하여 클라이언트 활동 측면에서 연결이 유휴 상태로 유지되더라도 데이터베이스 유휴 타이머를 재설정합니다.

모범 사례:

기본 설정인 50은 대부분의 워크로드에 적합하며 권장됩니다. 설정을 변경하면 다음과 같은 효과가 있습니다.

  • MaxIdleConnectionsPercent를 올리면 데이터베이스가 유휴 연결을 더 많이 관찰하여 피크 시간 외에 데이터베이스 리소스 소비를 늘릴 수 있습니다. 반면 프록시를 통해 처리되는 연결 스파이크는 풀에서 쉽게 사용할 수 있는 연결이 더 많기 때문에 대여 지연 시간이 줄어듭니다.

  • MaxIdleConnectionsPercent를 낮추면 프록시가 유휴 연결을 더 적극적으로 닫아 해당 연결로 인한 경합 및 리소스 소비를 잠재적으로 줄일 수 있습니다. 그러나 프록시를 통과하는 연결 급증으로 인해 대여 시간이 길어질 수 있습니다. 풀에서 사용 가능한 연결이 적기 때문에 프록시는 스파이크 중에 새 백엔드 연결을 여는 데 추가 시간을 할애해야 합니다.

유휴 연결에 의한 리소스 소비는 프로비저닝된 인스턴스 유형을 사용하는 데이터베이스에서 중요한 문제가 아닐 수 있지만 Serverless v2 인스턴스 유형을 사용하는 Aurora 데이터베이스는 유휴 리소스 소비를 최적화하여 비용을 절감하는 것이 좋습니다.

IdleClientTimeout

최소값 최대값 기본값
1분 8 시간 30 분

자세한 내용은 IdleClientTimeout 섹션을 참조하세요.

이 설정은 프록시가 연결을 닫기 전에 클라이언트 연결을 유휴 상태로 유지할 수 있는 기간을 결정합니다. RDS Proxy는 연결이 유휴 상태인지 여부에 관계없이 최대 연결 수명을 24시간으로 적용합니다. 예를 들어 IdleClientTimeout을 30분(기본값)으로 구성하고 1분마다 데이터베이스를 ping하는 경우 연결은 유휴 제한 시간을 초과하지 않지만 무기한 열린 상태로 유지되지 않습니다. RDS Proxy는 유휴 상태가 아니더라도 24시간 후에 연결을 닫습니다.

IdleClientTimeout 설정은 클라이언트(애플리케이션 또는 대화형 사용자)와 RDS Proxy 간의 연결에 적용됩니다. RDS Proxy와 데이터베이스 간 백엔드 연결의 유휴 동작을 이해하려면 MaxIdleConnectionsPercent 섹션을 참조하세요.

모범 사례:

  • 유휴 제한 시간은 클라이언트 연결 또는 트랜잭션 내에서 SQL 활동의 정상적인 일시 중지를 수용할 수 있을 만큼 충분히 길어야 합니다. 클라이언트가 더 이상 필요하지 않지만 다른 클라이언트가 필요로 할 수 있는 리소스를 유지할 수 있을 만큼 길지 않아야 합니다. 이는 한 클라이언트에서 고정한 연결을 다른 클라이언트에서 재사용할 수 없기 때문에 연결 고정이 관찰되는 경우에 특히 중요합니다.

  • RDS Proxy가 제한 시간을 올바르게 적용하려면 쿼리(SELECT 1; 같은 간단한 상태 확인) 또는 프로토콜 ping(예: MySQL의 COM_PING)을 전송하지 않고 클라이언트 연결이 실제로 유휴 상태여야 합니다. 제한 시간을 초과해도 연결이 닫히지 않는 경우 애플리케이션 드라이버의 연결 로직을 확인합니다. 애플리케이션 수준 연결 풀은 특히 IdleClientTimeout을 방해하는 자체 실시간 확인을 수행할 가능성이 높습니다.

ConnectionBorrowTimeout

최소값 최대값 기본값
(0) 5분 2 minutes

자세한 내용은 ConnectionBorrowTimeout 섹션을 참조하세요.

클라이언트가 RDS Proxy에 연결할 때 프록시는 풀에서 사용 가능한 기존 연결을 빌리거나 새 데이터베이스 연결을 열어야 합니다. 이 설정은 RDS Proxy가 오류를 반환하기 전에 연결이 빌리거나 열릴 때까지 기다리는 시간을 정의합니다.

다음 사항에 유의하세요.

  • 연결 풀에 사용 가능한 연결이 아직 포함되어 있지 않으면 ConnectionBorrowTimeout이 0인 경우 제한 시간 오류가 발생합니다. 풀이 최대 용량 미만이고 새 백엔드 연결을 열 수 있는 경우에도 마찬가지입니다.

  • MaxIdleConnectionsPercent가 MaxConnectionsPercent와 같더라도 풀의 실제 연결 수는 구성된 최대값보다 적을 수 있습니다. 즉, MaxIdleConnectionsPercent는 유휴 연결의 양을 제한하지만 연결을 강제로 열어 두지는 않습니다.

연결 풀이 최대 용량 미만으로 실행되는 것은 정상입니다. 이 경우 ConnectionBorrowTimeout을 0으로 설정하면 풀이 새 연결이 열릴 때까지 기다릴 수 없으므로 풀이 증가하지 않을 수 있습니다. 따라서 앞서 설명한 동작이 선호되지 않는 한 모든 워크로드에 0이 아닌 ConnectionBorrowTimeout 값을 사용해야 합니다.

참고

이 설정은 오프라인 유지 관리 작업 및 장애 조치와 같이 데이터베이스가 연결을 수락할 준비가 되지 않은 경우에도 적용됩니다. ConnectionBorrowTimeout을 적용하기 위한 로직은 데이터베이스의 가동 여부에 관계없이 동일합니다.

초기화 쿼리 및 필터 고정

RDS Proxy는 연결 고정을 줄이고 결과적으로 멀티플렉싱 효율성을 개선할 수 있는 추가 기능을 지원합니다.

초기화 쿼리는 프록시가 새 백엔드 데이터베이스 연결을 설정할 때마다 실행되는 하나 이상의 문입니다. 클라이언트가 동일한 문을 사용하여 세션 파라미터를 설정하는 경우 해당 문을 프록시의 초기화 쿼리로 이동할 수 있습니다. 이렇게 하면 고정 가능성을 줄이고 효율성도 개선할 수 있습니다. 특정 백엔드 데이터베이스 연결은 설정 중에 초기화 쿼리를 한 번 실행하지만 나중에 많은 클라이언트에서 재사용할 수 있습니다. SQL 문을 초기화 쿼리에 배치해도 클라이언트 트래픽에서 필터링되지 않습니다. 멀티플렉싱을 방해하지 않도록 애플리케이션 코드에서 이러한 문을 제거해야 합니다.

세션 고정 필터는 프록시가 특정 세션 상태를 고정하지 못하도록 하는 구성 속성입니다. 현재 사용 가능한 유일한 필터 옵션인 EXCLUDE_VARIABLE_SETS는 세션을 고정할지 여부를 결정할 때 모든 SET 문을 무시하도록 프록시에 지시합니다. SET 문은 여전히 데이터베이스에 전달되며 세션 상태에 영향을 미칠 수 있습니다. 즉,이 옵션은 다음 상황에서만 안전합니다.

  1. SET 문은 시스템 변수를 서버 기본값과 동일한 값으로 설정하는 것과 같은 노옵스입니다.

  2. SET 문과 후속 쿼리는 동일한 트랜잭션의 일부이며, 모든 트랜잭션은 다른 트랜잭션에 의해 설정된 변수의 영향을 받지 않도록 완전히 독립적으로 자체 상태를 설정합니다.

참고

EXCLUDE_VARIABLE_SETS 고정 필터는 전부 또는 전무 설정이며 무시할 SET 문을 선택적으로 선택할 수 없습니다. 사용 사례가 이전 목록에서 설명한 범주 중 하나에 속하지 않는 한 이 필터를 고정용 블랭킷 솔루션으로 사용하지 마세요.

최상의 결과를 얻으려면 가능한 경우 애플리케이션 코드에서 불필요한 문을 제거하고 애플리케이션 수정이 불가능한 경우에만 필터를 사용합니다. 이렇게 하면 처음에 필요하지 않은 문에 특별한 처리를 적용하는 대신 노이즈가 적고 예측 가능한 클라이언트-서버 환경을 촉진할 수 있습니다.

중요

초기화 쿼리나 고정 필터로 인해 RDS Proxy가 클라이언트-서버 쿼리 트래픽을 변경하지 않습니다. 클라이언트에서 도착하는 문은 초기화 쿼리 또는 고정 필터 구성과 관계없이 데이터베이스에 계속 전달됩니다.

자세한 내용은 다음을 참조하세요.

PostgreSQL 연결의 경우 클라이언트 드라이버와 프록시 간에 교환되는 시작 메시지에 지원되는 연결 파라미터를 넣을 수도 있습니다. 이렇게 하면 별도의 SET 명령이 전송되지 않으므로 왕복이 줄어들고 명시적 SET 문으로 인한 연결 고정이 방지됩니다. 자세한 내용은 PostgreSQL을 사용하여 연결할 때 고려할 사항 섹션을 참조하세요.

애플리케이션, 프록시 및 데이터베이스 구성 조정

이전 섹션에서 설명한 대로 RDS Proxy는 프록시 동작을 애플리케이션 요구 사항에 맞게 조정하는 데 도움이 되는 다양한 파라미터를 지원합니다. 그러나 올바른 구성 값을 선택하는 것은 애플리케이션, 프록시, 데이터베이스 자체 등 스택의 모든 계층을 자르는 작업입니다. 이러한 모든 구성 요소의 설정은 다음 목표에 맞게 조정되어야 합니다.

  1. 정상 운영 중에 예상되는 수준의 성능과 확장성을 제공합니다.

  2. 워크로드 문제 발생 시 문제 해결의 명확성과 용이성을 높입니다.

  3. 스택이 애플리케이션에 미치는 영향을 최소화하면서 예상치 못한 이벤트(예: 워크로드 급증)를 처리할 수 있도록 지원합니다.

다중 계층 환경에서 설정을 선택하고 조정할 때는 하위 계층의 제한 및 제한 시간이 상위 계층의 해당 제한 및 제한 시간보다 크거나 같도록 구성 값을 정렬해 보세요. 즉, 한 계층의 설정을 스택 바로 아래의 다음 구성 봉투에 맞는 봉투로 취급합니다.

예를 들어 애플리케이션이 최상위 계층이고 프록시가 중간 계층이며 데이터베이스가 하위 계층이라고 가정합니다. 프록시 수준의 제한 시간과 제한 시간이 애플리케이션 수준의 제한 시간보다 낮으면 프록시 제한은 애플리케이션 제한을 선점합니다. 애플리케이션이 설정을 실행할 수 없으며 자체 구성으로 설명할 수 없는 동작이 발생합니다.

IdleClientTimeout 프록시 설정을 예로 들어 보겠습니다. 애플리케이션 드라이버 또는 클라이언트 풀이 자체 유휴 제한 시간을 적용하는 경우 프록시의 유휴 제한 시간은 애플리케이션 설정 위에 있는 안전망입니다. 즉, 혼동을 방지하려면 IdleClientTimeout이 최소한 애플리케이션 수준 유휴 제한 시간과 같아야 합니다.

  • 애플리케이션 유휴 제한 시간이 프록시 제한 시간보다 낮으면 애플리케이션이 구성된 대로 연결을 종료할 것으로 예상됩니다. 애플리케이션이 유휴 연결을 적시에 닫지 못하면 프록시는 백스톱 역할을 합니다.

  • 애플리케이션 유휴 제한 시간이 프록시 제한 시간보다 길면 애플리케이션에 조기 연결 종료가 발생할 수 있습니다. 이로 인해 애플리케이션 측에서 혼동이 발생할 수 있습니다.

연결 제한과 같은 다른 설정에도 동일한 로직이 적용됩니다. 각 계층의 설정은 다음 계층의 구성에서 정의한 봉투 내에 맞아야 합니다.

최상의 결과를 얻으려면 구성 설정에 한 계층과 다음 계층 사이의 일부 패딩이 포함되어야 합니다. 예를 들어 클라이언트/서버 클럭 드리프트로 인한 산발적인 오류를 방지하기 위해 또는 클라이언트가 연결을 정상적으로 종료하는 데 추가 시간이 필요한 경우 프록시 제한 시간을 애플리케이션 제한 시간보다 몇 초 더 길게 설정할 수 있습니다.

즉, 다음과 같이 설정을 정렬합니다.

client timeout < proxy timeout < database timeout

다음 사용 안 함:

client timeout = proxy timeout = database timeout

그리고 다음을 피합니다.

client timeout > proxy timeout > database timeout

데이터베이스 구성

연결 제한

RDS Proxy는 MaxConnectionsPercent 설정을 사용하여 연결 풀의 최대 크기를 결정합니다. 즉, 프록시의 연결 풀 크기가 데이터베이스의 연결 제한을 기준으로 합니다. 데이터베이스의 연결 제한을 변경하면 프록시의 풀 크기가 자동으로 적용됩니다. 데이터베이스가 프록시가 아닌 사용자에 대한 연결 제한의 일부를 예약하도록 하려면 데이터베이스 제한을 늘리는 대신 프록시의 MaxConnectionsPercent 설정을 낮춰야 합니다.

RDS Proxy는 데이터베이스 연결 제한을 적절하게 구성할 필요가 없습니다. 단일 프록시 연결은 본질적으로 단일 직접 클라이언트 연결보다 가볍지 않으므로 프록시를 사용하는 경우에만 데이터베이스 제한을 늘리지 마세요. 프록시는 데이터베이스가 쿼리를 처리하기 위해 수행해야 하는 작업량을 줄이지 않지만 데이터베이스가 더 적은 연결로 동일한 워크로드를 처리하는 데 도움이 됩니다.

유휴 제한 시간

데이터베이스는 예를 들어 MySQL의 wait_timeout 및 interactive_timeout 설정 또는 PostgreSQL의 transaction_timeout 및 idle_in_transaction_session_timeout 설정을 사용하여 자체 유휴 제한 시간을 적용할 수 있습니다. 이러한 설정의 기본값은 프록시 구성을 방해할 가능성이 낮지만 사용자 지정 데이터베이스 수준 제한 시간을 사용하는 경우 해당 프록시 제한 시간보다 길거나 조기 제한 시간으로 인해 프록시에 연결 오류가 발생하는지 확인합니다.

세션 상태를 모니터링하고 특정 기준에 따라 연결을 적극적으로 종료하는 스크립트 또는 프로세스인 연결 킬러를 사용하는 데이터베이스 환경에도 동일한 로직이 적용됩니다. 환경에서 이러한 기술을 사용하는 경우 연결 종료 로직이 프록시 설정과 일치하는지 확인합니다.

프록시를 통해 모든 워크로드를 처리하는 데이터베이스는 일반적으로 유휴 제한 시간에 대한 프록시 구성에 따라 달라지고 데이터베이스 수준 설정을 기본값으로 둘 수 있습니다.

애플리케이션 구성

세션 상태 관리

많은 데이터베이스 드라이버, 애플리케이션 프레임워크 및 객체 관계형 매핑(ORM) 도구는 쿼리 트래픽을 보내기 전에 세션 변수 또는 SET 문을 사용하여 연결을 설정합니다. 애플리케이션 코드만 볼 때 연결 및 트랜잭션 초기화 문을 사용하는 것은 명확하지 않을 수 있으며 데이터베이스 자체와 SQL 문 및 애플리케이션 로직 사이에 여러 계층의 추상화가 있을 수 있습니다. RDS Proxy 향상된 로깅 기능을 사용하여 연결 고정 이유를 기록할 수 있으며, 데이터베이스 쿼리 로그는 데이터베이스 연결을 통해 전송되는 모든 명령문에 대한 추가 정보를 제공할 수 있습니다.

다음 모범 사례를 고려하세요.

  1. 데이터베이스 기본값과 다르고 클라이언트 세션이 해당 기본값에서 벗어나야 하는 경우에만 연결 파라미터를 설정합니다. 불필요한 초기화 문을 제거하면 멀티플렉싱에 도움이 될 뿐만 아니라 각 새 데이터베이스 연결에 대한 클라이언트-서버 왕복 횟수도 줄어듭니다.

  2. 모든 연결에서 변수와 구성 설정을 일관되게 설정합니다.

  3. 쿼리 런타임에도 적용할 수 있는 세션 구성을 사용하지 마세요. 예를 들어 클라이언트마다 다른 시간대의 데이터를 확인해야 하는 경우 세션 수준에서 시간대를 설정하는 대신 쿼리 수준에서 시간대 변환 함수를 사용하는 것이 좋습니다.

  4. 가능하면 초기화 쿼리 기능을 사용하여 세션 구성 문을 프록시 계층으로 이동합니다. 자세한 내용은 초기화 쿼리 및 필터 고정 섹션을 참조하세요.

활성도 확인

애플리케이션에서 연결 풀링 또는 고급 드라이버를 사용하는 경우 프로토콜 ping, 상태 확인 문 또는 연결 유지 쿼리와 같은 실시간 확인과 관련된 구성을 찾습니다. RDS Proxy는 모든 클라이언트 요청을 균등하게 처리하므로 SELECT 1; 쿼리 또는 COM_PING 요청이 애플리케이션 관점에서 운영되지 않더라도 프록시가 유휴 클라이언트 제한 시간을 적용하고 MaxIdleConnectionsPercent에 따라 연결 풀 크기를 관리하는 것을 방지합니다.

참고

RDS Proxy는 연결 활동에 관계없이 최대 연결 수명을 24시간으로 적용합니다.

대부분의 경우 클라이언트 측 실시간 확인을 비활성화하여 프로토콜 노이즈를 줄이고 RDS Proxy가 유휴 연결을 관리하는 데 도움이 될 수 있습니다. 다음과 관계없이 이러한 상태 확인을 실행하려는 엣지 케이스가 있습니다.

  • 의도적으로 프록시 계층에서 특정 연결이 시간 초과되는 것을 방지하려고 합니다.

  • 애플리케이션 드라이버 또는 풀이 프록시에 의해 연결이 끊어지는 시기를 사전에 감지하도록 허용하려고 합니다. 예를 들어 데이터베이스 재시작으로 인해 고정된 백엔드 연결이 종료되고 클라이언트 연결이 최대 수명인 24시간을 초과할 수 있습니다.

애플리케이션 측에서 라이브 상태 확인을 비활성화하거나 제한 시간을 초과하지 않도록 하려는 특정 연결에 대해서만 라이브 상태 확인을 수행하는 것이 좋습니다.

세션 상태 추적

MariaDB 드라이버와 같은 일부 MySQL 데이터베이스 드라이버는 session_track_* 변수를 사용하여 세션 상태를 추적할 수 있습니다. 이 기능을 활성화하면 클라이언트가 서버가 추적할 수 있는 세션 상태를 변경할 때마다 서버는 응답 패킷에 상태 변경 정보를 포함합니다. 이렇게 하면 서버의 세션 상태에 대해 드라이버에게 알릴 수 있습니다.

이러한 세션 상태 추적 방식은 클라이언트가 서버와 직접 상호 작용하고 다중 서버 환경에서 세션 마이그레이션과 같은 자체 세션 관리 기능을 구현할 때 의미가 있을 수 있습니다. RDS Proxy는 자체 상태 추적 메커니즘을 구현하고 session_track_* 변수에서 활성화된 정보를 사용하지 않지만 이러한 변수를 설정하면 세션 고정이 발생합니다.

데이터베이스 드라이버가 이러한 변수를 설정하는 경우 드라이버에서 추적 기능을 비활성화하거나, 다른 드라이버로 전환하거나, 안전한 경우 세션 고정 필터를 사용하여 문을 무시하는 방법을 찾을 수 있습니다. 자세한 내용은 초기화 쿼리 및 필터 고정 섹션을 참조하십시오.