View a markdown version of this page

애플리케이션 및 워크로드 고려 사항 - Amazon Aurora
다중 테넌트 및 다중 사용자 환경여러 애플리케이션 또는 소프트웨어 스택을 제공하는 데이터베이스RDS Proxy에서 애플리케이션 수준 풀링 및 고급 드라이버 사용

애플리케이션 및 워크로드 고려 사항

다중 테넌트 및 다중 사용자 환경

확장성 및 연결 관리 개선과 관련하여 RDS Proxy 사용의 이점은 연결 풀링을 수행하는 기능과 훨씬 더 큰 범위에서 연결 멀티플렉싱을 수행하는 기능에 따라 달라집니다. 연결 풀링은 연결 열기 및 닫기와 관련된 오버헤드를 줄입니다. 연결 멀티플렉싱을 사용하면 프록시가 트랜잭션 후 백엔드 데이터베이스 연결을 재사용할 수 있습니다. 자세한 내용은 RDS Proxy 개념 및 용어 섹션을 참조하세요.

연결을 멀티플렉싱할 수 없는 경우 프록시는 연결 고정이라는 동작으로 돌아갑니다. 고정은 클라이언트가 전체 세션에 동일한 기본 프록시 연결을 사용해야 하는 상황입니다. 프록시 연결은 해당 한 클라이언트에 대해 예약되어 있으므로 다른 클라이언트에서 재사용할 수 없습니다. 즉, 고정은 클라이언트-프록시 연결과 프록시-데이터베이스 연결 간에 배타적인 1:1 연결을 생성합니다. RDS Proxy가 주로 확장성 및 효율성 이유로 사용되는 모든 시나리오에서는 고정을 피하는 것이 중요합니다. 최신 고정 동작은 RDS 프록시 고정 방지 섹션을 참조하십시오.

일반적으로 연결이 동일한 상태일 때 연결을 멀티플렉싱할 수 있습니다. 사용자 지정 세션별 상태 정보가 포함된 연결은 멀티플렉싱할 수 없습니다. 세션 상태를 정의하는 측면 중 하나는 연결과 연결된 데이터베이스 사용자 이름입니다. 프록시에 ‘user_A’로 연결할 때 프록시는 백엔드 데이터베이스 연결도 ‘user_A’로 열어야 합니다. 프록시는 "user_A"로 로그인하는 다른 클라이언트에 대해이 백엔드 연결을 풀링하고 재사용할 수 있지만 다른 사용자 이름을 사용하는 클라이언트에는 재사용할 수 없습니다.

이 동작은 고유한 데이터베이스 계정이 많은 다중 사용자 환경에서 풀링 및 멀티플렉싱 효율성을 크게 줄일 수 있습니다. 이는 데이터베이스 수준 또는 스키마 수준 다중 테넌시를 사용하는 아키텍처에서 특히 그렇습니다. 데이터베이스에 수천 개의 스키마(테넌트당 하나)가 포함되어 있고 각 테넌트가 다른 사용자 이름으로 데이터베이스에 연결하는 경우 연결 풀이 사용자별 마이크로 풀로 조각화되어 전반적인 효율성이 떨어집니다.

또한 데이터베이스 엔진과 관련된 측면은 풀링 효율성과 프록시의 연결 멀티플렉싱 기능에도 영향을 미칠 수 있습니다.

  1. Amazon RDS 및 Aurora PostgreSQL에서는 테넌트당 하나의 데이터베이스를 사용하여 다중 테넌시를 구현하는 경우가 많습니다. 그러나 PostgreSQL에서 연결은 데이터베이스별로 다릅니다. 한 데이터베이스에 대해 열린 연결은 다른 데이터베이스의 데이터에 액세스할 수 없습니다. 따라서 데이터베이스 수준 다중 테넌시는 프록시 수준에서 풀링 및 멀티플렉싱의 효율성을 줄입니다. 이 고려 사항은 워크로드가 스키마 수준 다중 테넌시를 사용하고 클라이언트 세션이 사용자 지정 search_path를 사용하는 경우에도 적용됩니다. 그러나 모든 세션이 기본 검색 경로를 사용하고 정규화된 이름(schema_name.table_name)을 사용하는 테이블을 참조하는 경우 해당 세션을 멀티플렉싱할 수 있습니다.

  2. Amazon RDS 및 Aurora MySQL에서 ‘database’ 및 ‘schema’라는 용어는 동의어입니다. 다중 테넌시는 종종 테넌트당 하나의 스키마를 사용하여 구현되며, MySQL에서는 테넌트당 하나의 데이터베이스와 동일합니다. 연결은 MySQL 서버 전체에 대해 열리고 스키마에 연결되지 않습니다. 애플리케이션이 스키마 수준 다중 테넌시를 사용하는 경우 동일한 데이터베이스 사용자 이름을 사용하는 클라이언트의 경우 해당 연결이 다른 스키마의 데이터에 액세스해야 하는 경우에도 연결 멀티플렉싱이 가능합니다. 멀티플렉싱은 각 테넌트에 대해 서로 다른 데이터베이스 계정을 사용하는 대신 애플리케이션 수준에서 테넌트 분리를 수행하는 경우 가장 효과적입니다.

