Category: Amazon Aurora*


Amazon Aurora 기반 개발 및 테스트용 신규 T2.Medium DB 인스턴스 타입 추가

Amazon Aurora는 이미 db.r3.large (2 vCPUs/15 GiB of RAM)에서 db.r3.8xlarge (32 vCPUs/244 GiB of RAM)까지 단계별로 다섯 가지의 데이터베이스 인스턴스 타입을 지원하고 있습니다. 이를 통해 보다 높은 성능을 위해 폭넓은 애플리케이션 범위를 지원 하고 있습니다.

오늘 여섯번째 선택으로 db.t2.medium (2 vCPUs/4 GiB of RAM) 데이터베이스 인스턴스 타입 지원을 소개합니다. 다른 T2 인스턴스 처럼 싱글 코어 성능의 40% 정도를 보장하고, CPU를 많이 쓰는 질이나 다른 데이터베이스 작업에 CPU 성능 전체를 사용할 수 있는 크레딧을 제공합니다. 본 인스턴스 타입은 CPU 크레딧을 처음에 전체를 할당하고, CPU 추가 성능시 크레딧을 사용하고, 그렇지 않을 시간에는 보충하는 모델을 가지고 있습니다. (자세한 사항은 저가 T2 인스턴스 출시 – 급격한 트래픽 처리 가능 참고.)

db.t2.medium 인스턴스 타입은 정식 서비스 전 개발 및 테스트 혹은 작은 서비스에 최적의 비용 대비 성능을 보여줄 것입니다. CPUCreditUsageCPUCreditBalance 통계를 통해 크레딧 상태를 체크하는 것이 좋습니다.

정식 출시
오늘 부터 Amazon Aurora 데이터베이스 선택 시 모든 리전에서 사용 가능합니다. 사용 금액은 시간 당 $0.125(서울 리전)로 부터 시작되며, 예약 인스턴스 또한 지원 합니다.

Jeff;

이 글은 Use Amazon Aurora for Dev & Test Workloads with new T2.Medium DB Instance Class의 한국어 번역입니다.

Amazon Aurora 업데이트 – Lambda Function 호출 및 S3 데이터 읽기 지원

AWS 서비스들은 그 자체만으로도 훌륭하지만, 서로 결합함으로써 더욱 다양한 서비스를 만들 수 있습니다. 저희의 서비스 모델은 각 서비스를 선택하여 학습하여 경험을 쌓은 다음, 다른 서비스와 결합 및 확장하는 레고블럭을 조립하는 것 같은 방식입니다. 이를 통해 각 서비스를 다양하게 활용할 기회와 함께 고객의 요구에 따라 서비스 로드맵에 반영할 수 있습니다.

오늘은 이와 관련하여 MySQL 호환 관계형 데이터베이스 서비스인 Amazon Aurora에 두 가지 기능을 추가합니다.

  • Lambda 함수 호출 – Amazon Aurora 데이터베이스의 스토어드 프로시저(stored procedures)에서 AWS Lambda 함수를 호출 할 수 있습니다.
  • S3 데이터 읽기 – Amazon Simple Storage Service (S3) 버킷에 저장된 데이터를 Amazon Aurora 데이터베이스에서 읽을 수 있습니다.

위의 두 가지 기능은 다른 AWS 서비스를 연계하기 위해 Amazon Aurora에 적절한 권한을 부여해야합니다. IAM 정책(Policy) 및 IAM 역할(Role)을 만들고, 그 역할을 Amazon Aurora 데이터베이스 클러스터에 부여합니다. 자세한 단계는Authorizing Amazon Aurora to Access Other AWS Services On Your Behalf를 참조하십시오.

Lambda 함수 통합
관계형 데이터베이스 트리거(trigger)와 스토어드 프로시저를 함께 사용하여 본 기능을 수행할 수 있습니다. 트리거는 특정 테이블 작업 전후에 수행 할 수 있습니다. 예를 들어, Amazon Aurora는 MySQL과 호환성이 있기 때문에 INSERT, UPDATE, DELETE 작업에 트리거를 지원합니다. 스토어드 프로시저는 트리거에 대한 응답에서 실행 가능한 스크립트입니다.

