Category: Amazon Aurora

Amazon Aurora는 현재 가장 빠르게 성장하고 있는 AWS 서비스입니다. 클라우드에 최적화된 관계형 데이터베이스 엔진으로서 Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS는 높은 성능 향상과 최대 64TB까지 원활하게 스토리지 확장 및 견고성과 가용성 향상을 실현하였습니다.

Aurora을 MySQL 호환 엔진으로 디자인함으로써 고객은 기존 애플리케이션을 마이그레이션하거나 새로운 응용 프로그램 구축할 때 더욱 간단하게 접근하실 수 있습니다.오늘 추가로 세 가지 성능을 개선하는 새로운 기능을 Aurora에 추가했습니다. 각각의 기능은 AWS를 많이 이용하는 고객의 일반적인 워크로드에서 Aurora 성능을 최대로 개선하도록 설계되었습니다.

• 병렬 미리 읽기(Parallel Read Ahead) – 구간 선택, 전체 테이블 스캔, 테이블 변경, 인덱스 생성을 최대 5배 빠르게 성능 개선
• 빠른 인덱싱(Faster Index Build) – 인덱스 생성 시간을 약 75% 단축
• NUMA 인식 스케줄링(NUMA-Aware Scheduling) – 두 개 이상의 CPU가 탑재 된 데이터베이스 인스턴스를 사용하는 경우, 쿼리 캐시에서 및 버퍼 캐시에서 읽기 성능 향상 및 전체 처리량이 최대 10 % 향상

한 가지씩 자세히 살펴보겠습니다.

병렬 미리 읽기
MySQL에서 사용되는 InnoDB 스토리지 엔진은 테이블 행이나 인덱스 키(index key)를 이용하는 스토리지(디스크 페이지)를 관리합니다. 이는 테이블의 순차 스캔 속도와 새로 생성 된 테이블에 효과적입니다. 그러나, 테이블 행이 업데이트 혹은 생성 및 삭제되면, 데이터가 파편화됨으로써 물리적으로 더 이상 순차적이지 않고, 스캔 성능이 크게 저하됩니다. InnoDB의 선형 미리 읽기(Linear Read Ahead) 기능은 페이지가 실제로 사용할 때까지 메모리에서 64 페이지까지 정리하여 데이터 파편화에 대처하고 있습니다. 그러나, 일반적으로 엔터프라이즈 규모의 워크로드에서는 이 기능이 성능 향상을 제공하지 않는다고 알려져있습니다.

이번 기능 업데이트에서는 Aurora가 많은 상황에서 현명하게 이러한 상황을 처리할 수 있는 기능을 제공합니다. Aurora의 테이블을 스캔 할 때, 논리적으로 판단하고 병렬로 페이지를 미리 추가합니다. 이러한 미리 추가(pre-fetch)기능은 Aurora의 복제 스토리지 (3개 가용 영역에 각각 2 개씩 복사)에서 우위를 발휘하여, 데이터베이스 캐시중인 페이지가 스캔 작업과 관련 있는지를 판단하는 데 도움이 됩니다.

결과적으로, 구간 검색, 전체 테이블 검색, ALTER TABLE 그리고 index 생성을 이전 버전에 비해 최대 5 배 빠르게 할 수 있습니다.

Aurora 1.7로 업그레이드하면 바로 성능 향상을 경험하실 수 있습니다.

빠른 인덱싱
특정 테이블에 기본(Primary) 및 보조(Secondary) 인덱스를 만들 때, 스토리지 엔진은 새로운 키를 포함해서 트리 구조를 만듭니다. 이 작업은 통해 많은 하향식 트리 검색 및 키의 증가에 대응하기 위해 트리 재구축을 통해 페이지 분할을 하게됩니다.

Aurora는 상향식(bottom-up) 트리 구조를 만듭니다. 리프(leaves)를 먼저 만들고 필요한 만큼 부모 페이지를 추가합니다. 이를 통해 스토리지 이동을 줄이고, 각 페이지가 일단 모두 메워지도록 하여 페이지를 분할 할 필요가 없습니다.

이를 통해 테이블​ 스키마에 따라 다르지만, 인덱스 추가 또는 테이블 재구성이 최대 4배 빨라집니다. 예를 들어, Aurora 팀이 다음과 같은 스키마에서 테이블을 만들고 1억 행을 추가하여 5GB의 사이즈 테이블을 제작했습니다.

create table test01 (id int not null auto_increment primary key, i int, j int, k int);

그리고 4개의 index를 추가했습니다.

alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);

db.r3.large 인스턴스에서 쿼리 실행 시간이 67분에서 25분으로 줄었고, db.r3.8xlarge에서는 29분에서 11.5분으로 단축되었습니다.

본 신규 기능은 우선 정식 서비스 환경이 아닌 테스트를 먼저 하시길 권장합니다. Aurora 1.7으로 업그레이드 하신 후, DB 인스턴스 파라미터 그룹에서 aurora_lab_mode를 1로 설정합니다. (더 자세한 사항은 DB Cluster and DB Instance Parameters 를 참고하시기 바랍니다.)

본 기능에 대한 질문 및 피드백은 Amazon RDS Forum을 통해 보내주시면 감사하겠습니다.

