[AWS SCT] AWS SCT 활용하여 이기종 데이터베이스 스키마 전환하기

-          툴을 활용하여 쉽고 빠르게 이기종 데이터베이스 호환 스키마를 만들기

 

l  Version : AWS SCT

 

이전 포스팅에 AWS DMS 서비스를 소개하면서 이기종 간의 데이터 마이그레이션에 대해서 알아 보았다. AWS DMS 이기종간의 데이터 마이그레이션 뿐만 아니라, 실시간 마이그레이션, 그리고 마이그레이션 진행과정에서 데이터 마스킹등 다양한 기술을 지원한다.

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

 

그렇다면 이기종 간의 데이터 마이그레이션을 진행하기 위해서는 스미카 생성이 선행되어야 하는데, 이기종 간의 스키마 구조는 동일하게 하더라도, 데이터 타입은 벤더 마다 지원하는 부분이 조금씩 다르다. 그리고 모든 스키마를 손으로 한땀 한땀 수정하기에는 적은 수의 테이블이면 상관이 없지만, 많은 수의 컬럼을 가진 테이블이나, 테이블 개수가 많다면 수작업으로 하기에는 많은 불편함이 있을 것이다. 이처럼 벤더사에서 제공하는 데이터 타입에서 불일치에 대한 변환 작업과, 수동 작업으로 발생하는 여러가지 문제를 해결하기 위해서 AWS에서는 SCT라는 솔루션을 제공하고 있다. 이번 포스트에서는 AWS SCT에서 대해서 알아본다.

 

AWS SCT(Schema Conversion Tool) 기존 데이터베이스 스키마를 데이터베이스 엔진에서 다른 데이터베이스 엔진으로 변환할 있는 기능을 제공한다. 변환된 스키마는 Amazon RDS (아마존 관계형 데이터베이스 서비스) MySQL, MariaDB, 오라클, SQL 서버, PostgreSQL DB, Amazon Aurora DB 클러스터 또는 Amazon Redshift 클러스터에 적합하다. 변환된 스키마는 Amazon EC2 인스턴스에서 데이터베이스와 함께 사용하거나 Amazon S3 버킷에 데이터로 저장할 있다.

 

아래 표는 AWS SCT에서 변환을 지원하는 OLTP 목록이다. 간략히 정리한 것으로 자세한 내용은 공식 문서를 참고할 있도록 한다.

l  What is the AWS Schema Conversion Tool? : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

 

