Amazon RDS 프록시 엔드포인트 작업 - Amazon Aurora
프록시 엔드포인트 개요프록시 엔드포인트에 대한 제한 사항Aurora 클러스터에 리더 엔드포인트 사용VPC 간에 Aurora 데이터베이스 액세스

Amazon RDS 프록시 엔드포인트 작업

RDS 프록시 엔드포인트와 그 사용 방법에 대해 알아봅니다. 프록시 엔드포인트를 사용하면 다음과 같은 기능을 활용할 수 있습니다.

  • 프록시와 함께 여러 엔드포인트를 사용하여 여러 애플리케이션의 연결을 독립적으로 모니터링하고 문제를 해결할 수 있습니다.

  • Aurora DB 클러스터에 리더 엔드포인트를 사용하면 쿼리 집약적 애플리케이션의 읽기 확장성과 고가용성을 높일 수 있습니다.

  • VPC 간 엔드포인트를 사용하면 다른 VPC의 Amazon EC2 인스턴스와 같은 리소스에서 특정 VPC의 데이터베이스에 액세스하도록 허용할 수 있습니다.

주제

프록시 엔드포인트 개요

RDS 프록시 엔드포인트 작업을 수행하려면 Aurora DB 클러스터 및 리더 엔드포인트와 동일한 절차를 따릅니다. Aurora 엔드포인트에 익숙하지 않은 경우 Amazon Aurora 엔드포인트 연결에서 자세한 내용을 참조하세요.

기본적으로, Aurora 클러스터에 RDS Proxy를 사용할 때 연결하는 엔드포인트에는 읽기/쓰기 기능이 있습니다. 따라서 이 엔드포인트는 모든 요청을 클러스터의 라이터 인스턴스로 보냅니다. 이러한 모든 연결은 라이터 인스턴스의 max_connections 값에 포함됩니다. 프록시가 Aurora DB 클러스터에 연결되어 있는 경우, 해당 프록시에 대해 추가 읽기/쓰기 또는 읽기 전용 엔드포인트를 생성할 수 있습니다.

읽기 전용 쿼리를 위해 프록시와 함께 읽기 전용 엔드포인트를 사용할 수 있습니다. Aurora 프로비저닝된 클러스터에 리더 엔드포인트를 사용하는 것과 동일한 방식으로 이를 수행합니다. 이렇게 하면 하나 이상의 리더 DB 인스턴스가 있는 Aurora 클러스터의 읽기 확장성을 활용할 수 있습니다. 읽기 전용 엔드포인트를 사용하고 필요에 따라 Aurora 클러스터에 리더 DB 인스턴스를 더 추가하여 동시 쿼리를 더 많이 실행하고 동시 연결을 더 많이 생성할 수 있습니다.

작은 정보

AWS Management Console을 사용하여 Aurora 클러스터에 대한 프록시를 생성할 때 RDS 프록시를 선택하여 리더 엔드포인트를 자동으로 생성할 수 있습니다. 리더 엔드포인트의 이점에 대한 자세한 내용은 Aurora 클러스터에 리더 엔드포인트 사용 섹션을 참조하세요.

생성한 프록시 엔드포인트의 경우, 엔드포인트를 프록시 자체에 사용되는 다른 Virtual Private Cloud(VPC)와 연결할 수도 있습니다. 이렇게 하면 조직의 다른 애플리케이션에 사용되는 VPC와 같은 다른 VPC에서 프록시에 연결할 수 있습니다.

프록시 엔드포인트과 관련한 제한 사항에 대한 자세한 내용은 프록시 엔드포인트에 대한 제한 사항 섹션을 참조하세요.

RDS 프록시 로그에서 각 항목에는 연결된 프록시 엔드포인트의 이름이 접두사로 붙습니다. 이 이름은 사용자 정의 엔드포인트에 지정한 이름일 수 있습니다. 아니면 읽기/쓰기 요청을 수행하는 프록시의 기본 엔드포인트에 대한 특수 이름(default)일 수 있습니다.

