Category: Amazon RDS*


Amazon Neptune – 완전 관리형 그래프 데이터베이스 서비스

최근 애플리케이션 데이터 구조와 알고리즘 중에서 특히 그래프(Graph)는 하루가 다르게 발전하고 있습니다. 최근 다양한 기업들은 소셜 미디어나 데이터 추천 등 복잡한 관계 데이터를 지속적으로 생성하고 수집합니다. 그러나, 개발자들은 복잡한 관계 기반 데이터를 기존 데이터베이스에서 모델링하게 되는데, 이로 인해 관계를 추가할 때마다 비용이 많이 들고 성능을 점점 저하시키는 극도로 복잡한 쿼리가 발생합니다. AWS는 갈수록 복잡해지는 최신 데이터 세트, 관계 및 패턴을 처리하고자 하는 고객의 요구를 지속적으로 받아왔습니다.

Amazon Neptune 소개

오늘 Amazon Neptune의 제한적 프리뷰 버전을 출시합니다. Amazon Neptune은 빠르고 안정적인 그래프 데이터베이스 서비스로, 고도로 연결된 데이터 세트 간의 관계로부터 쉽게 통찰력을 얻을 수 있습니다. 즉, 수십억 개의 관계를 저장하고 몇 밀리초의 지연 시간으로 그래프 기반 데이터를 쿼리하는 데 최적화된, 특수 목적의 고성능 그래프 데이터베이스 엔진입니다.

Amazon Neptune은 완전 관리형 데이터베이스로 제공되므로 고객은 유지 보수, 패치 적용, 백업 및 복원 같은 지루하고 반복적인 작업보다 애플리케이션 업무에 집중할 수 있습니다. 이 서비스는 가용성 증대를 위해 빠른 장애 조치, 지정 시간 복구 및 다중 AZ 배포를 지원합니다. 읽기 복제본을 최대 15개 지원하므로 쿼리 처리량을 초당 수십만 개의 쿼리로 확장할 수 있습니다. Amazon Neptune은 Amazon Virtual Private Cloud 내에서 실행되며, 유휴 데이터를 암호화할 수 있어, 전송 중이거나 유휴 상태인 데이터의 무결성을 완벽하게 달성할 수 있습니다.

이 서비스에는 흥미로운 기능이 있지만 여러분에게는 그래프 데이터베이스가 익숙하지 않은 주제일 수 있으므로 지금부터 관련 용어를 검토하는 시간을 갖겠습니다.

그래프 데이터베이스 기초

그래프 데이터베이스는 키-값 쌍으로 저장되는 속성을 가질 수 있는 정점(노드)과 간선(관계 또는 연결)의 저장소입니다. 그래프 데이터베이스는 연결된 데이터, 컨텍스트 데이터, 관계 중심 데이터에 유용합니다. 대표적인 분야로 소셜 미디어 네트워크, 추천 엔진, 자동차 운전 안내 시스템, 물류, 진단, 사기 탐지 및 게놈 시퀀싱 등이 있습니다.

Amazon Neptune은 그래프 설명 및 쿼리 방식으로 두 가지 개방형 표준을 지원합니다.

  • Apache TinkerPop3 스타일 속성 그래프는 Gremlin으로 쿼리됩니다. Gremlin은 그래프 순회 언어로서, 쿼리는 노드의 엣지(Edge)에 따라 별개의 단계로 구성된 순회입니다. TinkerPop에서 작동하도록 설계된 기존 도구와 클라이언트를 사용하면 Neptune을 빠르게 시작할 수 있습니다.
  • RDF(Resource Description Framework)SPARQL로 쿼리됩니다. SPARQL은 W3C의 시맨틱 웹 표준을 기반으로 하는 선언적 언어입니다. subject->predicate->object 모델을 따릅니다. 특히 Neptune은 RDF 1.1, SPARQL Query 1.1, SPARQL Update 1.1 및 SPARQL Protocol 1.1 표준을 지원합니다.

SPARQL 또는 TinkerPop에서 작동하는 기존 애플리케이션이 있는 경우 애플리케이션이 연결되는 엔드포인트를 업데이트하기만 하면 Neptune을 사용할 수 있습니다. Amazon Neptune을 시작하는 방법을 알려드리겠습니다.

Amazon Neptune 시작하기

먼저 Neptune 콘솔로 이동한 다음 “Launch Neptune”을 클릭하여 시작 마법사를 시작합니다.

이 첫 번째 화면에서는 인스턴스의 이름을 지정하고 인스턴스 유형을 선택합니다. 그런 다음 고급 옵션을 구성합니다. 이전에 인스턴스 기반 AWS 데이터베이스 서비스(Amazon Relational Database Service(RDS) 또는 Amazon ElastiCache)를 실행해본 적이 있다면 대부분의 과정이 익숙하게 느껴질 것입니다.

Amazon Neptune은 VPC에서 안전하게 실행되며 편리한 액세스를 위해 EC2 인스턴스를 추가할 수 있는 자체 보안 그룹을 만들 수 있습니다.

다음으로 파라미터 그룹, 포트, 클러스터 이름 등 몇 가지 추가 옵션을 구성할 수 있습니다.

이 다음 화면에서는 KMS 기반의 저장 시 암호화, 장애 조치 우선 순위, 백업 보존 기간을 설정할 수 있습니다.

RDS와 마찬가지로 서비스에서 데이터베이스의 유지 관리를 처리할 수 있습니다.

인스턴스의 프로비저닝이 완료되면 클러스터의 세부 정보 페이지에서 연결 엔드포인트를 찾을 수 있습니다. 저의 경우 triton.cae1ofmxxhy7.us-east-1.rds.amazonaws.com입니다.

Amazon Neptune 사용

위에서 설명한 것처럼 Amazon Neptune에서는 두 종류의 쿼리 엔진을 사용할 수 있습니다. gremlin 엔드포인트에 연결하려면 /gremlin 엔드포인트를 사용해 다음 작업을 수행할 수 있습니다.


curl -X POST -d '{"gremlin":"g.V()"}' https://your-neptune-endpoint:8182/gremlin

마찬가지로 /sparql을 이용해 SPARQL 엔드포인트에 연결할 수 있습니다.


curl -G https://your-neptune-endpoint:8182/sparql --data-urlencode 'query=select ?s ?p ?o where {?s ?p ?o}'

데이터를 쿼리하기 전에 데이터베이스를 채워야 합니다. AWS re:Invent를 모델링하고 대량 로딩 API를 사용해 데이터를 삽입한다고 가정해봅시다. 속성 그래프의 경우, Neptune은 로딩 노드, 노드 속성, 엣지, 엣지 속성에 대해 Amazon Simple Storage Service(S3)에 저장된 CSV를 지원합니다.

일반적인 정점 CSV의 형식은 이와 같습니다.

~label,name,email,title,~id
Attendee,George Harrison,george@thebeatles.com,Lead Guitarist,1
Attendee,John Lennon,john@thebeatles.com,Guitarist,2
Attendee,Paul McCartney,paul@thebeatles.com,Lead Vocalist,3

엣지 CSV 형식은 이와 같습니다.

~label,~from,~to ,~id
attends,2,ARC307,attends22
attends,3,SRV422,attends27

이제 유사한 구조의 CSV를 Neptune에 로드하기 위해 다음과 같이 실행하겠습니다.

curl -H 'Content-Type: application/json' \
https://neptune-endpoint:8182/loader -d '
{
    "source": "s3://super-secret-reinvent-data/vertex.csv",
    "format": "csv",
    "region": "us-east-1",
    "accessKey": "AKIATHESEARENOTREAL",
    "secretKey": "ThEseARE+AlsoNotRea1K3YSl0l1234coVFefE12"  
}'

그러면 다음 결과가 반환될 것입니다.

{
    "status" : "200 OK",
    "payload" : {
        "loadId" : "2cafaa88-5cce-43c9-89cd-c1e68f4d0f53"
    }
}

이 결과를 가져와 로딩 상태를 쿼리할 수 있습니다. curl https://neptune-endpoint:8182/loader/2cafaa88-5cce-43c9-89cd-c1e68f4d0f53

{
    "status" : "200 OK",
    "payload" : {
        "feedCount" : [{"LOAD_COMPLETED" : 1}],
        "overallStatus" : {
            "fullUri" : "s3://super-secret-reinvent-data/stuff.csv",
            "runNumber" : 1,
            "retryNumber" : 0,
            "status" : "LOAD_COMPLETED",
            "totalTimeSpent" : 1,
            "totalRecords" : 987,
            "totalDuplicates" : 0,
            "parsingErrors" : 0,
            "datatypeMismatchErrors" : 0,
            "insertErrors" : 0
        }
    }
}

이 특정 데이터 직렬화 형식에 대해서는 이 로딩 프로세스를 내 엣지에도 반복합니다.

RDF의 경우 Neptune은 Turtle, N-Triples, N-Quads 및 RDF/XML 등 네 가지 직렬화를 지원합니다. 하나의 로딩 API를 통해 이 모든 것을 로드할 수 있습니다.

이제 데이터베이스에 데이터가 있으니 쿼리를 실행할 수 있습니다. Gremlin에서 그래프 순회로 쿼리를 작성합니다. 저는 폴 매카트니의 열렬한 팬으로서 그가 참여하는 모든 세션을 찾아보려고 합니다.
g.V().has("name","Paul McCartney").out("attends").id()

그러면 “Paul McCartney”라는 값의 “name” 속성을 가진 모든 노드를 찾는 그래프 순회가 정의됩니다(단 하나뿐입니다!). 다음으로 “참석” 유형의 해당 노드에서 모든 엣지를 따라 결과 노드의 ID를 가져옵니다.


==>ENT332
==>SRV422
==>DVC201
==>GPSBUS216
==>ENT323

위 내용을 통해 그래프 데이터베이스 기능의 간략한 개요를 파악하셨기를 바랍니다. 그래프 데이터베이스는 많은 고객들에게 새로운 가능성을 제공하며, Amazon Neptune을 사용하면 대용량 데이터를 쉽게 저장하고 쿼리할 수 있습니다.

Randall;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 Amazon Neptune – A Fully Managed Graph Database Service의 한국어 번역입니다.

Sprinklr의 AWS 리전간 대용량 재해 복구 구축 사례

Sprinklr에서 통합된 고객 경험 관리 플랫폼을 통해 세계에서 가장 큰 브랜드 기업들의 마케팅, 광고, 조사, 관리, 상거래를 지원합니다. Facebook, Twitter, LinkedIn 및 전 세계 22개 기타 소셜 채널과 통합된 당사 플랫폼은 수천 개의 서버를 사용하고, 페타바이트 단위의 데이터를 조사하고, 매일 수십억 건의 트랜잭션을 처리합니다. Twitter 하나만 해도 하루에 몇 억 개의 트윗을 처리해야 합니다.

매일 처리하는 엄청난 데이터 양을 고려할 때 재해 복구(Disaster Recovery, DR)는 더없이 중요한 문제입니다. 자연재해나 인재가 발생하더라도 비즈니스 연속성이 보장되어야 합니다.

대부분의 기업은 DR 대신에 고가용성(HA)을 구현하여 서비스 가동 중지 상황에 대비합니다. HA 보장을 위한 서비스 폴백 메커니즘을 갖추고 있습니다. HA 모드로 실행되는 서비스는 여러 가용 영역에서 실행되지만 동일한 지리적 리전에 속하는 호스트가 처리합니다. 그러나 이러한 접근 방식은 리전 전체가 다운된 경우에 비즈니스의 정상적인 운영을 보장하지 않습니다. DR은 250마일 이상 떨어진 다른 리전에서 복구할 수 있다는 점에서 완전히 새로운 차원을 보여 줍니다. DR 구현은 액티브/패시브 모델로, 이는 여러 리전에서 중요성이 가장 덜한 서비스를 항상 실행하지만 필요할 때 인프라의 주요 부분이 시작 및 복원됨을 뜻합니다.

당면 과제

재해 발생 시 비즈니스 운영이 중단되는 위험을 감수하고 싶지 않습니다. 고객에 대한 약속의 일환으로 튼튼한 재해 복구 프로세스를 갖춰야 합니다. 이는 어느 비즈니스에나 매우 중요합니다. 예를 들어 허리케인 샌디가 기승을 부릴 때 미국 북동부 지역에 데이터 센터가 있는 일부 회사만이 홍수로 인해 오프라인 상태가 되었습니다. 당사 DR의 경우 복구 목표 시점(RPO)이 24시간입니다. 이는 복구할 데이터가 생성된 지 24시간이 지나지 않았음을 뜻합니다. 복구 목표 시간(RTO)은 DR이 선언된 시점으로부터 복원이 완료되기까지 걸리는 시간을 뜻하며, 당사의 경우 고객 SLA에 따라 6시간~24시간입니다. 테스트를 하면서 RTO를 4시간으로 정했습니다.

