PostgreSQL에서 Aurora DSQL로 마이그레이션 - Amazon Aurora DSQL
프레임워크 및 ORM 호환성일반적인 마이그레이션 패턴아키텍처 차이점 이해호환성 고려 사항마이그레이션에 도움이 필요하세요?

PostgreSQL에서 Aurora DSQL로 마이그레이션

Aurora DSQL은 PostgreSQL과 호환되도록 설계되었으며 ACID 트랜잭션, 보조 인덱스, 조인, 표준 DML 작업과 같은 핵심 관계형 기능을 지원합니다. 대부분의 기존 PostgreSQL 애플리케이션은 최소한의 변경으로 Aurora DSQL로 마이그레이션할 수 있습니다.

이 섹션에서는 프레임워크 호환성, 마이그레이션 패턴, 아키텍처 고려 사항을 포함하여 애플리케이션을 Aurora DSQL로 마이그레이션하기 위한 실용적인 지침을 제공합니다.

프레임워크 및 ORM 호환성

Aurora DSQL은 표준 PostgreSQL 유선 프로토콜을 사용하므로 PostgreSQL 드라이버 및 프레임워크와 호환됩니다. 대부분의 인기 ORM은 변경 없이 또는 최소한의 변경만으로 Aurora DSQL과 호환됩니다. 참조 구현 및 사용 가능한 ORM 통합은 Aurora DSQL 어댑터 및 방언 섹션을 참조하세요.

일반적인 마이그레이션 패턴

PostgreSQL에서 Aurora DSQL로 마이그레이션할 때 일부 기능은 다르게 작동하거나 대체 구문이 있습니다. 이 섹션에서는 일반적인 마이그레이션 시나리오에 대한 지침을 제공합니다.

DDL 작업 대안

Aurora DSQL은 기존 PostgreSQL DDL 작업에 대한 최신 대안을 제공합니다.

인덱스 생성

비차단 인덱스를 생성하는 데 CREATE INDEX 대신 CREATE INDEX ASYNC를 사용합니다.

이점: 큰 테이블에서 가동 중지 시간 없이 인덱스를 생성할 수 있습니다.

데이터 제거

TRUNCATE 대신 DELETE FROM table_name를 사용합니다.

대안: 테이블을 완전히 다시 생성하려면 DROP TABLE을 사용한 후 CREATE TABLE을 사용합니다.

시스템 구성

Aurora DSQL은 완전 관리형이므로 구성이 워크로드 패턴에 따라 자동으로 처리됩니다. AWS 관리 콘솔 또는 API를 사용하여 클러스터 설정을 관리합니다.

이점: 데이터베이스 튜닝이나 파라미터 관리가 필요하지 않습니다.

스키마 설계 패턴

Aurora DSQL과의 호환성을 위해 다음과 같은 일반적인 PostgreSQL 패턴을 조정합니다.

참조 무결성 패턴

Aurora DSQL은 테이블 관계 및 JOIN 작업을 지원합니다. 참조 무결성을 위해 애플리케이션 계층에서 검증을 구현합니다. 이러한 설계는 애플리케이션 계층 검증을 통해 유연성을 높이고 연쇄적 작업으로 인한 성능 병목 현상을 방지하는 최신 분산 데이터베이스 패턴과 일맥상통합니다.

패턴: 일관된 이름 지정 규칙, 검증 로직 및 트랜잭션 경계를 사용하여 애플리케이션 계층에서 참조 무결성 검사를 구현하세요. 많은 대규모 애플리케이션은 오류 처리 및 성능을 더 잘 제어하기 위해 이 접근 방식을 선호합니다.

임시 데이터 처리

임시 테이블 대신 CTE, 하위 쿼리 또는 정리 로직이 포함된 일반 테이블을 사용합니다.

대안: 세션별 이름을 가진 테이블을 생성하고 애플리케이션 내에서 정리하세요.

아키텍처 차이점 이해

Aurora DSQL의 분산 서버리스 아키텍처는 여러 면에서 기존 PostgreSQL과 의도적으로 다릅니다. 이러한 차이점을 통해 Aurora DSQL은 단순성과 확장성이라는 핵심적인 이점을 제공합니다.

간소화된 데이터베이스 모델

클러스터당 단일 데이터베이스

Aurora DSQL은 클러스터마다 postgres라는 내장 데이터베이스 하나를 제공합니다.