각 프록시 엔드포인트에는 일련의 자체 CloudWatch 지표가 있습니다. 프록시의 모든 엔드포인트에 대한 지표를 모니터링할 수 있습니다. 특정 엔드포인트 또는 프록시의 모든 읽기/쓰기 또는 읽기 전용 엔드포인트에 대한 지표를 모니터링할 수도 있습니다. 자세한 내용은 Amazon CloudWatch를 사용한 RDS 프록시 지표 모니터링 섹션을 참조하세요.

프록시 엔드포인트는 연결된 프록시와 동일한 인증 메커니즘을 사용합니다. RDS Proxy는 연결된 프록시의 속성과 일치하는 사용자 정의 엔드포인트에 대한 권한 및 승인을 자동으로 설정합니다.

Aurora 글로벌 데이터베이스의 DB 클러스터에서 프록시 엔드포인트가 작동하는 방법을 알아보려면 RDS 프록시 엔드포인트가 글로벌 데이터베이스에서 작동하는 방식 섹션을 참조하세요.

프록시 엔드포인트에 대한 제한 사항

RDS 프록시 엔드포인트에는 다음과 같은 제한 사항이 있습니다.

  • 각 프록시에는 수정할 수는 있지만 생성하거나 삭제할 수 없는 기본 엔드포인트가 있습니다.

  • 프록시의 사용자 정의 엔드포인트의 최대 개수는 20개입니다. 따라서 프록시는 최대 21개의 엔드포인트(기본 엔드포인트와 사용자가 생성하는 20개)를 가질 수 있습니다.

  • 추가 엔드포인트를 프록시와 연결할 때 RDS Proxy는 클러스터에서 각 엔드포인트에 사용할 DB 인스턴스를 자동으로 결정합니다. Aurora 사용자 지정 엔드포인트처럼 특정 인스턴스를 지정할 수는 없습니다.

Aurora 클러스터에 리더 엔드포인트 사용

Aurora 클러스터에 RDS Proxy를 사용할 경우 리더 엔드포인트라는 읽기 전용 엔드포인트를 생성하고 연결할 수 있습니다. 이러한 리더 엔드포인트는 쿼리 집약적 애플리케이션의 읽기 확장성을 개선하는 데 도움이 됩니다. 또한 리더 엔드포인트는 클러스터의 리더 DB 인스턴스를 사용할 수 없게 될 경우 연결 가용성을 높이는 데에도 도움이 됩니다.

참고

새 엔드포인트를 읽기 전용으로 지정할 경우, RDS Proxy를 사용하려면 Aurora 클러스터에 리더 DB 인스턴스가 하나 이상 있어야 합니다. 경우에 따라 프록시의 대상을 단일 라이터만 포함하는 Aurora 클러스터로 변경할 수 있습니다. 그렇게 하면 오류로 인해 읽기 전용 엔드포인트에 대한 요청에 실패합니다. 프록시의 대상이 Aurora 클러스터가 아니라 RDS 인스턴스인 경우에도 요청이 실패합니다.

Aurora 클러스터에 리더 인스턴스가 있지만 해당 인스턴스를 사용할 수 없는 경우, RDS Proxy는 즉시 오류를 반환하는 대신 요청을 전송할 때까지 기다립니다. 연결 대여 제한 시간 내에 리더 인스턴스가 사용 가능한 상태가 되지 않으면 오류가 발생하여 요청이 실패합니다.

리더 엔드포인트가 애플리케이션 가용성을 높이는 방법

경우에 따라 클러스터에 있는 하나 이상의 리더 인스턴스를 사용할 수 없게 될 수 있습니다. 이 경우 DB 프록시의 리더 엔드포인트를 사용하는 연결은 Aurora 리더 엔드포인트를 사용하는 연결보다 더 빠르게 복구됩니다. RDS Proxy는 클러스터에서 사용 가능한 리더 인스턴스로만 연결을 라우팅합니다. 인스턴스를 사용할 수 없게 될 때 DNS 캐싱으로 인해 지연이 발생하지 않습니다.