NUMA 기반 스케줄링
가장 큰 데이터베이스 인스턴스( db.r3.8xlarge )는 2개의 CPU를 탑재하고 있고, 불균일 기억 장치 접근(Non-Uniform Memory Access, NUMA)라는 기능을 가지고 있습니다. 본 유형의 시스템은 메인 메모리 파티션을 각 CPU에서 직접 효율적으로 사용할 수 있습니다. 나머지 메모리는 조금 비효율적 CPU 간의 접근 경로를 통해 사용합니다.

Aurora는이 고르지 못한 접근 시간을 활용하기 위해 스케줄링 스레드의 작업을 효율적으로 처리 할 수 있게 되었습니다. 스케줄링 스레드는 다른 CPU에 연결되어 있는 비효율적인 메모리 접근을 고려할 필요가 없습니다. 결과적으로, 쿼리 캐시와 버퍼 캐시를 많이 사용하는 같은 CPU 바운드 작업에서 최대 10%까지 성능을 향상하였습니다. 동일한 데이터베이스 인스턴스에 수백 또는 수천개의 동시 연결이 되어 있을 때, 현저하게 성능이 높아집니다. 예를 들어, Sysbench oltp.lua 벤치 마크에서 570,000 reads/second에서 625,000 reads/second로 향상되었습니다. 이 테스트에서는 db.r3.8xlarge DB 인스턴스에서 다음 매개 변수를 이용하여 테스트릴 진행했습니다.

• oltp_table_count = 25
• oltp_table_size = 10000
• num-threads = 1500

Aurora 1.7로 업그레이드하면 바로 성능 향상을 경험하실 수 있습니다.

Aurora 1.7 업그레이드하기
DB 인스턴스를 새로 만드는 경우, Aurora 1.7로 자동으로 시작합니다. 이미 실행중인 DB 인스턴스에서 바로 업데이트하거나 다음 번에 업데이트를 선택하여 설치가 가능합니다.

아래 쿼리를 통해 Aurora 1.7이 적용되어 있는지 확인할 수 있습니다.

mysql> show global variables like "aurora_version";
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| aurora_version | 1.7   |
+----------------+-------+ 

— Jeff;

이 글은 Amazon Aurora Update – Parallel Read Ahead, Faster Indexing, NUMA Awareness의 한국어 번역입니다.

AWS 클라우드를 활용하는 고객들이 더 빠르게 관계형 데이터베이스에 저장되어있는 대량 데이터를 마이그레이션하는 방법에 대해 궁금해 합니다. 오늘 이와 관련된 Amazon Aurora의 중요한 새로운 기능을 출시했습니다. 이미 사내 환경과 Amazon EC2 인스턴스에서 MySQL을 사용하는 경우, 기존 데이터베이스를 백업하고 스냅샷 백업을 Amazon S3에 업로드하고, 스냅샷 백업을 사용하여 Amazon Aurora 클러스터를 만들 수 되었습니다. 기존 Amazon Aurora의 MySQL 데이터베이스에서 복제 할 수있는 기능과 함께 사용하면 MySQL에서 Amazon Aurora에 응용 프로그램을 중지시키지 않고 쉽게 마이그레이션 할 수 있습니다.

본 신규 기능을 이용하여 대용량의 데이터(2TB 이상)를 MySQL 데이터베이스에서 Amazon Aurora에 원본 데이터베이스에 성능 영향을 최소화하면서 효율적으로 전환할 수 있습니다. 사전 테스트에서는 mysqldump utility를 이용한 경우와 비교하여 20 배 빠르게 처리 할 수 있었습니다. InnoDB와 MyISAM 형식의 테이블이 모두 포함되어 있어도 전환은 가능하지만, 마이그레이션 전에 MyISAM에서 InnoDB로 변환 하는 것을 권장합니다.

마이그레이션 방법에 대해 간략하게 설명해 보겠습니다.

1. 원본 데이터베이스 준비 – 원본 데이터베이스에서 바이너리 로그 활성화를 합니다. 마이그레이션 동안 바이너리 로그가 남아있는 것처럼 설정을 해주십시오.
2. 원본 데이터베이스 백업 – Percona Xtrabackup를 이용하여 원본 데이터베이스에서 “핫(Hot)”백업을 만듭니다. 이 도구는 데이터베이스 테이블이나 트랜잭션을 잠그지 않고도, 압축 백업을 만들 수 있습니다. 하나의 백업 파일이나 여러 개의 작은 백업 파일을 만들 수 있으며, Amazon Aurora는 어떤 형식으로도 이용하실 수 있습니다.
3. S3 업로드 – S3로 백업 파일을 업로드합니다. 5TB 미만의 백업의 경우는 AWS Management Console 및 AWS Command Line Interface (CLI)를 이용하여 업로드합니다. 큰 백업 데이터의 경우 AWS Import/Export Snowball을 이용하는 것을 검토할 필요가 있습니다.
4. IAM Role – Amazon Relational Database Service (RDS)에 업로드 된 백업 데이터와 S3 버킷에 접근하기 위해 IAM role을 만듭니다. 본 IAM role은 반드시 RDS가 ListBucket과 GetBucketLocation 작업을 버킷에 실행할 수 있으며 GetObject을 백업 데이터에 적용합니다. (자세한 샘플 정책 기술 문서 에서 확인하실 수 있습니다).
5. 클러스터 생성 – 새로운 Amazon Aurora 클러스터를 업로드 한 백업 데이터에서 만듭니다. RDS 콘솔에서 Restore Aurora DB Cluster from S3를 클릭하고 원본 데이터베이스 버전을 선택합니다. 그리고 S3 버킷을 선택하고 IAM Role을 선택한 후, Next Step을 클릭합니다. 클러스터 작성 페이지 (DB Details 및 Configure Advanced Settings)의 나머지 항목을 입력합니다. Amazon Aurora는 백업 파일을 알파벳 순으로 처리합니다.
6. MySQL 스키마 전환– 사용자 권한과 MySQL INFORMATION_SCHEMA 설정을 마이그레이션합니다.
7. 관련 항목 전환 – 트리거(trigger), 함수(function)과 스토어드 프로시저(stored procedure)를 원본 데이터베이스에서 Amazon Aurora 클러스터로 마이그레이션합니다.
8. 복제 설정 – 원본 데이터베이스와 Amazon Aurora간에 복제를 구성합니다.
9. 데이터베이스 변경 – 모든 클라이언트 응용 프로그램의 연결을 Amazon Aurora 클러스터로 변경합니다.
10. 복제 정지 – Amazon Aurora 클러스터에 복제를 중지합니다.