재해 복구(DR)를 위한 단계

규모 파악

Sprinklr의 리전 간 재해 복구 동기화

목표를 이해하려면 서비스 유형과 그 개수를 포함하여 현재의 작업 규모를 고려해야 합니다. MongoDB, Elasticsearch, SOLR, Mesos, RDS 등 광범위한 데이터/비데이터 서비스 목록이 있습니다. 따라서 서버가 수천 개에 이르는데, ELB는 거의 100개, route53 항목 약 4,000개, 1페타바이트 이상의 기본 데이터, 그리고 RDS 인스턴스 50개 이상이 있습니다. 이러한 서비스는 모두 복원 시점에 DR 리전에서 시작되어야 합니다.

목적 달성을 위해 사용자 지정 스크립트를 작성했는데, 이 스크립트는 주로 AWS API 호출을 통해 인스턴스를 시작하고, 스냅샷을 연결하고, elb 및 경로 항목을 생성합니다.

위 그림과 같이, 관련된 모든 백업은 복원을 위해 DR 리전으로 복사됩니다.

복사할 백업 유형은 크게 세 가지입니다.

  1. EBS 스냅샷: 사용자 지정 로직을 구축하여 사용 가능한 모든 백업과 그 진행 상황 및 완료 여부를 지능적으로 추적합니다.  AWS 한도를 넘지 않고 전체 스냅샷 사본을 얻고자 노력합니다.
  2. S3 스냅샷: cross s3 동기화를 사용하며, 이는 매우 효과적으로 작동합니다. 단 몇 분만에 기본 리전에서 DR 리전으로 데이터를 복사할 수 있습니다.
  3. RDS 스냅샷: AWS RDS CopyDBSnapshot API를 사용하여 RDS 스냅샷을 복사합니다.

DR을 위한 파일럿 라이트 설정

재해 복구 미리 설정빠른 시작을 위해, 재해 복구를 위한 게이트웨이를 얻으려면 몇 가지 서비스가 실행 중이어야 합니다. VPC, 서브넷, Route53 항목을 설정하는 것도 여기에 포함됩니다. 이를 위해 사용자 지정 도구를 구축했습니다. 비슷한 CIDR 구성과 서브넷 마스킹으로 VPC를 만들고, 경로 항목의 경우 새 서브넷이 생성될 때마다 DR 리전에도 자동으로 생성되도록 합니다. 이를 위해 AWS API 호출을 통해 기본 리전의 서브넷 정보를 파악하고, 서부 리전에 해당하는 서브넷을 만들었습니다.

없을 경우 복원을 시작하기 위한 항목을 얻을 수 없는 필수 서비스를 파악합니다. 이는 인증 서버(ldap/IPA, 있는 경우), 빌드 서버 또는 모니터링 서버일 수 있습니다. 이러한 서비스는 항상 실행 중이어야 합니다. 즉 시작 및 설정한 후 어떠한 예기치 못한 상황에서도 항상 DR 리전으로 항목을 가져올 수 있도록 이러한 서비스를 계속 실행함을 뜻합니다.

또한 종속된 AWS 서비스를 사용할 수 있어야 합니다. 예를 들어 S3 버킷을 DR 리전에서 사용할 수 있어야 하고 항상 기본 리전과 동기화해야 합니다. 많은 구성, 속성 파일, 바이너리가 S3에 있기 때문에 이 단계는 중요합니다. 애플리케이션이 계속 작동되도록 하려면 DR 리전에서 이를 사용할 수 있도록 해야 합니다. 이를 위해 S3 교차 리전 복제 기능을 사용합니다. 이는 객체를 빠르고 거의 동시에 동기화하여 놀라운 작업을 수행합니다.

재해 복구 용량 계획의 그림

용량 계획

이제 규모를 고려하여 DR의 필요 용량을 알아내야 합니다.

애플리케이션 관점에서 첫 단계는 DR 리전에서 필요한 구성을 사용할 수 있는지 확인하는 것입니다. 이때 필요한 구성이란 DB별로 다른 파라미터일 수도 있고 사용자 지정된 설정 관련 파라미터일 수도 있지만, 기본적으로 애플리케이션이 작동하는 데 필요한 모든 것을 말합니다. 위 그림과 같이, 복원하는 각 파트너가 당사 DB에 저장한 속성을 토대로 다양한 서비스의 필요 용량을 파악합니다. 예를 들어 파트너 Z는 ES 클러스터 70개, MongoDB 40개, RDS 30개, SOLR 20개가 필요합니다. 다음 단계에서는 모든 서비스를 종합적으로 고려하여 특이한 것을 찾아냅니다. 파트너 간에 클러스터 DB를 공유하므로, 최초의 필요 용량에 있던 클러스터 중 일부를 실제로 다른 파트너들도 공유할 수 있기 때문입니다. 이렇게 해서 최종적인 필요 용량을 파악하고, 이를 인스턴스 유형별로 나눕니다. 위 그림과 같이 Elasticsearch 등 서비스마다 인스턴스 유형이 서로 다릅니다. 마지막으로 해당 인스턴스 유형의 총 필요 용량을 파악하는 일이 남았습니다.

첫 번째 단계가 명확해지면 ELB 및 경로 항목을 몇 개나 생성해야 하는지 알아냅니다. AWS API로 얻은 ELB 및 경로 항목 정보에 대한 메타데이터를 보유하고 있습니다. 이 정보는 서부에 항상 준비되어 있습니다. 이 방법으로 필요 용량의 정확한 수를 알아내고, 인프라를 추정합니다. 여기에는 EC2, ELB 및 경로 항목을 위한 용량 계획도 포함됩니다.

원활한 복구를 위해서는 위 단계 모두 중요하고 서로 밀접하게 관련되어 있으며, 가급적 이를 자동화하는 것이 좋습니다. 우리는 AWS API 호출을 사용한 Perl로 사용자 지정 스크립트를 작성하여 이 모든 단계를 자동화했습니다.

재해 발생 시

우선 순위 정하기

존재하는 여러 서비스 중에 가장 중요한 서비스를 기준으로 시작의 우선 순위를 정하고 서비스의 EC2 인스턴스를 시작해야 합니다. 서비스를 세 가지 세트로 나누는 것이 좋습니다. 이는 핵심적인 서비스를 쉽게 시작할 수 있도록 하기 위한 중요한 결정입니다. 우리가 피하고자 하는 주요 방해 요소는 AWS의 용량 또는 한도 문제입니다.  서비스를 나누면 API 호출 수가 적어지며, AWS가 그 시점에 보유하고 있는 티어 1 서비스에 사용 가능한 인스턴스 유형을 모두 활용할 수 있습니다. 두 번째 세트와 세 번째 세트는 다음에 시도합니다. 이러한 접근 방법의 장점은 우선 AWS API 호출을 너무 많이 사용하지 않고, 복원이 충돌하지 않는다는 것입니다. 이를 위해 다시 사용해야 할 것 같은 AWS API 호출 출력을 캐시하는 캐싱 로직을 개발했습니다. 이를 통해 API 호출 수를 50% 줄일 수 있습니다. 두 번째는 사용 가능한 용량이 대부분 가장 핵심적인 서비스에 할당된다는 점입니다.

용량에 대비한 플랜 B

당장 재해가 발생하면 원하는 인스턴스를 마음대로 시작하지 못할 수 있으므로 실행 시간 인텔리전스를 구축할 필요가 있습니다.

우선 순위가 두 번째나 세 번째인 서비스를 할 때쯤이면 사용 가능한 용량을 다 써버렸을 수도 있습니다. 따라서, 용량 한도를 이미 늘렸습니다. 그러나 어떤 인스턴스 유형은 DR 시점에 AWS에서 사용하지 못할 수 있고, 이로 인해 전체 DR 작업이 위험에 빠질 가능성이 있습니다.

이러한 위험을 완화하기 위해 플랜 B를 수립했습니다. 플랜 B가 준비되고 자동화를 통해 인텔리전스를 구축하여 동일한 패밀리의 다른 인스턴스 유형을 시작합니다. 이 인텔리전스를 구축하기 위해 AWS CloudWatch를 사용합니다. AWS CloudWatch 측정치의 정보를 사용하여 기본 리전의 인스턴스 사용량을 분석합니다. 이를 통해 현재 인스턴스 패밀리 및 유형을 사용할 수 없는 경우에 사용할 수 있는 인스턴스 패밀리 및 유형을 알아낼 수 있습니다. 다시 말해 r3.xlarge 인스턴스 유형을 사용하는 특정 서비스를 예로 들면, CloudWatch 측정치 덕분에 이 서비스가 사용하고 시작해 볼 수 있는 다음 인스턴스 유형을 정하기 위한 모든 정보를 확인할 수 있습니다.

새 인스턴스 유형을 결정하고 나면 인스턴스 개수를 계산해야 합니다. 예를 들어 r3.2xlarge에서 r3.xlarge로 한 단계 아래로 가면 용량을 두 배로 늘려야 할 수 있으며, 한 단계 위로 가면 용량을 절반으로 줄여야 할 수 있습니다. 따라서 실행 시 이를 계산해야 합니다.

다른 AWS 서비스 복원 및 시작

ELB, Route 등 EC2 이외의 서비스 시작이 이제 트리거됩니다. 기본 리전의 S3에서 동기화된 메타데이터를 사용하여 이러한 서비스를 불러옵니다. 메타데이터 정보에는 이 서비스를 시작하는 데 필요한 정보가 들어 있습니다. ELB의 경우 ELB 유형(내부 또는 외부), 인증서 정보, 연결된 서브넷, 연결된 인스턴스입니다. 경로 항목의 경우 DNS 레코드 유형과 그 값입니다.

구성을 위해 EC2 인스턴스 정보가 필요할 수 있으므로 EC2를 시작한 후 이를 시작합니다. 예를 들어 경로 항목에는 EC2 인스턴스의 퍼블릭 IP 주소 정보가 필요할 수 있습니다.

애플리케이션 복원

위 단계를 실행했으면 절반은 온 것입니다. AWS에서 리소스를 가져왔고 애플리케이션 요구 사항에 따라 이를 구성할 수 있었기 때문입니다. AWS에서 얻고자 하는 필요 용량이 대부분 처리되었습니다. 나머지는 주로 애플리케이션 및 로직과 관련이 있습니다. 코드베이스를 사용할 수 있게 준비해 두는 것과 필요 시 DR 리전에 바로 빌드를 배포할 수 있도록 하는 것도 여기에 포함됩니다.

직면한 문제 및 수정

위 모델을 구현한 후 API 호출과 관련된 몇 가지 문제에 직면했습니다. 복원 규모로 인해 엄청난 수의 API 호출이 발생했고, AWS에서는 이를 조정했습니다. API에서 보내는 막대한 정보를 캐시하기 위해 인텔리전트 캐싱 시스템을 개발했습니다. 그 결과 AWS API 호출이 처음의 4분의 1로 줄었습니다.

이 블로그 게시물에서 DR 프로세스의 계획 방식에 대한 아이디어를 얻으시기 바랍니다. DR 계획을 수립하고 주기적으로 테스트하는 것은 자연재해나 인재 발생 시 비즈니스 운영이 중단되지 않도록 하는 데 매우 중요합니다. 자세히 알아보려면 Sprinklr 웹 사이트를 방문하십시오.

이 글은 소셜 미디어 통합 관리 서비스인 Sprinklr의 책임 설계자인Senthilkumar Ramaswamy와 DevOps 책임 엔지니어 Rakesh Pillai가 작성한 AWS Startup 블로그의 Large scale disaster recovery using AWS regions의 한국어 번역입니다.

AWS 최신 기능 모음 – Amazon RDS 사용자 인증, SES 데이터 추적 및 AWS 솔루션 업데이트 등

AWS의 새로 출시된 몇 가지 서비스와 기능을 따라잡기 위해, 이 게시물에서는 지난 여름부터 9월 말까지 출시된 몇 가지 멋진 서비스를 요약 정리하고자 합니다. 더 자세한 업데이트 내역은 AWS 신규 기능 업데이트 페이지를 참고하세요.

오늘 여러분께 소개할 새로운 서비스와 기능은 다음과 같습니다.

  • RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM
  • Amazon SES 평판 대시보드
  • Amazon SES 확인 및 클릭 추적 지표
  • Solutions Builder 팀의 서버리스 이미지 핸들러
  • Solutions Builder 팀의 AWS Ops Automator

그럼 자세히 살펴보겠습니다.

RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM

Amazon RDS 데이터베이스 인스턴스 및 클러스터에 대한 액세스를 AWS IAM으로 관리하고 싶지 않으셨습니까? 이제 그 소원이 이루어졌습니다. Amazon RDS에서 MySQL용 Amazon RDS 및 Amazon Aurora DB에 대한 데이터베이스 액세스를 IAM으로 관리하는 기능을 출시했습니다.

