Amazon Aurora를 애플리케이션 개발자가 사용하기 위한 10가지 팁 – 1부

이 글은 AWS Database Delivery Blog에 게시된 10 Amazon Aurora tips for application developers – Part 1 by Rajeev Sakhuja을 한국어 번역 및 편집하였습니다.

Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 클라우드-네이티브 애플리케이션을 구축할 수 있는 엔터프라이즈 등급의 데이터베이스 엔진입니다. 애플리케이션 개발자는 코드를 작성하기 위해 Java 애플리케이션을 위한 JDBC 드라이버, Java 스크립트 애플리케이션을 위한 NodeJS 패키지들과 같은 기본 툴이나 라이브러리를 사용합니다. 개발자들은 종종 Aurora를 일반적인 RDBMS 데이터베이스 엔진처럼 취급하여 Aurora가 제공하는 다양한 기본 제공 기능을 활용하지 못하는 경우가 많습니다. 기본 제공 기능 외에도, Aurora는 기본적으로 다른 AWS 서비스와 통합되어 기능이 풍부하고 안전하며 성능이 뛰어난 애플리케이션을 구축할 수 있도록 지원합니다.

두 개의 블로그에서 우리는 애플리케이션 개발자로서 Aurora와 AWS의 다른 서비스들을 사용하여 애플리케이션의 보안, 성능, 안정성, 그리고 고가용성을 발전시킬 수 있는 팁을 공유할 것입니다. 1부를 통해, 독자는 애플리케이션의 읽기 전용 복제본, 빠른 장애조치, 클로닝, 글로벌 데이터베이스, 그리고 Amazon Aurora Serverless v2를 어떻게 최적화할 수 있는지 배우게 될 것입니다. 2부에서는 애플리케이션의 성능, 보안 그리고 고가용성을 어떻게 향상시킬 수 있는지 알려줄 것입니다.

사전조건

Amazon Aurora PostgreSQL-Compatible Edition 혹은 Amazon Aurora MySQL-Compatible Edition 을 통해 핸즈온 세션을 진행해볼 수 있습니다. 이 블로그는 Amazon Aurora PostgreSQL-Compatible Edition을 기준으로 작성되어 있습니다.

시작하기에 앞서 아래의 과정을 반드시 완료해야합니다:

리소스 생성 권한이 있는 AWS 계정을 가지고 있어야 합니다.
이 게시물에서 설명하는 다양한 기능을 사용해 보려면 Aurora PostgreSQL DB 클러스터(v13.7 이상)가 있어야 합니다. 기존 클러스터를 사용하거나 새 클러스터를 생성할 수 있습니다. 클러스터에는 항상 둘 이상의 DB 인스턴스를 사용하는 것이 가장 좋지만, 이 게시물에서는 단일 인스턴스로 클러스터를 생성해도 됩니다.
Amazon Linux 2 AMI 혹은 관련된 AMI를 사용하여 bastion 호스트 (an Amazon Elastic Compute Cloud (Amazon EC2) instance)를 생성합니다.
- AWS Command Line Interface (AWS CLI)와 PostgreSQL client (혹은 MySQL client)를 설치합니다.
- 데이터베이스와 동일한 VPC내에 작은 사이즈의 EC2 인스턴스를 생성합니다. 장비에서 연결이 가능한지 반드시 확인하시기 바랍니다.
- 네트워크 라우트를 설정하여, Aurora 엔드포인트와 연결할 수 있게 합니다.
- 아래의 커맨드를 사용하여 PostgreSQL client tools를 설치합니다.
  sudo amazon-linux-extras install postgresql13 -y
  sudo yum install postgresql-contrib-13.7 -y
- Python 코드를 사용하여, psycopg2 패키지를 설치합니다.
  pip install psycopg2-binary

Tip #1: 성능을 위해 SQL 읽기와 쓰기 트랜잭션을 분리하기