원본 데이터베이스 대상 데이터베이스
IBM DB2 LUW (9.1 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, PostgreSQL
Microsoft Azure SQL Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL
Microsoft SQL Server (2008 이상) Aurora MySQL, Aurora PostgreSQL, Aurora PostgreSQL, Microsoft SQL Server, MySQL, PostgreSQL
MySQL (5.5이상) Aurora PostgreSQL, MySQL, PostgreSQL
Oracle (10.2 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, Oracle, PostgreSQL
PostgreSQL(9.1 이상) Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL
SAP ASE (12.5 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, PostgreSQL

 

아래 표는 AWS SCT에서 변환을 지원하는 DW목록이다.

소스 데이터 웨어하우스 대상 데이터 웨어하우스
Amazon Redshift Amazon Redshift
Azure 시냅스 분석(10 이상)
Greenplum Database (4.3 이상)
Microsoft SQL Server (2008 이상)
Netezza (7.0.3 이상)
Oracle (10.2 이상)
Teradata (13 이상)
Vertica (7.2 이상)
스노우플레이크 (3이상)

 

AWS SCT툴은 설치형 프로그램으로 UI 인터페이스를 제공하므로 쉽게 설치 작동을 있다. 설치 가능한 운영체제로는 페도라 리눅스, 마이크로소프트 윈도우, 우분투 리눅스 15.04에서 사용할 있으며, 64비트 운영체제에서 실행 가능하다. 다운로드 설치 방법에 관해서는 아래 링크를 참고한다.  (설치 과정에 대한 부분을 포스팅에 다루지 않는 이유는 설치 과정 UI 언제든지 변경 가능성이 있기 때문에 최대한 공식 문서로 안내하고자 한다.)

l  Installing, verifying, and updating AWS SCT : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html

 

아래 그림은 AWS SCT 프로그램 화면에 대한 소개로 자세한 내용은 공식 문서를 참고할 있도록 한다.

 

1.       왼쪽 패널에서 원본 데이터베이스의 스키마가 트리 뷰에 표시되며 항목을 선택하면AWS SCT소스 데이터베이스에서 현재 스키마를 가져오고 표시한다.

2.       상단 가운데 패널에는 대상 데이터베이스 엔진으로 자동으로 변환할 없는 소스 데이터베이스 엔진의 스키마 요소에 대한 작업 항목이 나타난다.

3.       오른쪽 패널에는 대상 DB 인스턴스의 스키마가 트리 보기로 표시되며 트리 뷰에서 항목을 선택할 AWS SCT대상 데이터베이스에서 현재 스키마를 가져오고 표시한다.

4.       왼쪽 하단 패널에서 스키마 요소를 선택하면 등록 정보가 표시된다. 소스 스키마 요소와 소스 데이터베이스에 해당 요소를 만들기 위한 정보를 나타낸다.

5.       오른쪽 하단 패널에서 스키마 요소를 선택하면 등록 정보가 표시된다. 대상 스키마 요소와 대상 데이터베이스에 해당 요소를 만들기 위한 SQL 명령을 나타낸다. SQL 명령을 편집하고 업데이트된 명령을 프로젝트와 함께 저장할 있다.

 

스키마 변환을 완료하면 오른쪽 패널에 제안된 스키마를 있으며 아직까지는 대상 데이터베이스에 스키마가 적용되지 않은 상태이다. 상태에서 스키마를 편집할 있으며 편집된 스키마는 프로젝트 일부로 저장되며 스키마 적용을 하면 대상 데이터베이스에 스키마가 적용된다.

 

변환된 데이터베이스 스키마를 대상 데이터베이스에 적용하려면 아래 그림처럼 [Apply to database] 실행하면 된다.

 

 

AWS SCT 사용할 경우 함수, 매개변수, 로컬 변수 일부 항목은 변환이 지원되지 않으므로 해당 내용은 자세히 확인 추가 작업을 진행할 있도록 한다.

 

Aws SCT 설치형 독립 프로그램이므로 가지 옵션을 조정하여 툴에 대한 성능 조정을 진행할 있다. 예를 들면 툴에서 사용할 메모리의 양을 늘려 성능을 빠르게 수도 있다. 다만 경우 데스크톱의 메모리를 많이 사용하기 때문에 실행되는 컴퓨터 리소스를 확인하여 적절하게 조절하여 사용할 있도록 한다.

AWS SCT에서 사용될 메모리 크기를 조절하는 방법은 AWS Schema Conversion Tool.cfg 파일의 내용을 수정하여 사용한다.

C:\Program Files\AWS Schema Conversion Tool\App\ AWS Schema Conversion Tool.cfg

 

JavaOption항목에서 최소 최대 메모리를 설정한다. 아래 예제는 최소 4GB, 최대 40GB 메모리를 사용하도록 설정한다.

[JavaOptions]
-Xmx48960M
-Xms4096M

 

메모리 설정 외에도 로깅 정보를 상세히 기록할 있다. 다만 경우 로깅 정보가 증가하면서 변환 속도가 약간 느려질 수도 있다. 로깅 설정을 변경하려면 아래와 같은 순서로 진행한다.

1.       setting메뉴에서 Global setting 선택

2.       Global setting 창에서 Logging 선택

3.       Debug 모드에서 True 선택

4.       주요 항목을 선택하여 로깅 정보를 선택한다. 예를 들면 변환 주요 문제에 대한 정보를 기록하기 위해 파서, 매핑 형식, 사용자 인터페이스 추적 등을 로깅할 있다.

 

[참고자료]

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

l  What is the AWS Schema Conversion Tool? : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

l  Installing, verifying, and updating AWS SCT : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html

l  Best practices for the AWS SCT :  https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_BestPractices.html

 

 

 

2022-04-07 / Sungwook Kang / http://sungwookkang.com

 

 

AWS DMS, AWS SCT, Schema Migration, 스키마 변경, 스키마 마이그레이션, 스키마 추출, 스키마 변환

 

[AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기

-          데이터 마이그레이션 매핑 정보를 사용하여 개인 정보 특정 데이터 마스킹 하기

 

l  Version : AWS DMS

 

데이터 저장소 간의 데이터 복제는 평가, 스키마 변환, 데이터 마이그레이션, 데이터 유효성 검사, 데이터 액세스 보안 정책 구현을 포함하는 복잡한 다단계 프로세스이다. 데이터가 데이터 저장소에 걸쳐 복제됨에 따라 대부분의 조직은 개인 식별 정보(PII) 또는 해당 정보에 액세스 해서는 안되는 사용자로부터 상업적으로 민감한 데이터를 보호해야하는 규정 준수 요구 사항이 있다. 이러한 복잡한 단계의 데이터 마이그레이션을 쉽게 있는 클라우드 솔루션으로 AWS DMS (Database Migration Service)라는 서비스가 있다.

 

AWS DMS 관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 기타 유형의 데이터 저장소를 쉽게 마이그레이션할 있는 클라우드 서비스로, 클라우드 뿐만 아니라 온프레미스와 조합도 가능하다. 또한 DMS 사용할 경우 일회성의 데이터 마이그레이션을 포함하여 지속적인 변경사항(Changed Data Capture, CDC) 복제하여 소스와 대상을 동기화할 수도 있다. 그리고 동일한 데이터베이스 이기종 데이터베이스 마이그레이션도 가능하고 AWS KMS (Key Management Service) 암호화 SSL (Secure Socket Layer) 사용하여 소스에서 타겟으로 이동할 데이터를 암화 있다.

l  AWS DMS : https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/Welcome.html

 

 

이번 포스트에서는 Amazon Aurora PostgreSQL 클러스터에서 Amazon Simple Storage Service(Amazon S3) AWS Database Migration Service(AWS DMS) 사용하여 데이터를 복제하면서 데이터 마스킹을 구현하는 방법에 대해서 알아본다. 데이터 마스킹을 사용하면 필드의 데이터를 완전히 제거하는 대신 익명화 있다. AWS DMS 사용하여 데이터 세트를 복제하는 동안 사용자의 민감한 정보에 대한 임의 해시 또는 패턴 기반 대체를 수행할 있다.

 

마스킹 시나리오는, AWS DMS 복제 작업에서 SQLite 표현식 기반 데이터 변환을 사용하여 데이터 복제 중에 사회 보장 번호(SSN) 관련된 데이터 필드를 마스킹 한다. 아래 다이어그램은 AWS  솔루션 아키텍처를 보여준다.

 

AWS DMS 데이터를 대상 엔드포인트로 로드하기 전에 마스킹 하지만 데이터는 여전히 소스 엔드포인트에서 가져와 AWS DMS 복제 인스턴스로 로드한다. AWS DMS 복제 인스턴스를 사용하여 소스 데이터 스토어에 연결하고, 소스 데이터를 읽고, 대상 데이터 스토어에서 사용할 있도록 데이터를 포맷하고, 데이터를 대상 데이터 스토어에 로드 한다. 마스킹은 대상으로 로드하기 전에 복제 인스턴스에서 발생한다. 자세한 시나리오 실습 내용은 아래 링크를 참고한다.

l  Data masking using AWS DMS : https://aws.amazon.com/blogs/database/data-masking-using-aws-dms/

 

 

아래 그림처럼 AWS DMS 콘솔의 Mapping rules 탭에서 사용자 매핑룰을 입력 있다.

 

맵핑룰을 살펴보면 address_book 테이블의 ssn_or_emp_no열에 대해 변환이 설정 되어있다. 필드는 SSN 또는 직원 번호를 가지고 있어, SSN 경우 마스킹이 되고 직원 번호의 경우 마스킹을 하지 않는다. 변환 매핑 규칙에는 glob 연산자(Glob Operator : https://sqlite.org/lang_expr.html

) 사용하여 조건을 지정하여 SSN 패턴과 일치하는 값을 대체하고 내장 hash_sha256 함수를 사용하여 원본 SSN SHA256해시로 대체한다. 그런 다음 변환된 데이터는 대상 데이터 세트의 열인 ssn_or_emp_no_transformed 추가되고 원본 열은 제거 변환 규칙 작업을 통해 복제하는 동안 삭제된다.

 

{
rules”: [
{
rule-type”: “selection”,
rule-id”: “1”,
rule-name”: “1”,
object-locator”: {
schema-name”: “%”,
table-name”: “%”
},
rule-action”: “include”,
filters”: []
},
{
rule-type”: “transformation”,
rule-id”: “2”,
rule-name”: “2”,
rule-target”: “column”,
object-locator”: {
schema-name”: “%”,
table-name”: “address_book”
},
rule-action”: “add-column”,
value”: “ssn_or_emp_no_transformed”,
expression”: “CASE WHEN $ssn_or_emp_no glob ‘[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]’ THEN hash_sha256($ssn_or_emp_no) ELSE $ssn_or_emp_no END”,
data-type”: {
type”: “string”,
length”: 65
}
},
{
rule-type”: “transformation”,
rule-id”: “3”,
rule-name”: “3”,
rule-target”: “column”,
object-locator”: {
schema-name”: “%”,
table-name”: “address_book”,
column-name”: “ssn_or_emp_no”
},
rule-action”: “remove-column”
}
]
}

 

 

AWS DMS 작업이 완료되고 S3에서 결과를 살펴보면, 아래 그림과 같이 SSN 정보에 대해서는 매핑룰에 의해 마스킹 것을 확인할 있다.

 

 

이처럼 AWS DMS 서비스를 사용하면 단순히 데이터 마이그레이션 뿐만 아니라 민감한 정보에 대해서 기반의 변환 규칙을 설정함으로써 마이그레이션 과정에서 데이터 마스킹 또는 암호화를 진행하여 데이터 거버넌스에 대한 요구사항을 충족할 있다.

 

 

[참고자료]

l  https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/Welcome.html

l  https://aws.amazon.com/ko/blogs/korea/aws-database-migration-service/

l  https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Task.CDC.html

l  https://aws.amazon.com/blogs/database/data-masking-using-aws-dms/

l   

 

 

 

2022-04-03 / Sungwook Kang / http://sungwookkang.com

 

 

AWS DMS, Data Masking, Data Migration, 데이터 마스킹, 데이터 마이그레이션, 이기종 데이터 마이그레이션

[AWS S3] AWS S3 Storage Lens

-          S3버킷의 사용량 활동량을 눈에 분석하여 비용절감 전략 세우기  

 

l  Version : AWS S3

 

Amazon S3 Storage Lens 전체 Amazon S3 스토리지에 대한 객체 스토리지 사용량 활동을 한곳에서 있게 해준다. 이러한 서비스를 사용하면 현재 보유하고 있는 S3 많은 버킷에 대해서 얼마나 자주 사용하는지, 그리고 얼만큼의 용량을 사용하는지 쉽게 파악할 있다. 이렇게 수집된 데이터를 활용하면 어떤 객체가 미사용 중인지, 사용량이 객체는 무엇인지 등을 쉽게 분석하여 관리의 편의성 뿐만 아니라 최종적으로는 비용 절감까지의 전략을 세울 있다. S3 Storage Lens에는 조직, 계정, 리전, 버킷 또는 접두사 수준에서 모니터링이 가능하다.

 

l  Amazon S3 Storage Lens 대시보드 생성하기 : https://aws.amazon.com/ko/blogs/korea/s3-storage-lens/

 

S3 Storage Lens 사용량과 활동이라는 가지 유형의 스토리지 지표를 제공한다.

l  사용량 지표는 스토리지의 크기, 수량 특성을 설명한다. 여기에는 저장된 바이트 , 객체 평균 객체 크기가 포함되며, 암호화된 바이트 , 삭제 마커 객체 등의 기능 사용률을 설명하는 지표도 포함된다.

l  활동 지표는 스토리지 요청 빈도에 대한 세부 정보를 설명한다. 여기에는 유형별 요청 , 업로드 다운로드 바이트, 오류 등이 포함된다.

 

S3 Storage Lens 계정 스냅샷은 기본 대시보드의 지표를 요약하여 S3 콘솔 (버킷) 페이지에 스토리지, 객체 평균 객체 크기를 표시한다. 이렇게 하면 버킷 페이지에서 나가지 않고도 스토리지에 대한 정보를 빠르게 확인할 있다. 대시보드를 사용하여 인사이트와 추세를 시각화하고, 이상치에 표시하고, 스토리지 비용 최적화와 데이터 보호 모범 사례 적용을 위한 권장 사항을 수신할 있다.

 

Amazon S3 Storage Lens 사용량 활동 데이터를 Amazon S3 버킷에 CSV 또는 Parquet 형식으로 다운로드할 있도록 지표 내보내기 서비스를 제공한다. 지표 내보내기를 위한 S3 버킷은 S3 Storage Lens 구성과 동일한 리전에 있어야 한다. 대시보드 구성을 편집하거나 AWS CLI SDK 사용하여 S3 콘솔에서 S3 Storage Lens 지표 내보내기를 생성할 있다.

l  AWS CLI 사용한 Amazon S3 Storage Lens 예제 : https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/S3LensCLIExamples.html

l  SDK for Java 사용하는 Amazon S3 Storage Lens 예제 : https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/S3LensJavaExamples.html

 

S3 Storage Lens 가지 특징이 있는데, 간략히 정리하면 아래와 같다.

l  S3 Storage Lens에서 리전당 최대 50개의 대시보드를 생성할 있다.

l  대시보드를 비활성화하면 이상 업데이트되지 않으며, 사용자는 이상 새로운 일일 지표를 수신하지 않는다. 만료 기간 내에 대시보드를 다시 활성화면 데이터를 수신할 있다.

l  대시보드를 삭제하면 모든 대시보드 구성 설정이 손실된다. 사용자는 이상 새로운 일일 지표를 수신하지 않으며 해당 대시보드와 연결된 기록 데이터에도 액세스할 없게 된다.

l  삭제된 대시보드의 기록 데이터에 액세스하려면 동일한 리전에서 동일한 이름의 다른 대시보드를 만들어야 한다.

l  조직 수준의 대시보드는 리전 범위로만 제한할 있다.

 

Amazon S3 Storage Lens 지표는 최대 15개월 동안 보존된다. 무료 지표의 경우 대시보드에는 최대 14 까지의 지표를 표시할 있다. 이렇게 저장된 지표는 과거 추세를 확인하고 시간 경과에 따른 스토리지 사용량과 활동의 차이를 비교할 있다.

Amazon S3 Storage Lens에는 콜아웃이라고 하여 추가 주의나 모니터링이 필요할 있는 기간 동안 스토리지 사용량 활동 내에서 이상 현상에 대해서 알려주는 기능이 있다.

l  이상 콜아웃 : 최근 30 추세를 기반으로 이상인 지표에 대해서 아웃을 제공한다. 이때 표준 점수 계산법을 사용하는데, 현재 날짜의 지표를 기준으로 30 평균에서 지난 30 동안 해당 지표에 대한 표준 편차로 나누어 점수가 +/- 2범위를 벗어나는 경우(정규 분포 95% 보다 높거나 낮음) 이상으로 간주한다.

l  중요한 변경 콜아웃 : 자주 변경되지 않을 것으로 예상되는 지표에 적용하여 전날, 전주 또는 전월과 비교하여 +/-20% 범위에 있을 경우 이상으로 간주한다.

 

아웃을 수신하였다고 하여 반드시 문제가 되는 것은 아니다. 미리 계획된 운영에도 임계치를 초과할 경우 이상으로 판단되기 때문이다. 예를 들어 계획된 작업으로 많은 수의 객체를 추가 또는 삭제한 경우에도 이상으로 감지되어 아웃을 수신할 있다.

콜아웃 외에도, 가장 S3 버킷 식별, 불완전한 멀티파트 업로드 내역, 최신이 아닌 버전 내역,  S3 콜드 버킷 내역 등을 확인하여 불필요한 스토리지 사용을 예방하여 비용을 절약할 있다. 자세한 내용은 아래 스토리지 비용 최적화 부분을 참고 있도록 한다.

l  Amazon S3 Storage Lens 사용한 스토리지 비용 최적화 : https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage-lens-optimize-storage.html

 

 

[참고자료]

l  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html

l  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage_lens.html

l  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage-lens-optimize-storage.html

l  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage_lens_console_creating.html

l  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/S3LensJavaExamples.html

l  https://aws.amazon.com/ko/blogs/korea/s3-storage-lens/

 

 

 

2022-03-28 / Sungwook Kang / http://sungwookkang.com

 

 

AWS S3, S3 Storage Lens, 스토리지 비용 최적화, S3 버킷 사용량 모니터링, S3 비용 최적화, S3 관리

[AWS MySQL] AWS JDBC Driver for MySQL

-          AWS JDBC 드라이버를 사용하여 장애조치 시간 단축하기

 

l  Version : AWS MySQL, Aurora

 

 

Amazon Web Service (AWS) JDBC Driver for MySQL 사용하면 애플리케이션에서 클러스터된 MySQL 데이터베이스의 기능을 활용할 있다. AWS JDBC Driver for MySQL 오픈소스 MySQL JDBC Connector 기반으로 제작되었기 때문에 호환 가능하다.

l  mysql-connector-j : https://github.com/mysql/mysql-connector-j

l  aws-mysql-jdbc : https://github.com/awslabs/aws-mysql-jdbc

 

MySQL AWS JDBC Driver MySQL 호환되는 Amazon Aurora 대해서도 빠른 장애 조치를 지원한다. Amazon RDS for MySQL 온프레미스 MySQL 배포 기능을 포함하여 클러스터형 데이터베이스 추가 기능에 대한 지원이 계획되어 있다.

 

Amazon Aurora에서 장애 조치는 기본 DB 인스턴스를 사용할 없을 데이터베이스가 클러스터 상태를 자동으로 복구하는 메커니즘이다. 클러스터가 기본 쓰기-읽기 DB 인스턴스에 최대 가용성을 제공할 있도록 데이터베이스 복제본을 새로운 기본 DB 인스턴스로 선택하여 이를 달성한다. 복제본 인스턴스를 기본 DB 인스턴스 역할로 승격하려면 먼저 연결을 올바르게 지정하기 위해 DNS 레코드를 업데이트해야 한다. 프로세스는 최대 분이 소요될 있다.

 

MySQL AWS JDBC Driver 가동 중지 시간을 최소화하기 위해 동작을 최적화하여 설계되었다. MySQL 클러스터 토폴로지의 캐시와 인스턴스의 역할(복제본 또는 기본 DB 인스턴스) 유지함으로써 이를 달성한다. 토폴로지는 MySQL 데이터베이스에 대한 직접 쿼리를 통해 제공되어 DNS 확인으로 인한 지연을 우회하는 지름길을 제공한다. 이를 바탕으로 MySQL AWS JDBC Driver 데이터베이스 클러스터 상태를 보다 면밀히 모니터링하여 새로운 기본 DB 인스턴스에 대한 연결을 최대한 빨리 설정할 있다.

 

MySQL AWS JDBC Driver에는 연결 플러그인 관리자도 있다. 플러그인 관리자를 사용하면 개발자는 주요 드라이버 기능을 그대로 유지하면서 유연한 방식으로 드라이버 기능을 확장할 있다. 연결 플러그인 관리자는 연결에 대한 초기화, 트리거 연결 체인을 정리한다. 연결 플러그인은 해당 연결과 관련된 추가 또는 보완 논리를 실행하는 도움이 되도록 연결 개체에 연결된 위젯이다. Enhanced Failure Monitoring 기능은 연결 플러그인 하나이다. 아래 그림은 연결 플러그인 관리자의 간소화된 워크플로를 보여준다.

드라이버가 JDBC 메소드를 실행할 때마다 연결 플러그인 관리자로 전달된다. Connection Plugin Manager에서 JDBC 메소드가 Plugin 순서대로 전달되어 체인처럼 로드 된다. 예제에서는 메서드는 먼저 Custom Plugin A 전달되고, 다음으로 Custom Plugin B 전달되고, 마지막으로 Default Plugin으로 전달된다. 플러그인은 JDBC 메소드를 실행하고 체인을 통해 결과를 다시 반환한다.

 

Enhanced Failure Monitoring 모니터 스레드에 의해 구현된 연결 플러그인으로 MySQL AWS JDBC Driver 향상된 장애 조치를 지원한다. 모니터는 연결된 데이터베이스 노드의 상태를 주기적으로 확인한다. 데이터베이스 노드가 비정상인 것으로 확인되면 데이터베이스 노드로 쿼리가 재시도되고 모니터가 다시 시작된다. 기본적으로 Enhanced Failure Monitoring 플러그인이 로드 된다. 그러나 Amazon RDS Proxy 사용하는 경우에는 향상된 장애 조치가 필요하지 않으며 RDS Proxy드라이버가 처리한다.

 

아래 표는 Aurora MySQL 5.7(2.10.0) 사용하여 AWS JDBC Driver for MySQL MariaDB Connector/J(Aurora 인식하도록 구성됨) 간의 장애 조치 시간을 벤치마킹한 결과이다. 데이터베이스에 연결되고 1초마다 테이블에 대해 쿼리를 실행하는 간단한 Java 앱을 실행한다음 Amazon RDS 콘솔을 통해 기본 데이터베이스에 장애 조치 명령이 실행되었다. 경우 모두 드라이버가 복제본에 자동으로 다시 연결되었지만 MySQL AWS JDBC Driver 오류를 인식하고 연결하는데 훨씬 빠르게 동작하였다.

 

벤치 마크 결과를 살펴보면 AWS JDBC Driver for MySQL 오류 감지에 평균 2, 복제본에 연결에 평균2초를 수행하여 최종 읽기까지의 중단 시간은 4초가 소요되었다.

MySQL 5.7 AWS JDBC Driver for MySQL MariaDB Connector/J Driver
Average Client Failure Detection 2 seconds 19 seconds
Average Reconnect Time 2 seconds 18 seconds
Total Reconnect Time 4 seconds 37 seconds

 

 

AWS JDBC 드라이버를 RDS Proxy 함께 사용할 주의해야할 부분이 있다. Enhanced Failure Monitoring 플러그인이 포함된 MySQL AWS JDBC Driver 함께 RDS Proxy 엔드포인트를 함께 사용할 경우 심각한 문제가 발생하지는 않지만 함께 사용을 권장하지는 않는다. 이유는 RDS Proxy 드라이버 요청을 데이터베이스 인스턴스 하나로 투명하게 다시 라우팅하기 때문이다. RDS Proxy 여러 기준에 따라 어떤 데이터베이스 인스턴스가 사용되는지를 결정한다. 이러한 결정 전환은 인스턴스 상태 모니터링 측면에서 플러그인을 쓸모 없게 만든다. 플러그인은 연결된 실제 인스턴스와 모니터링 중인 인스턴스를 식별할 없기 때문에 오류 감지에 대해서 오탐지의 원인이 있다. 동시에 플러그인은 여전히 ​​RDS Proxy 엔드포인트에 대한 네트워크 연결을 사전에 모니터링하고 중단이 발생할 경우 사용자 애플리케이션에 다시 보고할 있기 때문이다. 따라서 Enhanced Failure Monitoring 플러그인을 사용할 때에는 RDS Proxy 엔드포인트를 사용하지 않는 것이 좋다.

 

 

[참고자료]

l  https://awslabs.github.io/aws-mysql-jdbc/

l  https://aws.amazon.com/blogs/database/improve-application-availability-with-the-aws-jdbc-driver-for-amazon-aurora-mysql/

l  https://github.com/awslabs/aws-mysql-jdbc#the-aws-jdbc-driver-failover-process

 

 

 

2022-03-27 / Sungwook Kang / http://sungwookkang.com

 

 

AWS JDBC Driver, MySQL Connector, AWS JDBC, MySQL Failover, 장애조치, AWS 장애조치

+ Recent posts