이 새로운 서비스 기능에서 가장 마음에 드는 부분은 시작하기가 정말 쉽다는 점입니다. IAM을 이용한 데이터베이스 사용자 인증을 활성화하려면 DB 인스턴스 또는 클러스터를 생성, 수정 또는 복원할 때 [Enable IAM DB Authentication] 확인란을 선택하면 됩니다. RDS 콘솔, AWS CLI 및/또는 Amazon RDS API를 사용해서 IAM에 액세스하도록 할 수 있습니다.

IAM 인증을 사용하도록 데이터베이스를 구성하면, 클라이언트 애플리케이션은 데이터베이스 엔진에 대해 자신을 인증할 때 IAM 보안 토큰 서비스에서 생성된 임시 보안 자격 증명을 제출합니다. 데이터베이스 엔진에 암호를 제시하는 대신 이러한 자격 증명을 사용하는 것입니다.

IAM으로 MySQL 및 Aurora에 대한 목표 권한 및 인증을 제공하는 자세한 방법은 Amazon RDS 사용 설명서에서 알아볼 수 있습니다.

Amazon SES 평판 대시보드

Amazon Simple Email Service 고객이 이메일 전송을 위한 모범 사례 지침을 활용할 수 있도록 이메일 전송 상태를 포괄적으로 보고해 주는 평판 대시보드가 출시되었다는 소식을 기쁜 마음으로 알려 드립니다. 이제 고객들은 전반적인 계정 상태, 전송 지표, 규정 준수 또는 시행 상태를 파악하여 전송 중인 이메일을 선제적으로 관리할 수 있습니다.

평판 대시보드는 다음과 같은 정보를 제공합니다.

  • 계정 상태: 계정 상태에 대한 설명입니다.
    • 정상 – 현재 계정에 영향을 주는 문제가 없습니다.
    • 관찰 – 계정이 관찰 상태입니다. 일시 중지 사태를 방지하기 위해 관찰을 유발한 문제를 해결해야 합니다.
    • 관찰 종료 결정 보류 중 – 계정이 관찰 상태입니다. Amazon SES 팀원이 해당 계정을 검토한 뒤 조치를 취해야 합니다.
    • 종료 – 계정이 종료되었습니다. Amazon SES를 사용해 이메일을 보낼 수 없습니다.
    • 종료 보류 중 – 계정이 관찰 상태이고 관찰 상태를 유발한 문제가 해결되지 않았습니다.
  • 반송 메일 발생률: 반송된 이메일의 비율과 반송률 상태에 대한 메시지입니다.
  • 불만 제기 비율: 수신자가 스팸으로 보고한 이메일의 비율과 불만 제기율에 대한 상태 메시지입니다.
  • 알림: 기타 계정 평판 문제에 대한 메시지입니다.

Amazon SES 확인 및 클릭 추적 지표

최근 Amazon SES에 추가된 또 한 가지 흥미로운 기능은 이메일 확인 및 클릭 추적 지표입니다. SES 고객은 이제 이메일 확인 및 클릭 추적 지표 기능으로 보낸 이메일의 확인 시점과 이메일 내 링크의 클릭 시점을 추적할 수 있습니다. 이 SES 기능을 사용하면 이메일 캠페인에 대한 참여도와 효과를 더욱 정확하게 추적할 수 있습니다.

이 기능은 어떻게 작동할까요?

이메일 확인 추적 기능을 사용하는 경우, SES에서는 사용자가 추적하도록 선택한 이메일에 투명한 작은 이미지를 추가합니다. 받는 사람이 이메일을 열어 보면 메일 애플리케이션 클라이언트가 앞서 언급한 추적 이미지를 로드하고, 이에 따라 Amazon SES에서 확인 추적 이벤트가 트리거됩니다. 이메일 클릭(링크) 추적의 경우 이메일 및/또는 이메일 템플릿에 들어 있는 링크가 사용자 지정 링크로 바뀝니다. 받는 사람이 이 사용자 지정 링크를 클릭하면 SES에 클릭 이벤트가 기록되고, 이메일 사용자는 사용자 지정 링크를 통해 원본 이메일의 링크 대상으로 리디렉션됩니다.

새로운 확인 추적 및 클릭 추적 기능을 사용하려면 SES에서 새로운 구성 집합을 생성하거나 기존 구성 집합을 변경하면 됩니다. 두 방법 중 하나를 선택한 다음, 확인 및 클릭 지표를 수신하기 위한 AWS 서비스로 Amazon SNS, Amazon CloudWatch 또는 Amazon Kinesis Firehose를 선택하십시오. 이제 전송할 모든 이메일에 대해 이러한 새 기능을 적용하는 새로운 구성 집합만 선택하면 됩니다.

AWS 솔루션: 서버리스 이미지 핸들러 및 AWS Ops Automator

AWS Solution Builder 팀은 AWS에서 애플리케이션 빌드 및 실행을 위해 일반적인 아키텍처 질문에 대한 답변을 쉽게 찾을 수 있도록 많은 노력을 기울이고 있습니다. 이러한 솔루션은 AWS Answers 페이지에서 찾을 수 있습니다. 올 가을 초 AWS Answers에 발표된 두 가지 새로운 솔루션은 서버리스 이미지 핸들러AWS Ops Automator입니다.
서버리스 이미지 핸들러AWS 클라우드의 이미지 취급 과정을 실시간으로 처리, 조작 및 최적화하는 고객을 위한 지원 솔루션으로 개발되었습니다. 이것은 캐싱을 위해 Amazon CloudFront를, 실시간 이미지 검색과 수정을 위해 AWS Lambda를, 이미지 저장을 위해 Amazon S3 버킷을 결합한 솔루션입니다. 또한 서버리스 이미지 핸들러는 이미지를 더 세밀하게 조작, 처리 및 최적화할 수 있도록 오픈 소스 이미지 처리 제품군인 Thumbor를 사용합니다.

AWS Ops Automator 솔루션의 자동 작업 프레임워크에서 시간 기반 트리거나 이벤트 기반 트리거를 사용하여 스냅샷 예약 등의 수작업을 자동화할 수 있습니다. 여기에는 작업 감사 추적, 로깅, 리소스 선택, 조정, 동시 처리, 작업 완료 전달 및 API 요청 재시도 등이 포함됩니다.

이 솔루션에는 다음 AWS 서비스가 포함됩니다.

  • AWS CloudFormation: 마이크로서비스 및 솔루션에서 생성한 작업 구성의 핵심 프레임워크를 시작하기 위한 템플릿
  • Amazon DynamoDB: 이벤트 트리거 및 리소스를 정의하기 위한 작업 구성 데이터와 작업 및 오류의 결과를 저장하는 테이블
  • Amazon CloudWatch Logs: 경고 및 오류 메시지 추적을 위한 로깅 기능 제공
  • Amazon SNS: 솔루션에서 로깅 정보를 보내는 구독자 이메일 주소로 관련 주제의 메시지 전송

즐겁게 탐구하고 코딩하시기 바랍니다.

Tara

이 글은 Just in Case You Missed It: Catching Up on Some Recent AWS Launches의 한국어 번역입니다.

MS SQL서버에서 AWS기반 MySQL 호환 DB 엔진으로 이전하기

이 게시물은 Microsoft SQL Server 데이터베이스를 Amazon RDS for MySQL, Amazon RDS for MariaDB 또는 Amazon Aurora MySQL 등 MySQL 호환 데이터베이스 엔진으로 마이그레이션할 수 있는 방법에 대한 개요를 제공합니다.

다음은 데이터베이스 마이그레이션의 두 가지 주요 부분입니다.

  1. 스키마 변환: 스키마 객체 변환은 일반적으로 다른 유형의 데이터베이스 마이그레이션에서 시간이 많이 소요되는 작업입니다. 이러한 변환은 데이터베이스의 토대이며, 잘 계획된 방식으로 처리해야 합니다. 스키마 변환이 적절하게 수행된 경우 다른 유형의 마이그레이션에 대한 중요한 마일스톤이 완료됩니다.
  2. 데이터 마이그레이션: 기본 데이터 요소는 앞에서 언급한 스키마 토대에 대한 빌딩 블록과 같습니다. 토대가 적절하게 배치될 경우 모범 사례를 따를 때 마이그레이션 중 이러한 블록의 배열이 비교적 간단합니다.

이 게시물에서는 SQL Server 데이터베이스를 Aurora MySQL, MySQL, MariaDB 등 자주 사용되는 MySQL 기반 데이터베이스 엔진으로 변환하기 위해 AWS SCT(AWS Schema Conversion Tool)AWS DMS(AWS Database Migration Service)를 사용하는 방법을 살펴봅니다. 이 게시물에서 이러한 모든 데이터베이스 엔진을 MySQL이라고 합니다.

SQL Server 데이터베이스를 MySQL 호환 데이터베이스로 마이그레이션에서는 SQL Server와 MySQL 간의 데이터베이스 객체 시맨틱이 유사합니다. 하지만 SQL Server에서 MySQL로 마이그레이션할 때 고려해야 할 중요한 아키텍처 차이점이 있습니다. 예를 들어, MySQL에서는 “데이터베이스” 및 “스키마”가 모두 동일한 의미를 공유합니다. 데이터베이스와 스키마 간에 기능적 차이점이 없습니다. 다음 예는 이러한 점을 보여 줍니다.

SQL
mysql> create schema test01;
Query OK, 1 row affected (0.01 sec)

mysql> create database test01;
ERROR 1007 (HY000): Can't create database 'test01'; database exists

예제에 표시된 대로 “데이터베이스” 및 “스키마”는 동일하며 별도의 의미가 없습니다. 데이터베이스 내의 테이블을 가리킬 경우 MySQL의 전체 테이블 식별자는 databasename.tablename과 같습니다.

반면에 SQL Server는 “데이터베이스” 및 “스키마” 키워드에 다른 의미와 기능을 부여합니다. SQL Server에서 데이터베이스는 모든 객체, 데이터 및 로그 파일을 저장하는 기본 컨테이너입니다. 스키마는 다른 데이터베이스 객체를 논리적으로 그룹화하는 특정 데이터베이스 내에 있는 객체입니다. SQL Server는 기본적으로 스키마 이름 dbo를 사용합니다. 그러나 조직, 기능 또는 비즈니스 요구 사항을 충족하기 위해 이러한 사항을 변경할 수 있습니다. SQL Server의 전체 테이블 식별자는 Databasename.Schemaname.tablename입니다.

 

마이그레이션 시나리오
SQL Server 데이터베이스 및 스키마를 MySQL 호환 데이터베이스로 마이그레이션할 경우 4개의 다른 시나리오가 있을 수 있습니다. 애플리케이션 및 데이터베이스 요구 사항에 따라 이러한 시나리오 중 하나(또는 조합)를 따를 수 있습니다.

시나리오 1: 기본 dbo 스키마 이름
SQL Server의 기본 스키마가 dbo인 경우, MySQL 데이터베이스로 마이그레이션하는 동안 dbo 스키마를 사용하지 않도록 선택하면 됩니다. SQL Server 데이터베이스 이름이 MySQL 데이터베이스 이름으로 변환됩니다. 예:

SQL Server: Db1.dbo.table1

MySQL: Db1.table1

(MySQL에서 데이터베이스 변환 중 dbo가 쉽게 삭제 가능)

전체 테이블 식별자 계층 구조 변경 사항을 반영하기 위해 애플리케이션 코드도 이에 따라 변경해야 합니다.

시나리오 2: 사용자 지정 스키마 이름
사용자 지정 스키마 이름이 있는 경우 데이터베이스 이름만 또는 스키마 이름만 MySQL 데이터베이스 이름으로 변환해야 하는지 여부를 결정해야 합니다. 예:

Db1.schema1.table1
db2.schema2.table2

데이터베이스 또는 스키마를 MySQL 데이터베이스로 변환할 때 애플리케이션 코드에 따라 스키마 또는 데이터베이스 이름이 계속 생략될 수 있습니다. 이 경우에는 다음과 같은 이름이 됩니다.

Db1.table1
Db1.table2

또는

Schema1.table1
Schema2.table1

시나리오 3: 다른 스키마에서 동일한 테이블 이름
이 시나리오에서는 동일한 테이블 이름이 동일한 데이터베이스의 다른 스키마에 있습니다.

Db1.schema1.table1
Db1.schema2.table1

이 경우, 데이터베이스 이름을 생략하고 MySQL 측에서 스키마 이름을 데이터베이스 이름으로 대신 사용합니다. 이렇게 하면 동일한 데이터베이스에서 동일한 테이블 이름의 혼동이 방지됩니다.

MySQL:

Db1.table1
Db2.table1

시나리오 4: 데이터베이스와 스키마 이름 조인
이 시나리오에서는 SQL Server의 데이터베이스 이름과 스키마 이름이 모두 조인되어 MySQL 측에서 데이터베이스를 생성할 수 있습니다. AWS SCT는 이 경로를 따릅니다. 예:

SQL Server: db1.schema1.table1

MySQL: db1_schema1.table1

여기에서, 데이터베이스 및 스키마 이름이 모두 밑줄로 조인되어 대상에 MySQL 데이터베이스를 생성합니다.

전체 마이그레이션 전략
한 엔진에서 다른 엔진으로 데이터베이스를 마이그레이션할 경우(여기에서는 SQL Server에서 MySQL 호환 엔진으로 마이그레이션), 다음 단계가 권장됩니다.

  1. 대상 데이터베이스에서 스키마를 생성합니다.
  2. 대상 데이터베이스에 보조 인덱스를 삭제하고 트리거를 비활성화합니다. AWS DMS는 전체 로드 단계 중 테이블별 로드를 수행하며, 이렇게 하려면 외래 키를 비활성화하는 것이 중요합니다. 이렇게 하려면 이 게시물의 후반부에 언급된 대상 엔드포인트 추가 연결 속성을 사용합니다.
  3. AWS DMS 작업을 설정하여 데이터를 복제(전체 로드 및 CDC(데이터 캡처 변경))합니다.
  4. 캐시된 변경 사항을 적용하기 전에 중지할 작업을 구성하고 대상 데이터베이스에 보조 인덱스를 추가합니다.
  5. CDC에 대한 AWS DMS 작업을 다시 시작합니다.
  6. 전환 후 트리거를 활성화합니다.

대상 MySQL 데이터베이스에 스키마 생성
스키마 객체를 분석하여 마이그레이션을 시작할 수 있습니다. 여기에서는 AWS SCT(AWS Schema Conversion Tool)를 사용하여 분석을 수행합니다. AWS SCT를 시작할 때 원본이 SQL Server이고 대상이 MySQL/Aurora인 새 프로젝트를 생성합니다. 연결되면 왼쪽에서 마이그레이션할 데이터베이스의 이름을 선택합니다. 데이터베이스 이름에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 [Convert Schema]를 선택합니다. 그런 다음 [View], [Assessment Report View]를 선택합니다.

AWS SCT 평가 보고서는 스키마 변환에 대한 높은 수준의 개요와 권장 사항을 제공합니다. 초기 평가 보고서에 따라 SQL Server 데이터베이스를 MySQL/Aurora로 변환하는 데에는 더 많은 노력이 필요할 수 있습니다. 다음은 평가 보고서에 대한 예시입니다.

보고서는 각 객체 유형별로 구분되며, 성공적으로 변환하기 위해 수동 작업 노력이 필요합니다. 일반적으로 패키지, 절차 및 기능에는 해결해야 할 몇 가지 문제가 있습니다. AWS SCT는 이러한 객체를 수정해야 하는 이유도 알려주며, 이를 수행하는 방법에 대한 힌트도 제공합니다.

스키마가 자동으로 변환되지 않는 경우, 여기 문제를 해결할 유용한 몇 가지 힌트가 있습니다.

  1. 스키마를 있는 그대로 변환하고 대상 MySQL 데이터베이스에 적용하기 전에 AWS SCT에서 생성된 스크립트를 수동으로 수정합니다.
  2. 변환할 수 없는 객체를 무시하고, 기능을 다른 AWS 제품 또는 애플리케이션 자체와 대체합니다. 예를 들어, Aurora MySQL에서 AWS Lambda 함수를 호출하여 알림 전송 등의 특정 기능을 수행할 수 있습니다.

대상 데이터베이스의 스키마를 검색하고 열 데이터 유형, 객체 이름 등의 모든 스키마 객체를 빠르게 확인하는 것이 좋습니다. 데이터 유형에 대한 자세한 내용은 원본대상 데이터 유형에 대한 AWS Database Migration Service 설명서를 참조하십시오. 또한 SQL Server에서 MySQL로 변환되기 때문에, SQL Server는 기본 데이터 정렬에서 대문자를 지원하는 반면, MySQL은 기본적으로 소문자를 지원하므로 SQL Server에서 객체 이름은 대문자입니다.

이전 변환 실행에서 AWS SCT는 시나리오 4에 언급된 데이터베이스/스키마 이름 지정 규칙을 따릅니다. 원본 SQL Server 데이터베이스 및 스키마 이름에서 대상 MySQL 데이터베이스의 결합된 데이터베이스 및 스키마 이름으로 변환합니다. 이 dms_sample 데이터베이스 및 dbo 스키마는 대상의 dms_sample_dbo 데이터베이스로 변환됩니다.

데이터를 마이그레이션하도록 AWS DMS 작업 설정
이제 대상에 스키마가 준비되었으므로 AWS DMS를 사용하여 데이터를 마이그레이션할 준비가 되었습니다. 전체 로드 및 CDC에 AWS DMS를 사용하려면 다음 준비 작업을 완료했는지 확인하십시오.

  • SQL ServerMySQL에 대한 로그인에 문서화된 필수 권한이 있습니다.
  • CDC(변경 데이터 캡처)를 위해 SQL Server 복구 모델이 [Bulk logged] 또는 [Full]로 설정됩니다.
  • 추가적인 준비 정보는 AWS DMS의 SQL Server를 원본으로 사용에 대한 AWS DMS 설명서를 참조하십시오.

복제 인스턴스 생성
AWS 콘솔에서 AWS Database Migration Service를 엽니다. 먼저 복제 인스턴스를 생성해야 합니다. 복제 인스턴스는 AWS DMS 작업을 실행합니다. 이 인스턴스는 원본 SQL Server 데이터베이스와 대상 MySQL/Aurora 데이터베이스에 모두 연결되는 중간 서버입니다. 적절하게 프로비저닝된 복제 인스턴스를 선택하십시오(백서 AWS Database Migration Service 모범 사례에 언급된 모범 사례를 따름).

다음으로 원본 데이터베이스에 대한 엔드포인트와 대상 데이터베이스에 대한 다른 엔드포인트를 생성합니다. SQL Server 데이터베이스 및 MySQL 데이터베이스에 대한 모든 적절한 연결 정보를 입력합니다. MySQL 대상 엔드포인트에 다음 추가 연결 속성을 추가하여 외래 키 점검을 비활성화합니다.

SQL
initstmt=SET FOREIGN_KEY_CHECKS=0

연결 테스트를 성공한 후 [Refresh schemas] 옵션을 선택하고, 각 엔드포인트 생성을 완료하기 전에 [Run test]를 선택해야 합니다.

SQL Server 엔드포인트를 생성하는 동안 데이터베이스 이름을 제공해야 합니다. 한 번에 데이터베이스 하나를 제공할 수 있으므로 엔드포인트는 데이터베이스 하나에만 연결할 수 있습니다. 즉, 작업마다 데이터베이스 하나를 마이그레이션할 수 있습니다. 여러 데이터베이스를 마이그레이션하려면 여러 AWS DMS 작업을 생성하고 모든 모범 사례를 따라 리소스 제약 문제가 발생하지 않도록 해야 합니다. 모든 AWS DMS 작업 생성은 AWS CLI를 통해 또는 AWS CloudFormation 템플릿을 사용하여 스크립팅 및 자동화할 수도 있습니다.

작업 구성
이제 작업을 생성할 준비가 되었습니다. 작업 이름을 입력하고, 생성한 복제 인스턴스를 선택하고, 원본 및 대상 엔드포인트를 선택합니다. [Migration type]에서는 [Migrate existing data and replicate ongoing changes]를 사용합니다. AWS SCT를 사용하여 스키마를 미리 생성하므로 [Target table preparation mode]에 대해 [Do nothing] 또는 [Truncate]를 선택합니다.

[Stop task after full load completes] 옵션에 대해 [Stop After Applying Cached Changes]를 선택합니다. 이렇게 하면 전체 로드가 완료되고 캐시된 변경 사항이 적용된 후 작업이 일시 중지됩니다. 캐시된 변경 사항은 전체 테이블 로드 프로세스가 실행되는 동안 발생하고 누적된 변경 사항입니다. 이는 CDC가 적용되기 바로 전의 단계입니다.

마지막으로, 작업에서 발생하는 오류나 경고를 확인하고 이러한 문제를 해결할 수 있도록 [Enable logging]을 선택하는 것이 좋습니다.

그런 다음 [Table mappings] 아래에서 마이그레이션할 스키마를 선택하고 [Add selection rule]을 선택합니다. [JSON] 탭을 선택합니다. [Enable JSON editing]을 선택하고 필수 JSON 문자열을 입력하여 테이블을 마이그레이션합니다. 다음은 그 예입니다.

Json
JSON String: 
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "person"
            },
            "rule-action": "include"
        },
        {a
            "rule-type": "selection",
            "rule-id": "2",
            "rule-name": "2",
                "object-locator": {
                "schema-name": "dbo",
                "table-name": "seat"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "selection",
            "rule-id": "3",
            "rule-name": "3",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "player"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "selection",
            "rule-id": "4",
            "rule-name": "4",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "seat_type"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "transformation",
            "rule-id": "5",
            "rule-name": "5",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "dbo"
            },
            "rule-action": "rename",
            "value": "mysqldb"
        },
        {
            "rule-type": "transformation",
            "rule-id": "6",
            "rule-name": "6",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "%"
            },
            "rule-action": "convert-lowercase"
        },
        {
            "rule-type": "transformation",
            "rule-id": "7",
            "rule-name": "7",
            "rule-target": "table",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
                "rule-action": "convert-lowercase"
        },
        {
            "rule-type": "transformation",
            "rule-id": "8",
            "rule-name": "8",
            "rule-target": "column",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%",
                "column-name": "%"
            },
            "rule-action": "convert-lowercase"
        }
    ]
}

이전 JSON 문자열에서 테이블 이름에 대해 “%“를 선택하여 스키마 내에 있는 모든 테이블을 복사하도록 선택할 수 있습니다. 여기에서는 네 가지 특정 예제 테이블( person, player, seatseat_type)을 선택합니다. 또한 다음을 수행하기 위해 개별 변환 규칙 4개를 생성했습니다.

  1. SQL Server 대문자 스키마 이름을 대상에서 소문자 스키마 이름으로 변환합니다.
  2. SQL Server 대문자 테이블 이름을 대상에서 소문자 테이블 이름으로 변환합니다.
  3. SQL Server 대문자 열 이름을 대상에서 소문자 열 이름으로 변환합니다.
  4. 대상에서 dbo 스키마를 생성/복사하는 대신 기존 mysqldb 데이터베이스에 생성/복사합니다.

AWS DMS는 SQL Server 데이터베이스를 MySQL로 마이그레이션하는 동안 적용될 수 있는 여러 추가 변환 규칙을 제공합니다. 자세한 내용은 AWS DMS 설명서의 변환 규칙 및 작업을 참조하십시오.

JSON 문자열을 복사한 후 [Guided] 탭을 선택합니다. 이 탭에서는 선택과 변환 규칙 모두에 대해 모든 스키마가 자동으로 채워짐을 확인할 수 있습니다.

생성 시 [Start task on create] 옵션을 선택한 경우 작업을 생성하면 해당 작업이 자동으로 시작됩니다. AWS DMS 콘솔을 통해 작업을 선택하고 [Table statistics] 탭을 선택하여 진행률을 모니터링할 수 있습니다. 전체 로드가 완료되고 캐시된 변경 사항이 적용되면 작업 자체가 중지됩니다.

전체 로드가 완료되고 캐시된 변경 사항이 적용된 후 계속 진행하여 외래 키 및 보조 인덱스를 다시 생성합니다.

통계는 복사된 테이블과 오류를 수신한 테이블에 대한 높은 수준의 정보를 제공합니다. 그러나 로고를 검토하여 변환 및 마이그레이션 중 객체와 관련된 오류나 데이터 잘림 및 데이터 자체에 대한 경고가 없는지 확인해야 합니다.

연속 복제를 위한 DMS 작업 활성화
이제 외래 키와 보조 인덱스가 있으므로 AWS DMS 작업을 활성화하여 다음 단계인 CDC를 시작할 수 있습니다. 이 단계에서는 원본 데이터베이스에서 발생한 순서대로 변경 사항을 적용합니다. AWS DMS 콘솔로 이동하여 [Tasks]를 선택합니다. 목록에서 작업을 선택하고 [Start/Resume]을 선택합니다. [Start] 옵션을 선택한 다음 [Start task]를 선택합니다.

전환할 때까지 복제를 실행합니다. 전환 중 애플리케이션이 원본 데이터베이스에 액세스하는 것을 중지했는지 AWS DMS가 마지막 데이터 변경 사항을 대상 데이터베이스에 복제했는지 확인합니다. AWS DMS 콘솔에서 AWS DMS 작업을 중지하고 대상 데이터베이스에서 트리거를 활성화합니다. 마지막으로, 새 대상에 애플리케이션을 가리킵니다.