Aurora 데이터베이스 클러스터는 쓰기/읽기 쿼리 요청을 서빙하는 하나의 주 인스턴스로 이루어져 있습니다. 그리고 15개의 리드 리플리카를 생성할 수 있습니다. 읽기 전용 복제본은 읽기 쿼리만 서빙하며, 읽기 전용 복제본에 대한 업데이트, 삭제 혹은 입력 쿼리를 수행하게 되면 애플리케이션에서 SQL 오류가 발생하게 됩니다. Aurora는 클러스터에 대한 쓰기 SQL을 수행하기 위한 클러스터 엔드포인트를 노출합니다. Aurora는 읽기 전용 복제본에 대한 선택 쿼리를 수행하기 위한 읽기 엔드포인트를 노출합니다. 만약 한 개 이상의 읽기 전용 복제본이 있다면, Aurora는 커넥션을 분배하기 위해 DNS Round Robin 방식을 사용합니다. 이 커넥션 분배 메커니즘은 로드 밸런싱과 다른 방식으로 동작합니다. 아래의 그림은 이 아키텍처를 설명해주고 있습니다.

AWS 모범 사례에 따르면, 애플리케이션의 트랜잭션을 읽기 트랜잭션과 쓰기 트랜잭션으로 분할하고 적절한 엔드포인트를 사용하여 SQL을 적절한 DB 인스턴스로 라우팅하는 것을 권고합니다. 이 접근 방식을 사용하면 SQL 부하가 여러 DB 인스턴스에 분산되므로 데이터베이스에서 더 나은 성능을 얻을 수 있습니다. 읽기 일관성은 복제 지연(일반적으로 기본이 업데이트를 작성한 후 100밀리초 미만)으로 인해 결국 일관성이 유지되므로 쓰기 일관성 후 읽기가 필요한 트랜잭션이 있는 경우 해당 트랜잭션에 대해 클러스터 엔드포인트를 사용해야합니다. DB 클러스터에 단일 인스턴스가 있는 경우 두 엔드포인트가 모두 동일한 인스턴스를 가리킵니다. 클러스터에 인스턴스가 두 개 이상인 경우, 읽기 엔드포인트에 대해 쓰기 트랜잭션을 호출하면 애플리케이션 오류가 발생합니다.

만약 클러스터 내에 하나 이상의 인스턴스가 있는 경우, 읽기 전용 복제본 엔드포인트에 대한 쓰기 트랜잭션에 대해 선언을 하면 애플리케이션 에러가 발생하게 될 것입니다. 아래의 Python 예제 코드를 통해, 읽기 전용 복제본 엔드포인트에 대해 리드 트래픽(SQL selects)을 수행하고 클러스터 엔드포인트에 대해 읽기 트래픽을 수행할 것입니다. 커맨드 창이나 터미널에 이 코드를 수행해보십시오.

이미 생성한 데이터베이스를 사용하거나, 신규로 생성하세요;테스트를 위해 어떠한 테이블을 사용하여도 무방합니다.
데이터베이스 스키마와 일치하는 코드 내에 SELECT문과 INSERT문을 적용하십시오.
환경변수를 설정하고 프롬프트에서 코드를 수행하십시오.

# Read & Write transactions split
import psycopg2import os
# Set these environment variables (PG_USER, PG_PASSWORD, PG_DATABASE
# AURORA_CLUSTER_ENDPOINT, AURORA_READER_ENDPOINT)
USER = os.getenv('PG_USER')
PASSWORD = os.environ.get('PG_PASSWORD')
DATABASE = os.environ.get('PG_DATABASE')
# Aurora PostgreSQL cluster endpoint
WRITE_EP = os.environ.get('AURORA_CLUSTER_ENDPOINT')
# Aurora PostgreSQL reader endpoint
READ_EP  = os.environ.get('AURORA_READER_ENDPOINT')
def  get_all_orders(customer_id):
    sql = "SELECT * FROM orders WHERE customert_id=..."
# Connect to the READER endpoint
    conn = psycopg2.connect(
        host= READ_EP,
        database = DATABASE,
        user = USER, password = PASSWORD
    )
# create a cursor
    cur = conn.cursor()
    cur.execute(sql)

    rows = cur.fetchall()