연결이 다중화된 경우 RDS Proxy는 애플리케이션을 중단하지 않고 후속 쿼리를 다른 리더 DB 인스턴스로 보냅니다. 새 리더 인스턴스로 자동 전환하는 동안 RDS Proxy는 이전 및 새 리더 인스턴스의 복제 지연을 확인합니다. RDS Proxy는 새 리더 인스턴스가 이전 리더 인스턴스와 동일한 변경 사항이 적용된 최신 버전인지 확인합니다. 따라서 RDS Proxy가 리더 DB 인스턴스 간에 전환할 때 애플리케이션에서 오래된 데이터 문제가 발생하지 않습니다.

연결이 고정된 경우 연결에 대한 다음 쿼리에서 오류가 반환됩니다. 그러나 애플리케이션은 동일한 엔드포인트에 즉시 다시 연결할 수 있습니다. RDS Proxy는 available 상태에 있는 다른 리더 DB 인스턴스로 연결을 라우팅합니다. 수동으로 다시 연결하면 RDS Proxy가 이전 리더 인스턴스와 새 리더 인스턴스 간의 복제 지연을 확인하지 않습니다.

Aurora 클러스터에 사용 가능한 리더 인스턴스가 없는 경우 RDS Proxy는 이 조건이 일시적인지 영구적인지 여부를 확인합니다. 각 경우의 동작은 다음과 같습니다.

  • 클러스터에 하나 이상의 리더 DB 인스턴스가 있지만 그 중 어느 것도 Available 상태가 아닙니다. 예를 들어 모든 리더 인스턴스가 재부팅되거나 문제가 발생했을 수 있습니다. 이 경우 리더 엔드포인트에 대한 연결을 시도하면 리더 인스턴스를 사용할 수 있을 때까지 기다립니다. 연결 대여 제한 시간 내에 리더 인스턴스가 사용 가능한 상태가 되지 않으면 연결 시도가 실패합니다. 리더 인스턴스를 사용할 수 있게 되면 연결 시도가 성공합니다.

  • 클러스터에 리더 DB 인스턴스가 없다고 가정합니다. 이 경우 리더 엔드포인트에 연결하려고 하면 RDS Proxy가 즉시 오류를 반환합니다. 이 문제를 해결하려면 리더 엔드포인트에 연결하기 전에 하나 이상의 리더 인스턴스를 클러스터에 추가합니다.

리더 엔드포인트가 쿼리 확장성을 높이는 방법

프록시용 리더 엔드포인트는 다음과 같은 방법으로 Aurora 쿼리 확장성을 높입니다.

  • 리더 인스턴스를 Aurora 클러스터에 추가하면 RDS Proxy가 리더 엔드포인트에 대한 새 연결을 다른 리더 인스턴스로 라우팅할 수 있습니다. 이렇게 하면 특정 리더 엔드포인트 연결을 사용하여 수행되는 쿼리가 다른 리더 엔드포인트 연결을 사용하여 수행되는 쿼리 속도를 저하시키지 않습니다. 쿼리는 별도의 DB 인스턴스에서 실행됩니다. 각 DB 인스턴스에는 자체 컴퓨팅 리소스, 버퍼 캐시 등이 있습니다.

  • 가능한 경우 RDS Proxy는 특정 리더 엔드포인트 연결을 사용하는 모든 쿼리 문제에 대해 동일한 리더 DB 인스턴스를 사용합니다. 이렇게 하면 동일한 테이블에 있는 일련의 관련 쿼리가 특정 DB 인스턴스에서 캐싱, 계획 최적화 등을 활용할 수 있습니다.

  • Reader DB 인스턴스를 사용할 수 없게 되면 세션이 멀티플렉싱되었는지 고정되어 있는지에 따라 애플리케이션에 미치는 영향이 달라집니다. 세션이 멀티플렉싱된 경우 RDS Proxy는 후속 쿼리를 사용자의 작업 없이 다른 리더 DB 인스턴스로 라우팅합니다. 세션이 고정되어 있으면 애플리케이션에 오류가 발생하여 다시 연결해야 합니다. 리더 엔드포인트에 즉시 다시 연결할 수 있으며 RDS Proxy는 연결을 사용 가능한 리더 DB 인스턴스로 라우팅합니다. 프록시 세션의 멀티플렉싱 및 고정에 대한 자세한 내용은 RDS Proxy 개념 개요 섹션을 참조하세요.

  • 클러스터에 리더 DB 인스턴스가 많을수록 리더 엔드포인트를 사용하여 더 많은 동시 연결을 생성할 수 있습니다. 예를 들어 클러스터에 각각 200개의 동시 연결을 지원하도록 구성된 4개의 리더 DB 인스턴스가 있다고 가정합니다. 또한 프록시가 최대 연결의 50%를 사용하도록 구성되어 있다고 가정합니다. 여기서 프록시의 리더 엔드포인트를 통해 생성할 수 있는 최대 연결 수는 리더 1의 경우 100개(200개의 50%)입니다. 또한 리더 2에 대해 100개와 같은 식으로 총 400개까지 생성할 수 있습니다. 클러스터 리더 DB 인스턴스의 수를 8개로 두 배로 늘리면 리더 엔드포인트를 통한 최대 연결 수도 800개로 두 배가 됩니다.

