들어가며

안녕하세요. 백엔드 엔지니어로 일하다 보면 데이터베이스 연결 관리는 항상 중요한 과제입니다. 특히 서버리스 환경이나 트래픽이 급증하는 상황에서 데이터베이스 커넥션 문제로 인한 장애를 경험해본 적이 있으실 겁니다. 이번 포스트에서는 AWS에서 제공하는 RDS Proxy가 무엇이고, 어떤 문제를 해결해주는지 알아보도록 하겠습니다.

RDS Proxy란 무엇인가?

AWS RDS Proxy는 Amazon RDS와 Aurora 데이터베이스 앞에 위치하는 완전 관리형 데이터베이스 프록시 서비스입니다. 애플리케이션과 데이터베이스 사이에서 중간자 역할을 하며, 데이터베이스 연결을 효율적으로 관리하고 공유합니다.

기본적인 아키텍처는 다음과 같습니다:

RDS Proxy는 2019년 AWS re:Invent에서 처음 발표되었으며, 특히 서버리스 아키텍처와 같이 짧은 수명을 가진 연결이 많은 환경에서 유용하게 사용됩니다.

RDS Proxy가 해결하는 문제들

1. Too Many Connections 문제

데이터베이스에는 동시 연결 수에 제한이 있습니다. 예를 들어 MySQL의 경우 기본적으로 max_connections 파라미터로 최대 연결 수가 제한됩니다.

특히 다음과 같은 상황에서 문제가 발생합니다:

• Lambda와 같은 서버리스 환경: 각 Lambda 실행마다 새로운 데이터베이스 연결을 생성하면, 트래픽이 급증할 때 순식간에 데이터베이스 연결 한계에 도달할 수 있습니다.
• 마이크로서비스 아키텍처: 여러 서비스가 동일한 데이터베이스에 연결할 때, 각 서비스의 커넥션 풀이 독립적으로 관리되면 전체 연결 수가 빠르게 증가합니다.
• 트래픽 스파이크: 갑작스러운 트래픽 증가로 인해 애플리케이션 인스턴스가 스케일 아웃될 때, 데이터베이스 연결 수도 비례해서 증가합니다.

RDS Proxy는 이러한 문제를 커넥션 풀링(Connection Pooling) 을 통해 해결합니다:

애플리케이션으로부터의 수많은 연결을 받아서, 실제 데이터베이스로는 훨씬 적은 수의 연결만 유지합니다.

2. Connection Overhead 감소

데이터베이스 연결을 새로 생성하는 것은 비용이 많이 드는 작업입니다:

• TCP 핸드셰이크
• TLS/SSL 협상 (암호화된 연결의 경우)
• 인증 프로세스
• 세션 초기화

매번 새로운 연결을 생성하고 종료하는 대신, RDS Proxy는 연결을 재사용함으로써 이러한 오버헤드를 크게 줄여줍니다. 이는 특히 짧은 수명의 연결이 많은 서버리스 환경에서 큰 성능 개선 효과를 가져옵니다.

3. 데이터베이스 장애 조치(Failover) 시간 단축

RDS나 Aurora에서 장애 조치가 발생하면, 일반적으로 애플리케이션은 연결 오류를 감지하고 재연결을 시도해야 합니다. 이 과정에서 상당한 다운타임이 발생할 수 있습니다.

RDS Proxy는 장애 조치 시:

• 새로운 데이터베이스 엔드포인트로 자동으로 라우팅
• 실패한 연결을 버퍼링했다가 재시도
• 애플리케이션 코드 변경 없이 장애 복구 시간을 최대 66%까지 단축

RDS Proxy의 주요 기능

커넥션 풀링 및 공유

RDS Proxy의 핵심 기능입니다. 여러 애플리케이션 연결을 하나의 데이터베이스 연결로 멀티플렉싱하여, 데이터베이스의 메모리와 CPU 리소스를 효율적으로 사용할 수 있게 합니다.

IAM 인증 지원

RDS Proxy는 AWS IAM 인증을 지원하여, 데이터베이스 자격 증명을 코드에 하드코딩하지 않고도 안전하게 인증할 수 있습니다. 또한 AWS Secrets Manager와 통합되어 자격 증명을 안전하게 관리합니다.

자동 스케일링

트래픽에 따라 RDS Proxy가 자동으로 스케일링되므로, 운영자가 별도로 용량을 관리할 필요가 없습니다.