# process the data ...
def add_order(order_details):
    sql = "INSERT INTO orders VALUES(...)"
# Connect to the CLUSTER endpoint
    conn = psycopg2.connect(
        host= WRITE_EP,
        database = DATABASE,
        user = USER, password = PASSWORD
    )
# Code for inserting an order ...

Aurora 엔드포인트를 테스트 해보겠습니다.

Amazon RDS 콘솔에서 데이터베이스로 이동합니다.
액션 메뉴에서 DB 클러스터를 선택하고, 읽기 추가를 선택합니다.
읽기 전용 복제본의 이름을 제공하고 다른 세팅은 기본값으로 설정합니다.
클러스터 엔드포인트를 복사하여 메모장에 남겨둡니다.
Bastion 호스트에 SSH로 연결하고, psql을 사용하여 클러스터 엔드포인트에 연결합니다.
psql -h <<Paste your cluster endpoint>> -U <<DB User name>>
=> \conninfo
DB 인스턴스의 IP 주소를 기록해 둡니다.
=> \q
메모장에 읽기 엔드포인트 정보를 복사합니다.
Bastion 호스트에 SSH로 붙고, psql을 이용하여 읽기 인스턴스에 연결합니다.
psql -h <<Paste your Reader endpoint>> -U <<DB User name>>
=> \conninfo
DB 인스턴스의 IP 주소를 기록합니다.
=> \q
두 엔드포인트의 IP 주소를 비교하면 다를 것입니다.
읽기 인스턴스에서 SQL 삽입을 실행해보면 실패합니다.
실행 중인 인스턴스는 비용이 발생하므로 완료되면 읽기 인스턴스를 삭제하여 정리해야합니다.

추가로, Aurora는 읽기 복제본에 대해 정책 기반 Auto Scaling 메커니즘을 제공하고 있습니다. Aurora Auto Scaling을 사용하면 클러스터의 읽기 인스턴스 수가 사용자 정의 Amazon CloudWatch 메트릭 혹은 읽기 전반의 평균 로드에 의해 자동으로 증가 혹은 감소할 수 있습니다. 리플리카 생성은 데이터베이스 사이즈에 따라 몇 분정도 소요될 수 있습니다. 이는 데이터베이스 인스턴스가 스토리지 볼륨을 공유하기 때문에 데이터를 읽기 인스턴스의 로컬 스토리지에 복사할 필요가 없는 Aurora의 컴퓨팅-스토리지 디커플링 기능 때문입니다.

Tip #2: 빠른 복구를 위한 JDBC 사용하기

Aurora 데이터베이스 클러스터의 읽기 복제본은 장애 조치 대상입니다. 장애조치는 수동으로 시작하거나 기본 인스턴스에 장애가 발생한 경우 자동으로 수행할 수 있습니다. 장애 조치 후에는 읽기 복제본 중 하나가 클러스터의 기본 인스턴스가 됩니다. 수동으로 장애조치가 시작된 경우, 원래의 쓰기 인스턴스가 읽기 노드가 됩니다. 자동 장애조치의 경우, Aurora 읽기 노드 중 하나가 새 쓰기 노드로 승격되고 이전 쓰기 노드는 교체되어 클러스터에 읽기 노드로 추가됩니다. Aurora는 클러스터 엔드포인트가 새 기본 인스턴스(IP 주소)를 가리키도록 자동으로 업데이트합니다. 애플리케이션이 클러스터 엔드포인트의 DNS 쿼리 결과를 장기간 캐싱하는 경우, 캐시에 있는 엔드포인트에 대한 오래된 IP 매핑으로 인해 애플리케이션에 오류가 발생할 수 있습니다. 아래 다이어그램은 해당 아키텍처를 보여줍니다.