리더 엔드포인트 사용의 예

다음 Linux 예제는 사용자가 리더 엔드포인트를 통해 Aurora MySQL 클러스터에 연결되었는지 확인하는 방법을 보여 줍니다. innodb_read_only 구성 설정이 활성화되어 있습니다. CREATE DATABASE 문과 같은 쓰기 작업을 수행하려고 하면 오류가 발생하여 실패합니다. 또한 aurora_server_id 변수를 확인하여, 리더 DB 인스턴스에 연결되어 있는지 확인할 수 있습니다.

작은 정보

DB 인스턴스 이름을 확인해야만 연결이 읽기/쓰기인지 아니면 읽기 전용인지 확인할 수 있습니다. Aurora 클러스터의 DB 인스턴스는 장애 조치가 발생할 때 라이터 및 리더 사이에서 역할을 바꿀 수 있습니다.

$ mysql -h endpoint-demo-reader.endpoint.proxy-demo.us-east-1.rds.amazonaws.com -u admin -p
...
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+
mysql> create database shouldnt_work;
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement

mysql> select @@aurora_server_id;
+---------------------------------------+
| @@aurora_server_id                    |
+---------------------------------------+
| proxy-reader-endpoint-demo-instance-3 |
+---------------------------------------+

다음 예에서는 리더 DB 인스턴스가 삭제되더라도 프록시 리더 엔드포인트에 대한 연결이 어떻게 계속 작동하는지 보여 줍니다. 이 예에서 Aurora 클러스터에는 두 개의 리더 인스턴스, instance-5507 및 instance-7448이 있습니다. 리더 엔드포인트에 대한 연결이 리더 인스턴스 중 하나를 사용하기 시작합니다. 예를 들어 이 리더 인스턴스는 delete-db-instance 명령에 의해 삭제됩니다. RDS Proxy는 후속 쿼리를 위해 다른 리더 인스턴스로 전환합니다.

$ mysql -h reader-demo.endpoint.proxy-demo.us-east-1.rds.amazonaws.com
  -u my_user -p
...
mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-5507      |
+--------------------+

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+

mysql> select count(*) from information_schema.tables;
+----------+
| count(*) |
+----------+
|      328 |
+----------+

mysql 세션이 계속 실행 중이지만, 다음 명령은 리더 엔드포인트가 연결된 리더 인스턴스를 삭제합니다.

aws rds delete-db-instance --db-instance-identifier instance-5507 --skip-final-snapshot

mysql 세션의 쿼리는 다시 연결할 필요 없이 계속 작동합니다. RDS Proxy가 자동으로 다른 리더 DB 인스턴스로 전환합니다.

mysql> select @@aurora_server_id;
+--------------------+
| @@aurora_server_id |
+--------------------+
| instance-7448      |
+--------------------+

mysql> select count(*) from information_schema.TABLES;
+----------+
| count(*) |
+----------+
|      328 |
+----------+

VPC 간에 Aurora 데이터베이스 액세스

기본적으로 Aurora 기술 스택의 구성 요소는 모두 동일한 Amazon VPC에 있습니다. 예를 들어 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 Aurora DB 클러스터에 연결한다고 가정합니다. 이 경우 애플리케이션 서버와 데이터베이스가 모두 동일한 VPC 내에 있어야 합니다.

