AWS re:Invent 리캡

Amazon Aurora와 주요 혁신 심층 분석 (DAT441)

리캡: 08 동영상: 세션 보기

리캡 시리즈

English 繁體中文 简体中文 Filipino 한국어 日本語

세션 노트

Aurora 개요

  • Amazon Aurora는 클라우드 네이티브 관계형 데이터베이스입니다.
  • 고급 상용 데이터베이스의 속도 및 가용성과 오픈 소스의 단순성 및 비용 효율성을 결합합니다.
  • MySQL 및 PostgreSQL과 호환되는 완전 관리형 서비스입니다.
  • 서버리스 및 머신 러닝 애플리케이션과 통합하기 위한 도구를 포함합니다.
  • Aurora를 사용하기 위해 애플리케이션을 변경할 필요가 없습니다.
  • PostgreSQL 확장 기능을 지원합니다.
  • 최근 Aurora DSQL(Distributed SQL)이 추가되었습니다.
  • Aurora 아키텍처:
  • 3개의 가용 영역을 사용합니다.
  • Aurora 스토리지가 세 가용 영역 전체에 걸쳐 구성됩니다.
  • 스토리지 노드는 로그 레코드를 처리해 데이터베이스 페이지로 변환합니다.

Aurora 스토리지의 주요 기능

  • 체크포인트, 전체 페이지 쓰기, 이중 쓰기 버퍼 또는 로그 보관과 같은 기존 데이터베이스 문제가 없습니다.
  • 데이터는 3개의 가용 영역에 있는 6개의 스토리지 노드에 총 6개 복사본으로 중복 저장됩니다.
  • 손상되거나 누락된 로그 레코드 또는 장애가 발생한 스토리지 노드를 자동으로 피어 투 피어 복구합니다.
  • 복제본 관리:
  • 일관성 지연 없이 최대 15개의 읽기 전용 복제본을 추가할 수 있습니다.
  • 헤드 노드 간 비동기 무효화 및 업데이트
  • 복제본은 크기와 인스턴스 유형이 다양할 수 있습니다(예: Graviton, Intel).
  • 스토리지는 최대 256테라바이트까지 자동으로 확장됩니다.
  • 자동 장애 조치:
  • 장애 발생 시 복제본을 읽기-쓰기 노드로 승격
  • 애플리케이션 재라우팅을 위한 DNS-based 엔드포인트 변경
  • 더 빠른(최대 66% 더 빠른) 장애 조치를 위해 사용 가능한 고급 고속 드라이버
  • 지역 간 스토리지의 비동기식 복제(글로벌 데이터베이스)
  • Aurora에 의해 처리되는 복제, 애플리케이션 변경 필요 없음
  • 보조 지역에서 애플리케이션을 실행하면 대기 시간이 짧은 지역-로컬 읽기가 가능합니다.
  • 글로벌 데이터베이스 설정에 최대 10 지역을 활용할 수 있습니다.
  • 기술 노트:
  • 헤드 노드는 복제 프로세스에 관여하지 않습니다.
  • 보조 지역의 읽기 전용 복제본은 1초 미만의 일반적인 RPO 지연으로 거의 즉각적인 데이터 가시성을 유지합니다.

