Data Science Lab

[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초가 소요되었다.

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 장애조치

[AWS] What is AWS Graviton processor?

l  Version : Amazon Web Service

이번 포스트는 AWS에서 출시하여 제공하고 있는 AWS Graviton 프로세서가 무엇인지 알아본다. Graviton 프로세서에 대한 성능 및 기존 X86 프로세서와의 벤치마크 등은 다른 자료를 참고할 수 있도록 한다.

AWS Graviton은 Amazon EC2(Elastic Compute Cloud) 가상 머신 인스턴스 고객을 위해 ARM 아키텍처를 기반으로 AWS에서 2018년 출시한 서버 프로세서이다.  AWS Graviton 1 프로세서는 맞춤형 실리콘과 64비트 Neoverse 코어를 특징으로 한다. 2020년 AWS Graviton2 프로세서를 출시했고. 2021년, re:Invent 컨퍼런스에서 Graviton3 프로세서를 발표했다.

l  ARM architecture family : https://en.wikipedia.org/wiki/ARM_architecture_family

Graviton2는 무엇일까?

AWS Graviton2 프로세서는 7nm 공정에서 제작된 맞춤형 프로세서로, Arm의 새로운 Neoverse N1 코어 기반으로 한다. Graviton2은 64개의 코어와 2.5GHz 클럭으로 동작하고, 이들은 2TB/s 메시 아키텍처로 연결된다. L3캐시는 32MB로 구성되어 있다. 이 시스템의 메모리 채널은 8채널 DDR4-3200 메모리 컨트롤러로 지원되며 PCIe4 64개를 지원한다.

Amazon Graviton2 : FIRST NEOVERSE N1 Chip

l  Neoverse N1 - Microarchitectures – ARM : https://en.wikichip.org/wiki/arm_holdings/microarchitectures/neoverse_n1

AWS가 Graviton 프로세스를 만든 이유는 무엇일까?

2020년 말에 AWS의 EC2 부사장인 David Brown은 흥미로운 관점을 밝혔다. 그는 크든 작든 엄청난 수의 Amazon EC2 고객이 EC2 용량을 간신히 사용하고 있다고 말했다. 그는 고객의 의견을 경청한 후 AWS는 여러 가지 이유로 서버용으로 X86-64 프로세서 제품군에서 전환했다.

AWS 요구사항 :

l  EC2 인스턴스 선택에 있어 고객에게 더 많은 선택권 제공

l  웹 서버와 같은 ARM 기반 애플리케이션 대상

l  가상화 비용을 줄이면서 고가용성 및 보안 제공

l  고객을 위한 저렴한 가격으로 적절한 서버 성능 조정

AWS는 위 요구사항 외에도 혁신을 위해 Intel과 AMD에 의존하기 보다 AWS가 작동하는 방식으로 작동하도록 구축된 사내 서버 프로세서 제품군을 필요했다.

AWS Graviton 프로세서는 좋은가?

일부 서클에서는 1세대 AWS Graviton 프로세서가 당시 AMD 및 Intel 프로세서에 비해 취급을 못 받을 것이라 했다. 그러나 시간이 지남에 따라 프로세서는 서버용 X86 기반 프로세서보다 약간 더 나은 것으로 판명되었다. 예를 들어 ARM 프로세서는 X86코어에 비해 전력 소비가 낮다. 이는 AWS가 추구해온 제안 중 하나이므로 궁극적으로 EC2의 요금까지 절감할 수 있게 되었다.

AWS Graviton Vs Graviton2 프로세서 차이점은 무엇일까?

출시 당시 AWS는 Graviton2는 X86 프로세서 보다 40%, AWS Graviton1 프로세서 보다 7배 더 나은 가격대비 성능을 제공한다고 발표했다. 또한 차세대 프로세서는 Graviton1 프로세서보다 4배 더 빠른 컴퓨팅 코어, 5배 더 빠른 메모리, 2 배 더 큰 캐시를 제공한다. 또한 AWS는 Graviton2를 통해 개발자가 안전하고 대규모로 실행할 수 있는 클라우드 네이티브 앱을 만들 수 있도록 몇 가지 주요 개선사항을 만들었다. 여기에는 항상 활성화 되어 있는 256비트 DRAM 암호화가 포함된다.

아래는 Graviton1 프로세서와 Graviton2 프로세서의 차이점에 대해서 살펴본다.

1.       스토리지

AWS Graviton1은 이미지, 비디오 및 분석 데이터와 같은 웹 서비스를 호스팅하는데 유용한 간단한 스토리지를 제공한다. 저장된 데이터에 원격으로 더 쉽게 액세스할 수 있게 해주는 객체 수준 데이터 스토리지 서비스를 제공한다. 이에 비해 Graviton2는 일반적으로 블록이라고 하는 여러 값으로 파일을 저장하는데 도움이 되는 블록 수준 저장소를 제공한다. 블록은 또한 인터넷 연결을 통해 원격으로 쉽게 액세스 할 수 없도록 하여 데이터를 보호한다.

2.       정보 접근성

AWS Graviton1은 데이터를 클러스터 되지 않은 형식으로 저장하므로 쉽게 데이터에 액세스 할 수 있다. HTTP 프로토콜을 사용하여 데이터를 검색할 수 있다. Graviton2는 오직 Attached연결에서만 액세스 할 수 있는 형식으로 데이터를 저장한다.

3.       가용성

AWS Graviton1은 API를 사용하여 인터넷을 통해 사용할 수 있다. Graviton2는 하드웨어 프로세서에 연결된 단일 인스턴스에서 사용할 수 있다.

4.       내구성

AWS Graviton1은 여러 가용 영역에 데이터를 저장하여 내구성을 제공하는 반면, Graviton2는 단일 가용 영역에서만 데이터를 저장한다.

5.       용도

Graviton2는 EC2인스턴스 외에도 Amazon ElastiCache, Amazon RDS 및 Amazon EKS(컨테이너 서비스)실행에도 사용할 수 있다.

언제 AWS Graviton 프로세서를 사용하면 좋을까?

웹 서버, 로그 처리, 비디오 인코딩, 전자 설계 자동화 및 CPU 인터페이스 기반의 기계 학습에 AWS Graviton1 및 Graviton2를 사용한다. 현재 X86기반 서버를 사용하는 경우 Arm 아키텍처에서 실행되도록 애플리케이션을 다시 설계해야 한다.

AWS Graviton을 사용하면 어떤 이점이 있을까?

AWS Graviton의 가장 중요한 이점은 비용 절감, 짧은 지연 시간, 향상된 확장성, 향상된 가용성 및 보안이다.

1.       비용 효율적

프로세서 제품군은 Arm 아키텍처 기반으로 한다. 즉 SoC(System On Chip)일 가능성이 높다. 이 뜻은 만족스러운 성능을 제공하는 동시에 전력 소비 비용을 낮출 수 있는 것으로 해석할 수 있다.

2.       생태계 지원

AWS Graviton1 및 Graviton2는 64비트 Arm Neoverse 코어 아키텍처를 기반으로 하기 때문에 여러 Linux 기반 운영체제가 이 구성을 지원한다. 여기에는 Amazon Linux 2, SUSE 및 Red Hat이 포함된다. 이는 고객에게 더 많은 선택권을 제공한다.

3.       효율적인 CPU 전력

AWS Graviton 프로세서는 전통적인 아키텍처보다 최대 3.45% 더 높은 성능을 제공한다. 또한 X86 프로세서보다 더 간단한 프로세서 구현을 제공한다.

4.       범용 구축

AWS Graviton 코어는 서버, 중간 규모 데이터 저장 프로세스, 마이크로 서비스 및 클러스터 컴퓨팅의 효울성을 개선하도록 구축되었다.

5.       버스트 가능한 워크로드 제공

확장 가능한 마이크로 서비스, 중소 규모 데이터베이스 서비스, 가상 데스크톱, 중요한 비즈니스에 적합한 애플리케이션 선택과 같은 광범위한 부분에서 버스트 가능한 워크로드 서비스 세트를 사용자에게 제공한다.

6.       컴퓨터 집약적 모델을 기반으로 구축

프로세서는 HD 비디오 성능 컴퓨팅, 비디오 인코딩, 게임 및 CPU 기반 컴퓨터 학습 프로세스와 같은 컴퓨터 집약적 모델을 기반으로 한다.

7.       향상된 네트워킹 제공

EFO(Elastic Fabric Operator)의 100Gbps 네트워킹 기능을 제공한다.

[참고자료]

l  https://www.cloudzero.com/blog/aws-graviton

l  https://techcrunch.com/2021/11/30/aws-launches-its-graviton-3-processor/

l  https://www.techrepublic.com/article/faq-what-arm-servers-on-aws-mean-for-your-cloud-and-data-center-strategy/

l  https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd

l  https://en.wikichip.org/wiki/arm_holdings/microarchitectures/neoverse_n1

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

AWS Graviton, AWS 그라비톤, ARM CPU, AWS ARM

[AWS RDS] RDS Proxy

-          커넥션풀을 관리하여 RDS에서 발생할 수 있는 연결 오류 및 오버헤드 방지

l  Version : Amazon RDS

AWS Relational Database Service(RDS)는 관리형 데이터베이스 서비스이다. RDS는 제한된 수의 커넥션 연결만 허용하는데 최근 애플리케이션의 패턴이 발전하고, 특히 서버리스 애플리케이션 에서는 많은 수의 DB 커넥션을 발생시킨다. 이렇게 제한된 숫자 이상의 커넥션 연결을 요청하게 되면 데이터베이스는 커넥션 연결 오류가 발생하고 애플리케이션은 정상적인 서비스 제공이 불가능하게 된다. 이러한 문제점을 해결하기 위해서 RDS Proxy(프록시)를 사용할 수 있다.

RDS 프록시는 다른 프록시 서비스와 유사하게 작동한다. 기본적으로 미들웨어 역할을 하여 RDS 데이터베이스 인스턴스와 Amazon Aurora 데이터베이스 클러스터로 들어오는 네트워크 트래픽을 구성한다.

RDS Proxy는 일반 프록시보다 훨씬 더 많은 기능을 제공한다. RDS 데이터베이스를 위해 특별히 설계되었으며 데이터베이스 프로토콜, 요청 및 응답 처리, 데이터베이스에서 클라이언트 애플리케이션으로 다시 푸시한 결과를 인식하는 기능이 있다.

RDS 프록시는 DB 연결을 풀링 및 공유하여 작동하므로 애플리케이션의 확장성과 데이터베이스 오류에 대한 탄력성을 높인다. RDS 프록시 사용의 주요 이점은 아래와 같다.

l  연결 풀링 및 연결 공유를 사용하여 열려 있는 데이터베이스 연결 수를 줄여 애플리케이션 성능 향상

l  데이터베이스가 애플리케이션 연결을 처리하기 위한 CPU및 메모리 절약

l  데이터베이스 장애조치(failover)와 같은 오류 시나리오 동안 애플리케이션 가용성을 개선

l  TLS/SSL 및 AWS IAM을 포함한 모든 RDS 보안 기능을 사용하여 애플리케이션 코드에서 데이터베이스 연결에 대한 자격증명 불필요

l  RDS Proxy에서 사용하는 리소스는 RDS 데이터베이스용으로 프로비저닝된 리소스와 독립적이므로 데이터베이스에 대한 추가 오버헤드를 발생시키지 않음

보안 측면에서 장점을 조금 더 설명하면, AWS Secrets Manager와도 작동한다. 더 이상 데이터베이스 자격 증명을 노출하거나 어떤 방식으로든 하드 코딩할 필요가 없다. 따라서 RDS Proxy가 Secrets Manager와 함께 작동하도록 구성하면 더 엄격한 보안 정책을 시행할 수 있다. 예를 들어 TLS를 활성화하려면 유효한 인증서를 AWS Certificate Manager에 추가한 다음 이를 사용하도록 RDS 프록시를 구성하기만 하면 된다. 구성이 –ssl-mode를 지원하기 때문에 종단 간 통신에 SSL 사용을 시행하는 것도 편리하다.

RDS 프록시를 모니터링하는 방법으로는 Amazon CloudWatch를 사용하여 모니터링할 수 있다. CloudWatch는 RDS 프록시와 잘 통합되어 프록시의 성능과 동작을 이해하는 데 사용할 수 있는 유용한 지표를 제공한다. 아래 목록은 모니터링에 사용되는 주요 지표들이다.

l  DatabaseConnections: 백엔드 데이터베이스에 대한 데이터베이스 연결 수

l  DatabaseConnectionsCurrentlyBorrowed: 현재 애플리케이션에서 사용 중인 연결 수. 이 지표에 대한 알림을 설정하여 빠르게 알림을 받을 수 있도록 한다.

l  DatabaseConnectionsCurrentlySessionPinned: 고정 상태의 연결 수. 이 숫자는 RDS 프록시 성능을 최대화하려면 이상적으로는 가능한 한 낮아야 한다.

CloudWatch를 사용한 RDS Proxy 모니터링에 관한 자세한 내용은 아래 링크를 참고 한다.

l  Monitoring RDS Proxy metrics with Amazon CloudWatch : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.monitoring.html

RDS 프록시에 대한 몇 가지 주요 제한 사항으로는 아래와 같이 정리할 수 있다.

l  RDS 프록시는 데이터베이스 인스턴스와 동일한 VPC에 있어야 한다. 데이터베이스 인스턴스가 있는 경우에도 프록시에 공개적으로 액세스할 수 없다.

l  RDS 프록시는 자체 관리형 EC2 인스턴스 기반 데이터베이스와 함께 사용할 수 없다.

l  RDS 프록시는 아직 Aurora Serverless에 사용할 수 없다. 현재  Aurora MySQL, Aurora PostgreSQL, RDS MySQL, RDS PostgreSQL 에서 사용할 수 있다.

l  프록시는 1개의 데이터베이스 인스턴스에만 연결할 수 있다.

RDS Proxy를 구성하는 방법으로는 아래 링크를 참고하여 실습할 수 있다.

l  AWS RDS Proxy를 사용한 공유 데이터베이스 연결 설정 : https://aws.amazon.com/ko/getting-started/hands-on/set-up-shared-database-connection-amazon-rds-proxy/

[참고자료]

l  https://aws.amazon.com/ko/getting-started/hands-on/set-up-shared-database-connection-amazon-rds-proxy/

l  https://aws.amazon.com/rds/proxy/

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html

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

AWS RDS, RDS Proxy, 아마존 프록시, DB Pooling, DB Connection

[AWS RDS] Modify RDS instance type

-          AWS RDS 인스턴스 타입 변경 (업그레이드 또는 다운그레이드)

l  Version : Amazon RDS

AWS RDS 환경에서는 운영중인 RDS 인스턴스의 용량 증설 및 감소(Scale-Up / Scale-Down) 작업을 Management Console을 통해서 매우 간단하게 변경할 수 있다. 아래 순서에 따라 인스턴스를 변경할 수 있다.

1.       변경할 인스턴스를 선택하고 Modify버튼을 클릭한다.

2.       DB Instance size 항목에서 변경할 인스턴스 타입을 선택 한다. 이 글에서는 db.r5.large 인스턴스를 db.t3.medium으로 다운그레이드 한다.

3.맨 아래 위치한 Continue 버튼을 클릭한다.

4. 변경하려는 인스턴스 타입을 다시 한번 확인하고, Scheduling of modifications 항목에서 정해진 시간에 수정사항을 적용할 것인지, 아니면 즉시 적용할 것인지 선택 한다. 이 글에서는 즉시 변경 (Apply immediately)를 선택한다.

5. 인스턴스가 수정되고 있는 상황을 확인할 수 있다.

즉시 변경을 선택하였더라도 인스턴스의 종류, 백업할 데이터 양에 따라 수초에서 수분이 걸릴 수 있다. 따라서 일정 시간 다운타임이 발생한다. 하지만 이러한 다운타임은 예방하기 위해서는 데이터베이스를 이중화 구성하여 롤링 업그레이드 방식을 통해서 하나씩 업그레이드 하면서 failover로 역할을 변경하면 다운타임을 예방할 수 있다.

높은 성능의 인스턴스에서 낮은 성능의 인스턴스로 변경할 때 간혹 아래와 같은 오류가 발생할 수 있다.

이때에는 Performance Insights 항목에서 Enable Performance Insights 항목을 선택해제하고, 적용한 후 인스턴스 타입을 변경할 수 있도록 한다. 이번 실습에서 db.r5.large에서 db.t3.medium으로 먼저 선택하면 해당 항목이 숨겨져서 보이지 않게 되는데, 실제 변경시에는 오류를 반환한다.

[참고자료]

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

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

AWS RDS, SQL Server, RDS 인스턴스 타입 변경, Modify RDS Instance type