유용한 힌트

  1. 스키마를 쉽게 변환하려면 AWS SCT를 사용하여 평가 보고서를 받고 작업 항목을 통해 반복합니다. 대상 MySQL 스키마의 최종 버전을 얻을 때까지 대상 스키마를 여러 번 생성해야 할 수 있습니다.
  2. 새 플랫폼에 애플리케이션 쿼리가 작동하도록 하려면 대상 시스템에서 애플리케이션을 테스트하십시오. AWS SCT는 애플리케이션 쿼리를 MySQL로 변환할 수도 있습니다. 자세한 내용은 AWS SCT 설명서를 확인하십시오. 애플리케이션을 테스트하는 것은 다른 유형의 마이그레이션 성공을 위한 핵심입니다.
  3. 이전 마이그레이션 단계를 테스트하고 온프레미스 환경 및 비즈니스 요구 사항에 따라 프로세스를 간소화합니다. 이러한 단계는 시작점일 뿐이며, 각 데이터베이스는 자체적으로 고유해야 합니다.

결론
이 게시물은 특정 상황에 필요할 수 있는 가능한 모든 단계 또는 고려 사항을 설명하지 않습니다. 그러나 AWS SCT 및 AWS DMS를 사용하여 SQL Server 데이터베이스에서 MySQL 호환 데이터베이스 엔진으로 이동하는 방법을 이해할 수 있습니다. AWS Database Migration Service 및 AWS Schema Conversion Tool에 대한 자세한 내용은 AWS DMS 사용 설명서AWS SCT 사용 설명서를 참조하십시오.


작성자 소개

Akm Raziul Islam은 Amazon Web Services에서 데이터베이스 및 분석에 집중하는 컨설턴트입니다. 고객과 협업하여 다양한 데이터베이스 및 분석 프로젝트에 대한 기술적 지원과 지침을 제공하며, AWS를 사용할 때 솔루션의 값을 향상하도록 지원합니다.

Arun Thiagarajan은 Amazon Web Services에서 DMS(Database Migration Service) 및 SCT(Schema Conversion Tool) 팀의 데이터베이스 엔지니어입니다. DB 마이그레이션 관련 문제점을 해결하고, 고객과 밀접하게 협업하여 DMS 제품의 진정한 잠재력을 이해하도록 지원합니다. DMS 및 SCT를 사용하여 AWS 클라우드로 100개의 데이터베이스를 마이그레이션하는 데 도움을 주었습니다.

이 글은 AWS Database Blog의 Migrating a SQL Server Database to a MySQL-Compatible Database Engine의 한국어 번역입니다.

MySQL에서 다운타임 거의 없이 DynamoDB로 마이그레이션하기

많은 고객들이 MySQL 과 같은 관계형 데이터베이스에서 Amazon DynamoDB으로 마이그레이션 하고자 합니다. 왜냐하면, 완전 관리형, 고성능, 높은 확장성과 유연성을 갖춘 NoSQL 데이터베이스 서비스이기 때문입니다.  DynamoDB의 경우, 트래픽 및 비즈니스 요구 사항에 따라 용량을 유연하게 증가 및 감소시킬 수 있기 때문에 서비스에 필요한 총 비용을 기존의 서버 기반의 RDBMS보다 더 쉽게 최적화 하는 것이 가능합니다.

하지만, 마이그레이션 작업은 통상적으로 다음과 같은 두 가지 이슈가 있을 수 있습니다:

  • 고객서비스가 반드시 24/7/365 가용 해야 할 경우 다운타임으로 인한 서비스 중단을 어떻게 최소화할 것인가?
  • RDBMS와 DynamoDB의 서로 다른 Key Design을 어떻게 반영할 것인가?

이 글에서는 다운타임을 최소화하면서 MySQL의 주요 DB 디자인을 NoSQL에 적합한 형태로 변환한 후,  MySQL의 기존 데이터를 DynamoDB로 원활하게 마이그레이션하는 두 가지 방법을 소개합니다.

마이그레이션을 위한 AWS 서비스 빌딩 블록
이 글에서 포함된 예제 코드들은 다음 AWS 서비스을 사용합니다:

  • AWS 데이터 마이그레이션 서비스(AWS DMS) 는 가장 범용적으로 사용되는 상용 및 오픈소스 데이터베이스 사이의 데이터 마이그레이션을 가능하게 해줍니다. AWS DMS는 서로 다른 데이터베이스 플랫폼 간의 동종 및 이종 데이터 마이그레이션을 지원합니다.
  • Amazon EMR은 방대한 양의 데이터를 신속하게 처리할 수 있도록 하는 관리형 Hadoop 프레임워크입니다. Hive 및 다른 비지니스 소프트웨어를 포함하는 이미 설정된 소프트웨어 스택들로 구성된 EMR 클러스터를 손쉽게 구축할 수 있습니다.
  • Amazon Kinesis는 실시간 트랜잭션, 로그 데이터, 클릭 스트림과 같은 방대한 양의 실시간 데이터를 최대 7일까지 지속적으로 저장하고 유지할 수 있습니다.
  • AWS Lambda는 서버를 준비하거나 운영하지 않고, 원하는 코드를 클라우드 상에서 직접 실행할 수 있도록 해 줍니다. AWS Lambda에서 실행되는 코드는 Amazon Kinesis Stream과 같은 다른 AWS 서비스들에 의해 자동으로 호출되도록 설정할 수 있습니다.

마이그레이션 방안

이 글에서는 다음 두가지 데이터 마이그레이션 옵션을 설명합니다.

  1.  AWS DMS 사용: AWS DMS는 DynamoDB 테이블을 타겟으로 마이그레이션을 지원합니다. 객체 매핑을 사용하여 마이그레이션 과정 중에 원본 데이터를 DynamoDB에서 요구하는 데이터 구조에 적합하게 재구성하는 것이 가능합니다.
  2. Amazon EMR, Kinesis 및 AWS Lambda 커스텀 스크립트 사용: 보다 복잡한 변환 과정 및 유연성이 요구될 때는 EMR, Kinesis, Lambda를 이용한 마이그레이션을 고려할 수 있습니다. MySQL 레코드를 더 적은 DynamoDB 항목으로 그룹화하고, 속성 이름을 동적으로 결정하고, 마이그레이션 중에 프로그래밍 방식으로 비즈니스 로직을 추가하고, 더 많은 데이터 유형을 지원하거나 하나의 큰 테이블에 대해 병렬 제어를 추가하려면 세분화된 사용자 제어가 필요합니다.

데이터 초기 적재 및 벌크 입력을 완료한 후에 가장 최근의 실시간 데이터를 CDC(Change Data Capture)로 처리하고 나면 최종적으로 애플리케이션이 DynamoDB를 바라보도록 설정을 변경하게 됩니다.

이 접근방법에서 변경데이터를 캡처하는 방법에 대한 상세한 내용은 AWS 데이터베이스 블로그 포스팅의 Streaming Changes in a Database with Amazon Kinesis에서 다루고 있습니다. 이 블로그 포스팅에서 사용한 모든 코드 및 테스트 코드는 big-data-blog GitHub 저장소를 통해 얻을 수 있습니다.

마이그레이션 솔루션 아키텍쳐

두 접근 방법의 전반적인 아키텍처는 다음과 같습니다.

방안 1:  AWS DMS 사용

이 절에서는 DMS를 이용하여 어떻게 MySQL 데이터베이스에 접속하고, 원본 데이터를 읽고, 데이터를 대상 DynamoDB 데이터베이스에 적재하기 위해 데이터를 정형화하는지에 대해 설명합니다.

1. 복제 인스턴스 생성 및 원본 및 대상 엔드포인트 설정하기

AWS Database Migration Service Best Practices를 참고하여 마이그레이션을 수행하기에 충분한 저장소와 처리능력을 갖춘 복제 인스턴스를 생성합니다. 예를 들어, 마이그레이션 대상 테이블이 많거나 동시에 여러 복제 작업을 수행할 계획이라면 더 큰 크기의 인스턴스들을 사용하는 것을 고려하여야 합니다. 데이터 복제 서비스는 상당한 양의 메모리와 CPU 리소스를 사용합니다.

MySQL 사용자 정보를 사용하여 MySQL에 접속하고 SUPER, REPLICATION CLIENT 권한으로 데이터를 추출합니다. MySQL 설정에서 Binary log를 활성화하고 CDC를 위해 binlog_format 파라미터를 ROW로 설정합니다. DMS를 사용하는 방법에 대한 더 상세한 정보는 AWS Database Migration Service 사용자 가이드의 Getting Started 문서를 참조합니다.

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'welcome1'; mysql> GRANT all ON <database name>.* TO 'repl'@'%'; mysql> GRANT SUPER,REPLICATION CLIENT ON *.* TO 'repl'@'%';

DMS에서 DynamoDB 데이터베이스를 대상으로 설정하기 전에, DMS가 사용할 IAM Role을 생성하고 DynamoDB 대상 테이블에 접근할 권한을 부여해야 합니다. 원본 및 대상 데이터베이스에 접근할 엔드포인트들도 다음 스크린샷과 같이 설정합니다.

다음 스크린샷은 source-mysql의 상세 정보 화면입니다.

객체 매핑 규칙 설정 및 작업 생성하기

다음 예제에서는, MySQL 테이블이 복합 프라이머리 키( customer id + ordered + productid )를 가지고 있다고 가정합니다. 이와 같은 경우, 객체 매핑 규칙을 사용하여 DynamoDB에서 요구하는 데이터 구조에 적합하게 키를 재구성할 수 있습니다.

여기에서는 대상 DynamoDB 테이블은 customer idorder id 컬럼의 조합을 hash key로 설정하고 product id 컬럼을 sort key로 설정합니다. 하지만, 실제 마이그레이션 상황에서는 데이터 적재 및 접근 패턴에 따라 파티션 키를 결정해야 합니다. 보통 카디널리티가 높은 속성을 파티션키로 사용하게 됩니다. DynamoDB에서 올바른 파티션 키를 결정하는 방법에 대한 상세한 내용은 Choosing the Right DynamoDB Partition Key 블로그를 참조하십시오.

여기서 rule-action을 map-record-to-record로 설정하였고 해당 컬럼을 제외 대상 컬럼(exclude-columns) 속성 리스트에 포함시키지 않았기 때문에, DMS 서비스는 원본 데이터의 quantity 컬럼을 대상 DynamoDB 테이블에 자동으로 생성합니다. map-record-to-recordmap-record-to-document 설정에 대한 상세 내용은 AWS Database Migration Service에서 Amazon DynamoDB 데이터베이스를 대상으로 사용 문서를 참조하십시오.

마이그레이션은 작업 생성시 Start task on create 옵션을 해제하지 않을 경우, 작업이 생성되는 즉시 시작됩니다. 마이그레이션 작업이 백그라운드에서 수행되는 동안 어떤 일이 발생하는지 확인하기 위하여 enabling logging을 선택하는 것을 추천합니다.

다음 스크린샷은 작업 생성 페이지를 보여줍니다.

콘솔에서 마이그레이션 개별 데이터베이스 테이블과 마이그레이션에 필요한 변환을 포함한 스키마를 지정할 수 있습니다. Guided 탭의 Where 항목에서 스키마, 테이블을 설정하고 Action 항목에서 포함/불포함 여부를 설정합니다. Filter 항목에서 테이블 내의 컬럼명 및 적용할 조건을 설정합니다.

테이블 매핑 정보는 JSON 형태로 생성할 수도 있습니다. JSON 탭에서 Enable JSON editing 체크박스를 선택하십시오.

다음은 원본데이터가 대상 테이블의 어디에 위치할지 결정하는 객체 매핑 규칙에 대한 예제입니다. 아래 예제를 복사하여 사용할 경우, 아래 속성들을 실제 사용하는 값으로 변경해야 합니다. 보다 많은 예제들은 AWS Database Migration Service에서 Amazon DynamoDB 데이터베이스를 대상으로 사용 문서를 참조하십시오.

  • schema-name
  • table-name
  • target-table-name
  • mapping-parameters
  • attribute-mappings
{
  "rules": [
   {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "mydatabase",
        "table-name": "purchase"
      },
      "rule-action": "include"
    },
    {
      "rule-type": "object-mapping",
      "rule-id": "2",
      "rule-name": "2",
      "rule-action": "map-record-to-record",
      "object-locator": {
        "schema-name": "mydatabase",
        "table-name": "purchase"
 
      },
      "target-table-name": "purchase",
      "mapping-parameters": {
        "partition-key-name": "customer_orderid",
        "sort-key-name": "productid",
        "exclude-columns": [
          "customerid",
          "orderid"           
        ],
        "attribute-mappings": [
          {
            "target-attribute-name": "customer_orderid",
            "attribute-type": "scalar",
            "attribute-sub-type": "string",
            "value": "${customerid}|${orderid}"
          },
          {
            "target-attribute-name": "productid",
            "attribute-type": "scalar",
            "attribute-sub-type": "string",
            "value": "${productid}"
          }
        ]
      }
    }
  ]
}