트랜잭션 경계 인식

RDS Proxy는 트랜잭션이 진행 중인지 감지하고, 트랜잭션이 완료될 때까지 동일한 데이터베이스 연결을 유지합니다. 이를 통해 트랜잭션의 일관성을 보장합니다.

RDS Proxy의 Reader/Writer 엔드포인트

Aurora의 경우 하나의 Writer 인스턴스와 여러 Reader 인스턴스가 있습니다. RDS Proxy는 이러한 구조를 지원하기 위해 두 가지 타입의 엔드포인트를 제공합니다:

Reader/Writer 엔드포인트 구조

Writer/Reader Endpoint 비교

연결 방식 예시

애플리케이션에서는 용도에 따라 다른 엔드포인트를 사용합니다:

# Writer Endpoint - 쓰기 작업용
writer_connection = pymysql.connect(
    host='my-proxy.proxy-xxx.us-east-1.rds.amazonaws.com',
    user='admin',
    password='password',
    database='mydb'
)

# Reader Endpoint - 읽기 작업용
reader_connection = pymysql.connect(
    host='my-proxy.proxy-xxx.us-east-1.rds.amazonaws.com:ro',
    user='admin',
    password='password',
    database='mydb'
)

Pinning 동작

RDS Proxy는 특정 상황에서 연결을 특정 데이터베이스 인스턴스에 “고정(Pinning)“합니다:

다음과 같은 경우 Pinning이 발생합니다:

• 명시적 트랜잭션 사용 시 (BEGIN, START TRANSACTION)
• 세션 변수 설정 시
• 임시 테이블 생성 시
• Prepared Statement 사용 시

Pinning이 발생하면 커넥션 풀링의 효율이 감소하므로, 가능한 한 피하는 것이 좋습니다.

언제 RDS Proxy를 사용해야 하는가?

RDS Proxy는 다음과 같은 경우에 특히 유용합니다:

사용을 권장하는 경우

1. AWS Lambda를 사용하는 경우

   • Lambda는 기본적으로 각 실행마다 새로운 연결을 생성하므로, RDS Proxy를 사용하면 큰 효과를 볼 수 있습니다.

2. 짧은 수명의 연결이 많은 경우

   • 빈번한 연결 생성/종료가 발생하는 애플리케이션

3. 예측 불가능한 트래픽 패턴

   • 갑작스러운 트래픽 증가에 대비해야 하는 경우

4. 마이크로서비스 아키텍처

   • 여러 서비스가 동일한 데이터베이스를 공유하는 경우

5. 높은 가용성이 필요한 경우

   • 데이터베이스 장애 조치 시간을 최소화해야 하는 경우

사용이 적합하지 않은 경우

1. 지속적인 연결을 유지하는 애플리케이션

   • 이미 효율적인 커넥션 풀을 사용하고 있다면 추가 이점이 크지 않을 수 있습니다.

2. 비용에 민감한 경우

   • RDS Proxy는 추가 비용이 발생하므로, 비용 대비 효과를 고려해야 합니다.

3. 매우 낮은 지연 시간이 중요한 경우

   • 프록시를 거치면서 약간의 추가 지연이 발생할 수 있습니다(일반적으로 1-5ms).

4. Pinning이 자주 발생하는 경우

   • 트랜잭션, 세션 변수, 임시 테이블 등을 많이 사용하면 커넥션 풀링 효과가 감소합니다.

마치며

AWS RDS Proxy는 데이터베이스 연결 관리의 복잡성을 추상화하고, 특히 서버리스 환경에서 발생할 수 있는 커넥션 문제를 효과적으로 해결해주는 서비스입니다.

핵심 포인트를 정리하면:

• 커넥션 풀링으로 데이터베이스 연결 수를 획기적으로 감소
• Reader/Writer 엔드포인트를 통한 읽기/쓰기 트래픽 분산
• 자동 Failover로 장애 복구 시간 단축
• IAM 인증으로 보안 강화

하지만 모든 상황에 만능은 아니므로, 자신의 애플리케이션 특성(트랜잭션 패턴, 연결 수명, 트래픽 패턴 등)과 요구사항을 고려하여 도입 여부를 결정하는 것이 중요합니다.

참고자료

• AWS RDS Proxy Documentation
• Amazon RDS Proxy – Now Generally Available
• Using Amazon RDS Proxy with AWS Lambda
• Best practices for working with Amazon RDS Proxy