Java로 작성된 애플리케이션은 MySQL용 AWS JDBC 드라이버를 사용하여 MySQL에 접속할 수 있습니다. 이 드라이버는 MySQL Connector/J 드라이버의 대체 가능한 버전으로 사용될 수 있습니다. 이 드라이버에는 클러스터 엔드포인트가 항상 클러스터 내의 쓰기 인스턴스에 매핑되도록 하는 메커니즘이 내장되어 있습니다. 그 결과, MySQL용 AWS JDBC 드라이버를 사용하는 Java 애플리케이션은 MySQL Connector/J 드라이버를 사용하는 애플리케이션에 비해 복구 속도가 빨라집니다. 이와 유사하게 Amazon Aurora PostgreSQL-Compatible Edition에 접속하는 Java 애플리케이션의 경우, PostgreSQL용 AWS JDBC 드라이버를 사용할 수 있습니다. JDBC 드라이버 교체에 제약이 있는 경우, 빠른 복구를 위해 Java 애플리케이션의 DNS TTL(Time to Live) 설정을 조정할 수 있습니다.

DNS TTL은 DNS 확인자가 새 쿼리를 요청하기 전에 쿼리를 캐시할 시간을 알려주는 설정입니다. 모범 사례로, DNS TTL을 30초 미만으로 설정하는 것이 좋습니다. 이렇게 하면 애플리케이션이 합리적인 시간 내에 새 기본 인스턴스에 다시 연결할 수 있습니다. 앱에 대해 연속 로드를 실행하고 강제 장애 조치를 수행하여 애플리케이션의 장애 조치 복구 동작을 테스트하는 것이 좋습니다.

호스트에서 실행 중인 모든 Java 앱에 대해 전역적으로 DNS TTL을 설정하려면 $JAVA_HOME/jre/lib/security/java.security 파일을 편집하여 속성을 설정하면 됩니다:

networkaddress.cache.ttl=15

Java 코드에서 DNS TTL을 설정할 수도 있습니다:

java.security.Security.setProperty(“networkaddress.cache.ttl”, “15”)

여기서 설명하는 기술은 Java 앱을 더 빠르게 복구하는 데 도움이 되지만, 이 시리즈의 2부에서 다루는 Amazon RDS Proxy를 사용하는 것을 권장합니다.

Tip #3: 프로덕션 데이터로 테스트 할 클론 생성하기

Aurora Fast Cloning 기능을 사용하면 동일한 Aurora 클러스터 볼륨을 사용하며 원본과 동일한 데이터를 가진 새로운 클러스터를 생성할 수 있습니다. 새로 생성된 클러스터는 원본 클러스터와 스토리지 레이어를 공유하기 때문에 스냅샷/복원이 필요 없으며, 그 결과 데이터베이스 크기에 관계없이 매우 빠른 복제가 가능합니다. 동일한 리전에 있는 클러스터에 최대 15개의 복제본을 생성할 수 있습니다. Aurora는 복제된 클러스터의 스토리지 관리를 위해 Copy-on-Write 프로토콜을 사용합니다. 클러스터에 대해 읽기 또는 쓰기가 수행 되더라도 다른 클러스터의 데이터는 변경되지 않습니다.

예를 들어 복제본 생성 시점에 데이터베이스 테이블에 10개의 행이 있다고 가정해 보겠습니다. 복제본이 생성된 후 원본 클러스터에 새 행을 추가하기 위해 삽입이 호출됩니다. 이 시점에서 원본 클러스터에 대한 SQL SELECT count(*) FROM .. 쿼리는 11개의 행을 표시하는 반면, 복제된 클러스터에 대한 동일한 쿼리는 10개의 행을 표시합니다. 복제된 클러스터에서는 새 행이 표시되지 않습니다.

Aurora 스토리지 아키텍처는 스토리지 노드의 데이터를 3개의 가용 영역에 분산 시킵니다. 따라서 스토리지 볼륨을 공유하는 클러스터가 다른 클러스터의 활동으로 인해 스토리지 지연 시간을 경험할 가능성은 거의 없습니다. 아래 다이어그램은 해당 아키텍처를 보여 줍니다.