마이그레이션 작업 시작하기
만약 target-table-name 속성에 정의된 대상 테이블이 DynamoDB에 존재하지 않을 경우, DMS는 데이터 변환 참조와 추가 주제를 포함하는 AWS Database Migration Service 참조 문서에서 설명하는 원본 데이터 형식대상 데이터 형식에  대한 데이터형 변환 규칙에 따라 테이블을 생성합니다. 마이그레이션 작업의 진행상황을 모니터링하는 많은 지표들이 제공됩니다. 보다 상세한 모니터링 관련 정보는 AWS Database Migration Service 작업 모니터링 문서에서 확인하실 수 있습니다.

다음 스크린샷은 CloudWatch Logs에 기록된 이벤트들과 오류 샘플입니다.

마이그레이션에 사용한 DMS 복제 인스턴스들은 모든 마이그레이션 작업이 완료된 후에는 삭제되어야 합니다. 보유기간이 경과한 Cloudwatch log들은 자동으로 삭제됩니다.

방안 2: EMR, Amazon Kinesis, Lambda 사용

이 절에서는 보다 정교한 제어와 유연성을 제공하기 위하여 EMR과 Amazon Kinesis, Lamdba를 사용하는 다른 방안에 대해 다룹니다. 만약 작업환경에 MySQL replica가 포함된다면, replica로부터 데이터를 마이그레이션하는 것을 추천합니다.

키 디자인 변경하기
데이터베이스를 RDBMS에서 NoSQL로 변경하기로 결정했다면, 성능 및 비용 효율성을 위해서 데이터 키를 NoSQL에 더 적합하도록 설계할 필요가 있습니다.

방안 #2에서는 방안 #1과 비슷하게 MySQL 데이터베이스 원본이 복합 프라이머리 키 (customerid + orderid + productid)를 가지고 있다고 가정합니다. 하지만, 여기서는 MySQL 레코드들을 customerid(hash key)와 orderid(sort key)를 사용하여 더 적은 DynamoDB 아이템들로 그룹화합니다. 이를 위하여, MySQL의 복합키 중 마지막 컬럼 (productid)을 복합키에서 제거하는 대신 DynamoDB의 속성 이름으로 하고, Quantity 컬럼을 해당 속성의 값으로  변환합니다.

이런 변환법을 통해 전체 아이템의 수를 줄일 수 있으며, 같은 양의 정보를 더 적은 RCU(Read Capacity Unit)을 사용하여 조회할 수 있어 비용을 절감하면서 더 나은 성능을 얻을 수 있습니다. RCU/WCU(Read Capacity Unit/Write Capacity Unit)를 어떻게 계산하는지에 대한 더 상세한 정보는 프로비저닝된 처리량 문서를 확인하시기 바랍니다.

단계별 마이그레이션

방안 #2는 다음 두 단계의 마이그레이션이 동시에 진행됩니다.:

  • 일괄 처리: MySQL 데이터 export, export파일의 S3 업로드, S3 데이터 DynamoDB에 import
  • 실시간 처리: MySQL의 변경 데이터 캡처, insert/update/delete 트랜잭션을 Kinesis Stream에 송신, DynamoDB에 데이터를 입력하기 위한 Lambda 함수 호출.

데이터의 일관성과 무결성을 유지하기 위해 데이터를 캡처하고 Amazon Kinesis Stream에 밀어넣는 작업은 일괄 처리 프로세스 전에 시작되어야 하고, EMR에서 처리되는 일괄처리 프로세스가 종료되기 전까지 Lambda 함수는 실행되지 않고 캡처된 데이터가 스트림에 유지되어야 합니다. 다음 순서와 같이 진행됩니다.:

  1. Amazon Kinesis Stream에 대해 데이터 실시간 처리를 시작합니다.
  2. 실시간 처리 프로세스가 시작되자마자, 일괄 처리 프로세스를 시작합니다.
  3. 일괄 처리 프로세스가 완료되면 Amazon Kinesis Stream으로 부터 데이터를 추출하여 DynamoDB에 put_item 함수를 실행하는 Lambda 함수를 호출합니다.
  4. 애플리케이션의 엔드포인트를 MySQL에서 DynamoDB를 바라보도록 설정을 변경합니다.

단계 1:  변경데이터캡처및 Amazon Kinesis Streams에밀어넣기

먼저, MySQL으로부터 트렌젝션 데이터를 캡처할 Amazon Kinesis Stream을 생성합니다. Data retention period 값을 일괄 처리 프로세스의 예상 처리시간에 맞춰 설정합니다. 데이터 무결성을 위해서는 데이터 보관 기간을 일괄 처리 프로세스가 실행되는 기간 동안 발생하는 모든 트랜잭션을 보관하기 충분할 정도로 길게 설정해야 하지만, 보관 기간을 반드시 최대값으로 설정할 필요는 없습니다. 마이그레이션 대상 데이터의 양에 따라 설정합니다.

MySQL 설정에서, BinLogStreamReader 모듈이 트랜잭션 데이터를 캡처할수 있도록 binlog_format 설정값을 ROW로 설정합니다. Binlog를 활성화하려면 log_bin 매개변수도 설정되어야 합니다. 더 상세한 내용은 AWS 데이터베이스 블로그의 Streaming Changes in a Database with Amazon Kinesis 포스트를 참조하시기 바랍니다.

[mysqld]
secure-file-priv = ""
log_bin=/data/binlog/binlog
binlog_format=ROW
server-id = 1
tmpdir=/data/tmp

다음 예제 코드는 트랜잭션 데이터를 캡처하여 Amazon Kinesis Stream으로 밀어넣는 Python 예제 코드입니다.

#!/usr/bin/env python
from pymysqlreplication import BinLogStreamReader
from pymysqlreplication.row_event import (
  DeleteRowsEvent,
  UpdateRowsEvent,
  WriteRowsEvent,
)

def main():
  kinesis = boto3.client("kinesis")

  stream = BinLogStreamReader(
    connection_settings= {
      "host": "<host IP address>",
      "port": <port number>,
      "user": "<user name>",
      "passwd": "<password>"},
    server_id=100,
    blocking=True,
    resume_stream=True,
    only_events=[DeleteRowsEvent, WriteRowsEvent, UpdateRowsEvent])

  for binlogevent in stream:
    for row in binlogevent.rows:
      event = {"schema": binlogevent.schema,
      "table": binlogevent.table,
      "type": type(binlogevent).__name__,
      "row": row
      }

      kinesis.put_record(StreamName="<Amazon Kinesis stream name>", Data=json.dumps(event), PartitionKey="default")
      print json.dumps(event)

if __name__ == "__main__":
main()

다음 코드는 위 Python 스크립트에 의해 생성된 JSON 데이터 예제입니다. 각 트랜잭션은 JSON 데이터에 다음과 같은 type 속성으로 기록됩니다:

  • WriteRowsEvent = INSERT
  • UpdateRowsEvent = UPDATE
  • DeleteRowsEvent = DELETE
{"table": "purchase_temp", "row": {"values": {"orderid": "orderidA1", "quantity": 100, "customerid": "customeridA74187", "productid": "productid1"}}, "type": "WriteRowsEvent", "schema": "test"}
{"table": "purchase_temp", "row": {"before_values": {"orderid": "orderid1", "quantity": 1, "customerid": "customerid74187", "productid": "productid1"}, "after_values": {"orderid": "orderid1", "quantity": 99, "customerid": "customerid74187", "productid": "productid1"}}, "type": "UpdateRowsEvent", "schema": "test"}
{"table": "purchase_temp", "row": {"values": {"orderid": "orderid100", "quantity": 1, "customerid": "customerid74187", "productid": "productid1"}}, "type": "DeleteRowsEvent", "schema": "test"}

단계 2. MySQL에서 DynamoDB로 데이터 덤프하기

DMS를 사용하는 가장 손쉬운 방법 중 하나는, 최근 추가된 Amazon S3를 마이그레이션 대상으로 사용하는 것입니다. S3를 대상으로 할 경우, full load 및 CDC 데이터가 CSV 형식으로 저장됩니다. 그러나, CDC의 경우에는 UPDATE 및 DELETE 문의 지원되지 않아 마이그레이션에 적합하지 않습니다. 보다 상세한 내용은 AWS Database Migration Service에서 Amazon S3를 대상으로 사용 문서를 참조하십시오.

Amazon S3로 데이터를 업로드하는 다른 방법은 스크립트에서 INTO OUTFILE SQL 절과 aws s3 sync CLI 명령어를 병렬로 사용하는 것입니다. 병렬 처리 수준은 서버 용량 및 로컬 네트워크 대역폭에 따라 달라집니다. pt-archiverPercona Toolkit 에 포함된 도구입니다. 상세 내용은 appendix를 참조하십시오. )와 같은 3rd party 도구도 유용하게 사용할 수 있습니다.

SELECT * FROM purchase WHERE <condition_1>
INTO OUTFILE '/data/export/purchase/1.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';
SELECT * FROM purchase WHERE <condition_2>
INTO OUTFILE '/data/export/purchase/2.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';
...
SELECT * FROM purchase WHERE <condition_n>
INTO OUTFILE '/data/export/purchase/n.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';

여기에서 다루는 사용사례의 경우 aws s3 sync 명령어를 추천합니다. 이 명령어는 내부적으로 S3 multipart 업로드기능을 사용하여 동작하고 패턴 매칭을 통해 특정파일을 포함하거나 제외시킬 수 있습니다. 또한, sync 명령어는 로컬 버전과 S3 버전 간에 파일 크기와 수정시간을 비교하여 서로 다른 경우에만 동기화를 수행하기 때문에 동기화 프로세스가 처리 도중에 중단되더라도 동일한 파일을 다시 업로드할 필요가 없습니다. 더 상세한 내용은 AWS CLI 명령어 참조문서의 sync command를 참고하시기 바랍니다.

$ aws s3 sync /data/export/purchase/ s3://<your bucket name>/purchase/ 
$ aws s3 sync /data/export/<other path_1>/ s3://<your bucket name>/<other path_1>/
...
$ aws s3 sync /data/export/<other path_n>/ s3://<your bucket name>/<other path_n>/ 

모든 데이터가 S3로 업로드된 후, 데이터를 DynamoDB에 밀어넣기 위해서는 다음과 같은 두가지 방법이 있습니다.:

  • 외부 테이블을 이용하여 Hive사용
  • MapReduce 코드 작성

외부 테이블을 이용하여 Hive 사용

S3의 데이터에 대해서 Hive 외부테이블을 생성하고 org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler 속성을 사용하여 생성한 DynamoDB 테이블을 대상으로 하는 다른 외부 테이블에 S3와 연결된 외부 테이블의 내용을 밀어넣습니다. 더 나은 생산성과 확장성을 위해 Hive용 UDF 모음인 Brickhouse를 사용하는 것을 고려해 볼 수 있습니다.

다음 샘플 코드는 DynamoDB용 Hive 테이블이 ARRAY<STRING> 타입의 products 컬럼으로 생성되었다고 가정합니다. Productidquantity 컬럼은 customeridorderid별로 그룹화되어 Brickhouse에서 제공하는 CollectUDAF 컬럼을 사용하여 products 컬럼에 삽입됩니다.

hive> DROP TABLE purchase_ext_s3; 
--- To read data from S3 
hive> CREATE EXTERNAL TABLE purchase_ext_s3 (
customerid string,
orderid    string,
productid  string,
quantity   string) 
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' 
LOCATION 's3://<your bucket name>/purchase/';

Hive> drop table purchase_ext_dynamodb ; 
--- To connect to DynamoDB table  
Hive> CREATE EXTERNAL TABLE purchase_ext_dynamodb (
      customerid STRING, orderid STRING, products ARRAY<STRING>)
      STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' 
      TBLPROPERTIES ("dynamodb.table.name" = "purchase", 
      "dynamodb.column.mapping" = "customerid:customerid,orderid:orderid,products:products");

--- Batch-puts to DynamoDB using Brickhouse 
hive> add jar /<jar file path>/brickhouse-0.7.1-SNAPSHOT.jar ; 
hive> create temporary function collect as 'brickhouse.udf.collect.CollectUDAF';
hive> INSERT INTO purchase_ext_dynamodb 
select customerid as customerid , orderid as orderid
       ,collect(concat(productid,':' ,quantity)) as products
      from purchase_ext_s3
      group by customerid, orderid; 

불행히도 DynamoDBStorageHandler클래스는 MAP, LIST, BOOLEAN 및 NULL  데이터형을 지원하지 않기 때문에 ARRAY<STRING> 데이터형을 선택하였습니다. Hive의 ARRAY<STRING> 형식의 products 컬럼은 DynamoDB의 StringSet데이터형 속성으로 변환됩니다. 샘플코드는 Brickhouse가 어떤 식으로 동작하는지, 어떻게 원하는 복수의 레코드들을 골라 DynamoDB의 하나의 StringSet  데이터형 속성으로 병합할 수 있는지 보여줍니다.