다중 스키마 환경에서 멀티플렉싱 효율성은 테이블 이름을 참조하는 방법에 따라 달라집니다.

  • 세션 변수(PostgreSQL의 SET search_path ... 및 MySQL의 USE schema;)를 사용하여 현재 스키마를 선택한 다음 쿼리에서 정규화되지 않은 테이블 이름(예: SELECT ... FROM table_name)을 사용하는 클라이언트의 경우 연결 멀티플렉싱은 동일한 스키마 또는 동일한 검색 경로를 사용하는 클라이언트 간에만 작동합니다.

  • 세션 상태를 수정하여 현재 스키마를 정의하지 않고 대신 SQL 문에서 정규화된 테이블 이름(예: SELECT ... FROM schema_name.table_name)을 사용하는 클라이언트의 경우 멀티플렉싱이 유사하게 제한되지 않습니다.

여러 애플리케이션 또는 소프트웨어 스택을 제공하는 데이터베이스

이전 섹션에서 설명한 것처럼 특정 연결 상태 특성으로 인해 고정이 발생하지는 않지만 프록시가 서로 다른 클라이언트 간의 연결을 재사용하는 기능은 여전히 감소합니다. MySQL 대상과 함께 사용할 경우 RDS Proxy는 문자 집합, 시간대 및 데이터 정렬 설정과 같이 세션 상태를 구성하는 여러 문 및 세션 변수를 추적합니다. 클라이언트가 추적된 문 또는 변수를 사용하여 세션 설정을 구성하는 경우 프록시 연결은 해당 설정에 대해 동일한 값을 가진 다른 클라이언트에만 재사용할 수 있습니다.

따라서 특정 애플리케이션 및 드라이버 동작으로 인해 프록시 내부의 연결을 재사용하는 기능이 저하될 수 있습니다. 예를 들어 프록시가 해당 애플리케이션 간의 연결을 재사용하고 멀티플렉스할 수 있다고 가정하면 다른 애플리케이션이 동일한 사용자 이름을 사용하여 데이터베이스에 연결하도록 허용할 수 있습니다. 그러나 한 애플리케이션이 시간대 A(SET time_zone = ?)와의 연결을 부트스트랩하고 다른 애플리케이션이 시간대 B를 사용하는 경우 애플리케이션 내에서 연결을 재사용할 수 있지만 애플리케이션 간에는 재사용할 수 없습니다. 이로 인해 연결 풀이 조각화되어 풀링 및 멀티플렉싱의 효과에 부정적인 영향을 미칩니다.

자세한 내용은 RDS 프록시가 Aurora MySQL 데이터베이스에서 추적하는 대상 섹션을 참조하세요. 세션 상태 추적은 현재 MySQL 이외의 데이터베이스 대상에는 지원되지 않습니다.

연결 고정을 방지하기 위한 세션 상태 관리에 대한 구성 지침 및 모범 사례는 구성 지침 섹션을 참조하세요.

RDS Proxy에서 애플리케이션 수준 풀링 및 고급 드라이버 사용

RDS Proxy는 애플리케이션 자체가 연결 풀링을 사용하지 않는 상황에서 확장성과 연결 효율성을 개선하는 데 도움이 됩니다. 동시에 많은 드라이버와 프레임워크에 풀링 기능이 포함되어 있습니다. 드라이버 수준에서 프록시의 일부 기능을 구현하는 고급 래퍼 또는 드라이버를 사용하고 있을 수도 있습니다.