정식 서비스 환경에서는 데이터베이스 마이그레이션 전에 사전 테스트 작업을 하기를 권장합니다.

정식 출시
이 새로운 기능은 오늘부터 Asia Pacific (Mumbai) 리전을 제외한 모든 리전에서 사용할 수 있습니다. 자세한 정보는 Amazon Aurora User Guide 내에 Migrating Data from an External MySQL Database to an Amazon Aurora DB Cluster 를 참조하십시오.

– Jeff;

이 글은 Amazon Aurora Update – Create Cluster from MySQL Backup의 한국어 번역입니다.

Amazon Aurora 기존 클러스터에 읽기 복제본(Read Replica)을 추가하여 읽기 용량에 대해 확장을 하실 수 있습니다. 오늘 부터 읽기 복제본을 다른 리전에서도 만들 수 있는 기능을 제공합니다. 신규 기능을 이용하여 리전 간 재해 복구 구성을 사용할 수 있으며, 읽기 용량을 확장 할 수 있습니다. 그 외에도 다른 리전 데이터베이스를 이전하거나, 새로운 환경을 구축하는 데에도 사용할 수 있습니다.

읽기 복제본을 다른 리전에 만들면 Aurora 클러스터가 그 리전에도 생성됩니다. Aurora 클러스터에는 15대까지 리전 내에서 낮은 지연 속도(대부분의 경우 20ms 이내)에서 읽기 복제본을 만들 수 있습니다. 리전 사이의 경우, 원본 클러스터와 대상 클러스터 사이의 거리에 따라 지연 시간이 증가합니다. 이러한 구성은 현재 Aurora 클러스터를 복제하거나, 재해 복구 목적으로 읽기 복제본를 리전간에 구성하기를 원할 때 사용할 수 있습니다. 만일 리전에 오류가 발생한 경우, 지역간 읽기 복제본이 마스터 데이터베이스로 변경됨으로, 다운타임을 최소화 할 수 있습니다. 본 기능은 암호화되지 않은 Aurora 클러스터에 적용 가능합니다.

읽기 복제본을 만들기 전에 대상 리전에 VPC와 Database Subnet Groups가 존재하는지 마스터에서 바이너리 로그가 활성화되어 있는지 확인해야합니다.

VPC 설정 하기
Aurora는 VPC내에서 동작하기 때문에, 원하는 리전에 적절한 Database Subnet Groups가 존재하는지 확인합니다.

바이너리 로그 사용하기
지역 간 읽기 복제본을 설정하기 전에 바이너리 로그를 활성화 해야 합니다. 만약 default 매개 변수 그룹을 사용하는 경우, 새로운 DB Cluster Parameter Group을 생성합니다.

바이너리 로그를 활성화 (MIXED로 선택)하고, Save Changes를 클릭합니다.

Next, Modify the DB Instance, select the new DB Cluster Parameter Group, check Apply Immediately, and click on Continue. Confirm your modifications, and then click on Modify DB Instance to proceed:

다음 단계로, 설정을 변경하고자 하는 DB 인스턴스를 선택하고 Modify를 선택합니다. 그리고 새로운 DB Cluster Parameter Group을 통해 Apply Immediately를 선택하고 Continue를 클릭합니다. 설정 변경을 확인한 후, Modify DB Instance를 누릅니다.

인스턴스를 선택하고 재시작을 실행될 때까지 기다립니다

읽기 복제본 만들기
사전 준비가 완료되면 읽기 복제본을 만듭니다. 우선 AWS Management Console에서 소스 클러스터를 선택하고, Instance Actions메뉴에서 Create Cross Region Read Replica를 선택합니다 :

Name the new cluster and the new instance, and then pick the target region. Choose the DB Subnet Group and set the other options as desired, then click Create:

새 인스턴스나 클러스터의 이름을 설정하고 대상 리전을 선택합니다. DB Subnet Group을 선택하고 다른 옵션도 원하는 설정한 후, 마지막으로 Create를 누릅니다.

본 기능은 오늘 부터 바로 사용할 수 있습니다.

— Jeff;

이 글은 New – Cross-Region Read Replicas for Amazon Aurora의 한국어 번역입니다.