글로벌 엔드포인트 및 장애 조치

  • 전역 끝점은 현재 작성자 지역을 가리키는 DNS 이름입니다.
  • 기본 지역에 문제가 있는 경우 장애 조치(failover) 작업이 실행됩니다.
  • 장애 조치는 다른 지역의 복제본을 작성자 노드로 승격합니다.
  • 비동기 복제로 인해 잠재적인 데이터 손실이 발생할 수 있음
  • 전역 엔드포인트의 DNS 이름은 Route 53 데이터 계획 API 전역 데이터베이스 전환을 통해 업데이트됩니다.
  • 두 지역 모두 정상일 때 전환이 발생하고 운영상의 이유로 기록기가 이동됩니다.
  • 최근 개선으로 전환 시간이 5분에서 30초로 단축되었습니다.
  • 로그 기반 아키텍처를 활용하여 데이터 손실 없음(RPO/0) 및 30초 복구 시간(RTO/30초)을 달성합니다.
  • 로컬 쓰기 전달:
  • 보조 가용성 영역의 쓰기가 작가 노드로 전달되도록 허용합니다.
  • 시스템을 활성-활성 구성으로 변환하지 않습니다.
  • 가용성 영역 2의 쓰기는 실행된 가용성 영역 1,의 쓰기 노드로 전달되고 결과가 반환됩니다.
  • 데이터 무결성이나 시스템 설계를 손상시키지 않고 운영 유연성을 향상시킵니다.
  • Aurora의 일관성 모드:
  • 세 가지 다른 일관성 modes/visibility 모드 사용 가능
  • 기본 모드는 읽기를 진행하기 전에 업데이트가 승인될 때까지 기다리는 세션 가시성입니다.
  • 최종 일관성 모드는 업데이트를 기다리지 않으므로 잠재적으로 최신 쓰기가 반영되지 않는 읽기가 발생할 수 있습니다.
  • 글로벌 일관성 모드는 진행하기 전에 전체 클러스터의 모든 업데이트를 기다리며 읽기에 모든 쓰기가 반영되도록 합니다.
  • 로컬 쓰기 전달:
  • 보조 가용성 영역의 쓰기가 작가 노드로 전달되도록 허용합니다.
  • 로컬 작업과 동일한 일관성 모드 및 고려 사항을 유지합니다.
  • 지역 간 지연 시간 차이는 전역 쓰기 전달 Aurora 스토리지 노드 작업의 요인입니다.
  • 각 스토리지 노드는 엔진과 스토리지 간의 통신을 용이하게 하는 "스토리지 악마"를 실행합니다.
  • 로그 레코드는 수신 대기열에 기록되고 디스크의 핫 로그로 배출된 후 승인됩니다.
  • 누락된 로그 기록(예: 전송 지연으로 인해)은 다른 스토리지 노드에서 P2P로 가져올 수 있습니다.
  • 로그 기록이 데이터베이스 페이지로 통합되어 대기 시간에 미치는 영향을 최소화하면서 읽기 요청이 처리되도록 보장합니다.
  • S3에 대한 지속적인 백업을 통해 지난 35일 이내에 특정 시점으로 복원할 수 있습니다.

IO 최적화 구성

  • IO- 집약적인 애플리케이션의 처리량을 향상시키기 위해 구성 옵션을 조정합니다.
  • 보다 공격적인 일괄 처리를 위해 스토리지 드라이버를 수정하여 IO-무거운 애플리케이션에 유용합니다.
  • 추가 최적화를 위해 최신 엔진 버전을 활용합니다.
  • 대기 시간과 지터를 줄이기 위해 수신 대기열을 내구성 있는 대기열로 변경하여 성능을 향상합니다.
  • Aurora PostgreSQL 호환성 및 업데이트:
  • Aurora PostgreSQL는 PostgreSQL와 완벽하게 호환됩니다.
  • 업스트림에서 PostgreSQL 업데이트를 정기적으로 통합합니다.
  • PostgreSQL 버전 17.6.까지 지원
  • 로컬 디스크와 RAG 인스턴스 유형과의 호환성.
  • 상관 하위 쿼리 캐시, 적응형 조인 등을 포함하여 업스트림의 성능이 크게 향상되었습니다.
  • 메모리 효율성을 위한 공유 계획 캐시 도입.
  • 대규모 인스턴스 및 복제본에 대한 읽기 가용성이 향상되었습니다.
  • FIPS 140-3 보안 암호화 구현.
  • 다양한 확장, 특히 PG 벡터에 대한 업데이트.
  • 최대 256 테라바이트의 볼륨을 지원합니다.
  • Aurora PostgreSQL 성능 분석:
  • 다양한 인스턴스 세대에 걸쳐 처리량을 평가합니다.
  • 예시 테스트:
  • R52.4Xlarge(이전 인스턴스)와 R7i.48Xlarge(최신, 대규모 인스턴스)의 CPU-bound 성능은 2.1배의 성능 향상을 보여줍니다.
  • 기준선에 비해 2.7배 향상된 성능을 보여주는 R8G(Graviton 버전, 차세대) 도입으로 선형 확장보다 더 우수함을 나타냅니다.
  • 선형보다 나은 확장이란 데이터 시각화, 데이터베이스 성능 및 계산 효율성에 적용되는 선형 성장(입력이 2배가 되면 출력이 2배가 됨) 또는 하위 선형 확장(반환 감소, 암달의 법칙 한계)과 대조되는 로그 성장 또는 특수 아키텍처에서 흔히 볼 수 있는 리소스(예: 데이터 크기 또는 노드)가 증가함에 따라 시스템 또는 프로세스의 성능 또는 효율성이 불균형적으로 향상됨을 의미합니다.