애플리케이션 개발자는 종종 프로덕션 데이터에 대해 코드를 테스트합니다. 기존 데이터베이스 또는 Amazon 관계형 데이터베이스 서비스(Amazon RDS) 데이터베이스를 사용 중인 경우, 새 클러스터를 생성하고 원본 데이터베이스의 데이터를 테스트 데이터베이스로 복사하는 방법밖에 없습니다. 테스트 데이터베이스를 세팅하는 이 과정에는 리소스와 시간이 필요합니다. Aurora 복제 기능을 사용하면 몇 분 안에 테스트 데이터베이스 인스턴스를 사용할 수 있습니다. 프로덕션과 개발이 서로 다른 두 개의 AWS 계정을 사용하는 경우, 개발팀이 프로덕션 Aurora 데이터베이스 클러스터의 복제본을 생성할 수 있는 Aurora cross-acount 복제 기능을 사용할 수 있습니다. 이를 통해 개발자는 프로덕션 클러스터에 영향을 주지 않고 프로덕션 데이터에 대해 앱을 테스트할 수 있습니다.

또한, 복제 기능은 데이터베이스 엔진 업그레이드에도 사용할 수 있습니다. 기존 데이터베이스의 복제본을 생성하고, 복제된 데이터베이스 클러스터를 최신 버전으로 업그레이드한 후 이를 대상으로 애플리케이션을 테스트하여 애플리케이션의 유효성을 검증할 수 있습니다. 테스트에 성공하면 데이터베이스를 업그레이드할 준비가 된 것입니다.

복제를 시도하려면 다음 단계를 완료하세요:

Amazon RDS 콘솔의 탐색 창에서 데이터베이스를 선택합니다.
Aurora 클러스터를 선택합니다.
작업 메뉴에서 클론 생성을 선택합니다.
클론을 생성한 후 bastion 호스트에 SSH로 접속하여 클론 클러스터 엔드포인트에 연결합니다:
psql -h <<Paste Clone cluster endpoint>> -U <<DB User name>>
```
-- Create a test table (use different name if needed)
=> CREATE TABLE test(id int);
=> INSERT INTO test VALUES(1);
=> SELECT * FROM test;
=> \q
```
psql 을 활용하여 오리지널 클러스터에 연결합니다:
psql -h <<Paste Clone cluster endpoint>> -U <<DB User name>>
=> SELECT * FROM test;
테스트 테이블을 찾을 수 없을 것입니다.
복제본 테스트가 끝나면 실행 중인 클러스터에 요금이 부과되지 않도록 복제된 클러스터를 삭제해야 합니다.
데이터베이스 페이지에서 복제 클러스터의 인스턴스를 선택하고 작업 메뉴에서 삭제를 선택합니다.
최종 스냅샷을 만들려면 옵션을 선택 해제하세요.

Tip #4: 재해 복구 및 성능 향상을 위해 글로벌 데이터베이스를 사용하기

Amazon Aurora 글로벌 데이터베이스를 사용하면 하나의 기본 클러스터와 서로 다른 리전에 걸쳐 최대 5개의 보조 클러스터로 구성된 글로벌 데이터베이스 클러스터를 생성할 수 있습니다. 기본 클러스터의 로그 레코드는 스토리지 수준에서 복제되며 쓰기 노드에 오버헤드를 주지 않습니다. 이 물리적 복제 메커니즘은 논리적 복제와 비교할 때 성능이 매우 뛰어납니다. SQL 쓰기는 기본 클러스터의 쓰기 노드에 대해서만 수행될 수 있지만 읽기는 모든 클러스터의 모든 엔드포인트에 대해 수행될 수 있습니다.

예를 들어, 다음 그림과 같이 Aurora 글로벌 데이터베이스를 사용하는 세 개의 리전에 배포된 글로벌 애플리케이션을 생각해 보겠습니다. 각 애플리케이션 인스턴스는 읽기 트랜잭션을 로컬 읽기 엔드포인트로 전송하고 쓰기 트랜잭션을 기본 클러스터의 쓰기 엔드포인트로 전송합니다.