Amazon Aurora는 MySQL 호환 고성능 데이터베이스 엔진입니다. Aurora는 고성능 데이터베이스 속도 및 가용성을 오픈 소스 데이터베이스의 비용 효율성과 간편함으로 이용하실 수 있습니다. (더 자세한 것은 Amazon Aurora 정식 출시를 참고하세요.) Aurora를 통해 Amazon RDS에서 활용할 수 있는 간편 관리, 손 쉬운 확장, 속도, 보안, and 비용 효율성 등의 몇 가지 중요한 기능을 가지고 있습니다.

또한, 몇 번의 클릭으로 Aurora 클러스터 백업을 위해 스냅 샷을 만들 수 있습니다. 스냅 샷을 생성 후, 같은 몇 번의 클릭으로 스냅 샷에서 데이터베이스를 복원 할 수 있습니다.

스냅 샷 공유
오늘 부터 Aurora 스냅 샷을 공유하실 수 있게 되었습니다. 스냅 샷은 다른 AWS 계정과 공유 할뿐만 아니라 공개적으로 공유도 가능합니다. 동일 지역 다른 AWS 계정에서 실행중인 Aurora 스냅 샷에서 데이터베이스를 복원 할 수 있습니다.

스냅 샷 공유의 주요 사례를 몇 가지 소개합니다.

분리된 개발 환경간 공유 – 많은 AWS 고객께서 개발, 테스트, 준비 및 정식 서비스 환경에서 개별 AWS 계정을 사용하고 있습니다. 필요에 따라 이러한 계정간에 스냅 샷을 공유하실 수 있습니다. 예를 들어, 초기 데이터베이스를 준비 환경에서 구축하고 스냅 샷을 만듭니다, 그리고 스냅 샷을 프로덕션 환경의 계정에 공유 스냅 샷에서 프로덕션 데이터베이스를 만듭니다. 그 밖에도 정식 서비스 코드나 쿼리에서 문제가 발생한 경우 프로덕션 환경의 데이터베이스 스냅 샷을 만들어 테스트 환경에 디버깅 목적으로 공유할 수 있습니다.

파트너와의 공유 – 필요에 따라 스냅 샷을 특정 파트너에 공유 할 수 있습니다

데이터 공동 이용 – 만약 연구 프로젝트를 실시하고 있다면, 스냅 샷을 생성하고 공개적으로 공유 할 수 있습니다. 관심을 가진 사람이 그 스냅 샷에서 자신의 Aurora 데이터베이스를 만들고 여러분의 데이터를 시작점으로 사용할 수 있습니다.

스냅 샷을 공유하기 위해서는 RDS 콘솔에서 Share Snapshot을 클릭합니다. 그리고 공유 대상 AWS 계정을 입력합니다. (혹은 공용 공유를 위해 Public를 선택합니다) 그리고 Add를 선택합니다.

공유 스냅 샷은 수동 작성된 것, 암호화되지 않은 것을 다른 AWS 계정 및 공용으로 공유 할 수 있습니다. 자동 취득 된 스냅 샷과 암호화 된 스냅 샷은 공유할 수 없습니다.

공유 된 스냅 샷은 곧바로 다른 계정에서 보실 수 있습니다.

공개 스냅 샷도 볼 수 있습니다. (Filter에서 All Public Snapshots를 선택)

정식 출시
이 기능은 오늘부터 바로 사용하실 수 있습니다.

— Jeff;

이 글은 New – Cross-Account Snapshot Sharing for Amazon Aurora의 한국어 번역입니다.

Amazon Aurora를 오늘 부터 Asia Pacific (Seoul)  리전에서 사용할 수 있습니다.

Amazon Aurora는 MySQL과 호환되는 관계형 데이터베이스 관리 시스템(RDBMS)로, 고급 상용 데이터베이스의 속도와 가용성을 오픈소스 데이터베이스를 쓸 때 만큼의 편리함과 저렴한 비용으로 누리실 수 있습니다.

기존 MySQL 대비 다섯 배 강력한 성능을 제공하며, 고급 상용 데이터베이스의 1/10 수준의 가격으로 사용하실 수 있습니다.

Amazon Aurora는 고성능의 99.99% 가용성을 지원하며 64TB까지의 스토리지 확장성을 쉽고도 효율적으로 제공합니다. 이 서비스는 내부 및 가용 영역 내 스토리지 복제가 가능하고 쿼럼 쓰기(quorum writes) 기반의 업데이트 모델을 가지고 있습니다.

지금 시작해 보세요!
2015년 7월 정식 출시하여 AWS 리전에 확대되어 왔으며, 오늘(3월 30일)부터 서울 리전에서도 Amazon Aurora를 사용해 한국 내 최종 사용자들에게 더 뛰어난 서비스와 경험을 제공하실 수 있습니다.

요금 정책은 아래와 같습니다:

• 데이터베이스 인스턴스 – 기본 인스턴스와 리플리카에 대해 시간당 과금이 되며, 2vCPU/15.25Gib메모리 모델부터 32vCPU/244GiB메모리 모델까지 5가지 인스턴스 종류가 있습니다. 또한, 예약 인스턴스(Reserved Instances)를 통해 일상 DB 운영의 경우 저렴하게 이용하실 수 있습니다.
• 스토리지 – 스토리지에 대해서는 월간 GB당 $0.10이 실제 데이터베이스에서 시간 당 측정해서 사용한 용량 만큼만 과금됩니다. 본 요금을 통해 여러분은 6개의 데이터 복사본을 가지게 되며, 각 3개의 가용영역 당 2개의 복사본을 의미합니다.
• 입출력(I/O) – 데이터베이스가 만드는 각 1백만 입출력(I/O) 요청 당 $0.20를 과금합니다.