Aurora PostgreSQL 동적 데이터 마스킹

  • Aurora의 민감한 데이터를 보호하기 위한 새로운 기능입니다.
  • 민감한 데이터에는 계좌 번호, 계좌 소유자 이름, 개인 식별 정보(PII)가 포함됩니다.
  • Aurora PostgreSQL의 동적 데이터 마스킹:
  • 반올림되거나 마스킹된 버전의 데이터를 제공하여 민감한 데이터를 보호하도록 설계되었습니다.
  • Aurora의 새로운 PG 열 마스크 확장을 통해 구현되었습니다.
  • 특정 테이블 및 열에 대한 마스킹 정책을 정의할 수 있습니다.
  • 예:
  • 고객 ID을 X로 마스킹하고 계정 잔액을 반올림합니다.
  • 정책은 충돌 해결을 위해 정의된 가중치를 사용하여 지정된 역할(예: '분석가')에 적용됩니다.
  • 인덱스에 영향을 주지 않고 효율적인 성능을 위해 쿼리 재작성 계층에 구현됩니다.
  • 동적 데이터 마스킹 구현 세부 사항:
  • 마스킹 기능은 가져온 후가 아닌 쿼리 재작성 단계에서 적용됩니다.
  • 우수한 성능을 보장하고 인덱스 기능을 유지합니다.
  • 마스크 함수가 대상 열에 적용되는 쿼리 설명 출력에 표시됩니다.
  • Aurora MySQL 업데이트:
  • MySQL 8.0.43 호환성을 갖춘 3.11 버전의 최신 릴리스입니다.
  • 향상된 기능을 갖춘 3.10.0 장기 지원 버전을 소개합니다.
  • 최대 40% 향상된 로그 복제 처리량을 위한 메모리 내 릴레이 로그 캐시입니다.
  • MySQL용 고급 고속 드라이버에서 ODBC을 지원합니다. ODBC(개방형 데이터베이스 연결)는 애플리케이션이 표준 언어 SQL를 사용하여 다양한 데이터베이스 관리 시스템의 데이터에 액세스할 수 있도록 하는 API입니다. 이는 브리지 역할을 하여 각각에 대해 다시 작성할 필요 없이 단일 애플리케이션이 SQL 서버, MySQL 또는 Oracle과 같은 다른 데이터베이스에 연결할 수 있도록 해줍니다.
  • 최대 256 테라바이트까지 볼륨 지원이 증가되었습니다.
  • 글로벌 문제 발생 시 읽기 가용성 향상을 위한 글로벌 데이터베이스 보조 리더입니다.

Aurora Serverless

  • 간소화된 플릿 관리를 위해 권장되는 인스턴스 유형입니다.
  • 워크로드 수요에 따라 CPU 및 메모리를 자동으로 조정합니다.
  • V1.의 수명이 끝난 후 Aurora Serverless V2에서 Aurora Serverless로 이름이 변경되었습니다.
  • 유연한 리소스 할당을 위해 탄력적인 인스턴스 유형을 제공합니다.
  • Aurora Serverless 기능 및 이점:
  • 엔진 재부팅 없이 메모리, CPU 및 네트워크를 자동으로 확장합니다.
  • 조정은 Aurora 용량 단위(ACUs)로 측정되며 매초 발생하며, 각각은 RAM의 2 GB 및 관련 리소스를 나타냅니다.
  • Lambda 함수 또는 분석 작업에 따라 확장하여 수요에 따라 ACUs를 조정합니다.
  • 초당 가격이 책정되며 사용자는 실제로 사용한 리소스에 대해서만 비용을 지불합니다.
  • Aurora Serverless의 확장 메커니즘:
  • 주기적으로 크레딧을 채우는 확장 버킷을 사용하여 작동하므로 설정된 최대 ACU 한도까지 확장할 수 있습니다.
  • 확장이 필요할 때 크레딧이 소비되며, 시간이 지남에 따라 버킷이 다시 채워집니다.
  • 최근 개선 사항에는 더 빠른 트리거 응답(1초 미만), 더 큰 초기 버킷 크기 및 더 빠른 리필 속도가 포함됩니다.
  • 플랫폼 버전 3의 성능 향상:
  • 선택이나 추가 구성 없이 최대 30% 향상된 성능을 제공합니다.
  • 모든 새 클러스터에 사용할 수 있으며 백업에서 복원하거나 복제하거나 새 클러스터를 생성하여 액세스할 수 있습니다.
  • 성능 예:
  • 빠른 확장이 포함된 플랫폼 버전과 포함되지 않은 플랫폼 버전 2을 비교한 테스트에서는 최대 성능 기간이 3.6배 더 길고 빠른 확장을 사용하면 9% ACU 시간이 단축된 것으로 나타났습니다.
  • 플랫폼 버전 3(빠른 확장과 결합)를 사용한 테스트에서는 플랫폼 버전 2,에 비해 런타임 및 사용 시간이 20% 감소하여 청구 금액이 20% 낮아졌습니다.
  • 더 빠른 확장과 플랫폼 버전 3은 모두 새 클러스터에 자동으로 적용되어 사용자의 추가 노력 없이도 향상된 성능과 비용 효율성을 제공합니다.