모범 사례로, 낮은 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)를 요구하는 애플리케이션에 글로벌 데이터베이스를 사용하는 것을 고려하세요. 보조 클러스터의 복제 지연은 일반적으로 1초 미만입니다. 리전 고가용성에 문제가 있는 경우, 다른 리전의 보조 클러스터가 기본 클러스터로 승격될 수 있습니다. 이 리전 장애 조치 메커니즘을 통해 한 자릿수 분 단위의 RTO를 달성할 수 있습니다. 수동으로 시작된 장애 조치를 관리형 계획 장애 조치라고 합니다. 매우 드물지만, Aurora 글로벌 데이터베이스의 기본 리전에서 예기치 않은 중단이 발생할 수 있습니다. 이러한 예기치 않은 중단으로부터 복구하려면 다른 리전에서 보조 클러스터를 승격하여 기본 클러스터가 되도록 해야 합니다.

또한 보조 리전에 배포된 애플리케이션의 복사본은 공동 배치된 클러스터의 로컬 읽기를 활용할 수 있으므로 읽기 관점에서 애플리케이션 성능이 향상될 수 있습니다. 이 활성-활성 설정을 사용하면 보조 리전의 애플리케이션이 기본 클러스터의 쓰기 노드에 쓰기를 전송합니다.

Amazon Aurora MySQL 호환 에디션은 보조 클러스터에 대해 쓰기를 수행할 수 있는 쓰기 전달을 지원합니다. 보조 클러스터에 대한 쓰기 작업은 자동으로 기본 클러스터의 쓰기 노드로 전달됩니다. 또한, 보조 클러스터의 읽기 일관성 수준을 제어할 수도 있습니다. 기본적으로 보조 클러스터의 읽기 일관성은 ‘Eventual(최종)’로 설정되어 있지만, 이는 ‘Session(세션)’이나 ‘Global(글로벌)’로 설정할 수 있습니다. 읽기 일관성이 ‘Global’로 설정된 경우, 보조 클러스터에서의 읽기 작업은 주 클러스터에서 최신으로 커밋된 데이터를 보여줍니다.

때때로 한 리전에서 다른 리전으로 Aurora 클러스터를 마이그레이션해야 하는 경우가 있습니다. Aurora 글로벌 데이터베이스는 이러한 마이그레이션에 사용할 수 있는 빠른 솔루션입니다. 이를 위해 클러스터에 보조 리전을 추가하면 됩니다. 보조 리전이 기본 리전을 따라잡으면 기본 리전에 대한 쓰기를 중지하고, 보조 클러스터를 글로벌 데이터베이스에서 분리한 다음, 글로벌 데이터베이스와 기본 클러스터를 삭제하면 됩니다.

Aurora 글로벌 데이터베이스를 사용해 보겠습니다:

Amazon RDS 콘솔의 탐색 창에서 서브넷 그룹을 선택합니다.
DB 서브넷 그룹 생성을 선택하고 서브넷 그룹을 생성합니다.
DB 클러스터를 생성할 VPC를 선택합니다:
a. 이름을 입력합니다.
b. 가용 영역을 3개 이상 선택합니다.
c. 세 개의 가용 영역에서 서브넷을 선택합니다.
데이터베이스 페이지에서 클러스터를 선택하고 작업 메뉴에서 AWS 리전 추가를 선택합니다.
기존 클러스터에 보조 리전을 추가합니다:
1. 글로벌 DB 식별자를 입력합니다.
2. 보조 리전을 선택합니다.
3. 적절한 크기의 인스턴스를 선택합니다(예: db.t3.medium).
4. 연결 그룹의 경우:
  - VPC를 선택합니다.
  - 이전에 생성한 서브넷 그룹을 선택합니다.
  - 적절한 보안 그룹을 선택합니다(기본값 선택 해제).