더 자세한 것은 Amazon Aurora 요금 정책을 참고하시기 바랍니다.

더 자세히 보기
Amazon Aurora 제품 페이지에 더 많은 정보를 제공하고 있으며, Amazon Aurora 문서를 참고하십시오. Aurora를 실전에 사용하기 위한  온라인 세미나 발표를 참고하시는 것도 권장해 드립니다.

 [온라인 세미나] Amazon Aurora 100% 활용하기

• 강사: 김상필 (AWS코리아, 솔루션즈아키텍트)
• 발표자료 다운로드 Adobe Connect로 다시 보기

Aurora 관련 한국 블로그 목록

• Amazon RDS 확장 모니터링 기능 – MySQL 5.6, MariaDB 및 Aurora용
• Amazon Aurora 암호화 기능 지원 시작!
• Amazon Aurora 정식 출시

Aurora 이전 관련 고객 블로그

• 최소한의 다운타임으로 아마존 RDS Aurora DB로 이전하기 by Sendbird
• RDS MySQL에서 RDS Aurora로 DB이전 다운타임 최소화 하기 by  드라마앤컴퍼니

Amazon Aurora 완전 관리형 MySQL 호환 관계형 데이터베이스 서비스로서 빠른 성능과 고가용성을 통해 엔터프라이즈급 데이터베이스를 오픈 소스 수준의 가격 효율성을 통해 제공 받을 수 있는 신규 서비스입니다. (더 자세한 것은 Amazon Aurora – 신규 비용 효율적인 MySQL 호환 데이터베이스 엔진을 참고하세요.)

Aurora는 15개까지 읽기 복제본을 만들 수 있고, 이를 통해 읽기 처리량을 높을 수 있을 뿐 아니라 장애 복구에도 도움이 됩니다. 각 복제본은 기본 인스턴스와 스토리지를 공유하고, 경량의 세부적인 복제가 거의 동시적으로 일어나기 때문에 10에서 20 밀리초 단위 내에 이루어집니다.

추가적인 장애 복구 제어 기능
오늘 좀 더 원활하게 장애 복구 처리가 가능하도록 읽기 복제본의 우선 순위를 높일 수 있는 제어 기능을 제공합니다. 각 읽기 복제본은 티어(0-15)를 제공할 수 있습니다. 장애 복구 시 Amazon RDS는 가장 우선 순위의 티어(낮은 숫자)를 기반으로 장애 복구를 시작하고, 2개 이상의 읽기 복제본이 같은 우선 순위일때는 이전 기본 인스턴스와 같은 용량을 우선 선택합니다.

Aurora DB 인스턴스를 만들 때 우선 순위를 설정할 수 있습니다.

이 기능은 지금 부터 사용 가능하며, 더 자세한 사항은 Fault Tolerance for an Aurora DB Cluster를 참고하시기 바랍니다.

— Jeff;

이 글은 Additional Failover Control for Amazon Aurora의 한국어 번역입니다.

여러분이 기존 환경에서 오라클, SQL서버, MySQL, MariaDB 및  PostgreSQL 데이터베이스를 운영하고 계시다면, AWS 클라우드로 이전하셔서 확장성이 높은 운영 효율적인 다양한 대용량 데이터 스토리지 옵션의 혜택을 누리실 수 있습니다.

그러면 어떻게 다운타임 없이 이전을 할 수 있을까요? 오늘 출시된 AWS Database Migration Service (DMS) 서비스가 바로 그 해답입니다. 작년 가을 AWS re:Invent 행사에서 미리 보기로 발표된 이후로 이미 우리 고객들의 1,000여개가 넘는 데이터베이스가 AWS로 이전하였습니다. 여러분도 바로 테라 바이트급 데이터베이스를 운영하는 도중이나 (신규 요구사항에 맞춤) 새로운 버전으로 업그레이드 하면서 라이브로 옮겨 보실 수 있습니다. 만약 클라우드로 옮기려고 하는 데이터베이스가 완전히 다른 엔진이라면 AWS Schema Conversion Tool 을 통해 스키마와 저장 프로시저를 새로운 환경으로 옮길 수 있습니다

AWS Database Migration Service는 AWS 상의 리플리케이션 인스턴스를 설정하여 동작하게 됩니다. 이 인스턴스는 기존 소스 데이터베이스에서 데이터를 업로드하고, 이전 대상 데이터베이스에 전송을 합니다. 이를 통해 최소한의 다운타임을 지원하는 리플리케이션 방식을 따라서 한번에 이전이 가능하다는 장점이 있습니다. DMS는 마이그레이션에 관련된 복잡한 문제들, 예를 들어 데이터 타입 변환, 데이터 플랫폼의 이전(오라클, Aurora 등)이 가능합니다. 또한, 리플리케이션 인스턴스 현황 및 헬스 체크 모니터링을 제공하며, 문제가 있을 때 알림을 보내고 필요하다면 자동으로 인스턴스를 대체할 수 있습니다. 