Express 구성으로 생성

  • 몇 초 만에 데이터베이스 클러스터를 빠르게 생성합니다.
  • CI/CD 파이프라인 또는 에이전트 AI 애플리케이션과 같이 클러스터를 자주 생성하는 사용자를 대상으로 합니다.
  • 각 상호 작용에 대해 새 데이터베이스를 생성하여 민첩성과 속도를 향상시킵니다.
  • Express 구성으로 생성 기능:
  • 16 ACUs(Aurora 용량 단위)로 시작하는 유연하고 편집 가능한 구성을 제공합니다.
  • ACUs 및 기타 구성을 변경하는 기능을 포함하여 생성 후 대부분의 설정을 수정할 수 있습니다.
  • 암호화 및 IAM(ID 및 액세스 관리)가 활성화되어 기본적으로 보호됩니다.
  • 글로벌 데이터베이스 및 ETL 제로를 포함하여 거의 모든 Aurora 기능을 지원합니다.
  • VPC 아니요 요구 사항:
  • VPC(Virtual Private Cloud) 없이도 데이터베이스 클러스터에 대한 액세스를 용이하게 하는 새로운 구성 요소인 Aurora Internet Access Gateway를 소개합니다.
  • 인터넷 액세스 게이트웨이는 PostgreSQL 유선 프로토콜과 호환되는 고가용성 엔드포인트로 대기 시간을 최소화합니다.
  • 어디서나 DB 클러스터에 액세스할 수 있으므로 VPNs의 필요성이 줄어들고 개발자의 프로세스가 단순화됩니다.
  • 사기 방지 및 데이터 보호와 같은 향상된 보안 기능을 위해 Amazon IAM 및 AWS Shield와 통합됩니다.
  • AWS Shield는 분산 서비스 거부(DDoS) 공격으로부터 Amazon Web Services(AWS)에서 실행되는 애플리케이션을 보호하기 위한 관리형 서비스입니다. 일반적인 네트워크 계층 공격을 자동으로 완화하는 무료 AWS Shield Standard와 보다 정교한 공격, 고급 기능 및 전문가 지원에 대한 보호를 제공하는 유료 AWS Shield Advanced의 두 가지 계층을 제공합니다.

Aurora와 Agentic AI의 통합

  • Aurora는 에이전트 AI 루프의 기능에 필수적인 에이전트 AI 시스템용 메모리 역할을 할 수 있습니다.
  • "Letter" 프레임워크 사용 예: 빠른 구성으로 DB 클러스터 생성, 벡터 임베딩을 위한 PG 벡터 확장 활성화, Letter 프레임워크를 PostgreSQL 끝점으로 지정.
  • Aurora PostgreSQL는 LangChain와 같은 다양한 프레임워크에서 유전적 AI 메모리에 사용될 수 있습니다.
  • AWS에서 오픈 소스로 제공되는 MCP(모델 컨텍스트 프로토콜) 서버는 Aurora 데이터베이스의 스키마를 이해하는 자연어 쿼리를 허용하여 이를 SQL 쿼리로 변환합니다. 이는 데이터베이스를 탐색하는 신규 사용자와 효율성을 추구하는 고급 사용자 모두에게 유익합니다.
  • Aurora의 패치 및 업그레이드:
  • Aurora는 보류 중인 유지 관리 작업을 콘솔에 표시하여 클러스터 패치 및 업그레이드를 위한 관리형 환경을 제공합니다.
  • OS 패치는 클러스터의 여러 노드에 롤링 방식으로 적용되어 가용성을 향상시킵니다.
  • 사용자는 업데이트를 위한 유지 관리 기간을 설정하고 유지 관리 작업에 대한 알림을 받을 수 있습니다.
  • 유지 관리 작업 자동화는 선택 사항이므로 사용자는 Terraform과 같은 자체 시스템을 통해 업그레이드를 제어할 수 있습니다.
  • 여러 클러스터의 경우 개발 환경, QA 및 프로덕션 환경 전반에 걸쳐 순차적인 업그레이드가 중요합니다.
  • Aurora 클러스터에 대한 순차적 업그레이드:
  • 테스트 및 반응 시간을 허용하기 위해 다양한 환경(dev, QA, prod)에서 순차적 업그레이드의 중요성.
  • 원하는 순서와는 반대로 개발 전에 QA 환경을 잠재적으로 업그레이드할 수 있는 무작위 유지 관리 발표에 도전하세요.