마이그레이션 팁: 애플리케이션에서 여러 데이터베이스를 사용하는 경우 논리적 분리를 위해 별도의 Aurora DSQL 클러스터를 생성하거나 단일 클러스터 내에서 스키마를 사용하세요.

임시 테이블 미지원

임시 데이터 처리를 위해서는 복잡한 쿼리에 대한 유연한 대안을 제공하는 공통 테이블 표현(CTE) 및 하위 쿼리를 사용해야 합니다.

대안: 임시 결과 집합의 경우 WITH 절과 함께 CTE를 사용하고, 세션별 데이터의 경우 고유한 이름이 지정된 일반 테이블을 사용할 수 있습니다.

자동 스토리지 관리

Aurora DSQL을 사용하면 테이블스페이스 및 수동 스토리지 관리가 필요 없습니다. 스토리지는 데이터 패턴에 따라 자동으로 규모가 조정되고 최적화됩니다.

이점: 디스크 공간을 모니터링하거나 스토리지 할당을 계획하거나 테이블스페이스 구성을 관리할 필요가 없습니다.

최신 애플리케이션 패턴

Aurora DSQL은 유지 관리성과 성능을 향상시키는 최신 애플리케이션 개발 패턴을 장려합니다.

데이터베이스 트리거 대신 애플리케이션 수준 로직

트리거와 같은 기능을 사용하려면 애플리케이션 계층에서 이벤트 기반 로직을 구현합니다.

마이그레이션 전략: 트리거 로직을 애플리케이션 코드로 이동하거나, EventBridge와 같은 AWS 서비스와 함께 이벤트 기반 아키텍처를 사용하거나, 애플리케이션 로깅을 통해 감사 추적을 구현하세요.

데이터 처리를 위한 SQL 함수

Aurora DSQL은 SQL 기반 함수를 지원하지만 PL/pgSQL과 같은 절차적 언어는 지원하지 않습니다.

대안: 데이터 변환에 SQL 함수를 사용하거나, 복잡한 로직을 애플리케이션 계층 또는 AWS Lambda 함수로 이동하세요.

수동적 잠금 대신 낙관적 동시성 제어

Aurora DSQL은 기존 데이터베이스 잠금 메커니즘과 다른, 잠금 없는 방식인 낙관적 동시성 제어(OCC)를 사용합니다. Aurora DSQL은 다른 트랜잭션을 차단하는 잠금을 획득하는 대신 차단 없이 트랜잭션이 진행되도록 하고 커밋 시 충돌을 감지합니다. 이를 통해 교착 상태를 방지하고 느린 트랜잭션이 다른 작업을 차단하는 것을 막습니다.

주요 차이점: Aurora DSQL은 충돌이 발생할 경우 트랜잭션이 잠금을 기다리도록 하는 대신 직렬화 오류를 반환합니다. 이를 위해 애플리케이션이 기존 데이터베이스에서 잠금 제한 시간을 처리하는 것과 유사하게 재시도 로직을 구현해야 하지만, 충돌이 즉시 해결되어 차단 대기를 유발하지 않습니다.

설계 패턴: 재시도 메커니즘을 갖춘 멱등성 트랜잭션 로직을 구현하세요. 무작위 프라이머리 키를 사용하고 키 범위 전체에 걸쳐 업데이트를 분산시켜 경합을 최소화하도록 스키마를 설계합니다. 자세한 내용은 Aurora DSQL의 동시성 제어을 참조하세요.

관계 및 참조 무결성

Aurora DSQL은 JOIN 연산을 포함한 테이블 간의 외래 키 관계를 지원합니다. 참조 무결성을 위해 애플리케이션 계층에서 검증을 구현합니다. 참조 무결성을 적용하는 것은 중요할 수 있지만 연쇄적 작업(예: 연쇄 삭제)은 예기치 않은 성능 문제를 일으킬 수 있습니다. 예를 들어, 1,000개의 품목이 있는 주문을 삭제하는 경우 1,001개의 행을 처리하는 트랜잭션이 실행됩니다. 이러한 이유로 많은 고객이 외래 키 제약 조건을 피합니다.

설계 패턴: 애플리케이션 계층에서 참조 무결성 검사를 구현하거나, 최종 일관성 패턴을 사용하거나, AWS 서비스를 활용하여 데이터를 검증하세요.

운영 간소화