Lambda 함수를 스토어드 프로시저를 사용하여, Aurora 데이터베이스와 다른 AWS 서비스를 묶을 수 있습니다. Amazon Simple Email Service (SES)를 이용하여 이메일을 보내거나 Amazon Simple Notification Service (SNS)를 이용해 알림을 보내고, Amazon CloudWatch에 사용자 정의 통계를 추가하거나, Amazon DynamoDB 테이블을 업데이트할 수 있습니다.

그 외에도 복잡한 ETL 작업 또는 워크 플로우, 데이터베이스 테이블에 대한 감사, 성능 모니터링 및 분석 등의 용도로도 사용할 수 있습니다.

스토어드 프로시저에서 mysql_lambda_async 프로시저를 호출 하면 됩니다. 이 프로시저는 비동기적으로 주어진 Lambda 함수를 실행하기 위해 함수 실행 완료를 기다리지 않고 처리를 종료합니다. Lambda 함수에 이용하는 AWS 서비스 및 자원에 대한 권한을 부여해야합니다.

자세한 내용은 Invoking a Lambda Function from an Amazon Aurora DB Cluster를 참조하십시오.

S3 데이터 읽기

또한, AWS의 주요서비스인 Amazon S3 버킷에 저장된 데이터를 직접 Aurora에 가져올 수 있게 되었습니다 (지금까지는 한 번 EC2 인스턴스에 다운로드 한 후 가져와야했습니다.)

Amazon Aurora 클러스터에서 접근 가능하면, AWS 어느 리전에 데이터가 배치되어 있어도 읽기 가능합니다. 형식은 텍스트 또는 XML 형식을 지원합니다.

텍스트 형식의 데이터를 가져 오기 위해서는, LOAD DATA FROM S3 명령을 이용합니다. 이 명령은 MySQL의 LOAD DATA INFILE과 거의 같은 옵션을 지원합니다. 그리고, 압축 데이터는 현재 지원하지 않습니다. 특정 행이나 필드 구분자와 문자 집합 설정이 가능하고, 지정한 행과 열 수를 무시하고 통합 할 수 있습니다.

XML 형식 데이터를 가져 오기 위해 새로운 LOAD XML from S3

Xml
<row column1="value1" column2="value2" />
...
<row column1="value1" column2="value2" />

또는 아래와 같습니다.

Xml
<row>
  <column1>value1</column1>
  <column2>value2</column2>
</row>
...

또는 아래와 같습니다.

Xml
<row>
  <field name="column1">value1</field>
  <field name="column2">value2</field>
</row>
...

더 자세한 사항은 Loading Data Into a DB Cluster From Text Files in an Amazon S3 Bucket 문서를 참고하십시오.

정식 출시
본 신규 기능은 오늘부터 이용하실 수 있습니다! 추가로 요금이 부과되지 않지만, 일반적인 Amazon Aurora, Lambda, S3 요금이 발생합니다.

Jeff;

이 글은 Amazon Aurora Update – Call Lambda Functions From Stored Procedures; Load Data From S3의 한국어 번역입니다.

Amazon Aurora – 신규 읽기 엔드 포인트 기능 (로드 밸런싱 및 고가용성 제공)

Amazon Aurora는 더욱 사용하기 쉬우면서 강력한 데이터베이스 서비스로 자리잡고 있습니다. 지난 몇 달 동안 저희는 MySQL 백업에서 클러스터 생성, 리전간 Read Replica 추가 가능, 계정간 스냅샷 공유 기능 추가, 장애 처리를 위한 추가 기능데이터베이스 마이그레이션 서비스 등을 지속적으로 출시했습니다.