AWS 조직의 업그레이드 출시 정책

  • 순서 문제를 해결하기 위해 도입되어 업그레이드를 웨이브(1st, 2nd, 마지막)로 나눌 수 있습니다.
  • 이 프로세스에는 사용자에게 알리고, 첫 번째 웨이브의 유지 관리 기간을 기다리고, 해당 인스턴스를 업그레이드하고, 베이킹(테스트 기간)한 후 다음 웨이브로 진행하는 과정이 포함됩니다.
  • 문제가 발생할 경우 사용자가 대응하거나 거부할 수 있는 충분한 시간을 제공합니다.
  • 업데이트가 출시되는 요일에 관계없이 업그레이드가 순차적으로 진행됩니다.
  • 업그레이드 출시 정책 구현:
  • AWS 조직을 활성화하고 조직 내에 계정을 배치해야 합니다.
  • 일반 설정에는 자동 마이너 버전 업그레이드 활성화 및 유지 관리 기간 설정이 포함됩니다.
  • 정책은 태그를 리소스와 연결하여 설정됩니다. 예를 들어 마지막 웨이브에 대해 "env=prod"로 리소스에 태그를 지정합니다.
  • 인식된 태그가 없는 리소스는 기본적으로 지정된 웨이브(예: 두 번째 웨이브)로 설정됩니다.
  • 사용자는 태그를 사용하지 않고 모든 리소스에 대한 일회성 업그레이드에 대한 기본값을 수락하도록 선택할 수 있습니다.
  • 업그레이드 출시 정책 적용:
  • 정책을 생성한 후 전체 조직(루트) 또는 개별 계정에 연결하여 선택적으로 적용할 수 있습니다.
  • 업그레이드하는 동안 사용자는 보류 중인 유지 관리 작업 및 AWS 상태에서 업그레이드가 발생할 웨이브를 나타내는 알림을 볼 수 있습니다.

메이저 버전 업그레이드를 위한 블루-그린 배포

  • 블루-그린 배포는 현재 버전과 호환되지 않고 내부에서 수행할 경우 가동 중지 시간이 필요한 주요 버전 업그레이드에 필수적입니다.
  • 이 프로세스에는 프로덕션 환경("그린" 환경)의 전체 복사본을 생성하고, 논리적 복제를 사용하여 데이터를 동기화하고, 블루-그린 배포가 실행되는 동안 동기화를 유지하는 과정이 포함됩니다.
  • 전환하기 전에 업그레이드된 환경을 철저하게 테스트할 수 있습니다.
  • CLI 또는 콘솔을 통해 촉진되는 전환은 AWS 리소스의 이름을 바꾸고 엔드포인트를 친환경 환경으로 전환하여 데이터 손실이 없고 가동 중지 시간을 최소화합니다(일반적으로 1분 미만).
  • 전환 시간이 초과되면 대체 옵션을 제공하여 자동으로 원래(블루) 환경으로 되돌아갑니다.
  • 버전 업그레이드뿐만 아니라 스키마 변경, 정적 매개변수 변경, 내부 변경에 너무 위험한 것으로 간주되는 유지 관리 업데이트에도 유용합니다.
  • 글로벌 데이터베이스를 위한 블루-그린 배포:
  • 글로벌 데이터베이스에 대한 최근 지원을 통해 블루-그린 배포를 사용하여 지역 간 주요 버전 업그레이드가 가능합니다.
  • 이 프로세스는 데이터 동기화 및 최소 가동 중지 시간(전환에 약 1분)을 보장하는 논리적 복제를 통해 단일 지역 배포의 프로세스를 미러링합니다.
  • 데이터 손실이 없고(RPO/0) 약 1분의 복구 시간 목표(RTO)로 전체 글로벌 클러스터의 주요 버전 업그레이드를 활성화합니다.