Aurora DSQL을 사용하면 기존 데이터베이스 유지 관리 작업이 대부분 필요 없어지므로 운영 오버헤드가 줄어듭니다.

수동 유지 관리 불필요

Aurora DSQL은 스토리지 최적화, 통계 수집 및 성능 튜닝을 자동으로 관리합니다. VACUUM과 같은 기존 유지 관리 명령은 시스템에서 처리합니다.

이점: 데이터베이스 유지 관리 기간, vacuum 예약 및 시스템 파라미터 튜닝이 필요 없어집니다.

자동 파티셔닝 및 규모 조정

Aurora DSQL은 액세스 패턴에 따라 데이터를 자동으로 파티셔닝하고 배포합니다. 최적의 배포를 위해 UUID 또는 애플리케이션 생성 ID를 사용합니다.

마이그레이션 팁: 수동 파티셔닝 로직을 제거하고 Aurora DSQL이 데이터 배포를 처리하도록 하세요. 최적의 배포를 위해 UUID 또는 애플리케이션 생성 ID를 사용합니다. 애플리케이션에 순차적 식별자가 필요한 경우 시퀀스 및 자격 증명 열 섹션을 참조하세요.

PostgreSQL 호환성을 위한 Aurora DSQL 고려 사항

Aurora DSQL은 분산 아키텍처, 서버리스 운영 및 자동 규모 조정을 가능하게 하는 기능 지원 측면에서 자체 관리형 PostgreSQL과 차이가 있습니다. 대부분의 애플리케이션은 이러한 차이점에도 불구하고 수정 없이 작동합니다.

일반적인 고려 사항은 Amazon Aurora DSQL 사용에 대한 고려 사항 섹션을 참조하세요. 할당량 및 한도는 Amazon Aurora DSQL의 클러스터 할당량 및 데이터베이스 한도 섹션을 참조하세요.

  • Aurora DSQL은 클러스터당 postgres라는 단일 내장 데이터베이스를 사용합니다. 논리적 분리를 위해 별도의 Aurora DSQL 클러스터를 만들거나 단일 클러스터 내에서 스키마를 사용합니다.

  • postgres 데이터베이스는 광범위한 국제 문자 지원을 제공하는 UTF-8 문자 인코딩을 사용합니다.

  • 데이터베이스는 C 데이터 정렬만 사용합니다.

  • Aurora DSQL은 UTC를 시스템 시간대로 사용합니다. Postgres는 모든 시간대 인식 날짜 및 시간을 UTC로 내부적으로 저장합니다. TimeZone 구성 파라미터를 설정하여 클라이언트에 표시되는 방식을 변환하고 서버가 UTC로 내부적으로 변환하는 데 사용할 클라이언트 입력의 기본값으로 사용할 수 있습니다.

  • 트랜잭션 격리 수준은 PostgreSQL Repeatable Read에서 고정됩니다.

  • 트랜잭션의 제약 조건은 다음과 같습니다.

    • DDL 및 DML 작업에는 별도의 트랜잭션이 필요합니다.

    • 하나의 트랜잭션에는 DDL 문이 하나만 포함될 수 있습니다.

    • 하나의 트랜잭션은 보조 인덱스 수와 관계없이 최대 3,000개의 행을 수정할 수 있습니다.

    • 행 3,000개 한도는 모든 DML 문(INSERT, UPDATE, DELETE)에 적용됩니다.

  • 데이터베이스 연결은 1시간 후에 시간 초과됩니다.

  • Aurora DSQL은 스키마 수준 권한 부여를 통해 권한을 관리합니다. 관리자 사용자는 CREATE SCHEMA를 사용하여 스키마를 만들고 GRANT USAGE ON SCHEMA를 사용하여 액세스 권한을 부여합니다. 관리자 사용자는 퍼블릭 스키마에서 객체를 관리하는 반면, 관리자가 아닌 사용자는 명확한 소유권 경계를 위해 사용자가 만든 스키마에서 객체를 만듭니다. 자세한 내용은 데이터베이스 역할이 데이터베이스에서 SQL을 사용하도록 권한 부여 섹션을 참조하세요.

마이그레이션에 중요하지만 현재 Aurora DSQL에서 지원되지 않는 기능이 있는 경우 Amazon Aurora DSQL에 대한 피드백 제공에서 AWS와 피드백을 공유하는 방법에 대한 정보를 참조하세요.