애플리케이션 수준 풀링 및 기타 연결 처리 개선 사항을 사용하는 것은 RDS Proxy 사용과 본질적으로 충돌하지 않으며 이점을 부정하지 않습니다. 예를 들어 애플리케이션 컨테이너에서 연결 풀링을 사용할 수 있지만 프록시를 사용하지 않고 데이터베이스 연결 제한이 여전히 부족할 정도로 컨테이너 수가 큽니다. 애플리케이션 수준 풀 및 기타 연결 관련 기능과 함께 RDS Proxy를 사용하는 경우 애플리케이션 수준에서 고급 연결 처리 기능이 존재하는 이유를 검토하고 이해합니다. 이러한 기능 중 유지할 가치가 있는 기능(또는 무해한 기능)과 프록시 동작을 겹치거나 방해할 수 있는 기능을 결정합니다. 예제:

  1. 드라이버 및 프레임워크에 내장된 풀링 기능은 RDS Proxy 기능과 겹치는 것처럼 보이더라도 유용할 수 있습니다. 프록시에서 제공하는 이점 외에도 애플리케이션 수준 풀이 로컬 연결 효율성을 개선하는 경우 유지할 수 있습니다.

  2. 장애 조치 처리와 관련된 기능은 RDS Proxy 로직을 방해하거나 이점을 제공하지 않고 전체 스택 복잡성을 증가시킬 수 있습니다. 예를 들어 애플리케이션이 DNS 관련 장애 조치 지연을 방지하기 위해 Aurora 클러스터의 토폴로지를 적극적으로 추적하는 경우 더 이상 RDS Proxy를 사용할 필요가 없습니다. 이 토폴로지 추적 로직을 유지하면 애플리케이션 스레드가 프록시를 우회하고 개별 데이터베이스 인스턴스에 직접 연결하는 등 원치 않는 동작이 발생할 수 있습니다. 이 시나리오에서는 애플리케이션 수준 추적 로직을 비활성화하고 RDS Proxy가 클러스터 토폴로지를 추상화하도록 할 수 있습니다.

  3. 연결 풀링 라이브러리는 이론적으로는 유용해 보이지만 프록시 동작을 방해하는 상태 관리 기능을 사용할 수 있습니다. 이러한 예제 중 하나는 차용 간의 연결 상태를 재설정하기 위해 DISCARD ALL 쿼리를 직접적으로 호출하는 PostgreSQL 라이브러리입니다. 연결을 재설정하면 풀링 및 멀티플렉싱에 도움이 되는 것처럼 보일 수 있지만 Amazon RDS Proxy의 내부 세션 상태 관리를 방해합니다. DISCARD를 사용할 때 프록시는 릴리스 시 클라이언트 연결을 고정하여 멀티플렉싱 효율성을 줄입니다.

유지하는 애플리케이션 수준 연결 처리 구성 요소의 경우 구성이 Amazon RDS Proxy에서 사용하는 연결 처리 로직을 방해하지 않는지 확인합니다. 예제:

  • 스택의 모든 계층에서 풀 크기 조정을 조정합니다. 애플리케이션 수준 풀의 크기가 크거나(또는 프록시 풀의 크기가 작으면) 애플리케이션은 프록시가 처리하도록 구성되지 않은 연결을 열려고 시도할 수 있습니다. 이러한 연결은 최대한 지연되고 최악의 경우 거부 오류가 발생할 수 있습니다.

  • 제한 시간 설정을 조정하여 이탈을 줄이고 연결 동작에 대한 혼동을 방지합니다. 애플리케이션 풀이 300초 동안 연결을 유지하지만 프록시가 60초 후에 연결을 닫도록 구성된 경우 예상 동작 대신 조기 연결 종료가 표시됩니다.

이러한 아키텍처 결정 및 구성 선택 중 일부는 테스트 및 실험이 필요할 수 있습니다. 여러 계층의 풀링 및 연결 관리가 있는 환경에서 애플리케이션 동작을 정확하게 예측할 수 있는 것은 아닙니다.

일반적인 구성 지침은 구성 지침 섹션을 참조하세요.