Aurora의 Zero ETL 기능

  • ETL 파이프라인을 관리하지 않고도 Aurora PostgreSQL에서 Redshift로 지연 시간이 짧은 데이터 전송을 촉진합니다.
  • Aurora 및 Redshift 클러스터 사이에 파이프라인을 생성하는 CLI 명령을 통해 달성됩니다.
  • 5~12초의 복제 지연을 제공하여 Redshift에서 빠른 데이터 가용성을 보장합니다.
  • 데이터 시딩, 유지 관리 및 변경 데이터 캡처(CDC) 스트리밍을 관리하여 사용자의 이러한 복잡성을 덜어줍니다.
  • 여러 Aurora 클러스터(MySQL 및 PostgreSQL 모두)를 단일 Redshift 클러스터 또는 데이터 레이크로 통합하는 것을 지원합니다.
  • 또한 동일한 기술을 사용하여 Aurora MySQL에서 SageMaker로의 데이터 흐름을 활성화합니다.
  • Zero ETL의 기본 기술:
  • 스토리지 계층에서 병렬 직접 내보내기를 활용하여 성능에 영향을 주지 않고 데이터를 Redshift에 빠르게 시드합니다.
  • 향상된 bin 로그(MySQL용) 또는 스토리지에 내장된 PostgreSQL에 상응하는 로그를 사용하여 논리적 복제 로그를 캡처합니다.
  • CDC 스트리밍 서버는 스토리지에서 직접 로그를 읽고 데이터를 Redshift로 푸시하기 전에 필터와 수정 사항을 적용하여 헤드 노드에 성능에 영향을 미치지 않도록 합니다.
  • Aurora 저장 유형:
  • Aurora 표준: 기본적인 성능과 비용 특성을 제공하는 기본 스토리지 유형입니다.

Aurora 스토리지 비용 및 성능에 대한 자세한 설명

  • 읽기 작업: 데이터가 캐시되면 비용이 최소화됩니다(인스턴스 실행 시간이 몇 밀리초 정도). 캐시가 누락된 경우 스토리지에서 데이터를 읽으며 데이터베이스 엔진에 따라 8K 또는 16K 데이터베이스 페이지당 비용이 1센트도 채 되지 않습니다.
  • 쓰기 작업: 최대 4킬로바이트의 비용은 1센트도 안 됩니다. 더 큰 쓰기는 최대 4 I/O로 일괄 처리될 수 있으며, 각 일괄 처리 비용은 크기에 따라 1센트 미만입니다.
  • Aurora I/O 최적화된 스토리지:
  • 보다 예측 가능한 가격과 잠재적으로 더 나은 성능을 제공합니다.
  • 클러스터 생성 시 선택하거나 온라인으로 전환할 수 있는 클러스터 수준 구성입니다.
  • 스토리지 측 변경을 포함하여 시스템 성능과 아키텍처를 모두 변경합니다.
  • Aurora 청구서의 I/O 비율이 25% 이상인 사용자에게 권장됩니다. 비용 절감과 더 나은 성능을 제공할 가능성이 높기 때문입니다.
  • 지난 18개월 동안의 모든 최신 엔진 버전에서 사용 가능하며 데이터베이스 절약 계획과 호환됩니다.
  • I/O 최적화된 스토리지의 비용 모델:
  • 사용자는 컴퓨팅 및 스토리지에 대해 약간의 프리미엄을 지불하지만 I/O에 대한 비용은 전혀 없으므로 청구가 더욱 간단하고 예측 가능해집니다.
  • 컴퓨팅 및 스토리지에 대한 프리미엄 비용이 I/O 비용 제거로 상쇄되므로 상당한 I/O 작업이 포함된 워크로드에 이상적입니다.
  • I/O를 통한 성능 개선 최적화:
  • 16X 대형 인스턴스에 대한 테스트를 통해 입증되었으며, 버전 14.를 실행하는 R6I 16X 대형 인스턴스에서 활성화된 I/O 최적화를 통해 처리량이 1.9x 향상된 것으로 나타났습니다.
  • 16 PostgreSQL 버전의 R7I 인스턴스로 업그레이드할 때 추가 개선(추가 10%)이 관찰되었습니다.