DMS는 다양한 이전 시나리오 및 네트워크 옵션을 제공합니다. 엔드 포인트가 AWS일 수도 있고, 기존 온-프레미스 환경일 수도 있습니다. 또한 EC2  인스턴스에 설치된 DB 혹은 RDS 인스턴스가 될 수도 있습니다. 소스 및 최종 이전 대상은 같은  Virtual Private Cloud (VPC)에 있거나, 두 개의 나눠진  VPC에서도 가능합니다. 여러분이 온-프레미스 데이터베이스를 이전하시려면, AWS Direct Connect.를 사용하여 전용 회선으로 연결하여 VPC 설정 후 사용 가능합니다.

데이터베이스 마이그레이션 하기
관리 콘솔에서 몇 번 클릭을 하기만 하면, 이전 작업을 시작할 수 있습니다. 먼저 이전을 원하는 데이터베이스를 선택하고, 스키마 이전, 리플리케이션 설정, 마이그레이션 시작을 하면 됩니다. 소스에서 이전이 완전히 완료가 되면, 애플리케이션에서 DB의 설정만 바꾸어 주면 됩니다.

AWS Database Migration Service 콘솔에서 DMS 를 클릭한 후, Create migration을 선택합니다.

콘솔에서는 마이그레이션 절차에 대해 간단하게 소개해 드립니다.

리플리케이션 인스턴스를 만들 각종 파라미터 값을 입력합니다.

이 글에서는 기존 VPC를 선택하고, Publicly accessible를 선택하지 않았습니다. 이전 대상 데이터베이스는 EC2 인스턴스에 있기 때문입니다.

리플리케이션 인스턴스가 만들어지면, 소스 및 최종 이동 대상 데이터베이스를 선택한 후   Run test를 선택합니다. 접속이 잘되는지 네트워크 이슈가 없는 지를 테스트해 볼 수 있습니다.

이제 실제 마이그레이션 작업이 진행되기 위해, Migration type을 설정하면, 기존 데이터, 이전 후 리플리케이션, 리플리케이션 등을 선택할 수 있습니다.

이제 Task Settings를 선택합니다. (LOBs는 Large Objects를 의미합니다).

마이그레이션 작업을 위해, Start/Resume를 선택하면 됩니다.

진행 사항을 보실 수 있으며, Table statistics를 통해 이전 사항을 확인할 수 있습니다. (아래 그림은 테스트 테이블입니다.)

이전이 완료되면, 간단한 테스트를 거쳐 애플리케이션의 DB 엔드포인트를 변경 한 후 배포하시면 됩니다.

AWS Database Migration Service는 다양한 선택 사항을 제공합니다. 예를 들어, 특정 테이블만 옮긴다던지, 여러 개의 다른 리플리케이션 작업을 할 수도 있고, 시간에 따라 작업을 활성화 시킬 수도 있습니다. 좀 더 자세한 사항은 DMS 기술 문서 (영문)을 참고하시면 됩니다.

여러분이 다양한 데이터베이스 세트를 옮기신다면, AWS Command Line Interface (CLI)나 the Database Migration Service API를 활용하시길 권장합니다.

가격 및 출시 리전
AWS Database Migration Service는 현재 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore),  및 Asia Pacific (Sydney) 리전에 우선 출시되었으며, 향후 빠른 시일 내에 (서울 리전을) 비롯한 다른 리전에 출시될 예정입니다.

— Jeff;

이 글은 AWS Database Migration Service의 한국어 번역입니다.

Amazon Relational Database Service (RDS)를 이용하여 손쉽게 관계형 데이터베이스의 설치 및 실행, 확장 등의 유지 보수를 할 수 있습니다. 여러분은 애플리케이션이나 비즈니스에만 주력할 수 있도록, 대부분의 관리는 AWS에서 수행합니다.

확장 모니터링
Amazon RDS를 활용하고 있는 고객들로부터 RDS 내부의 상세한 정보를 모니터링하고 싶다는 요청을 많이 받았습니다. 그래서, 오늘 확장 모니터링 기능을 추가했습니다.

데이터베이스 인스턴스에서 확장 모니터링 기능을 활성화하면 CPU, 메모리, 파일 시스템 및 디스크 I/O 등의 50개 이상의 측정치에 대한 정보를 얻을 수 있습니다. 본 기능은 데이터베이스 인스턴스 단위로 할 수 있습니다. 모니터링 및 측정 시간도 (1 초 단위까지) 세부적으로 설정 가능합니다. 사용 가능한 통계 목록은 아래와 같습니다.

아래는 제 RDS 인스턴스에서 얻은 샘플 데이터입니다.

RDS 콘솔에서 모니터링 설정을 구성하려는 데이터베이스 인스턴스를 선택하고 Instance Options 메뉴에서 Modify를 선택하여 이미 실행중인 데이터베이스 인스턴스에 설정할 수 있습니다.

기능을 활성화 한 후, IAM Role을 선택하고 단위를 선택한 후, Apply Immediately에 체크하고 Continue를 클릭합니다.

확장 모니터링은 CloudWatch Logs 및 Amazon CloudWatch에 로그를 게시 할 수 있습니다. 이와 같이 설정할 때는 측정치 필터를 설정해야 하며, 자세한 내용은 를 참조하십시오. 일단 CloudWatch Logs에 수치들이 저장된 후에는 타사 제품의 분석·모니터링 도구를 활용하는 것도 가능합니다.

정식 출시
확장 모니터링 기능은 오늘부터 US East (Northern Virginia), US West (Northern California), US West (Oregon) Europe (Ireland) Europe (Frankfurt), Asia Pacific (Singapore) Asia Pacific (Sydney), Asia Pacific (Tokyo) 지역의 t1.micro과 m1.small을 제외한 MySQL 5.6, MariaDB, Amazon Aurora의 모든 인스턴스 유형에서 사용할 수 있습니다.