5. 지역 추가를 선택합니다.
보조 리전에서 클러스터에 연결할 bastion 호스트(Amazon EC2) 인스턴스를 설정합니다.
PostgreSQL 클라이언트를 설치합니다:
sudo amazon-linux-extras install postgresql13
보조 리전의 bastion 호스트에 SSH로 접속하여 SQL을 사용하여 데이터를 확인합니다.
기본 리전의 bastion 호스트에 SSH로 접속하여 일부 데이터를 테스트 테이블에 삽입합니다.
보조 리전의 bastion 호스트에 SSH로 접속하여 SQL을 사용하여 데이터를 체크아웃합니다.
과금을 피하기 위해 보조 클러스터를 정리합니다:
1. 글로벌 데이터베이스에서 클러스터를 제거합니다.
2. 최종 스냅샷 생성 옵션을 선택 해제합니다.
3. 보조 리전에서 서브넷 그룹을 삭제합니다.
4. 글로벌 데이터베이스에서 주 클러스터를 제거합니다.
5. 글로벌 데이터베이스를 삭제합니다.
6. 보조 클러스터에서 DB 인스턴스를 선택하고 삭제합니다.

Tip #5: Aurora Serverless v2 를 활용하여 일관된 애플리케이션 성능 확보하기

Aurora는 데이터베이스 인스턴스의 자원 사용량에 따라 자동으로 확장되는 특별한 데이터베이스 인스턴스 유형을 제공합니다. 프로비저닝된 Aurora 데이터베이스 클러스터에서는 메모리, vCPU 및 네트워크 대역폭이 인스턴스 유형에 따라 결정됩니다. Aurora Serverless v2 인스턴스는 프로비저닝된 데이터베이스 인스턴스를 코드나 설정 변경없이 교체 가능합니다. Aurora Serverless v2 인스턴스를 사용하려면, 새 클러스터에서 Aurora Serverless v2 인스턴스 유형을 선택하거나 기존 클러스터에 Aurora Serverless v2 인스턴스를 추가해야 합니다. Aurora Serverless v2 용량 범위는 클러스터 레벨에서 최소/최대값으로 설정됩니다. Aurora는 지속적으로 메모리, CPU, 네트워크 등 인스턴스 자원을 모니터링합니다. 이러한 측정 값들을 모아 로드 라고 합니다. 인스턴스의 로드에 따라 Aurora Serverless는 자동으로 확장 또는 축소합니다. 인스턴스의 리소스를 확장하는 것 외에도, Aurora Serverless v2는 현재 용량에 기반하여 인스턴스에서 사용 가능한 최대 연결 수를 동적으로 조정합니다.

Aurora Serverless v2 인스턴스는 사용량이 급증하는 애플리케이션—즉, 데이터베이스의 부하가 대부분 낮게 유지되지만 시간별, 일별 또는 주별 등 드물게 사용량이 급증하는 애플리케이션에 활용할 수 있습니다. 이러한 시나리오에서는 최대 사용량에 맞게 프로비저닝된 인스턴스가 대부분 유휴 상태로 유지 되어 비용 효율적이지 않을 수 있습니다. Aurora Serverless v2는 이러한 문제를 해결하기 위해 수요 곡선에 맞춰 자동으로 자원을 조정하여 이러한 불규칙한 사용량에 대해 비용 효율성을 높입니다.

Aurora Serverless v2 로 할당된 자원은 최소로 지정한 용량에 근접하게 유지되며, 인스턴스의 자원 사용에 따라 확장 및 축소됩니다. 이렇게 하면 사용한 용량 만큼만 지불하게 되며, 결과적으로 비용을 절감 하면서 애플리케이션에 대한 일관된 사용자 경험을 유지할 수 있습니다.

용량 범위는 Aurora Capacity Units(ACUs) 라는 단위로 클러스터 레벨에서 설정됩니다. 1개의 ACU는 2 GiB의 메모리, 동등한 vCPU 및 네트워크 대역폭을 프로비저닝합니다. Aurora Serverless v2 인스턴스로만 구성된 클러스터를 생성하거나 프로비저닝된 인스턴스와 서버리스 인스턴스를 혼합하여 클러스터를 생성할 수 있습니다. 아래 그림은 이러한 아키텍처를 표현하고 있습니다.