I/O 최적화를 통한 지연 시간 및 처리량 개선

  • 지연 시간 테스트: 버전 17 PostgreSQL를 실행하는 R8G 48X 대형 인스턴스에 최적화된 I/O를 사용할 때 로우엔드에서 3배 개선, 하이엔드에서 6.4배 개선을 통해 지연 시간이 크게 개선되었음을 보여줍니다.
  • 처리량 테스트: 동일한 조건에서 처리량이 5배 향상된 것으로 나타나 대기 시간과 처리량 모두에 최적화된 I/O의 이중 이점을 강조합니다.
  • 임시 개체 및 로컬 NVMe 저장소:
  • 로컬 NVMe 스토리지는 서버 또는 클라우드 인스턴스 내에서 엄청나게 빠른 물리적으로 연결된 솔리드 스테이트 드라이브(SSDs)를 말하며, 매우 짧은 대기 시간과 높은 처리량을 제공하며 임시 고성능 스크래치 공간이 필요한 까다로운 앱(AI/ML, 데이터베이스)에 적합합니다.
  • 속도: PCIe 버스를 사용하여 밀리초 미만의 지연 시간과 대규모 IOPS를 제공하며 네트워크/컨트롤러 병목 현상을 우회합니다.
  • 직접 연결: server/instance 섀시(예: AWS EC2 또는 Azure VM) 내부에 물리적으로 연결됩니다.
  • 임시: 데이터는 일시적입니다. 인스턴스 종료, 실패 또는 때로는 restarts/maintenance.에서도 살아남지 못합니다.
  • 메모리를 초과하고 디스크 저장소가 필요할 수 있는 인덱스 재구축 또는 대규모 정렬과 같은 작업을 위해 PostgreSQL에서 임시 개체를 사용합니다.
  • 일반 시스템에서 이 디스크는 성능 고려 사항을 도입하는 EBS 디스크입니다.
  • RAGD와 같은 D 인스턴스를 사용하면 로컬 NVMe 인스턴스 스토리지가 대신 사용되어 유출에 할당할 메모리 크기를 최대 6배 허용하여 지연 시간을 크게 줄이고 이러한 임시 개체를 사용하는 워크로드의 성능을 향상시킵니다.
  • 임시 개체 저장소에 최적화된 I/O의 영향:
  • I/O 최적화는 임시 개체에 대한 할당을 메모리의 6배에서 2배로 줄여 성능 향상을 제공하지만 저장 공간을 덜 사용합니다.
  • 저장 공간의 절약은 추가 캐싱 계층을 제공하여 성능을 더욱 향상시키도록 설계된 계층형 캐시라는 기능에 활용됩니다.

계층형 캐시

  • I/O에서 임시 객체 스토리지 할당을 줄여 절약된 공간을 최적화합니다.
  • 추가 캐싱 계층을 추가하여 성능을 향상시키는 것을 목표로 하지만 계층형 캐시 작동 방식에 대한 구체적인 세부 정보는 발췌에서 제공되지 않습니다.
  • 일반 읽기 프로세스:
  • 공유 버퍼의 초기 확인; 데이터가 발견되면 추가 조치가 필요 없이 다시 읽혀집니다.
  • 데이터가 공유 버퍼에 없으면 저장소에서 공유 버퍼로 읽어온 다음 엔진에 제공됩니다.
  • D 인스턴스로 최적화된 읽기:
  • 공유 버퍼와 유사하게 사용되는 계층형 캐시에 디스크 메모리의 4 배를 할당합니다.
  • 메타데이터는 요청된 데이터가 디스크 캐시에 있는지 확인하는 데 사용됩니다.
  • 저장소에서 읽은 데이터는 공유 버퍼에 배치됩니다. 버퍼가 가득 차면 메타데이터 추적을 통해 데이터가 계층형 캐시로 제거됩니다.
  • 계층형 캐시로 업데이트 처리:
  • 업데이트는 메타데이터 비트를 뒤집어 계층형 캐시에 대한 잦은 쓰기를 방지하여 계층형 캐시의 데이터를 무효화합니다.
  • 탄력적이고 동적 계층형 캐시:
  • 워크로드 요구 사항에 따라 계층화된 캐시와 임시 개체의 크기를 조정하는 기능.
  • 디스크 유출이 많은 워크로드를 위한 임시 공간을 늘리고 워크로드 후 더 큰 계층형 캐시를 위해 이를 줄입니다.