일반적인 CloudWatch Logs 수집 및 데이터 전송 요금으로 이용하실 수 있습니다. (자세한 내용은 CloudWatch Logs 요금 페이지를 참조하십시오.)

— Jeff;

이 글은 New – Enhanced Monitoring for Amazon RDS (MySQL 5.6, MariaDB, and Aurora)의 한국어 번역입니다.

약 1년 전 Amazon Aurora를 출시하였습니다. (참고. Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS). Amazon Aurora는 AWS 서비스 중 가장 빠르게 고객이 사용하는 서비스가 되었습니다! 최근에 Amazon Aurora는 Asia Pacific (Tokyo)에 적용되어, 일본 고객들이 많이 활용하고 있으며, 다른 지역에서도 계속 확장 중입니다.(US East (Northern Virginia), US West (Oregon) 및 Europe (Ireland) regions).

암호화 기능 도입
데이터 보호 전략에서 암호화는 매우 중요한 영역입니다. 여러분이 Amazon Aurora에 저장된 데이터 암호화를 좀 더 쉽게 하기 위해, 다른 RDS 암호화 기능처럼 데이터베이스 인스턴스를 만들 때, AWS Key Management Service (KMS)를 사용하여 (AWS 관리 혹은 여러분이 관리하는) 키를 간단히 선택함으로서 암호화 기능을 사용할 수 있습니다.

데이터베이스, 로그, 백업, 스냅샷 및 읽기 복제본 내 데이터에 암호 알고리듬 (AES-256)을 적용할 수 있습니다. 데이터베이스 인스턴스를 만들 때, 암호화 기능을 시작해야 하며 현재 사용 중인 인스턴스에서는 사용 및 중지할 수 없습니다. 더 자세한 것은 Amazon RDS 자원 암호화 문서를 참고하시기 바랍니다.

만약 자체 키를 만든다면, 매년 변경 요청을 할 수 있습니다.

AWS 계정에 대한 감사를 위한 AWS CloudTrail 로그도 가능하며, 이를 통해 KMS를 통해 호출된 모든 로그를 확인할 수 있습니다. (Encrypt, Decrypt API 참고). 더 자세한 내용은 Logging AWS KMS API Calls Using AWS CloudTrail 문서를 참고하시기 바랍니다.

— Jeff;

PS – 요청하시기 전에 Amazon Aurora는 AES-256 암호화 알고리즘을 사용합니다.

본 글은 New – Encryption at Rest for Amazon Aurora의 한국어 번역입니다.

작년 AWS re:Invent에서 발표했던 Amazon Aurora를 오늘 정식 출시합니다. (참고: Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon) Amazon Aurora는 고성능의 99.99% 가용성을 지원하며 64TB까지의 스토리지 확장성을 쉽고도 효율적으로 제공합니다. 이 서비스는 내부 및 가용 영역 내 스토리지 복제가 가능하고 쿼럼 쓰기(quorum writes) 기반의 업데이트 모델을 가지고 있습니다.

지난 9개월 동안 AWS 고객들께서 Amazon Aurora를 직접 테스트하셨으며, 다양한 테이블 설정, 접근 패턴 그리고 다양한 쿼리 등을 실행해 보았습니다. 이를 통해 얻어진 피드백을 통해 서비스에 대한 더 자세한 기능 개선을 지속하였습니다. 그 결과, 고객들은 Amazon Aurora 인스턴스가 초 당 10만 쓰기와 50만 읽기의 성능을 보이는 결과를 얻었습니다. 또한 이전에 같은 성능의 가격 보다 5배 정도 성능 대비 가격이 저렴하게 되었습니다.

Amazon Aurora 정식 출시
오늘부터 모든 고객이 AWS Aurora를 사용하실 수 있으며 현재 3개의 리전에서 서비스를 시작합니다. 테스트 기간 동안 몇 가지 중요한 기능을 추가하였는데, 우선 소개해 드릴 것이 바로 빠르고 쉽게 데이터를 이전하는 기능입니다. 원래 블로그 글에 소개된 핵심 기능 중 하나로서, 오늘은 여기에 집중해 보고자 합니다.

지연 없는 데이터 이전
만약 여러분이 Amazon RDS for MySQL를 사용하시고 Amazon Aurora로 이전하고자 하신다면, 지연 없이(zero-downtime) 바로 데이터 이전이 가능합니다. 여기에서 간단한 과정을 설명해 드리겠지만, 실제로 사용 중인 데이터를 이전할 때는 반드시 개발자 문서를 참고하셔서 진행하시기 바랍니다. 데이터 이전이 즉시 완료되고 나면, 여러분은 Amazon Aurora의 고성능 처리량(throughput), 높은 보안 및 저렴한 가격의 서비스를 경험하실 수 있습니다. 생각한 것 보다 훨씬 짧은 시간에 데이터베이스의 확장 및 관리 및 애플리케이션 코드와의 호환이 가능하다는 것을 아실 수 있습니다.

이미 데이터베이스가 사용 중이라면, 인스턴스 파라미터 그룹(MySQL Database Log Files 참고)의 바이너리 로깅을 시작하십시오. 특정 경우에서는 RDS 읽기 복제본(RDS Read Replica)를 설정할 필요가 있고, 데이터 이전 및 복제를 위한 것으로 사용할 수도 있습니다. (Replication with Amazon Aurora 참고).