오늘은 Aurora 읽기 복제 기능을 위해 클러스터 수준의 읽기 엔드 포인트를 추가했습니다. 여러분이 만든 응용 프로그램은 지금까지 하던 방식 대로 특정 읽기 복제본에 대해 직접 쿼리를 실행할 수도 있습니다. 이번에 추가한 읽기 엔드 포인트를 이용하도록 변경하면, 부하 분산 및 고가용성 등 두 가지 큰 이점을 얻을 수 있습니다.

로드 밸런싱(Load Balancing)
클러스터 엔드 포인트에 연결하여 DB 클러스터의 읽기 복제본 간의 로드 밸런싱ㅣ 가능합니다. 이것은 읽기 워크로드를 분산하고, 사용 가능한 복제본 간에 자원을 효율적으로 활용할 수 있어 보다 높은 성능을 얻을 수 있습니다. 장애 발생 시, 각 응용 프로그램이 연결되어있는 복제본이 기본 인스턴스로 승격하는 경우 연결은 일단 끊기고, 그 후 다시 연결을 할 클러스터의 다른 복제본에 읽기 쿼리를 실행할 수 있습니다.

고 가용성(Higher Availability)
Aurora 복제본을 각 가용 영역(Availability Zone)마다 배치하고, 읽기 엔드 포인트를 통해 연결할 수 있습니다. 특정 가용 영역에 문제가 만일 발생했을 경우, 읽기 엔드 포인트를 이용하여 최소한의 다운 타임으로 읽기 트래픽을 다른 가용 영역내 복제본에서 실행 가능합니다.

엔드 포인트 확인하기
읽기 엔드 포인트는 Aurora Console에서 확인 가능합니다.

본 기능은 Aurora를 제공하는 모든 리전에서 지금 바로 사용 가능합니다.

Jeff;

이 글은 New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability의 한국어 번역입니다.

Amazon Aurora 기능 업데이트 – 병렬 미리 읽기, 고속 인덱싱 , NUMA 인식 등

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의 사이즈 테이블을 제작했습니다.

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

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

SQL
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_mode1로 설정합니다. (더 자세한 사항은 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이 적용되어 있는지 확인할 수 있습니다.

SQL
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의 한국어 번역입니다.

Amazon Aurora, MySQL 백업에서 클러스터 구축 기능 제공

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 ConsoleAWS Command Line Interface (CLI)를 이용하여 업로드합니다. 큰 백업 데이터의 경우 AWS Import/Export Snowball을 이용하는 것을 검토할 필요가 있습니다.
  4. IAM RoleAmazon Relational Database Service (RDS)에 업로드 된 백업 데이터와 S3 버킷에 접근하기 위해 IAM role을 만듭니다. 본 IAM role은 반드시 RDS가 ListBucketGetBucketLocation 작업을 버킷에 실행할 수 있으며 GetObject을 백업 데이터에 적용합니다. (자세한 샘플 정책 기술 문서 에서 확인하실 수 있습니다).
  5. 클러스터 생성 – 새로운 Amazon Aurora 클러스터를 업로드 한 백업 데이터에서 만듭니다. RDS 콘솔에서 Restore Aurora DB Cluster from S3를 클릭하고 원본 데이터베이스 버전을 선택합니다. 그리고 S3 버킷을 선택하고 IAM Role을 선택한 후, Next Step을 클릭합니다. 클러스터 작성 페이지 (DB Details 및 Configure Advanced Settings)의 나머지 항목을 입력합니다. rds_aurora_pick_src_backupAmazon 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 추가 가능

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, 계정간 스냅샷 기능 추가

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, 서울 리전 출시!

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% 활용하기

Aurora 관련 한국 블로그 목록

Aurora 이전 관련 고객 블로그

Amazon Aurora, 추가 장애 복구 기능 지원

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의 한국어 번역입니다.

AWS 데이터베이스 마이그레이션 서비스(DMS) 오픈!

여러분이 기존 환경에서 오라클, 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의 한국어 번역입니다.