R8GD 인스턴스 성능

  • R6GD와 가격은 동일하지만 165% 성능 향상을 제공하는 새로운 인스턴스 유형입니다.
  • 계층형 캐시 사용자와 그 사용을 고려하는 사용자에게 권장됩니다.
  • 계층형 캐시를 통한 성능 개선:
  • 특히 메모리 용량을 초과하는 데이터의 경우 읽기 작업의 대기 시간이 단축됩니다.
  • 340 GB 테스트의 경우 계층형 캐시는 메모리에 비해 대기 시간이 1.5% 증가했으며, 계층형 캐시가 없는 경우 8배 증가에 비해 3배 적자가 나타났습니다.
  • 파레토 무작위 분포 테스트는 대규모 테스트의 경우 대기 시간이 1.4 배만 감소하여 훨씬 더 나은 성능을 보여줍니다.
  • 실제 사용 사례:
  • PG 벡터 벤치마크는 최적화된 읽기(R7GD 대 R8G)를 통해 초당 쿼리가 3.5배 이상 향상된 것을 보여줍니다.
  • R6GD를 8GD(둘 다 동일한 가격)와 비교하면 벡터 성능이 1.6x 향상됩니다.
  • R: 메모리 최적화 인스턴스 패밀리를 나타냅니다.
  • 7: 현재 세대(7번째 세대)를 나타냅니다.
  • g: 인스턴스가 AWS Graviton 프로세서(Arm 아키텍처)를 사용함을 나타냅니다.
  • d: 로컬 NVMe 기반 SSD 스토리지가 포함되어 있음을 나타냅니다.
  • AWS Graviton 4 프로세서로 구동되는 Amazon EC2 R8g 인스턴스는 대규모 데이터베이스, 실시간 분석과 같은 까다로운 인 메모리 워크로드를 위한 AWS의 최신 세대 메모리 최적화 인스턴스를 나타냅니다.
  • Aurora PostgreSQL 및 Aurora MySQL 개요:
  • Aurora PostgreSQL: PostgreSQL와 완벽하게 호환되며 동시 쓰기에 대한 암시적 또는 명시적 잠금 기능이 있는 단일 작성자 아키텍처를 사용합니다.
  • Aurora MySQL: 다중 쓰기에 활성-활성 쿼리 프로세서를 활용하고 낙관적 동시성 제어를 사용하여 충돌을 관리합니다.
  • Aurora PostgreSQL에서 확장하려면 비동기식 복제를 통해 복제본을 추가하고, 일관성에 대한 질문을 제기하고, 성능을 위해 캐싱을 활용하는 것이 포함됩니다.
  • 주요 차이점:
  • 동시성 처리: PostgreSQL는 잠금을 사용합니다. MySQL는 낙관적 동시성 제어를 사용합니다.
  • 쓰기 아키텍처: PostgreSQL에는 단일 작성자가 있습니다. MySQL는 여러 활성 작성자를 지원합니다.
  • 확장 메커니즘: PostgreSQL는 복제본을 통해 확장됩니다. MySQL는 추가 쿼리 프로세서를 통해 확장됩니다.

Aurora PostgreSQL 및 Aurora MySQL의 상세 비교

  • Aurora PostgreSQL: 단일 작성자와 동시성을 위한 명시적 잠금이 포함된 활성-수동 아키텍처를 사용합니다. 복제본 추가를 통한 확장을 지원하고 비동기 복제를 사용합니다.
  • Aurora MySQL (DSQL): 낙관적 동시성 제어를 사용하여 쓰기를 위한 여러 쿼리 프로세서가 있는 활성-활성 아키텍처를 사용합니다. 분산 블록 스토어를 사용하여 읽기를 위해 독립적으로 확장됩니다.
  • Aurora의 읽기 및 쓰기 프로세스:
  • 읽기: 선택한 쿼리 프로세서에 의해 가용성 영역(AZs)에 걸쳐 스토리지 서버에서 데이터를 가져옵니다.
  • 쓰기: 쿼리 프로세서는 트랜잭션이 커밋될 때까지 쓰기 작업을 스풀링합니다. 커밋 시 쓰기는 조정자(충돌 해결을 위해)로 전송된 다음 저널(AZs 전체의 로그 스토리지용)로 전송되어 영향을 받은 스토리지 샤드를 업데이트합니다.
  • 다중 지역 운영:
  • Aurora PostgreSQL: 리전 간 데이터에 비동기 복제를 사용하므로 리전 내 커밋 지연 시간이 발생합니다.
  • Aurora MySQL: 커밋은 지역 간에 동기식으로 복제되므로 근본적인 차이점으로 지역 간 커밋 대기 시간이 발생합니다.