RDS 프록시를 사용하면 EC2 인스턴스와 같은 다른 VPC의 리소스에서 한 VPC에 있는 Aurora DB 클러스터에 대한 액세스를 설정할 수 있습니다. 예를 들어 조직에 동일한 데이터베이스 리소스에 액세스하는 애플리케이션이 여러 개 있을 수 있습니다. 각 애플리케이션은 자체 VPC에 있을 수 있습니다.

VPC 간 액세스를 활성화하려면 프록시를 위한 새 엔드포인트를 생성합니다. 프록시 자체는 Aurora DB 클러스터와 동일한 VPC에 상주합니다. 하지만 VPC 간 엔드포인트는 EC2 인스턴스 등의 다른 리소스와 함께 다른 VPC에 상주합니다. VPC 간 엔드포인트는 EC2 및 기타 리소스와 동일한 VPC의 서브넷 및 보안 그룹과 연결됩니다. 이러한 연결을 사용하면 VPC 제한으로 인해 데이터베이스에 액세스할 수 없는 애플리케이션이 엔드포인트에 연결할 수 있습니다.

다음 단계에서는 RDS Proxy를 통해 VPC 간 엔드포인트를 생성하고 액세스하는 방법을 설명합니다.

  1. VPC 2개를 생성하거나 Aurora 작업에 이미 사용 중인 VPC 2개를 선택합니다. 각 VPC에는 인터넷 게이트웨이, 라우팅 테이블, 서브넷 및 보안 그룹과 같은 연결된 자체 네트워크 리소스가 있어야 합니다. VPC가 하나만 있는 경우 Amazon Aurora 시작하기에서 Aurora를 성공적으로 사용하기 위해 다른 VPC를 설정하는 단계를 참조하세요. 또한 Amazon EC2 콘솔에서 기존 VPC를 조사하여 함께 연결할 리소스의 종류를 확인할 수 있습니다.

  2. 연결할 Aurora DB 클러스터에 연결된 DB 프록시를 생성합니다. RDS 프록시 생성의 절차를 따르십시오.

  3. RDS 콘솔에서 프록시의 [세부 정보(Details)] 페이지에 있는 [프록시 엔드포인트(Proxy endpoints)] 섹션에서 [엔드포인트 생성(Create endpoint)]을 선택합니다. 프록시 엔드포인트 생성의 절차를 따르십시오.

  4. VPC 간 엔드포인트를 읽기/쓰기와 읽기 전용 중 무엇으로 설정할지 선택합니다.

  5. Aurora DB 클러스터와 동일한 VPC인 기본값을 사용하지 않고, 다른 VPC를 선택합니다. 이 VPC는 프록시가 상주하는 VPC와 동일한 AWS 리전에 있어야 합니다.

  6. 이제 Aurora DB 클러스터와 동일한 VPC의 서브넷 및 보안 그룹에 대한 기본값을 사용하지 않고 새로 선택합니다. 선택한 VPC의 서브넷과 보안 그룹을 기준으로 선택합니다.

  7. Secrets Manager 보안 정보에 대한 설정은 변경할 필요가 없습니다. 각 엔드포인트가 속한 VPC에 관계없이 프록시의 모든 엔드포인트에 대해 동일한 자격 증명이 작동합니다.

  8. 새 엔드포인트가 [사용 가능(Available)] 상태로 바뀔 때까지 기다립니다.

  9. 전체 엔드포인트 이름을 기록해 둡니다. 이 값은 데이터베이스 애플리케이션의 연결 문자열의 일부로 제공하는 Region_name.rds.amazonaws.com으로 끝납니다.

  10. 엔드포인트와 동일한 VPC에 있는 리소스에서 새 엔드포인트에 액세스합니다. 이 프로세스를 테스트하는 간단한 방법은 이 VPC에 새 EC2 인스턴스를 생성하는 것입니다. 그런 다음 EC2 인스턴스에 로그인하고 mysql 또는 psql 명령을 실행하여 연결 문자열의 엔드포인트 값을 통해 연결합니다.