이 실습에서는 기존의 프로비저닝된 클러스터를 Aurora Serverless v2 클러스터(혼합 구성)로 변환하기 위해 읽기 전용 레플리카를 추가하고, 그 다음 프로비저닝된 인스턴스를 제거합니다. 이 방법을 사용하여 기존의 프로비저닝된 Aurora 클러스터를 Aurora Serverless v2 클러스터로 변환할 수 있습니다. 마지막으로 클러스터에 대해 부하 테스트를 실행하여 Aurora Serverless v2 인스턴스의 스케일링 특성을 확인합니다.

Amazon RDS 콘솔 접속 후, 네비게이션 패널에서 데이터베이스 를 선택합니다.
DB 클러스터를 선택하고 작업 메뉴에서 읽기 추가 를 선택합니다.
DB 인스턴스 식별자를 입력합니다.
인스턴스 구성에서 서버리스 v2를 선택합니다.
최소 ACUs 범위를 2로, 최대 ACUs 범위를 8로 설정합니다.
읽기 추가를 선택합니다.
읽기 인스턴스를 생성한 후, 프로비저닝된 인스턴스를 삭제합니다.

스케일링 동작을 이해하기 위해, 클러스터에 부하 테스트를 실행하고 CloudWatch의 ServerlessDatabaseCapacity 지표를 관찰합니다.

Bastion 호스트로 SSH 접속 후, pgbench 유틸리티를 사용하여 클러스터에 대해 부하 테스트를 실행합니다.

# Initialize pgbench database
psql -h <cluster-endpoint> -U <user name> -c “create database pgbench;”

# Create a temp database for the load test
pgbench -i -h <cluster-endpoint> -U <user name> pgbench

# Run the load test for 2 minutes with 100 connections
pgbench -c 100 -T 120 -P 2 -d pgbench -b simple-update -h <cluster-endpoint> -U <user name>

# Once the test has completed, you may drop the temp database
psql -h <cluster-endpoint> -U <user name> -c “drop database pgbench;”

pgbench를 실행하면 클러스터 엔드포인트에 100개의 커넥션을 생성하고, 2분 동안 해당 클러스터에 대해 간단한 업데이트 벤치마크 테스트를 합니다. 이로 인해 Aurora Serverless v2 클러스터의 인스턴스가 스케일링됩니다.

CloudWatch 콘솔에서 접속 후, ServerlessDatabaseCapacity 메트릭으로 이동합니다.
연습을 위해 클러스터를 생성 했다면, 해당 클러스터를 삭제합니다.

결론

이 글에서는 Aurora 기능을 효과적으로 활용하기 위한 다섯 가지 팁을 소개하였습니다. 성능을 향상시키고 DB 리소스를 최적화하기 위하여 애플리케이션은 Aurora DB 클러스터에 대한 읽기 및 쓰기 작업을 분리하도록 제안합니다. Java 애플리케이션의 빠른 장애 복구를 위해서 AWS JDBC 드라이버를 사용하거나 Amazon RDS Proxy(이 시리즈의 2부에서 논의하는)를 사용하는 것도 고려해 볼 수 있습니다. Aurora의 빠른 클론 기능을 사용하면, 애플리케이션 개발자는 손쉽게 프로덕션 데이터를 기반으로 애플리케이션을 테스트 할 수 있습니다. 애플리케이션은 여러 리전에 걸쳐 배포될 것이고, Aurora 글로벌 데이터베이스를 사용하여 재해 복구, 지역별 읽기 및 리전 마이그레이션 기능을 제공 받을 수 있습니다. 갑자기 사용량이 급증하는 특성을 가진 워크로드의 경우, 애플리케이션은 Aurora Serverless v2 인스턴스를 활용할 수 있습니다. 이런 다양한 기능들을 어떻게 활용할 수 있을 지, 애플리케이션을 검토해보세요.

이 시리즈의 2부에서는 Aurora 데이터베이스를 통합하거나 보완하는 AWS 서비스를 활용하여 애플리케이션의 성능, 보안 및 가용성을 향상시키는 다섯 가지 팁을 공유합니다.

AWS 기술 블로그