Hadoop Streaming으로 Python MarReduce 코드 작성하기
맵퍼 작업은 S3의 입력데이터로부터 각 레코드를 읽고 입력 키-값 쌍을 중간 키-값 쌍으로 매핑합니다. S3의 원본 데이터를 탭 문자(“\t)로 구분된 키 부분과 값 부분의 두 부분으로 나눕니다. 맵퍼 데이터는 중간 키(customeridorderid) 값으로 정렬되어 reducer로 전송됩니다. reducer단계에서 각 레코드들이 DynamoDB에 저장합니다.

#!/usr/bin/env python
import sys
 
# get all lines from stdin
for line in sys.stdin:
    line = line.strip()
    cols = line.split(',')
# divide source data into Key and attribute part.
# example output : “cusotmer1,order1	product1,10”
    print '%s,%s\t%s,%s' % (cols[0],cols[1],cols[2],cols[3] )

일반적으로 reduce 작업은 매핑( 키 / 값 목록의 쌍 ) 프로세스가 생성한 결과값을 수신한 뒤 각 키에 대해 값의 목록에 대한 작업을 수행합니다.

여기서는 reducer를 STDIN/STDOUT/Hadoop streaming을 기반으로 하여 Python으로 작성하였습니다. 문제는 이와 같은 경우 열거형 데이터 형식을 사용할 수 없다는 것입니다. 이와 같은 경우 reducer를 매퍼의 중간 키값 – 이 경우, customeridoerderid(cols[0],cols[1]) -으로 정렬된 데이터를 수신하고 모든 속성을 item_data dictionary의 특정 키로 저장합니다. Item_data dictionary의 속성들은 sys.stdin에서 새 중간 키가 들어올 대마다 DynamoDB에 입력되거나 플러싱됩니다.

#!/usr/bin/env python
import sys
import boto.dynamodb
 
# create connection to DynamoDB
current_keys = None
conn = boto.dynamodb.connect_to_region( '<region>', aws_access_key_id='<access key id>', aws_secret_access_key='<secret access key>')
table = conn.get_table('<dynamodb table name>')
item_data = {}

# input comes from STDIN emitted by Mapper
for line in sys.stdin:
    line = line.strip()
    dickeys, items  = line.split('\t')
    products = items.split(',')
    if current_keys == dickeys:
       item_data[products[0]]=products[1]  
    else:
        if current_keys:
          try:
              mykeys = current_keys.split(',') 
              item = table.new_item(hash_key=mykeys[0],range_key=mykeys[1], attrs=item_data )
              item.put() 
          except Exception ,e:
              print 'Exception occurred! :', e.message,'==> Data:' , mykeys
        item_data = {}
        item_data[products[0]]=products[1]
        current_keys = dickeys

# put last data
if current_keys == dickeys:
   print 'Last one:' , current_keys #, item_data
   try:
       mykeys = dickeys.split(',')
       item = table.new_item(hash_key=mykeys[0] , range_key=mykeys[1], attrs=item_data )
       item.put()
   except Exception ,e:
print 'Exception occurred! :', e.message, '==> Data:' , mykeys

MapReduce 작업을 실행하려면 EMR 마스터 노드에 접속하여 Hadoop 스트리밍 작업을 실행하십시오. hadoop-streaming.jar 파일 위치 및 파일 이름은 EMR 버전에 따라 다를 수 있습니다. reducer가 실행되는 동안 발생하는 exception 메시지들은 -output 옵션으로 지정한 디렉토리에 저장됩니다. 예외 또는 오류의 원인이되는 데이터를 식별하기 위해 해시 키 및 범위 키 값들도 기록됩니다.

$ hadoop fs -rm -r s3://<bucket name>/<output path>
$ hadoop jar /usr/lib/hadoop-mapreduce/hadoop-streaming.jar \
           -input s3://<bucket name>/<input path> -output s3://<bucket name>/<output path>\
           -file /<local path>/mapper.py -mapper /<local path>/mapper.py \
           -file /<local path>/reducer.py -reducer /<local path>/reducer.py

위 스크립트와 자체 생성한 테스트 데이터를 사용하여 수행한 마이그레이션 테스트에서 데이터베이스 크기 및 데이터 마이그레이션을 완료하기까지 걸린 시간은 다음과 같습니다.

Server MySQL instance m4.2xlarge
EMR cluster master : 1 x m3.xlarge

core  : 2 x m4.4xlarge

DynamoDB 2000 write capacity unit
Data Number of records 1,000,000,000
Database file size (.ibc) 100.6 GB
CSV files size 37 GB
Performance (time) Export to CSV 6 min 10 sec
Upload to S3 (sync) 3 min 30 sec
Import to DynamoDB depending on write capacity unit

다음 스크린샷은 마이그레이션 작업 도중 write capacity 사용 결과를 보여줍니다.

성능 결과는 사용한 서버 용량과 네트워크 대역폭, 병렬 처리 수준, 변환 로직, 사용 프로그램 언어 및 기타 조건에 달라질 수 있습니다. 이 경우 프로비저닝된 write capacity unit이 모두 데이터 import를 위해 사용한 MapReduce 작업에 의해 소비되었으므로, EMR 클러스터의 크기 및 DynamoDB 테이블의 write capacity unit을 늘릴 수록 데이터 이전작업 완료에 걸리는 시간을 단축할 수 있습니다. Jave 기반 MapReduce 코드를 사용할 경우 MapReduce 프레임워크 사용 및 함수 작성시 보다 많은 유연성을 제공합니다.

단계 3: Amazon Lambda 함수를 사용하여 Amazon Kinesis로부터 데이터를 읽고 DynamoDB에 업데이트하기

AWS Lambda 콘솔에서 Create a Lambda functionkinesis-process-record-python blueprint를 선택합니다. 다음 버튼을 클릭하고 Configure triggers 페이지에서 생성한 Kinesis stream을 선택합니다.

생성한 Lambda 함수가 Amazon Kinesis 스트림을 읽고 데이터를 DynamoDB에 쓸 수 있도록 해당 권한을 가진 IAM role을 설정하여야 합니다.

Lambda 함수는 각 레코드의 type 속성을 확인하여 트랜잭션 유형을 식별합니다. 트랜잭션 유형에 따라 변환 및 업데이트 방법이 결정됩니다.

예를 들어 JSON 레코드가 함수에 전달되면 함수는 type 속성을 확인하고 DynamoDB 테이블에 들어온 레코드와 동일한 키를 가진 아이템이 이미 존재하는지 확인합니다. 만약 동일한 키를 가진 아이템이 이미 있다면 기존 아이템을 조회하여 dictionary 변수 (다음 코드에서는 item 변수)에 저장하고 DynamoDB 테이블에 저장하기 전에 dictionary 변수에 저장된 기존 아이템 정보에 새로 전달된 정보를 반영하여 저장합니다. 이렇게 해서 들어오는 레코드가 기존 항목을 덮어 쓰지 않도록 합니다.

from __future__ import print_function

import base64
import json
import boto3

print('Loading function')
client = boto3.client('dynamodb')

def lambda_handler(event, context):
    #print("Received event: " + json.dumps(event, indent=2))
    for record in event['Records']:
        # Amazon Kinesis data is base64-encoded so decode here
        payload = base64.b64decode(record['kinesis']['data'])
        print("Decoded payload: " + payload)
        data = json.loads(payload)
        
        # user logic for data triggered by WriteRowsEvent
        if data["type"] == "WriteRowsEvent":
            my_table = data["table"]
            my_hashkey = data["row"]["values"]["customerid"]
            my_rangekey = data["row"]["values"]["orderid"]
            my_productid = data["row"]["values"]["productid"]
            my_quantity = str( data["row"]["values"]["quantity"] )
            try:
                response = client.get_item( Key={'customerid':{'S':my_hashkey} , 'orderid':{'S':my_rangekey}} ,TableName = my_table )
                if 'Item' in response:
                    item = response['Item']
                    item[data["row"]["values"]["productid"]] = {"S":my_quantity}
                    result1 = client.put_item(Item = item , TableName = my_table )
                else:
                    item = { 'customerid':{'S':my_hashkey} , 'orderid':{'S':my_rangekey} , my_productid :{"S":my_quantity}  }
                    result2 = client.put_item( Item = item , TableName = my_table )
            except Exception, e:
                print( 'WriteRowsEvent Exception ! :', e.message  , '==> Data:' ,data["row"]["values"]["customerid"]  , data["row"]["values"]["orderid"] )
        
        # user logic for data triggered by UpdateRowsEvent
        if data["type"] == "UpdateRowsEvent":
            my_table = data["table"]
            
        # user logic for data triggered by DeleteRowsEvent    
        if data["type"] == "DeleteRowsEvent":
            my_table = data["table"]
            
            
    return 'Successfully processed {} records.'.format(len(event['Records']))

단계 4:  애플리케이션 엔드포인트를 MySQL에서 DynamoDB로 변경하기

애플리케이션이 MySQL 대신 DynamoDB를 데이터베이스로 사용하려면 애플리케이션 코드를 리팩토링해야 합니다. 애플리케이션의 데이터베이스 액세스에 대한 모든 경우를 여기에서 다루기는 어렵기 때문에, 여기서는 다음의 간단한 자바 코드로 데이터베이스 연결 및 쿼리 부분이 어떻게 바뀌어야 하는지 확인해 보겠습니다. 더 자세한 내용에 대해서는 DynamoDB 및 AWS SDK를 사용한 프로그래밍 문서를 참조하시기 바랍니다.

MySQL 쿼리 코드 예제

다음 샘플 코드는 MySQL 데이터베이스에 연결하고 데이터를 조회하는 일반적인 방법을 보여줍니다.

import java.sql.* ;
...
try {
    Connection conn =  DriverManager.getConnection("jdbc:mysql://<host name>/<database name>" , "<user>" , "<password>");
    stmt = conn.createStatement();
    String sql = "SELECT quantity as quantity FROM purchase WHERE customerid = '<customerid>' and orderid = '<orderid>' and productid = '<productid>'";
    ResultSet rs = stmt.executeQuery(sql);

    while(rs.next()){ 
       int quantity  = rs.getString("quantity");   //Retrieve by column name 
       System.out.print("quantity: " + quantity);  //Display values 
       }
} catch (SQLException ex) {
    // handle any errors
    System.out.println("SQLException: " + ex.getMessage());}
...
==== Output ====
quantity:1

DynamoDB 쿼리 코드 예제

DynamoDB에서 데이터를 조회하려면 다음 단계를 따르면 됩니다:

  1. AmazonDynamoDBClient 및 ProfileCredentialProvider를 이용하여 DynamoDB 클래스의 인스턴스 생성
  2. DynamoDB 클래스 인스턴스의 getTable method를 사용하여 대상 Table 클래스 인스턴스 획득
  3. withHashKey및 withRangeKeyCondition method를 사용하여 QuerySpec 클래스 인스턴스 생성
  4. QuerySpec 클래스 인스턴스를 사용하여 Table 클래스 인스턴스의 query method를 실행. 결과값이 JSON 형식으로 반환되므로, 결과값에 대하여 특정 속성 값을 확인하기 위하여 getJSON method 사용
...
DynamoDB dynamoDB = new DynamoDB( new AmazonDynamoDBClient(new ProfileCredentialsProvider()));

Table table = dynamoDB.getTable("purchase");

QuerySpec querySpec = new QuerySpec()
        .withHashKey("customerid" , "customer1")  // hashkey name and its value 
        .withRangeKeyCondition(new RangeKeyCondition("orderid").eq("order1") ) ; // Ranage key and its condition value 

ItemCollection<QueryOutcome> items = table.query(querySpec); 

