Amazon Aurora
1. 개요
1. 개요
Amazon Aurora는 아마존 웹 서비스(AWS)가 제공하는 완전관리형 관계형 데이터베이스 서비스이다. MySQL 및 PostgreSQL과 호환되도록 설계되었으며, 클라우드 환경을 위해 기존의 오픈 소스 데이터베이스 엔진의 성능과 가용성을 재구상하였다.
이 서비스는 AWS 클라우드의 내구성과 확장성을 활용하여 고성능 OLTP 워크로드를 처리하는 데 적합하다. Aurora는 데이터베이스 엔진과 스토리지 계층을 분리한 독자적인 아키텍처를 채택하여, 전통적인 데이터베이스의 제약을 극복하고 높은 처리량과 낮은 지연 시간을 제공한다.
Aurora의 주요 목표는 기업이 복잡한 데이터베이스 관리 작업에서 벗어나 애플리케이션 개발과 비즈니스 로직에 집중할 수 있도록 하는 것이다. 이를 위해 패치 적용, 백업, 복구, 장애 조치와 같은 일상적인 운영 작업의 대부분이 자동화되어 있다.
2. 아키텍처와 핵심 구성 요소
2. 아키텍처와 핵심 구성 요소
Amazon Aurora의 아키텍처는 전통적인 관계형 데이터베이스 관리 시스템의 모놀리식 설계를 탈피하여, 컴퓨팅과 스토리지를 분리하고 분산 시스템 원칙을 적용한 것이 핵심이다. 이 설계는 성능, 가용성, 내구성, 확장성의 균형을 이루도록 고안되었다.
아키텍처의 핵심은 스토리지 계층 분리에 있다. Aurora는 데이터베이스 인스턴스(컴퓨팅 노드)와 스토리지 볼륨을 물리적으로 분리한다. 스토리지 계층은 AWS의 고가용성 인프라를 기반으로 구축된 6개의 데이터 복사본을 3개의 가용 영역(AZ)에 걸쳐 자동으로 생성하고 유지한다. 데이터 변경은 쿼럼 기반 복제를 통해 스토리지 계층에 기록되며, 컴퓨팅 인스턴스는 이 분산 스토리지 풀에 논리적으로 연결된다. 이로 인해 데이터베이스 인스턴스의 장애 시 빠른 장애 조치가 가능하며, 스토리지는 컴퓨팅 리소스와 독립적으로 자동 확장된다.
복제 및 고가용성 측면에서 Aurora는 기본적으로 단일 마스터 모델을 사용한다. 하나의 기본 인스턴스(쓰기 전용)와 최대 15개의 읽기 전용 복제본을 구성할 수 있다. 복제본은 기본 인스턴스와 동일한 스토리지 볼륨을 공유하는 논리적 복제가 아닌, 스토리지 계층에서의 물리적 복제를 기반으로 하기 때문에 복제 지연이 거의 발생하지 않는다. 고가용성을 위해 Aurora는 다중 AZ 배포를 기본으로 지원하며, 기본 인스턴스에 장애가 발생하면 자동으로 읽기 전용 복제본 중 하나를 새로운 기본 인스턴스로 승격시킨다.
컴퓨팅 계층은 Amazon RDS 관리형 서비스와 유사한 형태로 제공된다. 사용자는 데이터베이스 인스턴스 유형(예: 메모리 최적화, 버스트 성능)을 선택하고, 필요에 따라 읽기 전용 복제본을 추가하여 읽기 워크로드를 분산시킬 수 있다. 컴퓨팅 인스턴스는 로그 적용과 같은 무거운 스토리지 작업 부담이 제거되어, 대부분의 리소스를 쿼리 처리에 집중할 수 있다. 이 모든 구성 요소는 Amazon Virtual Private Cloud(VPC) 내에서 관리되어 네트워크 보안과 격리를 보장한다.
2.1. 스토리지 계층 분리
2.1. 스토리지 계층 분리
Amazon Aurora의 가장 두드러진 설계 특징은 컴퓨팅 계층과 스토리지 계층을 물리적으로 분리한 아키텍처입니다. 기존의 전통적인 RDBMS는 데이터 파일, 로그 파일, 인덱스 등을 관리하는 스토리지 엔진이 데이터베이스 인스턴스와 긴밀하게 결합되어 동일한 서버에서 실행되는 것이 일반적이었습니다. 반면 Aurora는 이 개념을 재정의하여 데이터베이스 인스턴스(컴퓨팅 노드)가 쿼리 처리와 트랜잭션 관리를 담당하고, 데이터 자체는 전용의 분산형 스토리지 서비스에 저장됩니다.
이 분리된 스토리지 계층은 자동으로 확장되는 클라우드 스토리지 볼륨으로 구현됩니다. 데이터는 가용 영역에 걸쳐 최소 3개, 최대 6개의 복제본으로 자동 복제되어 저장됩니다. 컴퓨팅 인스턴스는 이 스토리지 계층과 네트워크를 통해 통신하며, 로그 구조화 방식을 채택하여 데이터 페이지 수준이 아닌 로그 레코드만 스토리지 계층으로 전송합니다. 스토리지 서비스는 이 로그 스트림을 수신하여 백그라운드에서 비동기적으로 데이터 페이지를 재구성하고 유지 관리합니다.
이러한 설계는 몇 가지 중요한 이점을 제공합니다. 첫째, 스토리지 용량은 애플리케이션의 필요에 따라 10GB 단위에서 최대 128TB까지 자동으로 확장되므로 용량 계획과 프로비저닝 오버헤드가 크게 줄어듭니다. 둘째, 컴퓨팅 인스턴스와 스토리지의 분리로 인해 읽기 및 쓰기 성능이 향상됩니다. 컴퓨팅 인스턴스는 버퍼 풀 캐시에 집중할 수 있고, 스토리지 계층은 복제본 간의 일관된 일관성과 내구성을 보장하는 복잡한 작업을 담당합니다. 마지막으로, 이 구조는 고가용성 설계의 기초가 됩니다. 컴퓨팅 인스턴스에 장애가 발생하더라도 데이터는 분산 스토리지에 안전하게 보관되며, 새로운 인스턴스가 몇 분 내에 동일한 스토리지 볼륨에 연결되어 빠르게 복구할 수 있습니다.
2.2. 복제 및 고가용성
2.2. 복제 및 고가용성
Amazon Aurora는 스토리지 계층 분리 아키텍처를 기반으로 한 고유한 복제 방식을 통해 높은 가용성을 제공한다. 전통적인 관계형 데이터베이스의 복제 방식과 달리, Aurora는 데이터를 스토리지 계층에 6개의 복제본으로 3개의 가용 영역에 분산 저장한다. 이는 내구성을 극대화하기 위한 설계이다. 데이터 쓰기 요청은 쿼럼 기반 시스템을 통해 처리되며, 6개 복제본 중 4개에 대한 쓰기 성공을 기준으로 한다. 이는 단일 또는 심지어 두 개의 가용 영역 장애가 발생하더라도 데이터 손실 없이 쓰기 가용성을 유지할 수 있음을 의미한다.
컴퓨팅 계층의 고가용성은 프라이머리 DB 인스턴스와 하나 이상의 Aurora 리플리카를 통해 구현된다. 프라이머리 DB 인스턴스에 장애가 발생하면, Aurora는 자동으로 장애 조치를 수행하여 Aurora 리플리카 중 하나를 새로운 프라이머리로 승격시킨다. 이 과정은 일반적으로 30초 이내에 완료되며, 애플리케이션의 다운타임을 최소화한다. Aurora 리플리카는 읽기 트래픽 분산을 위한 읽기 전용 복제본 역할도 동시에 수행한다.
이러한 복제 구조는 다양한 장애 시나리오로부터 시스템을 보호한다.
장애 시나리오 | Aurora의 대응 방식 | 결과 |
|---|---|---|
단일 스토리지 복제본 장애 | 쿼럼 기반 쓰기(4/6) 유지, 자동 복구 | 영향 없음 |
단일 가용 영역 장애 | 다른 두 가용 영역의 복제본으로 쿼럼 유지 | 영향 없음 |
프라이머리 DB 인스턴스 장애 | 자동 장애 조치로 Aurora 리플리카 승격 | 짧은 읽기/쓰기 중단 |
전체 리전 장애 | Aurora 글로벌 데이터베이스(별도 구성)를 통한 크로스-리전 복제 필요 | 별도 구성 시 재해 복구 가능 |
결과적으로, Aurora의 복제 및 고가용성 모델은 데이터 내구성과 서비스 연속성을 위한 다중 방어층을 구성한다. 스토리지 계층의 다중 AZ 복제는 데이터 손실 위험을 거의 제거하고, 컴퓨팅 계층의 자동 장애 조치는 애플리케이션 가용성을 유지한다. 사용자는 복잡한 복제 설정이나 페일오버 스크립트를 관리할 필요 없이 이러한 이점을 기본적으로 얻을 수 있다.
2.3. 컴퓨팅 계층
2.3. 컴퓨팅 계층
컴퓨팅 계층은 Amazon Aurora 클러스터에서 데이터베이스 인스턴스를 실행하는 계층이다. 이 계층은 애플리케이션의 연결을 처리하고 쿼리를 실행하며, 트랜잭션을 관리하는 역할을 담당한다. 컴퓨팅 리소스는 Amazon RDS와 유사한 DB 인스턴스 형태로 제공되며, 필요에 따라 인스턴스 유형을 선택하거나 스케일 업할 수 있다.
주요 구성 요소는 다음과 같다.
구성 요소 | 설명 |
|---|---|
프라이머리 인스턴스 | 읽기/쓰기 워크로드를 처리하는 주 데이터베이스 인스턴스이다. 각 Aurora 클러스터는 반드시 하나의 프라이머리 인스턴스를 가진다. |
리더 인스턴스 | 읽기 전용 워크로드를 분산시키기 위한 인스턴스이다. 최대 15개까지 추가할 수 있으며, 프라이머리 인스턴스와 자동으로 데이터를 동기화한다. |
서버리스 옵션 | 사용량에 따라 자동으로 용량을 조정하는 Aurora Serverless 구성도 가능하다. 이는 예측하기 어려운 워크로드에 적합하다. |
컴퓨팅 계층은 스토리지 계층과 완전히 분리되어 운영된다. 이는 데이터베이스 인스턴스를 재시작하거나 장애가 발생하더라도 데이터에 영향을 미치지 않으며, 인스턴스 교체나 업그레이드가 빠르게 이루어질 수 있음을 의미한다. 또한, 읽기 워크로드가 많은 경우 리더 인스턴스를 추가하여 쿼리 부하를 분산시키고 애플리케이션의 성능을 향상시킬 수 있다.
3. 주요 기능과 장점
3. 주요 기능과 장점
Amazon Aurora는 클라우드 컴퓨팅 환경에서 관계형 데이터베이스의 주요 과제를 해결하기 위해 설계된 여러 기능과 장점을 제공합니다. 전통적인 오픈 소스 데이터베이스 엔진의 호환성을 유지하면서, 클라우드 네이티브 아키텍처를 통해 성능, 가용성, 관리 편의성에서 차별화된 이점을 가집니다.
성능과 확장성 측면에서 Aurora는 스토리지 계층 분리 설계가 핵심입니다. 데이터는 SSD 기반의 자동으로 확장되는 스토리지 볼륨에 저장되며, 최대 128TB까지 확장할 수 있습니다. 컴퓨팅 리소스(인스턴스)는 스토리지와 독립적으로 확장되거나 축소될 수 있습니다. 특히 Aurora MySQL의 경우, 표준 MySQL 대비 최대 5배의 처리량을 제공하며, Aurora PostgreSQL도 유사한 성능 향상을 보입니다. 읽기 작업의 확장성을 위해 최대 15개의 읽기 전용 복제본을 빠르게 추가할 수 있고, 이 복제본들은 기본 인스턴스의 성능 부하를 거의 받지 않습니다.
내구성과 가용성은 Aurora의 또 다른 강점입니다. 데이터는 가용 영역에 걸쳐 최소 6개의 복사본으로 자동 복제되어 99.999999999%(11개의 9)의 내구성을 보장합니다. 고가용성 설계로 인해 데이터 센터 수준의 장애가 발생하더라도, 일반적으로 30초 이내에 자동 장애 조치가 이루어집니다. 이 과정에서 데이터 손실 없이 지속적인 가용성을 제공하는 것이 목표입니다. 또한 스토리지 계층의 자동 데이터 조각 모음 및 수리 기능은 성능 저하 없이 백그라운드에서 지속적으로 수행됩니다.
보안 및 관리 편의성도 통합되어 제공됩니다. 네트워크 격리를 위한 Amazon VPC, 전송 중 및 저장 데이터 암호화, AWS Key Management Service와의 통합을 통해 강력한 보안 체계를 구축합니다. 관리 측면에서는 하드웨어 프로비저닝, 데이터베이스 패치 적용, 백업 및 복원 작업의 대부분이 자동화됩니다. 사용자는 지속적인 모니터링을 위해 Amazon CloudWatch 및 Enhanced Monitoring과 같은 도구를 활용할 수 있으며, 점진적 롤백이 가능한 백업 시스템을 통해 실수로 인한 데이터 손실 위험을 줄일 수 있습니다.
3.1. 성능과 확장성
3.1. 성능과 확장성
Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 관계형 데이터베이스 서비스로, 전통적인 클라우드 데이터베이스보다 최대 5배 높은 처리량을 제공하는 것을 목표로 설계되었다. 이 성능 향상은 로그 구조적 스토리지를 기반으로 한 혁신적인 아키텍처에서 비롯된다. 기존 데이터베이스는 디스크에 데이터 페이지를 쓰는 데 많은 입출력 작업이 필요하지만, Aurora는 스토리지 계층에 로그 레코드만 전달한다. 스토리지 노드가 로그를 받아 페이지를 재구성하고, 백그라운드에서 가비지 컬렉션을 수행함으로써 데이터베이스 엔진의 부담을 크게 줄인다.
확장성 측면에서 Aurora는 컴퓨팅과 스토리지를 독립적으로 확장할 수 있다. 컴퓨팅 리소스는 데이터베이스 인스턴스의 크기를 변경하여 수직적으로 확장한다. 스토리지는 최대 128TB까지 자동으로 확장되며, 사용량에 따라 용량이 증가한다. 읽기 성능을 확장하기 위해 최대 15개의 읽기 전용 복제본을 생성할 수 있다. 이 복제본들은 공유 스토리지를 사용하므로, 마스터 인스턴스에 부하를 주지 않고도 읽기 쿼리를 분산시킬 수 있다.
성능 최적화를 위한 몇 가지 주요 기능이 포함되어 있다. Aurora 병렬 쿼리 기능은 분석 쿼리를 여러 스토리지 노드에 분산하여 실행하여 스캔 및 집계 작업의 속도를 크게 향상시킨다. Aurora 글로벌 데이터베이스는 최대 1초 미만의 지연 시간으로 전 세계 여러 리전에 읽기 전용 복제본을 배포하여 글로벌 애플리케이션의 성능을 개선한다. 또한, 인 메모리 쿼리 가속을 지원하는 Aurora Accelerator를 통해 자주 접근하는 데이터에 대한 응답 시간을 더욱 단축할 수 있다.
3.2. 내구성과 가용성
3.2. 내구성과 가용성
Amazon Aurora는 클라우드 컴퓨팅 환경에서 데이터의 안전한 보관과 지속적인 접근을 보장하기 위해 설계된 내구성 및 가용성 메커니즘을 갖추고 있다. 핵심은 데이터를 가용 영역에 걸쳐 6개의 복제본으로 자동 복제하는 스토리지 시스템에 있다. 이 복제본들은 3개의 가용 영역에 각각 2개씩 분산 배치되어, 단일 가용 영역 전체 또는 스토리지 노드 다수의 장애에도 데이터 손실 없이 서비스를 유지할 수 있다. 쓰기 작업은 쿼럼 기반으로 4개 이상의 복제본에 성공적으로 기록되어야 커밋되므로, 높은 내구성이 보장된다.
가용성 측면에서는 기본 인스턴스에 장애가 발생할 경우, 자동 장애 조치 메커니즘을 통해 대기 중이던 Aurora 복제본 중 하나가 새로운 기본 인스턴스로 승격된다. 이 과정은 일반적으로 30초 이내에 완료되어 애플리케이션의 다운타임을 최소화한다. 또한 다중 AZ 배포를 기본으로 지원하여, 전체 데이터센터 수준의 장애로부터도 보호를 제공한다. 이러한 설계는 서비스 수준 계약으로 공식화되어 있으며, Aurora는 일반적으로 99.99%의 가용성을 보장한다.
데이터 보호를 위한 추가 기능으로 지속적 백업과 시점 복구가 포함된다. 자동 백업은 기본적으로 활성화되어 있으며, 지정된 보관 기간(기본 1일, 최대 35일) 내의 특정 시점으로 데이터베이스를 복원할 수 있다. 장기적인 데이터 보관 및 규정 준수를 위해 Aurora 스냅샷 기능을 사용할 수 있다. 스냅샷은 수동 또는 자동으로 생성 가능하며, Amazon S3에 저장되어 거의 무제한의 보관이 가능하다.
기능 | 설명 | 이점 |
|---|---|---|
6방향 복제 | 데이터가 3개 가용 영역에 6개 복제본으로 분산 저장됨 | 단일 AZ 장애나 스토리지 노드 다수 장애에도 데이터 내구성 보장 |
자동 장애 조치 | 기본 인스턴스 장애 시 Aurora 복제본으로 자동 전환 | 30초 이내 복구로 고가용성 및 짧은 다운타임 제공 |
시점 복구 | 백업 보관 기간 내 특정 초 단위 시점으로 복원 가능 | 사용자 오류나 데이터 손상 시 빠른 복구 |
Aurora 스냅샷 | 데이터베이스 상태의 사용자 생성 백업, Amazon S3 저장 | 장기 보관, 개발/테스트 환경 생성, 크로스 리전 복제에 활용 |
3.3. 보안 및 관리 편의성
3.3. 보안 및 관리 편의성
Amazon Aurora는 클라우드 컴퓨팅 환경에서 데이터베이스의 보안과 운영 관리를 단순화하는 여러 기능을 제공합니다. 기본적으로 AWS Identity and Access Management와 통합되어 데이터베이스 리소스에 대한 세밀한 접근 제어가 가능합니다. 네트워크 격리를 위해 Amazon Virtual Private Cloud 내에서 실행될 수 있으며, 전송 중 및 저장 중 데이터는 TLS 및 AES-256 암호화를 통해 보호됩니다. 자동으로 생성되고 관리되는 데이터베이스 백업은 기본적으로 암호화되며, AWS Key Management Service를 사용한 키 관리도 지원합니다.
관리 측면에서는 많은 운영 작업이 자동화되어 관리 부담을 줄입니다. 하드웨어 프로비저닝, 소프트웨어 패치 적용, 백업, 복구 작업은 대부분 AWS에서 처리합니다. 특히 자동 페일오버와 스토리지 자동 확장 기능은 고가용성과 성능 유지를 위해 중요한 역할을 합니다. 데이터베이스 성능에 대한 가시성을 제공하는 Amazon CloudWatch 및 Enhanced Monitoring과 같은 모니터링 도구와도 통합되어 있습니다.
보안 기능 | 관리 편의성 기능 |
|---|---|
VPC 네트워크 격리 | |
자동화된 소프트웨어 패치 | |
미사용 데이터 AES-256 암호화 | |
IAM 기반 인증 및 권한 부여 | |
AWS KMS 통합 키 관리 | Performance Insights 성능 모니터링 |
이러한 통합된 접근 방식은 데이터 보호에 대한 규정 준수 요구사항을 충족시키는 동시에, 데이터베이스 관리자가 복잡한 인프라 관리보다 애플리케이션 개발과 비즈니스 로직에 더 집중할 수 있도록 합니다.
4. 엔진 유형 및 호환성
4. 엔진 유형 및 호환성
Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 두 가지 주요 데이터베이스 엔진을 제공합니다. 각 엔진은 상응하는 오픈 소스 데이터베이스와의 높은 수준의 호환성을 유지하면서, Aurora의 분산 스토리지 및 관리형 서비스의 이점을 제공합니다.
Aurora MySQL은 MySQL 5.7 및 MySQL 8.0과 호환됩니다. 기존 MySQL 애플리케이션, 도구, 드라이버를 대부분 수정 없이 사용할 수 있습니다. Aurora MySQL은 표준 MySQL보다 최대 5배 높은 처리량을 제공한다고 주장하며, 특히 쓰기 집약적인 워크로드에서 성능 향상을 보입니다. InnoDB 스토리지 엔진을 완벽히 지원하며, JDBC, ODBC와 같은 표준 연결 인터페이스를 그대로 사용할 수 있습니다.
Aurora PostgreSQL은 PostgreSQL 11부터 최신 버전까지의 호환성을 제공합니다. PostgreSQL의 고급 기능들, 예를 들어 JSONB 데이터 타입 지원, 공간 데이터 처리를 위한 PostGIS 확장, 그리고 다양한 프로시저 언어를 완벽히 지원합니다. Aurora의 분산 아키텍처는 PostgreSQL의 복제 및 병렬 쿼리 처리 능력을 강화하여, 대규모 데이터 세트에 대한 복잡한 분석 쿼리의 성능을 개선합니다.
두 엔진 모두 다음과 같은 공통적인 Aurora의 고급 기능을 공유합니다.
* 자동 장애 조치를 통한 고가용성
* 최대 128TB까지 자동 확장되는 스토리지
* 읽기 전용 복제본에 대한 빠른 추가
* 지속적인 백업 및 특정 시점 복구 기능
* 다른 AWS 서비스와의 긴밀한 통합
사용자는 애플리케이션의 요구사항, 기존 기술 스택, 그리고 특정 데이터베이스 기능에 대한 의존도에 따라 적합한 엔진을 선택합니다.
4.1. Aurora MySQL
4.1. Aurora MySQL
Amazon Aurora MySQL은 MySQL과 호환되는 관계형 데이터베이스 관리 시스템으로, Amazon Aurora의 두 가지 주요 데이터베이스 엔진 중 하나입니다. 이 엔진은 기존 MySQL 애플리케이션, 도구, 드라이버와의 높은 수준의 호환성을 제공하며, Aurora의 분산 아키텍처를 통해 향상된 성능과 내구성을 제공합니다. 사용자는 표준 MySQL 프로토콜과 API를 사용하여 데이터베이스에 연결하고 작업할 수 있습니다.
이 엔진은 MySQL 5.7 및 MySQL 8.0의 주요 버전과 호환됩니다. 호환성은 SQL 문법, 데이터 타입, 저장 프로시저, 트리거 등 광범위한 영역에 걸쳐 있습니다. 이를 통해 기존 MySQL 기반 애플리케이션을 최소한의 코드 변경으로 Aurora로 마이그레이션할 수 있습니다. 또한 MySQL Workbench, mysqldump, Percona XtraBackup과 같은 친숙한 관리 도구와 JDBC, ODBC와 같은 표준 커넥터를 계속 사용할 수 있습니다.
성능 측면에서 Aurora MySQL은 표준 MySQL을 실행하는 Amazon RDS 인스턴스보다 최대 5배 향상된 처리량을 제공할 수 있습니다[1]. 이는 로그 기반의 분산 스토리지 계층과 쿼리 실행을 위한 최적화된 컴퓨팅 계층 덕분입니다. 특히 쓰기 성능이 크게 개선되었으며, 읽기 전용 복제본을 추가함으로써 읽기 워크로드를 수평적으로 확장할 수 있습니다.
4.2. Aurora PostgreSQL
4.2. Aurora PostgreSQL
Amazon Aurora PostgreSQL은 PostgreSQL 오픈 소스 관계형 데이터베이스와 호환되는 Amazon Aurora의 두 가지 주요 엔진 유형 중 하나이다. 이 엔진은 PostgreSQL의 기능, 구문 및 도구와의 높은 수준의 호환성을 제공하면서 Aurora 아키텍처의 이점을 활용하도록 설계되었다. 사용자는 표준 PostgreSQL 연결 드라이버, 클라이언트 및 애플리케이션을 사용하여 Aurora PostgreSQL 데이터베이스에 연결할 수 있다.
이 엔진은 PostgreSQL의 핵심 기능을 지원하며, 동시에 Aurora의 분리된 스토리지 계층과 자동화된 복제를 통해 향상된 성능과 가용성을 제공한다. 예를 들어, Aurora 스토리지는 PostgreSQL 엔진에 최적화되어 있으며, 읽기 전용 복제본을 빠르게 추가하고 자동 장애 조치를 통해 고가용성을 보장한다. 또한, Aurora 글로벌 데이터베이스를 구성하여 여러 AWS 리전에 걸쳐 낮은 지연 시간의 읽기 및 재해 복구를 구현할 수 있다.
Aurora PostgreSQL은 특정 PostgreSQL 버전을 기반으로 하며, AWS는 정기적으로 새로운 주요 버전과 마이너 업데이트를 지원한다. 지원되는 기능에는 다음과 같은 것들이 포함된다.
지원 영역 | 주요 내용 |
|---|---|
표준 기능 | |
Aurora 고유 기능 | Aurora 머신 러닝 통합, Aurora I/O-Optimized 스토리지 티어, 백트래킹(Backtrack) 기능[2] |
성능 확장 | 병렬 쿼리, 향상된 락 관리, Aurora 버스트 버퍼를 통한 쓰기 성능 최적화 |
이 엔진은 PostgreSQL 생태계에 익숙한 개발자와 조직이 클라우드 네이티브 애플리케이션을 구축하거나 기존 온프레미스 PostgreSQL 워크로드를 AWS로 마이그레이션할 때 널리 선택된다.
5. 배포 모델
5. 배포 모델
Amazon Aurora는 애플리케이션의 가용성, 확장성 및 성능 요구사항에 따라 단일 마스터와 다중 마스터라는 두 가지 주요 배포 모델을 제공한다. 각 모델은 쓰기 작업을 처리하는 인스턴스의 구성 방식에 근본적인 차이가 있다.
단일 마스터 배포 모델은 하나의 기본 인스턴스가 모든 쓰기 및 읽기 작업을 처리하는 전통적인 마스터-슬레이브 아키텍처를 따른다. 이 기본 인스턴스는 최대 15개의 읽기 전용 복제본과 연결될 수 있으며, 복제본들은 읽기 쿼리 부하 분산과 고가용성을 위한 장애 조치 대기 목적으로 사용된다. 기본 인스턴스에 장애가 발생하면 Aurora는 자동으로 복제본 중 하나를 새로운 기본 인스턴스로 승격시킨다. 이 모델은 대부분의 애플리케이션에 적합하며, 쓰기 트래픽이 단일 엔드포인트로 집중되는 워크로드에 최적화되어 있다.
반면, 다중 마스터 배포 모델은 모든 노드가 읽기와 쓰기를 모두 처리할 수 있는 클러스터를 구성한다. 이 모델에서는 여러 인스턴스가 동시에 여러 리전에 걸쳐 데이터를 쓸 수 있으며, Aurora의 분산 스토리지 계층이 쓰기 충돌을 해결한다. 이를 통해 거의 무제한에 가까운 쓰기 확장성과 지속적인 가용성을 제공한다. 다중 마스터 클러스터는 단일 마스터 모델에서의 장애 조치 시간을 제거하여, 애플리케이션에 지속적인 쓰기 가용성이 필수적인 사용 사례에 적합하다.
다음 표는 두 배포 모델의 주요 특징을 비교한다.
특성 | 단일 마스터 | 다중 마스터 |
|---|---|---|
쓰기 엔드포인트 | 1개 (기본 인스턴스) | 여러 개 (모든 인스턴스) |
읽기 확장성 | 최대 15개의 읽기 전용 복제본 | 모든 인스턴스가 읽기 처리 |
쓰기 확장성 | 제한적 (단일 인스턴스 성능 내) | 높음 (분산 쓰기 처리) |
장애 조치 | 필요 (일시적 중단 발생) | 불필요 (지속적 가용성) |
주요 사용 사례 | 일반적인 OLTP, 읽기 중심 워크로드 | 초고가용성 요구사항, 글로벌 분산 쓰기 |
5.1. 단일 마스터
5.1. 단일 마스터
단일 마스터 배포 모델은 Amazon Aurora 클러스터에 하나의 쓰기 가능한 데이터베이스 인스턴스(마스터 인스턴스)와 최대 15개의 읽기 전용 복제본 인스턴스(리더 인스턴스)로 구성된다. 이 모델은 쓰기 작업이 단일 엔드포인트로 집중되고, 읽기 작업은 여러 복제본으로 분산되는 전통적인 마스터-슬레이브 아키텍처를 따른다. 쓰기 인스턴스는 모든 데이터 수정 작업(INSERT, UPDATE, DELETE)을 처리하며, 변경 사항은 스토리지 계층에 기록되고 비동기적으로 읽기 복제본들로 전파된다.
이 모델의 주요 장점은 구조의 단순성과 명확한 역할 분리이다. 애플리케이션은 쓰기용 연결 문자열과 읽기용 연결 문자열을 명시적으로 분리하여 사용할 수 있다. 읽기 복제본들은 읽기 전용 쿼리 부하를 분산시켜 마스터 인스턴스의 부담을 줄이고, 전체적인 처리량을 향상시킨다. 또한, 고가용성을 위해 마스터 인스턴스에 장애가 발생하면 아마존 RDS는 자동으로 읽기 복제본 중 하나를 새로운 마스터로 승격시키는 장애 조치를 수행한다.
단일 마스터 모델은 대부분의 애플리케이션에 적합하지만, 쓰기 작업의 확장성에는 한계가 있다. 모든 쓰기 트래픽이 하나의 인스턴스를 통해 이루어지기 때문에, 극도로 높은 쓰기 병목이 예상되거나 글로벌하게 분산된 애플리케이션에서 여러 지역에 걸쳐 낮은 지연 시간으로 쓰기를 수행해야 하는 경우에는 다중 마스터 배포 모델을 고려해야 한다.
특징 | 설명 |
|---|---|
쓰기 인스턴스 | 클러스터당 1개. 모든 데이터 수정 작업을 처리한다. |
읽기 인스턴스 | 클러스터당 최대 15개. 읽기 쿼리 부하 분산 및 고가용성 대기 역할을 한다. |
장애 조치 | 마스터 인스턴스 장애 시, 자동으로 읽기 복제본이 새로운 마스터로 승격된다. |
적합한 워크로드 | 쓰기 트래픽이 중앙 집중화 가능하고, 읽기 부하가 많은 애플리케이션에 이상적이다. |
5.2. 다중 마스터
5.2. 다중 마스터
Amazon Aurora의 다중 마스터 배포 모델은 단일 마스터 모델의 제약을 극복하기 위해 설계되었다. 이 모델에서는 모든 Aurora 인스턴스가 읽기와 쓰기 작업을 모두 처리할 수 있는 마스터 노드 역할을 한다. 각 인스턴스는 동일한 스토리지 볼륨에 직접 쓰기를 수행할 수 있으며, 이를 통해 애플리케이션의 여러 지점에서 거의 무제한에 가까운 쓰기 확장성을 제공한다. 이 아키텍처는 특히 쓰기 병목 현상이 발생하거나 단일 쓰기 노드 장애 시에도 쓰기 가용성을 유지해야 하는 워크로드에 적합하다.
다중 마스터 클러스터의 핵심은 분산 락 관리자이다. 이 구성 요소는 여러 마스터 노드 간의 데이터 일관성을 보장하며, 행 수준의 락을 관리하여 동시 쓰기 작업이 충돌 없이 안전하게 처리되도록 한다. 쓰기 요청은 어떤 마스터 노드로도 전송될 수 있으며, 해당 노드는 DLM을 통해 필요한 락을 획득한 후 Aurora 스토리지 계층에 직접 데이터를 기록한다. 이 과정은 네트워크 지연 시간을 최소화하고 처리량을 극대화한다.
주요 사용 사례와 장점은 다음과 같다.
사용 사례 | 설명 |
|---|---|
핫 스탠바이 제거 | 단일 마스터 모델에서 장애 조치 시 필요한 팔오버 시간이 제거되어 지속적인 쓰기 가용성을 보장한다. |
쓰기 확장성 | 애플리케이션 계층에서 부하를 분산시켜 여러 마스터 노드에 쓰기를 분배할 수 있다. |
세션 친화적 워크로드 | 사용자 세션이 특정 인스턴스에 고정되어 대기 시간이 짧은 읽기/쓰기가 모두 가능한 애플리케이션에 적합하다. |
이 모델은 모든 Aurora MySQL 호환 에디션에서 지원되지만, Aurora PostgreSQL 호환 에디션에서는 지원되지 않는다는 점에 유의해야 한다. 또한, 모든 애플리케이션이 다중 마스터의 이점을 필요로 하는 것은 아니므로, 쓰기 트래픽 패턴과 가용성 요구사항을仔細히 평가한 후 선택하는 것이 중요하다.
6. 사용 사례
6. 사용 사례
Amazon Aurora는 다양한 상업적 및 기술적 요구 사항을 가진 애플리케이션에 적합한 데이터베이스 서비스이다. 특히 높은 처리량, 낮은 지연 시간, 그리고 뛰어난 가용성이 필요한 엔터프라이즈급 OLTP 워크로드에서 두각을 나타낸다. 전자상거래 플랫폼, 금융 거래 시스템, 모바일 게임 백엔드와 같은 애플리케이션은 Aurora의 자동 확장성과 내결함성 설계를 통해 일관된 성능과 최소한의 다운타임을 보장받는다.
SaaS(Software as a Service) 제공업체나 다중 테넌트 시스템을 구축하는 경우, Aurora의 다중 마스터 배포 모델과 데이터베이스 샤딩 지원이 유용하다. 이 아키텍처는 여러 테넌트의 데이터를 효율적으로 분리하고 관리하면서도, 특정 테넌트의 급증하는 부하가 전체 시스템에 영향을 미치지 않도록 격리한다. 또한 Aurora PostgreSQL의 논리적 복제 기능은 테넌트별 데이터 동기화나 보고용 레플리카 생성에 활용된다.
고성능 OLTP 워크로드를 처리해야 하는 사용 사례에서 Aurora는 MySQL 및 PostgreSQL과의 호환성을 바탕으로 기존 애플리케이션의 마이그레이션 부담을 줄인다. 동시에, 분산된 스토리지 계층과 쿼럼 기반의 복제 방식은 기존 오픈소스 엔진보다 우수한 읽기/쓰기 성능과 데이터 내구성을 제공한다[3]. 이는 실시간 분석이 결합된 트랜잭션 처리, 대규모 사용자 기반을 가진 웹 및 모바일 앱에 적합하다.
사용 사례 유형 | Aurora의 주요 활용 기능 | 기대 효과 |
|---|---|---|
엔터프라이즈 애플리케이션 (예: ERP, CRM) | 고가용성 구성, 자동 백업 및 포인트 인 타임 복구 | 비즈니스 연속성 보장, 관리 부담 감소 |
SaaS / 다중 테넌트 시스템 | 다중 마스터, 리소스 격리, 데이터베이스 클러스터 | 테넌트별 성능 격리, 운영 효율성 향상 |
고성능 OLTP (예: 거래 플랫폼, 게임) | 낮은 지연 시간, 높은 처리량, 읽기 전용 레플리카 | 사용자 경험 개선, 피크 시간대 트래픽 처리 능력 확보 |
6.1. 엔터프라이즈 애플리케이션
6.1. 엔터프라이즈 애플리케이션
Amazon Aurora는 고가용성과 내구성, 그리고 예측 가능한 고성능을 요구하는 대규모 엔터프라이즈 애플리케이션의 핵심 데이터 계층으로 적합하다. 이러한 애플리케이션은 전자상거래 플랫폼, 금융 거래 시스템, ERP 시스템 등으로, 수천 건의 동시 트랜잭션을 처리하면서도 데이터 무결성과 지속적인 서비스 가용성을 보장해야 한다. Aurora의 분리된 스토리지 계층과 6방향으로 데이터를 복제하는 설계는 하드웨어 장애 시에도 데이터 손실 없이 자동 장애 조치를 가능하게 하여, 중요한 비즈니스 애플리케이션의 연속성을 보장한다.
성능 측면에서 Aurora는 OLTP 워크로드에 최적화되어 있다. 읽기 전용 복제본을 손쉽게 추가하여 보고서 생성이나 분석 쿼리와 같은 읽기 작업을 분리할 수 있어, 주요 트랜잭션 처리 성능에 영향을 주지 않는다. 또한, 자동 장애 조치 시간이 일반적으로 30초 미만으로 짧아 서비스 중단 시간을 최소화한다. 이는 고객-facing 애플리케이션에서 사용자 경험을 유지하는 데 결정적으로 중요하다.
관리 부담 감소 또한 엔터프라이즈 환경에서 주요 장점이다. Aurora는 백업, 패치 적용, 복제와 같은 일상적인 데이터베이스 관리 작업을 대부분 자동화한다. 또한 Amazon RDS와 호환되는 관리 도구를 사용할 수 있어, 기존 운영 방식을 크게 변경하지 않고도 마이그레이션과 관리를 수행할 수 있다. 이는 복잡한 인프라 관리에 리소스를 소모하기보다 핵심 비즈니스 로직 개발에 집중할 수 있게 한다.
6.2. SaaS 및 다중 테넌트 시스템
6.2. SaaS 및 다중 테넌트 시스템
Amazon Aurora는 다중 테넌트 아키텍처를 가진 SaaS 애플리케이션을 구축하는 데 적합한 데이터베이스 플랫폼을 제공합니다. SaaS 제공업체는 물리적 데이터베이스 인스턴스를 효율적으로 공유하면서도 각 테넌트의 데이터를 논리적으로 격리하고 성능을 보장해야 하는 과제에 직면합니다. Aurora의 아키텍처는 이러한 요구 사항을 해결하는 데 도움을 줍니다.
Aurora는 테넌트별 데이터베이스 클러스터를 쉽게 프로비저닝하고 관리할 수 있는 기능을 지원합니다. Aurora MySQL 및 Aurora PostgreSQL 엔진 모두에서 데이터베이스 수준의 격리를 기본적으로 제공하며, 각 테넌트를 별도의 데이터베이스로 할당할 수 있습니다. 성능 측면에서는 Aurora DB 클러스터의 자동 스케일링과 읽기 전용 복제본을 활용하여 특정 테넌트의 부하 증가에 대응할 수 있습니다. 또한, 다중 마스터 배포 모델을 사용하면 여러 테넌트가 동시에 쓰기 작업을 분산된 Aurora 인스턴스에 수행할 수 있어 쓰기 병목 현상을 줄일 수 있습니다.
관리 효율성을 위해 Aurora는 Amazon RDS API 및 AWS Management Console과 통합되어 테넌트 데이터베이스의 생명주기를 자동화하는 데 사용됩니다. AWS Lambda 및 AWS CloudFormation과 같은 서비스와 결합하면, 신규 테넌트 가입 시 데이터베이스 리소스를 자동으로 생성하고 구성하는 프로비저닝 파이프라인을 구현할 수 있습니다. 비용 최적화 측면에서는 Aurora Serverless v2를 고려할 수 있으며, 이는 사용량에 따라 컴퓨트 용량이 자동으로 조정되어 유휴 상태의 테넌트에 대한 비용을 절감하는 데 유용합니다.
고려 사항 | Aurora의 대응 방식 |
|---|---|
데이터 격리 | 데이터베이스 또는 스키마 수준의 논리적 격리 제공 |
성능 예측 가능성 | 인스턴스 클래스 지정, 읽기 전용 복제본 분리, 서버리스 자동 스케일링 |
운영 오버헤드 | 자동화된 백업, 패치, 복제를 통한 관리 부담 감소 |
비용 효율성 | 서버리스 옵션, 예약 인스턴스, 스토리지 사용량에 따른 과금 |
이러한 특성으로 인해 Aurora는 테넌트 간 리소스 공유와 격리 사이의 균형을 유지해야 하는 SaaS 공급자에게 널리 채택되고 있습니다.
6.3. 고성능 OLTP 워크로드
6.3. 고성능 OLTP 워크로드
Amazon Aurora는 온라인 트랜잭션 처리(OLTP) 워크로드의 높은 성능 요구사항을 충족하도록 설계되었다. 전통적인 관계형 데이터베이스가 직면하는 디스크 I/O 병목 현상을 해결하기 위해, 로그 구조의 분산 스토리지 계층을 채택하여 데이터베이스 엔진과 스토리지를 분리한다. 이 아키텍처는 쓰기 작업을 지연 없이 저널에 기록하고, 읽기 작업은 SSD 기반의 스토리지 노드에서 병렬로 처리하여 높은 처리량과 낮은 지연 시간을 제공한다.
성능 최적화를 위해 쿼리 실행 계획 캐싱, 커넥션 풀링, 비동기 I/O와 같은 기법을 활용한다. 특히 Aurora MySQL과 Aurora PostgreSQL은 각각 호환되는 오픈 소스 엔진보다 향상된 성능을 제공하도록 튜닝되었다. 예를 들어, Aurora MySQL은 네트워크 통신 오버헤드를 줄이고 버퍼 풀 관리와 로그 버퍼 처리를 개선하여, 표준 Amazon RDS for MySQL에 비해 최대 5배 높은 처리량을 제공할 수 있다[4].
고성능 OLTP 환경에서의 주요 사용 패턴은 다음과 같다.
사용 패턴 | Aurora의 대응 방식 |
|---|---|
높은 트랜잭션 처리량 | |
짧고 예측 가능한 지연 시간 | 메모리 중심 설계 및 네트워크 최적화를 통한 빠른 응답 |
급증하는 트래픽 처리 | |
실시간 분석 쿼리 |
이러한 특성으로 인해 Amazon Aurora는 전자 상거래 플랫폼의 주문 처리, 금융 서비스의 실시간 거래, 모바일 게임의 사용자 상태 업데이트, 그리고 대화형 웹 애플리케이션의 백엔드 데이터베이스와 같이 지연 시간에 민감하고 초당 수천 건의 트랜잭션을 처리해야 하는 환경에서 널리 채택된다.
7. 비용 구조 및 가격 모델
7. 비용 구조 및 가격 모델
Amazon Aurora의 비용 구조는 사용한 컴퓨팅 리소스, 스토리지, I/O 작업량에 따라 지불하는 종량제 모델을 기반으로 한다. 주요 비용 요소는 Aurora DB 인스턴스의 사양과 실행 시간, 실제로 사용한 스토리지 용량, 그리고 수행한 I/O 작업의 횟수로 구성된다. 컴퓨팅 비용은 선택한 인스턴스 클래스(예: 메모리 최적화, 버스트 가능)와 해당 인스턴스가 실행된 시간에 따라 청구된다. 스토리지 비용은 월별로 프로비저닝된 용량이 아닌, 실제로 데이터베이스에 저장된 데이터의 기가바이트(GB) 단위 사용량에 따라 부과된다.
I/O 비용은 Aurora의 아키텍처에서 중요한 차별점이다. 기존 RDBMS에서는 스토리지에 대한 읽기/쓰기 작업 비용이 일반적으로 스토리지 자체에 포함되지만, Aurora는 스토리지 계층이 분리되어 있어 요청당 비용이 발생할 수 있다. 그러나 Aurora는 효율적인 로그 구조 스토리지를 사용하여 불필요한 I/O를 줄이므로, 많은 워크로드에서 전통적인 데이터베이스보다 실제 I/O 비용이 낮을 수 있다.
비용 최적화를 위한 몇 가지 모델이 제공된다. Aurora Serverless v2는 애플리케이션 수요에 따라 수초 단위로 컴퓨팅 용량을 자동으로 확장/축소하므로, 변동성이 큰 워크로드에 대해 비용 효율적일 수 있다. 또한, 1년 또는 3년 약정을 통해 할인을 받는 예약 인스턴스 모델을 선택할 수 있어, 장기적이고 안정적인 워크로드의 경우 상당한 비용 절감이 가능하다. 데이터 전송 비용은 일반적으로 AWS 리전 내에서는 무료지만, 리전 간 또는 인터넷으로의 데이터 전출 시에는 별도 요금이 부과된다.
비용 요소 | 설명 | 청구 방식 |
|---|---|---|
컴퓨팅 | DB 인스턴스의 vCPU 및 메모리 | 인스턴스 유형별 시간당 또는 초단위(Serverless) |
스토리지 | 클러스터 볼륨에 실제 저장된 데이터 | 사용한 GB당 월별 |
I/O 작업 | 스토리지에 대한 요청 수 | 백만 요청당 |
백업 스토리지 | 자동 백업 및 스냅샷 보관 | 사용한 GB당 월별 (일정 무료 할당량 존재) |
데이터 전송 | 리전 외부로의 데이터 전출 | GB당 |
비용 관리와 예측을 돕기 위해 AWS Cost Explorer 및 AWS 예산 설정과 같은 도구를 사용하여 지출을 모니터링하고 예산 알림을 설정할 수 있다.
8. 마이그레이션 및 통합
8. 마이그레이션 및 통합
Amazon Aurora로의 마이그레이션은 AWS Database Migration Service(DMS) 또는 AWS Schema Conversion Tool(SCT) 같은 관리형 도구를 통해 비교적 원활하게 수행할 수 있다. DMS는 마이그레이션 중에도 소스 데이터베이스의 가동 중단 시간을 최소화하는 지속적인 복제를 지원하여, 온라인 트랜잭션 처리(OLTP) 애플리케이션의 마이그레이션에 적합하다. SCT는 오라클 데이터베이스나 Microsoft SQL Server 같은 상용 데이터베이스의 스키마와 코드 객체를 Aurora MySQL 또는 Aurora PostgreSQL 호환 형식으로 자동 변환하는 데 주로 사용된다.
통합 측면에서 Aurora는 AWS 생태계와 깊이 연동되어 있다. Amazon RDS 콘솔과 API를 통해 통합 관리할 수 있으며, Amazon CloudWatch를 통한 모니터링, AWS Identity and Access Management(IAM)을 통한 세밀한 접근 제어, AWS Key Management Service(KMS)를 이용한 암호화가 기본적으로 제공된다. 또한 Amazon S3와의 직접적인 데이터 내보내기/불러오기 기능, AWS Lambda와의 트리거 연동, Amazon Redshift를 위한 데이터 공유 등 다양한 서비스와의 통합을 지원한다.
다른 데이터베이스에서 Aurora로의 마이그레이션 경로는 다음과 같이 요약할 수 있다.
소스 데이터베이스 | 권장 마이그레이션 경로 | 주요 고려 사항 |
|---|---|---|
Amazon RDS for MySQL/PostgreSQL | 스냅샷 복원 또는 DMS | 파라미터 그룹 및 보안 설정 조정 필요 |
온프레미스 MySQL/PostgreSQL | DMS를 이용한 지속적 복제 | 네트워크 대역폭 및 지연 시간 고려 |
SCT로 스키마 변환 후 DMS로 데이터 이전 | 저장 프로시저, 함수 등 코드 변환 검증 필수 | |
다른 클라우드의 데이터베이스 | DMS 또는 네이티브 도구를 통한 데이터 덤프/복원 | 소스/대상 간의 네트워크 연결 구성 필요 |
9. 관련 서비스 및 생태계
9. 관련 서비스 및 생태계
Amazon Aurora는 AWS 생태계 내 다른 서비스들과 긴밀하게 통합되어 포괄적인 데이터 관리 및 애플리케이션 구축 솔루션을 제공한다. 주요 통합 서비스로는 Amazon RDS가 있으며, Aurora는 RDS의 관리형 데이터베이스 서비스 패밀리에 속한다. 따라서 사용자는 익숙한 RDS API, CLI 도구, AWS Management Console을 통해 Aurora 인스턴스를 프로비저닝, 모니터링, 관리할 수 있다. 또한 AWS Database Migration Service를 이용해 기존 온프레미스 또는 EC2 상의 MySQL, PostgreSQL 데이터베이스를 Aurora로 마이그레이션할 수 있다.
스토리지 및 분석 영역에서는 Amazon S3와의 통합이 핵심적이다. Aurora는 스냅샷 백업을 S3에 저장하며, `LOAD DATA FROM S3` 또는 `SELECT INTO OUTFILE TO S3`와 같은 구문을 통해 S3와 직접 데이터를 주고받을 수 있다. 분석 워크로드를 위해 Amazon Redshift나 Amazon EMR과의 통합도 지원되어, 운영 데이터에 대한 대규모 분석을 수행할 수 있다.
애플리케이션 레이어에서는 AWS Lambda를 이용한 서버리스 아키텍처와의 결합이 일반적이다. Lambda 함수는 Aurora와 직접 연결되어 이벤트 기반의 데이터 처리를 가능하게 한다. 또한 Amazon CloudWatch를 통한 성능 모니터링, AWS IAM을 이용한 세밀한 접근 제어, AWS Secrets Manager를 통한 자격 증명 관리가 지원된다. 고가용성 및 글로벌 배포를 위해서는 Amazon Route 53과 AWS Global Accelerator와 같은 네트워킹 서비스와 함께 사용될 수 있다.
통합 영역 | 관련 AWS 서비스 | 주요 통합 기능 |
|---|---|---|
관리 및 마이그레이션 | 프로비저닝, 모니터링, 데이터베이스 마이그레이션 | |
스토리지 및 분석 | 데이터 백업/복원, 데이터 레이크 통합, 분석 쿼리 | |
애플리케이션 개발 | 서버리스 백엔드, GraphQL API 생성 | |
보안 및 모니터링 | 접근 제어, 성능 지표 수집, 감사 로깅 | |
네트워킹 | 격리된 네트워크 환경, 프라이빗 연결, 글로벌 라우팅 |
