[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결

 

l  Version : AWS EBS

 

AWS EC2에는 여러 개의 EBS 볼륨 스토리지를 연결하여 데이터를 있다. 그렇다면 반대로 하나의 EBS 볼륨에 여러 개의 EC2 인스턴스를 연결할 수는 없을까? 결로부터 말하자면 가능하다.

 

 

Amazon EBS 다중 연결을 사용하면 단일 프로비저닝된 IOPS SSD(io1, io2) 볼륨을 동일한 가용 영역에 있는 여러 인스턴스에 연결할 있다. 볼륨이 연결된 인스턴스는 공유된 볼륨에 대한 전체 읽기 쓰기 권한을 가진다. 다중 연결을 사용하면 동시 쓰기 작업을 관리하는 클러스터링 Linux 애플리케이션에서 쉽게 높은 애플리케이션 가용성을 얻을 있다. 다중 연결 지원 볼륨은 다른 Amazon EBS 볼륨을 관리하는 것과 거의 동일한 방식으로 관리할 있으며 연결을 만들  기능을 활성화 해야 한다.

 

하지만 다중 연결에 대한 일부 제약사항이 있다.

l  다중 연결 지원 볼륨은 최대 16개의 Nitro 시스템 기반 Linux 연결할 있다.

l  다중 연결 지원 볼륨은 Windows에서도 사용은 가능하지만 인스턴스 간에 공유되는 볼륨의 데이터를 인식하지 못해 데이터 불일치가 발생할 있다.

l  XFS EXT4 같은 표준 파일 시스템은 EC2 인스턴스와 같은 여러 서버에서 동시에 액세스 하도록 설계되지 않았다. 따라서 표준 파일 시스템에서 다중 연결을 사용하면 데이터가 손상될 가능성이 있기 때문에 프로덕션의 안정성을 보장할 없다.

l  다중 연결 지원 볼륨은 I/O 차단 기능을 제공하지 않아 일관성을 유지하기 위해 공유된 스토리지 환경에서 쓰기 액세스를 제어 해야한다. 애플리케이션은 데이터 일관성 유지하기 위해 연결된 인스턴스에 쓰기 순서를 제공해야 한다.

l  다중 연결 지원 볼륨은 부팅 볼륨으로 만들 없다.

l  다중 연결 지원 볼륨은 인스턴스당 하나의 블록 디바이스 매핑에 연결할 있다.

l  인스턴스 시작중에는 Amazon EC2 콘솔 또는 RunInstnace API 사용하여 다중 연결을 활성화 없다.

l  Amazon EBS 인프라 계층에 문제가 있는 다중 연결 지원 볼륨은 연결된 모든 인스턴스에서 사용할 없다.

l  Amazon EC2 또는 네트워킹에 문제가 있는 경우 연결된 일부만 영향을 받을 있다.

 

 

 

[참고자료]

l  https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

 

 

 

2022-06-17 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, EBS, 다중 연결 지원 볼륨, EC2

[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상

 

l  Version : AWS Aurora MySQL 2.10 later

 

Binlog 복제는 소스 데이터베이스에서 트랜잭션 작업 오프로드, 분석을 실행하기 위한 별도의 전용 시스템으로 변경 사항 복제, 다른 시스템으로 데이터 스트리밍을 포함하여 여러 사용 사례를 제공하는 인기 있는 기능 이지만 무료(기능에 따른 오버헤드 비용으로 해석) 제공되지 않는다.

 

바이너리 로깅은 binlog 이벤트에 대한 로깅이 트랜잭션 커밋의 중요한 경로의 일부로 통합되기 대문에 데이터베이스에 오버헤드가 발생할 있다. 뜻은 높은 커밋 대기 시간 낮은 처리량으로 해석할 있다. MySQL 엔진은 추가 정보(binlog 이벤트) binlog 파일에 쓰기 시작한다. 일반적으로 binlog 파일은 로컬 스토리지에 기록 되지만 Aurora MySQL-Compatible Edition 이러한 binlog 파일을 Aurora 스토리지 엔진에 기록 한다. Binlog 파일은 MySQL binlog 이벤트를 binlog 파일에 기록 뿐만 아니라 동일한 파일에서 binlog 이벤트를 읽기 때문에 MySQL 이러한 binlog 이벤트를 다른 MySQL 데이터베이스에 복제하기 시작할 성능 병목 현상이 있다.

 

Aurora MySQL 2.10 릴리스에서는 사용 사례를 개선하기 위해  binlog I/O 캐시라는 새로운 기능이 도입되었다. 사용 사례에서는 Aurora MySQL 바이너리 로깅을 켜고 binglog 이벤트를 동일한 파일에 적극적으로 복제한다. 이번 포스트에서는 새로운 binlog I/O 캐시의 성능 향상 관련 모니터링 메트릭과 상태 변수에 대해 알아 본다.

 

Binlog I/O 캐시는 순환 캐시에 가장 최근의 binlog 이벤트를 유지하여 Aurora 스토리지 엔진의 읽기 I/O 최소화 한다.  Binlog I/O 캐시는 db.t2, db.t3 인스턴스를 제외한 대부분의 Aurora MySQL 인스턴스에 대해 활성화 된다. 아래 그래프는 binlog I/O 캐시를 활성(파란선), 비활성(주황선) 했을때 초당 평균 쓰기를 측정한 결과이다. 그래프를 통해서  binlog I/O 캐시로 얻을 있는 처리량 향상 정도를 확인할 있다.

 

그래프에서 읽기 전용 복제본의 I/O 경합 없이 최적의 성능을 보여주는 복제본 없음설정(회색선) 처리량도 표시했다. 그림을 보면 binlog I/O 캐시가 활성화 경우 쓰기 처리량 증가(파란색) 따라 원본 인스턴스가 연결된 복제본이 없는 것처럼 (회식) 최적의 쓰기 처리량으로 확장될 있음을 보여준다.

 

Binlog I/O 캐시를 출시하기 전에 aurora_binlog_replication_max_yield_seconds 매개변수를 사용하여 관련 binlog 성능 향상을 구현했으며, 이는 MySQL 5.7(2.04.5 later) 5.6(1.17.6)에서 출시 되었다. 매개변수는 binlog 덤프 스레드가 “aurora_bin_log_replication_max_yield_seconds” 초까지 기다리도록 지시한다. 덤프 스레드의 이러한 양보(yield)” 통해 binlog 기록기 스레드는 binlog 덤프 스레드와의 경합없이 활성 binlog 파일에 있지만 잠재적으로 높은 복제 지연이 발생할 있다. Binlog I/O 캐시를 사용하기 위해서는 추가 구성이 필요하지 않지만 기능을 최대한 활용하려면 기존 최대 산출량 기능인 aurora_bin_log_replication_max_yield_seconds 다시 0으로 재설정 하는 것이 좋다.

 

Binlog I/O cache 대한 모니터링을 위해 두가지 상태 변수(aurora_binlog_io_cache_reads, aurora_binlog_io_cache_read_requests) 새로운 로그인 dump thread metrics 도입되었다. aurora_binlog_io_cache_read_requests 변수는 binlog 파일에 대한 읽기 I/O수를 보여주고  aurora_binlog_io_cache_reads 캐시에서 읽을 있는 읽기 I/O 수를 보여준다. 아래 코드는 binlog I/O 캐시의 적중률을 구하는 예제이다.

mysql> SELECT(SELECT VARIABLE_VALUE
              FROM INFORMATION_SCHEMA.GLOBAL_STATUS
              WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')/
             (SELECT VARIABLE_VALUE
              FROM INFORMATION_SCHEMA.GLOBAL_STATUS
              WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')*100
              as binlog_io_cache_hit_ratio;
 
+-------------------------+
| binlog_io_cache_hit_ratio |
+-------------------------+
|       99.99847949080622 |
+-------------------------+
1 row in set, 2 warnings (0.00 sec)

 

또한 소스에서 작성된 최신 binlog 이벤트에서 binlog 복제본의 거리(바이트) 모니터링할 있다. 정보는 원본에서 가져온 복제본을 읽은 최신 binlog이벤트가 binlog I/O 캐시에서 제공되는지 여부를 분석할 있기 때문에 중요하다. 검색 키워드 “dump thread metric” 사용하여 메트릭을 필터링 있다. “dump thread”라는 이름은 MySQL 문서의 binary log dump thread에서 차용했다. 지표는 복제본이 소스 인스턴스에 연결될 기록되며 1분마다 내보낸다. Aurora MySQL log_error_verbosity 기본값인 3 경우에만 메시지를 생성한다. Log_error_verbosity값은 Aurora MySQL DB 파라미터 그룹 또는 DB 클러스터 파라미터 그룹을 통해 구성할 있다.

 

 

[참고자료]

l  https://aws.amazon.com/ko/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/

 

 

2022-05-11 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Aurora, binlog, Binlog I/O cache, Aurora performance, Aurora replication

[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리

 

l  Version : AWS Elastic Compute Cloud

 

클라우드 서비스의 여러 장점 하나는 다양한 지역에 서비스를 배포하고 원하는 지역에서 빠르게 서비스를 제공할 있는 것이다. Amazon EC2 세계 각지의 여러 곳에서 호스팅 되고 있으며 위치는 리전, 가용 영역, Local Zone, AWS Outposts Wavelength Zone으로 구성된다. 이번 포스트는 이러한 구성에 따른 개념 특징을 정리해 본다.

 

리전(Region)

AWS에는 리전이라는 개념이 있다. AWS 세계에서 데이터 센터를 클러스터링하는 물리적 위치를 리전이라고 한다. 논리적 데이터 센터의 그룹을 가용 영역이라고 하는데, AWS 리전은 지리적 영역 내에서 격리되고 물리적으로 분리된 여러 개의 AZ 구성된다. AZ 독립된 전원, 냉각 물리적 보안을 갖추고 있으며 지연 시간이 매우 짧은 중복 네트워크를 통해 연결된다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

AWS 북미, 남미, 유럽, 중국, 아시아 태평양, 남아프리카 중동의 리전을 포함하여 여러 지리적 리전을 유지 관리하고 있다. 리전은 추가 또는 변경될 있으므로 최신의 리전 정보는 아래 링크를 참고 한다.

l  리전 엣지 네트워크 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

 

글을 쓰는 현재, 세계 26개의 지리적 리전에 84개의 가용 영역을 운영하고 있으며, 호주, 캐나다, 인도, 이스라엘, 뉴질랜드, 스페인, 스위스 아랍에미리트(UAE) 8개의 리전과 24개의 가용영역을 추가할 계획이다.

 

일부 정부기관 중국의 경우 리전 제약이 있으므로 공식 문서를 반드시 확인할 있도록 한다.

 

가용 영역 (Availability Zone)

AZ(가용 영역) AWS 리전의 이중화 전력, 네트워킹 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성된다. AWS 리전의 모든 AZ 높은 대역폭, 지연 시간이 짧은 네트워킹, 완전한 이중화를 갖춘 전용 메트로 네트워크와 상호 연결되어 있어 AZ 간에 높은 처리량과 지연 시간이 짧은 네트워킹을 제공한다. 네트워크 성능은 AZ 동기 복제 기능을 충분히 수행할 있으며 AZ 간의 모든 트래픽은 암호화된다. AZ 다른 모든 AZ 킬로미터에 상당하는 유의미한 거리를 두고 물리적으로 분리되어 있다. 다만 모든 AZ 서로 100km(60마일) 이내의 거리에 위치한다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

 

AWS Local Zone

AWS 로컬 영역은 컴퓨팅, 스토리지, 데이터베이스 기타 셀렉트 AWS 서비스를 최종 사용자에게 가까운 위치에서 실행할 있게 한다. , 주요 리전이 없는 전략적 위치에 소규모 데이터 센터( AWS Outposts 설계 기반) 구축하여 범위를 확장한다. AWS 로컬 영역을 사용하면 미디어 엔터테인먼트 콘텐츠 작성, 실시간 게임, 저장소 시뮬레이션, 전자 설계 자동화, 기계 학습과 같이 지연 시간이 10밀리초 미만이어야 하는 매우 까다로운 애플리케이션을 쉽게 실행할 있다.

 

AWS 로컬 영역 위치는 최종 사용자에게 근접한 지역에서 Amazon Elastic Compute Cloud, Amazon Virtual Private Cloud, Amazon Elastic Block Store, Amazon File Storage, Amazon Elastic Load Balancing 등의 AWS 서비스를 사용하여 지연 시간에 민감한 애플리케이션을 실행할 있는 AWS 리전의 확장이다. AWS 로컬 영역은 로컬 워크로드와 AWS 리전에서 실행 중인 워크로드 간의 고대역폭 보안 연결을 제공하여 동일한 API 도구 세트를 통해 전체 리전 서비스에 원활하게 다시 연결할 있게 한다.

 

AWS Wavelength

AWS Wavelength 사용하면 개발자가 모바일 디바이스 최종 사용자 측에서 발생하는 지연 시간이 10밀리초 미만인 애플리케이션을 제작할 있다. AWS 개발자는 이동 통신 사업자 데이터 센터 내의 5G 네트워크 엣지에 AWS 컴퓨팅 스토리지 서비스를 포함하는 AWS 인프라 배포 환경인 Wavelength Zone 애플리케이션을 배포하고 해당 리전의 다양한 AWS 서비스에 원활하게 액세스할 있다. 이를 통해 개발자는 게임 라이브 동영상 스트리밍, 엣지의 기계 학습 추론, 증강 가상 현실(AR/VR) 10밀리초 미만의 지연 시간이 요구되는 애플리케이션을 제공할 있다. AWS Wavelength 5G 네트워크 엣지에 AWS 서비스를 제공하여 모바일 디바이스에서 애플리케이션에 연결할 발생하는 지연 시간을 최소화 한다. 애플리케이션 트래픽은 모바일 사업자 네트워크 내의 Wavelength Zone에서 실행되는 애플리케이션 서버로 전송될 있다. 이를 통해 지연 시간이 100밀리초를 초과하게 만들어 고객이 5G 향상된 대역폭 지연 시간을 완전히 활용하지 못하게 있는 인터넷에 대한 추가적인 네트워크 홉이 줄어들게 된다. 아래 그림은 미국 버라이즌 통신사에 구축된 Wavelength 이다.

 

Wavelength 여러 면에서 Outpost 유사하지만 다르다. 물리적으로 엣지 액세스에서 컴퓨팅을 제공하는 개념은 비슷하지만 Wavelength 주요 목표는 가용성 영역과 같은 리전의 확장이다. Wavelength 데이터 센터에서 물리적으로 구매하고 컴퓨팅을 배치할 필요가 없다는 점에서 매우 유사하지만 이동 통신사에서 제공된다.

 

AWS Outposts

AWS Outposts() AWS 인프라, 서비스, API 도구를 고객 온프레미스로 확장하는 완전관리형 서비스이다. AWS 관리형 인프라에 대한 로컬 액세스를 제공하는 AWS Outposts() 통해 고객은 AWS 리전에서 사용하는 것과 동일한 프로그래밍 인터페이스를 사용해 온프레미스에서 애플리케이션을 구축하고 실행할 있으며, 짧은 지연 시간과 로컬 데이터 처리가 필요한 경우에 로컬 컴퓨팅 스토리지 리소스를 사용할 있다. , 데이터 센터 또는 코로케이션 시설에 설치형 기반 솔루션을 제공하여 AWS 기술 서비스를 사용하는 것이다.

 

Outposts 고객 사이트에 배포된 AWS 컴퓨팅 스토리지 용량 풀이다. AWS 용량을 AWS 리전의 일부로 운영, 모니터링 관리한다. Outposts 서브넷을 만들고 EC2 인스턴스, EBS 볼륨, ECS 클러스터 RDS 인스턴스와 같은 AWS 리소스를 생성할 해당 서브넷을 지정할 있다. Outposts 서브넷의 인스턴스는 프라이빗 IP 주소를 사용하여 AWS 리전의 다른 인스턴스와 통신한다 (모두 동일한 VPC 있음).

 

아래 그림은 Outposts 서비스에 사용되는 랙의 모습이다.

 

 

 

 

 

[참고자료]

l  글로벌 인프라 : https://aws.amazon.com/ko/about-aws/global-infrastructure/

l  리전 영역 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#az-ids

l  리전 가용 영역 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

l  AWS Outposts : https://docs.aws.amazon.com/ko_kr/outposts/latest/userguide/what-is-outposts.html

l  Local Zone: https://aws.amazon.com/blogs/aws/announcing-a-second-local-zone-in-los-angeles/

l  Outpost vs Azure MEC: https://msandbu.org/amazon-outpost-vs-azure-stack-hub/  https://noise.getoto.net/2019/12/03/aws-now-available-from-a-local-zone-in-los-angeles/

 

2022-05-08 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Region, Availability Zone, Local Zone, Wavelength Zone, Outposts

[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기

 

l  Version : Devops Guru for RDS

 

이전 포스트에서 AWS Performance Insight(성능 개선 도우미) 사용하여 데이터베이스 운영에 필요한 다양한 지표 쿼리 관련 모니터링에 대해서 살펴 보았다.

l  [AWS RDS] Performance Insight DB부하의 원인 찾기 : https://sungwookkang.com/1503

 

이러한 모니터링은 데이터를 수집하고 관리자가 대시보드를 통한 정보 확인후 문제점 여부를 확인하는데 매우 도움이 된다. 하지만 조금 발전시켜 이러한 이상 현상을 사전에 탐지하고 진단 결과를 알려준다면 조금 빠르게 사전 대응이 가능하지 않을까 생각해 있다. 물론 AWS CloudWatch 사용하여 이상 패턴 발견 SNS 등을 사용하여 알림을 보낼 수도 있지만, 알림은 단순 임계치 값에서 변경이 발생하였을 경우에만 가능 하기 때문에 아래 솔루션을 사용하면 조금 스마트한 모니터링 병목 구간에 대한 진단이 가능하다.

 

Amazon DevOps Guru for RDS 기계 학습(ML) 기반으로 하는 서비스로 모든 AWS RDS 엔진에서 사용할 있으며 이를 통해 애플리케이션의 운영 성능 가용성을 쉽게 개선할 있다.

l  Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

 

서비스는 ML 사용하여 호스트 리소스의 과도한 사용, 데이터베이스 병목 현상 또는 SQL 쿼리의 오작동과 같은 광범위한 성능 관련 데이터베이스 문제를 자동으로 식별하고 분석한다. 또한 발견한 문제를 수정하기 위한 가이드라인을 제공한다. 이상 현상이 감지되면 콘솔에서 결과를 확인할 있을 뿐만 아니라 Amazon Event Bridge또는 Amazon SNS 사용하여 알림을 보낼 있다.

 

 

 DevOps Guru for RDS 사용하기 위해서는 Amazon Console에서 RDS 성능 개선 도우미(Performance Insight) 활성화 DevOps Guru 콘솔로 이동하여 활성화 한다.

 

RDS DevOps Guru 데이터베이스 로드(DB Load) 성능 메트릭에서 이상 감지를 사용하여 문제를 감지한다. DB 로드는 AAS(Average Active Sessions) 단위로 측정된다. DB 로드는 데이터베이스의 활동 수준을 측정하므로 DB 부하가 높으면 성능 문제가 발생할 있다. 메트릭은 가상 CPU(vCPU) 수와 비교할 있으며, DB 부하가 수보다 높으면 문제가 발생할 있다.

 

아래 그림은 DevOps Guru for RDS리포트 결과로, 그래프는 AAS에서 대부분이 테이블 또는 CPU 대한 액세스를 기다리고 있음을 보여준다. 대기 이벤트는 현재 실행 중인 SQL 기다리고 있는 상태로 가장 일반적인 이유는 CPU 기다리거나 읽기 또는 쓰기를 기다리거나 잠긴 리소스를 기다리는 상태이다. Top SQL 차원은 DB 로드에 가장 많이 기여하는 쿼리를 보여준다.

 

DevOps Guru for RDS 분석 페이지에서는 문제의 원인과 해결을 위한 가지 권장 사항도 보여주는데 메트릭에서의 이상 징후는 높은 로드 대기 이벤트와 CPU 용량 초과라는 가지 문제가 감지되었다. 그리고 아래와 같은 분석결과는 나타내었다.

l  IO CPU 대기 유형에 대한 27개의 AAS 있는 고부하 대기 이벤트를 있으며 전체 DB 로드의 99%이다.

l  실행 중인 작업이 6 프로세스를 초과했음을 알려준다. 데이터베이스에는 2개의 vCPU 있으며 권장되는 실행 프로세스 수는 최대 4(vCPU 2)여야 한다.

 

다른 예외에서 그래프는 대기 이벤트의 로드가 높았고 하나의 SQL 쿼리에 추가 조사가 필요한 것으로 나타났다. SQL 다이제스트 ID 클릭하면 정확한 SQL 쿼리를 수도 있다. 예를 들어 대기 이벤트 wait/io/table/sql/handler 또는 문제 해결 문서 보기 링크에서 대기 이벤트를 클릭하면 자세한 정보를 많이 얻을 있다.

 

 

외에도 데이터베이스 분석을 보려면 Insight 페이지로 이동하여 분석 정보를 확인할 있다.

 

 

 

[참고자료]

-          Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

-          Amazon DevOps Guru for RDS to Detect, Diagnose, and Resolve Amazon Aurora-Related Issues using ML : https://aws.amazon.com/ko/blogs/aws/new-amazon-devops-guru-for-rds-to-detect-diagnose-and-resolve-amazon-aurora-related-issues-using-ml/

 

 

 

 

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

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선, DevOps Guru for RDS, 사전탐지, 장애방지, 장애대응

+ Recent posts