Iterator<Item> iterator = items.iterator();          
while (iterator.hasNext()) {
Item item = iterator.next();
System.out.println(("quantity: " + item.getJSON("product1"));   // 
}
...
==== Output ====
quantity:1

맺음말
이 글에서는 MySQL에서 DynamoDB로 데이터를 원활하게 마이그레이션하고 마이그레이션 중 중단 시간을 최소화하기 위한 두 가지 방안을 소개했습니다. 방안 #1에서는 DMS를 사용하였고, 방안 #2에서는 EMR, Amazon Kinesis 및 Lambda를 복합적으로 사용하였습니다. 또한 각 데이터베이스의 특성에 따라 키 디자인을 변환하여 읽기 및 쓰기 성능을 개선하고 비용을 절감하는 방법도 설명했습니다. 각 방안은 서로 장단점이 있으므로 비즈니스 요구 사항에 따라 어떤 접근방법을 취할지 고려할 필요가 있습니다.

여기에서 사용한 예제 코드들은 다양한 환경에서 완벽하고 효율적이며 신뢰할 수 있는 데이터 마이그레이션 용으로 재사용되기에 충분한 수준이 아닙니다. 데이터 마이그레이션을 시작하기 전에 참조용으로 사용하시고 실제 마이그레이션에서는 신뢰할 수 있는 마이그레이션을 수행할 수 있도록 모든 요소들을 충분히 고려하여 작성되어야 합니다.

이 글이 여러분의 데이터베이스 마이그레이션을 계획 및 구현하고 서비스 중단을 최소화하는데 도움이 되기를 바랍니다.

Appendix

Percona Toolkit 설치법:

# Install Percona Toolkit
$ wget https://www.percona.com/downloads/percona-toolkit/3.0.2/binary/redhat/6/x86_64/percona-toolkit-3.0.2-1.el6.x86_64.rpm
$ yum install perl-IO-Socket-SSL
$ yum install perl-TermReadKey
$ rpm -Uvh percona-toolkit-3.0.2-1.el6.x86_64.rpm

Pt-archiver 실행 예제:

# run pt-archiver
$ pt-archiver –source h=localhost,D=blog,t=purchase –file ‘/data/export/%Y-%m-%d-%D.%t’  –where “1=1” –limit 10000 –commit-each

이 글은 AWS 빅데이터 서비스의 기술 지원 엔지니어인 이용성님이 작성하신 글 Near Zero Downtime Migration from MySQL to DynamoDB을 AWS 솔루션즈 아키텍트인 김병수님이 번역해 주셨습니다.

Amazon RDS for SQL Server – 윈도 인증 기능 서울 리전 출시

2012년에 Amazon RDS 서비스에 대한 SQL Server 지원을 처음 시작했습니다. 그 후 SSL 지원, 주요 버전 업그레이드, 데이터 암호화Multi-AZ를 포함한 많은 기능을 추가했습니다. 이러한 신규 기능은 SQL Server 기반 RDS 적용 범위를 넓히고 고객들의 추가 사용 사례를 열었습니다.

윈도우즈 워크로드를 실행하는 많은 기업에서 Active Directory를 기반한 계정 자격 증명 및 관련 사용 권한을 지정합니다. 디렉토리는이 정보에 대한 단일 소스를 제공하며 중앙 집중식 관리를 허용합니다. 지난 3월에 출시된 AWS Directory Service를 사용하여 Microsoft Active Directory의 Enterprise Edition을 실행을 오늘 부터 서울 리전에서도 사용 가능합니다.

서울 리전, 윈도 인증 지원
Microsoft Active Directory (Enterprise Edition)를 통해 AWS Directory Service에 저장된 자격 증명을 사용하여 SQL Server용 Amazon RDS에 대한 애플리케이션 인증을 허용 할 수 있습니다. 동일한 디렉토리에 모든 자격 증명을 유지함으로서 더 이상 각 복사본을 찾고 업데이트 할 필요가 없으므로 시간과 노력을 절약하면서 전체 보안 프로필이 향상 될 수도 있습니다.

SQL Server를 실행할 새 데이터베이스 인스턴스를 만들 때, 이 기능을 활성화하고 Active Directory를 선택할 수 있습니다. 또한, 기존 데이터베이스 인스턴스에 대해서도 새로 설정할 수 있습니다. 새 데이터베이스 인스턴스를 만들 때 디렉터리를 선택하는 방법은 다음과 같습니다 (새 데이터베이스 인스턴스를 만들 수도 있습니다).

자세한 내용은 SQL Server DB 인스턴스와 함께 Microsoft SQL Server Windows 인증 사용을 참조하십시오.

서울 리전 정식 출시
본 기능은 현재 미국 동부 (버지니아 북부), 미국 서부 (오레곤), EU (아일랜드), 아시아 태평양 (시드니), 아시아 태평양 (도쿄) 및 아시아 태평양 (싱가포르)에서 사용할 수 있으며 오늘 부터 아시아 태평양(서울) 리전에서 사용을 시작할 수 있습니다 오늘. 해당 기능은 무료이지만 Active Directory 용 AWS Directory Service의 표준 요금만 지불하게 됩니다.

Jeff;

AWS 데이터베이스 마이그레이션, 2만회 돌파!

1년 전 AWS Database Migration Service 출시를 했을 때, 이미 1,000여 고객이 데이터베이스 이전 도구로서 DMS 서비스를 활용하고 있었습니다.

즉, AWS Database Migration ServiceSchema Conversion Tool (SCT)는 AWS 고객이 고가의 자체 데이터베이스와 데이터웨어 하우스에서 보다 비용 효율적인 Amazon Aurora, Amazon Redshift, MySQL, MariaDB PostgreSQL 같은 클라우드 기반 데이터베이스와 데이터웨어 하우스로 이동하고 있으며, 이를 통해 다운 타임을 최소화 한 상태에서 전환하게 되었습니다. 예를 들어 Amazon Aurora로 전환하면 상용 데이터베이스의 10 분의 1의 비용으로 MySQL과 PostgreSQL 호환 데이터베이스를 사용할 수 있습니다. Expedia, Thomas Publishing, Pega, Veoci 등 고객 사례는 AWS DMS 활용 사례에서 보실 수 있습니다.

20,000 데이터베이스 이전 달성
AWS 고객은 지금까지 AWS Database Migration Service 를 사용하여 20,000 건의  데이터베이스를 AWS로 이전하고 현재도 그 수는 늘어나고 있습니다. (2016 년 9 월에 10,000 건 기록).

지난해에도 DMS와 SCT 서비스에 몇 가지 새로운 기능을 추가했습니다.

  • 2016년 3월 – 8개 리전 정식 출시
  • 2016년 5월 – 전환 대상으로 Redshift 추가
  • 2016년 7월 – 지속적인 복제를 위한 고가용서 아키텍처 제공
  • 2016년 7월 – 전환 소스 및 타겟으로 SSL 엔드포인트 및 Sybase 엔진 지원
  • 2016년 8월 – Asia Pacific (Mumbai) , Asia Pacific (Seoul) , South America (Brazil) 리전 확장
  • 2016년 10월 – US East (Ohio) 리전 확장
  • 2016년 12월 – Oracle SSL 연결 기능제
  • 2016년 12월 – Canada (Central)와 Europe (London) 리전 확장
  • 2017년 1월 – 이벤트와 이벤트 구독 기능 추가
  • 2017년 2월 – Oracle and Teradata에서 Amazon Redshift 전환 지원

자세한 정보
데이터 베이스 마이그레이션을 위해서는  먼저 최근 온라인 세미나 및 상세한 기술 문서들을 참고하시기 바랍니다.

Migrating From Sharded to Scale-Up – 일부 고객은 스케일 아웃 전략을 통해 데이터베이스 샤딩으로 마이그레이션 효과를 극대화 하고 있습니다. 두 개 이상의 샤드를 하나의 Aurora 인스턴스에 정리 복잡성을 줄이고 신뢰성을 높이면서 비용 절감을 실현하는 방법에 대한 블로그 글, 세미나 동영상, 발표 자료를 참고 하시기 바랍니다.

Migrating From Oracle or SQL Server to Aurora – Oracle 또는 SQL Server와 같은 상용 데이터베이스에서 Aurora로 이전하고 있습니다. 관련 정보는 발표 자료동영상을 참고하시기 바랍니다.

그 밖에도 AWS Database Blog에 다양한 글이 있습니다.

기술 문서에도 다양한 정보를 제공하고 있습니다.

서울 Summit에서 만납시다!
오는 4월 19-20일 개최되는 AWS Summit 2017 서울 행사에서 다양한 데이터베이스 관련 세션을 마련하였습니다. 지금 등록하시고 많은 참여 바랍니다.

Jeff;

이 글은 AWS Database Migration Service – 20,000 Migrations and Counting의 한국어 요약입니다.

Amazon RDS MySQL로 부터 Aurora 읽기 복제본 생성 기능 출시!

24시간 실행하는 웹 사이트 또는 애플리케이션인 경우, 기존 데이터베이스 엔진에서 다른 엔진으로 마이그레이션은 매우 까다로운 작업입니다. 데이터베이스를 중단하고 작업을 할 수 없다면, 일반적으로 복제를 기반으로 하는 접근 방식이 가장 좋습니다.

오늘 Amazon Aurora 읽기 복제본(Read Replica)을 통해 MySQL 용 Amazon RDS DB 인스턴스에서 Amazon Aurora로 마이그레이션 할 수 있는 새로운 기능을 출시했습니다. 마이그레이션 프로세스는 기존 DB 인스턴스의 DB 스냅 샷을 만든 다음, 이를 새로운 Aurora 읽기 복제본을 사용합니다. 복제본을 설정 한 후 복제를 사용하여 원본과 같은 최신 상태로 만들고, 복제 지체가 없어지면 복제를 완료합니다. 이 시점에서 오로라 읽기 복제본을 독립 실행 형 Aurora DB 클러스터로 만들고 클라이언트 응용 프로그램을 연결합니다.

마이그레이션은 테라 바이트 데이터 당 몇 시간이 걸리고, 최대 6 테라 바이트의 MySQL DB 인스턴스에서 작동합니다. InnoDB 테이블은 MyISAM 테이블보다 복제가 약간 더 빠르며 압축되지 않은 테이블도 가능합니다. 마이그레이션 속도가 중요한 요소라면 MyISAM 테이블을 InnoDB 테이블로 옮기고, 압축 테이블을 압축 해제하여 성능을 향상 시킬 수도 있습니다.

RDS DB 인스턴스를 마이그레이션하려면 AWS 관리 콘솔에서 Instance Actions를 선택하고 인스턴스 작업을 클릭 한 다음 Create Aurora Read Replica을 선택하십시오.

그런 다음 데이터베이스 인스턴스 식별자를 입력하고, 원하는 옵션을 설정 한 다음 Create Read Replica를 클릭합니다.

콘솔에서 마이그레이션 진행 상황을 모니터링 할 수 있습니다.

마이그레이션이 완료되면 새로운 Aurora 읽기 복제본에서 Replica Lag가 0이 될 때까지 기다렸다가 (복제본에서 SHOW SLAVE STATUS 명령을 사용하여 “Masters 뒤의 Seconds”를 확인) 복제본이 소스와 모두 동기화되면,   원본 MySQL DB 인스턴스에 대한 신규 트랜잭션을 중지하고 오로라 읽기 복제본을 DB 클러스터로 올립니다.

새 클러스터를 사용할 수 있을 때까지 기다립니다 (일반적으로 1 분 정도).

이제 응용 프로그램에 클러스터의 엔드포이트를 지정하면 됩니다!

본 기능은 오늘 부터 Amazon Aurora를 제공하는 모든 리전에서 사용 가능합니다.

Jeff;

이 글은 New – Create an Amazon Aurora Read Replica from an RDS MySQL DB Instance의 한국어 번역입니다.

AWS 2016년 12월 31일 윤초 대응 방법

2016년말 새해를 맞이하기 전 1초를 추가하는 윤초가 시행됨을 잊지 마시기 바랍니다.

이번 윤초 (통산 27 번째)는 UTC(세계 표준시) 2016년 12월 31일 23:59:60으로 삽입됩니다 (한국 표준시로 2017년 1월 1일 8:59:60). 이는 지구 시간(협정 세계시)과 태양시(천문시)과의 차이를 줄이기 위해 진행되며, UTC 기준 올해 마지막 1분은 61가 됩니다.

이전에 윤초를 진행할 때 드린 정보(AWS에서 윤초 대응)은 계속 유효하며, 이번에도 마찬가지로 처리되지만 약간의 차이가 있습니다 :

AWS 조정 시간 (AWS Adjusted Time) – 윤초 삽입 전후의 24시간 동안 윤초의 1초를 조금씩 분산합니다(UTC에서 12월 31일 11:59:59부터 2017년 1월 1일 12:00:00까지). AWS 조정 시간과 세계 시간은 이 기간이 끝난 후 동기화합니다.

Microsoft Windows – Amazon에서 제공 된 Microsoft Windows AMI를 이용하고 있는 인스턴스는 AWS 조정 시간에 따릅니다.

Amazon RDS – 대부분 Amazon RDS 인스턴스(UTC로 설정되어있는 경우) “23:59:59″을 두 번 기록합니다. 그러나 Oracle 11.2.0.2, 11.2.0.3, 12.1.0.1는 AWS 조정 시간에 따릅니다. Oracle 11.2.0.4 및 12.1.0.2에 대한 자세한 정보가 필요한 경우 AWS 지원에 문의하십시오.

자세한 정보
윤초 삽입에 대한 질문이있는 경우AWS SupportEC2 Forum에 문의해 주시기 바랍니다.

Jeff;

이 글은 Look Before You Leap – December 31, 2016 Leap Second on AWS의 한국어 번역입니다.

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