RDS 관리 콘솔을 여신 후, 기존 데이터베이스 인스턴스를 선택하고 Instance Actions 메뉴에서 Migrate Database를 선택합니다.

내용을 입력하시고 Migrate 버튼을 클릭합니다. (대부분의 경우, DB Instance Class 내용 이상을 채울 필요는 없을 것입니다.)

Aurora가 새로운 DB 인스턴스를 만들고 데이터 이전을 시작합니다.

조금 시간이 걸린 후 (데이터베이스 크기에 따라 다르지만 커피 한잔 정도의 여유), Amazon Aurora 인스턴스가 실행됩니다.

Aurora를 설치하는 동안 원본 데이터베이스가 변경이 되었다고 가정하고, mysql.rds_set_external_master 명령을 통해 새로운 Aurora로 최신 데이터를 복제한 후, 애플리케이션에 Aurora 엔드 포인트로 변경합니다.

다양한 측정 기준(Metrics) 제공
각 Aurora 인스턴스는 Amazon CloudWatch를 통해 다양한 측정 기준에 따른 값들을 제공합니다. 이들 기준값을 콘솔에서도 보실 수 있으며 이를 통해 알람을 설정하고 이를 기반으로 다양한 기능 수행을 할 수 있습니다.

쉽고 빠른 복제(Replication) 기능
Amazon Aurora 인스턴스는 15개까지 리플리카(Replicas)를 구성할 수 있으며, 이는 추가로 읽기 성능을 높혀주게 됩니다. 몇 번의 클릭으로 리플리카를 바로 생성할 수 있습니다.

Amazon Aurora의 독특한 스토리지 구조를 통해 복제 지연 시간은 거의 없으며 10-20ms 정도를 보이게 됩니다.

5배 좋아진 가격 대비 성능
처음 Amazon Aurora를 발표했을 때, 기존 솔루션 보다 적어도 4배의 가격 대비 성능 향상이 있을 거라 발표했습니다. 이제 정식 출시를 맞아 이러한 기존 목표를 훨씬 뛰어 넘어 같은 성능의 하드웨어 구성에서 전통적 관계형 데이터베이스를 운용할 때 보다 5배의 가격 대비 성능을 보이게 되었다고 알려드리게 되어 매우 기쁘게 생각합니다.

다만, 일반적으로 이전 보다 개별 쿼리 속도가 5배가 늘었다는 것을 의미하는 것은 아닙니다. (물론 Amazon Aurora의 빠른 SSD 기반의 스토리지가 속도 개선이 있습니다.) 대신, 이는 Amazon Aurora가 다른 제품 보다 동시에 보다 많은 쿼리(읽기/쓰기)를 실행할 수 있다는 의미입니다. Amazon Aurora는 스토리지에서 병렬 접근을 통해 데이터 획득에 대한 비용을 줄이고 높은 효율성의 쿼리 실행이 가능하게 합니다.

파트너 지원
주요 AWS Partner Network (APN) 파트너는 Amazon Aurora를 직접 테스트 하면서 다양한 경험을 쌓았으며, 몇 가지 주요 기능에 대한 지원을 시작했습니다. 아래는 그 중 일부 솔루션입니다.

• 비지니스 지능화(Business Intelligence) – Tableau, Zoomdata, and Looker.
• 데이터 통합(Data Integration) – Talend and Attunity.
• 질의 모니터링(Query and Monitoring) – Webyog, Toad,  and Navicat.
• 시스템 통합 및 모니터링(SI and Consulting) – 8K Miles, 2nd Watch, and Nordcloud.

지금 시작해 보세요!
많은 고객과 파트너들이 Amazon Aurora를 테스트해보고, 실제 업무에 적용하고 있습니다. 현재 US East (Northern Virginia), US West (Oregon) 및 Europe (Ireland) 리전에 지원을 시작했으며 앞으로도 계속 확대할 예정입니다.

요금 정책은 아래와 같습니다:

• 데이터베이스 인스턴스 – 기본 인스턴스와 리플리카에 대해 시간당 과금이 되며, 2- 32 vCPUs 및 15.25 – 244 GiB 메모리 사이의 5가지 인스턴스 종류가 있습니다. 또한, 예약 인스턴스(Reserved Instances)를 통해 일상 DB 운영의 경우 저렴하게 이용하실 수 있습니다.
• 스토리지 – 스토리지에 대해서는 월간 GB당 $0.10이 실제 데이터베이스에서 시간 당 측정해서 사용한 용량 만큼만 과금됩니다. 본 요금을 통해 여러분은 6개의 데이터 복사본을 가지게 되며, 각 3개의 가용영역 당 2개의 복사본을 의미합니다.
• 입출력(I/O) – 데이터베이스가 만드는 각 1백만 입출력(I/O) 요청 당 $0.20를 과금합니다.

더 자세한 것은 Amazon Aurora 요금 정책을 참고하시기 바랍니다.

더 자세히 보기
Amazon Aurora 제품 페이지에 더 많은 정보를 제공하고 있으며, Amazon Aurora 문서를 참고하십시오. Aurora를 실전에 사용하기 위한 Amazon Aurora 온라인 세미나에 참여하시는 것도 권장해 드립니다.

— Jeff;

이 글은 Now Available – Amazon Aurora의 한국어 번역입니다.