[AWS] AWS Redshift 실행된 쿼리 Slow query 확인

 

l  Version : AWS Redshift, Redshift Serverless

 

AWS Redshift에서 특정 시간이상 실행된 쿼리 또는 사용자에 의한 취소 쿼리 목록 실행시간, 실행된 쿼리 등을 확인하는 방법에 대해서 알아본다.

 

아래 스크립트는 3 이상 실행된 쿼리 목록을 확인하여, WHERE 부분을 수정하여 사용자에 필요한 시간으로 변경하여 사용할 있다. 조회 결과는 오래 수행된 쿼리의 내림 차순으로 표시되며, S3 spectrum 사용할 경우 외부 테이블에 대한 사용 정보도 함께 나태낸다. 쿼리 결과에서 elapsed_time 전체 쿼리가 수행에 걸린 시간을 나타내므로 해당 시간이 클수록 느린 쿼리라고 판단할 있다.

select
        a.query_id,
        a.database_name,
        a.query_type,
        a.start_time,
        a.end_time,
        (a.elapsed_time * 1.0) / 1000 / 1000 as elapsed_time_sec,
        (a.execution_time * 1.0) / 1000 / 1000 as execution_time_sec,
        a.returned_rows,
        a.returned_bytes,
        a.query_text,
        b.source_type, -- Spectrum : S3, 연합쿼리 : PG
        b.duration as external_query_duration,
        b.total_partitions as s3_partition,
        b.qualified_partitions as s3_scan_partiton,
        b.scanned_files as s3_scan_file,
        b.returned_rows as s3_returned_rows,
        b.returned_bytes as s3_returned_bytes,
        b.file_format as s3_file_formant,
        b.file_location as s3_file_location,
        b.external_query_text as external_query_text,
        a.result_cache_hit,
        (a.queue_time * 1.0) / 1000 /1000  as queue_time_sec,
        a.status,
        a.error_message,
        a.user_id,
        a.transaction_id,
        a.session_id
from SYS_QUERY_HISTORY as a
        left outer join SYS_EXTERNAL_QUERY_DETAIL as b on a.query_id = b.query_id
where (a.elapsed_time * 1.0) / 1000 / 1000 > 3 -- 마이크로세컨을 세컨으로 계산하도록 변경. 숫자 변경하여 사용
        and a.status in ('success', 'canceled') -- 사용자 쿼리가 성공 또는 사용자에 의한 취소 쿼리만 조회
/* 사용 가능 status value
planning, queued, running, returning, failed, canceled, success
*/
        and a.start_time >= '2023-01-11 01:00' -- UTC 시간
        and a.end_time <= '2023-01-11 23:00' -- UTC 시간
order by elapsed_time desc

 

[참고 자료]

l  쿼리 계획 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c-the-query-plan.html

l  쿼리 요약 분석 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c-analyzing-the-query-summary.html

l  쿼리 계획 분석 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/c-analyzing-the-query-plan.html

l  쿼리 히스토리 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/SYS_QUERY_HISTORY.html

l  외부 쿼리 상세 보기 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/SYS_EXTERNAL_QUERY_DETAIL.html

l  쿼리 세부 정보 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/SYS_QUERY_DETAIL.html

l  서버리스 사용량 확인 : https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/SYS_SERVERLESS_USAGE.html

 

 

 

2023-02-19 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Redshift, Serverless, SYS_QUERY_HISTORY, SlowQuery, 슬로우 쿼리 확인

[AWS] AWS Redshift Serverless 사용량을 확인하여 빌링비용 예상하기

 

l  Version : AWS Redshift Serverless

 

AWS Redshift Serverless 사용한 RPU (Redshift Serverless 리소스 단위로 RPU 라는 것을 사용한다.) 만큼의 비용이 발생하는 구조이다. 그렇다면 사용자가 쿼리를 실행하였을 , 얼마만큼의 RCU 사용하였는지 확인하여 예상 빌링 비용을 산출하는 방법에 대해서 알아본다.

 

AWS Redshift Serverless 환경에서 쿼리를 실행을 완료한 다음, SYS_SERVERLESS_USAGE 라는 시스템 테이블을 확인하면, 서버가 실행된 시간과 사용된 리소스 사용량을 확인할 있다.

select * from sys_serverless_usage

 

 

이름 데이터 형식 설명
start_time timestamp 시작 시간
end_time timestamp 완료된 시간
compute_seconds double precision 시간 동안 사용된 누적 컴퓨팅 단위(RPU) 이며, 유휴 시간이 포함되어 있음.
compute_capacity double precision 시간 동안 할당된 평균 컴퓨팅 단위(RPU)
data_storage integer 시간 동안 사용된 평균 데이터 스토리지 공간(MB) 으로 사용된 데이터 스토리지는 데이터가 데이터베이스에서 로드되거나 삭제될 동적으로 변경 있음.
cross_region_transferred_data integer 시간 동안 리전간 데이터 공유를 위해 전송된 누적 데이터(byte) .

 

아래 스크립트는 1 사용량에 따른 비용을 계산하는 예제이다. SYS_SERVERLESS_USAGE 시스템 테이블을 쿼리하여 사용량을 추적할 있으며, 쿼리가 처리된 기간의 근사값을 계산할 있다. 현재 서비스 중인 리전의 RPU 가격을 확인하여 대입하면 된다. 아래 스크립트에서는 서울 리전의 RPU 가격을 대입한 결과 이다.

Select
  trunc(start_time) "Day",
  sum(compute_seconds)/60/60 as sum_compute_seconds,
  (sum(compute_seconds)/60/60) * 0.438 as price -- <Price for 1 RPU>
from sys_serverless_usage
group by trunc(start_time)
order by 1

 

 

Redshift Serverless 사용한 만큼 비용이 발생하는 구조이지만, 쿼리가 실패 하였을 경우에는 비용이 발생하지 않는다. 하지만 사용자 요청에 의해 취소되는 작업에 대해서는 취소될 까지 사용된 리소스에 대해서는 비용이 발생한다. 따라서, 실행중인 쿼리를 캔슬하거나 쿼리 타임아웃으로 인해 쿼리가 취소 되지 않도록 시간을 적절히 조절하여 의도하지 않은 불필요한 비용이 발생하지 않도록 한다.

 

Redshift에서 S3 저장된 데이터를 직접 수행할 있도록 하는 Amazon Redshift Spectrum 사용할 경우, 스캔한 바이트 수에 대해 비용이 부과되며 10MB 기준으로 반올림하여 처리 된다. DDL문에 대해서는 파티셔닝 관리와 실패한 쿼리에 대해서는 비용이 부과되지 않는다.

 

AWS S3에서는 Amazon Redshift Serverless 외부 데이터 쿼리는 별도로 청구되지 않으며, Amazon Redshift 서버리스에 대한 청구 금액(RPU) 포함되어 있다.

 

 

[참고자료]

l  https://docs.aws.amazon.com/ko_kr/redshift/latest/dg/SYS_SERVERLESS_USAGE.html

l  https://aws.amazon.com/ko/redshift/pricing/

 

 

 

2023-01-09 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Redshift, Serverless, SYS_SERVERLESS_USAGE

[AWS Aurora] Aurora PostgreSQL Auto Vacuum 이해하기

 

l  Version : AWS Aurora PostgreSQL

 

PostgreSQL 오픈소스 관계형 데이터베이스로 AWS PostgreSQL 오픈소스 데이터베이스를 완전 관리형 데이터베이스 서비스로 제공한다.

l  Amazon Aurora : https://aws.amazon.com/ko/rds/aurora/

 

많은 사용자들이 PostgreSQL(이하 PG) 사용할 Vacuum 동작으로 인해 예상하지 못한 성능 하락 문제를 겪고 있는데 Vacuum 수행되었을 발생하는 문제는 무엇이 있는지, 그리고 이러한 문제를 최소화하기 위한 전략이 무엇이 있는지에 대해서 알아본다.

 

[Vacuum 하는 것일까]

Vacuum 일반 적으로 진공 청소기라는 뜻으로, 의미와 동일하게 PG에서 이상 사용되지 않는 데이터를 정리해주는 역할을 한다. 쉽게 예를 들면 디스크 조각모음과 같다.

 

 PG MVCC (Multi Version Concurrency Control, 다중 버전 동시성 제어) 지원하기 때문에 데이터의 삭제, 수정이 발생하면 이상 사용하지 않는 여러 버전의 데이터가 존재한다. 만약 Vacuum 진행하지 않으면 이러한 데이터가 지속적으로 쌓여 실제 테이블 데이터 자체는 적은데 테이블의 공간을 차지하여 테이블이 지속적으로 커지는 문제가 발생한다. 그러면 당연히 불필요하거나 부적절한 인덱스가 증가하여 조회속도가 느려지고, I/O 오버헤드가 증가한다. 또한 트랜잭션 ID 겹침이나, 다중 트랜잭션 ID 겹침 상황으로 오래된 자료가 손실될 수도 있으며 이러한 현상이 지속되면 트랜잭션 ID 재활용하지 못해서 최악의 상황에는 데이터베이스가 멈추는 상황까지 발생할 있다. 이러한 여러 이유로 Vacuum 작업은 이유에 맞게 다양한 주기로, 다양한 대상으로 진행된다.

 

MVCC :
동시접근을 허용하는 데이터베이스에서 동시성을 제어하기 위해 사용하는 방법. , MVCC 모델에서 데이터에 접근하는 사용자는 접근한 시점에서의 데이터베이스의 Snapshot 읽는데, snapshot 데이터에 대한 변경이 완료될 (트랜잭션이 commit )까지 만들어진 변경사항은 다른 데이터베이스 사용자가 없다. 이러한 개념에 의해 사용자가 데이터를 업데이트하면 이전의 데이터를 덮어 씌우는게 아니라 새로운 버전의 데이터를 생성한다. 대신 이전 버전의 데이터와 비교해서 변경된 내용을 기록한다. 이렇게해서 하나의 데이터에 대해 여러 버전의 데이터가 존재하게 되고, 사용자는 마지막 버전의 데이터를 읽게 된다.

 

 

[Vacuum 하는 ]

Vacuum 실행되면 사용되지 않는 Dead Tuple (이하 데드 튜플) FSM(Free Space Map) 반환한다. 데드 튜플은 Vacuum 작업을 통해 FSM 반환되기 전까지는 자리에 새로운 데이터를 저장할 없다. 예를 들어 10 row 가지고 있는 테이블에 update 10만개를 했다면 10만개의 데드 튜플이 생기고, 다시 10만개의 업데이트를 했다면 Vacuum 실행되지 않은 상태에서는 다시 10만개의 데드 튜플이 발생한다. . 해당 테이블은 실제 데이터 10만개와, 20만개의 데드 튜플이 존재하게 된다. 이때 Vacuum 실행하면 20만개의 데드 튜플 공간을 FSM 반환하게 되며 다음 업데이트부터는 해당 공간을 재활용할 있다. 하지만 Vacuum 실행한다고 해서 이미 늘어난 테이블의 크기는 줄어들지는 않으며 해당 공간이 재활용되어 사용되므로 테이블 크기가 이상 늘어나지는 않는다. Vacuum 실행되므로써 FSM 공간반환 뿐만 아니라, 인덱스 전용 검색 성능을 향상하는데 참고하는 자료 지도 (VM, Visivility Map)정보를 갱신한다. 또한 삭제된 데이터뿐만 아니라 남아 있는 데이터에 대해서도 Frozen XID(XID 2) 변경해 주어 앞으로 XID wrap around 발생하더라도 트랜잭션 ID 겹침을 방지할 있다.

 

PG에서는 트랜잭션 ID 크기가 32bit 정수형 크기이며 하나의 서버에서 해당 크기를 넘기면 트랜잭션 ID 겹치는 현상이 발생한다.

 

 

[Vacuum 실행]

Vacuum 작업은 기본적으로 디스크 I/O 오버헤드를 유발한다. 때문에 동시에 작업하고 있는 다른 세션의 성능을 떨어뜨릴 있다. Vacuum 작업에 대한 비용은 아래 링크를 참고한다.

l  Cost-based Vacuum Delay : https://www.postgresql.kr/docs/9.4/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST

Vacuum 수동 또는 자동으로 실행될 있다. 그리고 Vacuum 실행 옵션에 따른 특징이 있다. 수동으로 실행할 경우 아래와 같은 명령으로 실행할 있다.

-- DB 전체 full vacuum
vacuum full analyze;
 
-- DB 전체 간단하게 실행
vacuum verbose analyze;
 
-- 특정 테이블만 간단하게 실행
vacuum analyze [테이블 ];
 
-- 특정 테이블만 full vacuum
vacuum full [테이블 ];

 

l  Vacuum : 데드 튜플을 FSM 반환하는 작업을 하며, 운영 환경에서도 DML (SELECT, INSERT, UPDATE, DELETE) 실행되고 있어도 동시에 사용할 있다.  하지만 DDL (ALTER TABLE) 명령은 Vacuum 작업이 실행되는 동안에는 사용할 없다.

l  Vacuum FULL : VACUUM FULL 작업은 해당 테이블의 사용할 있는 자료들만을 모아서 파일에 저장하는 방식을 이용하기 때문에 운영체제 입장에서 디스크 여유 공간을 확보할 있다. 작업 결과로 해당 테이블에 대해서 최적의 물리적 크기로 테이블이 만들어진다. 하지만 작업 테이블에 대한 베타적 잠금(Exclusive Lock) 지정하여 실행되기 때문에 어떠한 작업도 없다. (운영중인 데이터베이스에서는 사용 금지) 그리고 일반 VACUUM 작업에 비해 시간이 오래 걸린다. 또한 작업이 완료되기 전까지 작업을 있는 여유 공간이 있어야 작업을 있다.

l  Vacuum Analyze : 통계 메타데이터를 업데이트하므로 쿼리 옵티마이저가 정확한 쿼리 계획을 생성할 있어 Vacuum 명령어 실행 같이 실행하는 것이 좋다.

 

Autovacuum(자동) 내부 알고리즘으로 필요에 따라 Vacuum 자동으로 처리해 주는 것으로 수동처럼 명령어로 테이블을 정리하는 것이 아닌 테이블 혹은 DB 단위의 설정을 통해서 vacuum 진행된다. 이때 설정된 값에 따라서 데드 튜플의 증가를 얼마나 제어할지가 정해지기 때문에 Autovacuum 사용할 때에는 현재 운영중인 서버의 최적화 값을 파악하고 있어야 한다.

 

일반적인 Vacuum 전략은 주기적인 표준 Vacuum 작업을 진행하여 지속적으로 빈공간을 확보하여 디스크가 어느정도 커지지만 이상 커지지 않게 하여 최대한 Vacuum FULL 작업을 방지하는 것이다. Autovacuum 데몬이 이러한 전략으로 작업을 한다. , autovacuum 기능을 사용하되 Vacuum FULL 작업을 하지 않는 것을 기본 정책으로 설정하면 된다. 기본적으로 실시간(주기적) Vacuum(FULL Vacuum아님)실시하며, autovacuum_freeze_max_age 도달하면 강제로 Vacuum 작업을 실시하게 된다.

 

정확한 데이터베이스 사용량을 파악하지 않은 상태에서 autovacuum 기능을 끄는 것은 현명하지 않은 방법일 있다.

 

아래 쿼리는 튜플에 대한 정보를 확인한다.

SELECT
    n.nspname AS schema_name,
    c.relname AS table_name,
    pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid) as total_tuple,
    pg_stat_get_live_tuples(c.oid) AS live_tuple,
    pg_stat_get_dead_tuples(c.oid) AS dead_tupple,
    round(100*pg_stat_get_live_tuples(c.oid) / (pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid)),2) as live_tuple_rate,
    round(100*pg_stat_get_dead_tuples(c.oid) / (pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid)),2) as dead_tuple_rate,
    pg_size_pretty(pg_total_relation_size(c.oid)) as total_relation_size,
    pg_size_pretty(pg_relation_size(c.oid)) as relation_size
FROM pg_class AS c
JOIN pg_catalog.pg_namespace AS n ON n.oid = c.relnamespace
WHERE pg_stat_get_live_tuples(c.oid) > 0
AND c.relname NOT LIKE 'pg_%'
ORDER BY dead_tupple DESC;

 

아래 쿼리는 Vacuum 통계 정보를 확인한다.

SELECT * FROM pg_stat_all_tables ORDER BY schemaname, relname;

 

Vacuum FULL 실행시 pg_class relfilenode 값이 변경된다. 아래 쿼리는 relfilenode 물리적인 파일 위치를 확인한다.

SELECT oid, pg_relation_filepath(oid), relname, relfilenode FROM pg_class LIMIT 10;

 

아래 쿼리는 현재 실행중인 Vacuum세션 정보를 확인할 있다.

SELECT
 datname,
 usename,
 pid,
 CURRENT_TIMESTAMP - xact_start AS xact_runtime,
 query
FROM
 pg_stat_activity
WHERE
 upper(query)
 LIKE '%VACUUM%'
ORDER BY
 xact_start;

 

[Autovacuum 데몬 워크플로우]

Autovacuum 데몬은 Autovacuum 실행기와 Autovacuum 작업자의 가지 다른 종류의 프로세스로 설계되어있다.

 

Autovacuum 실행기는 Autovacuum 매개변수가 on으로 설정될 postmaster 시작하는 기본 실행 프로세스이다. postmaster PostgreSQL 시스템에 대한 요청에 대한 처리 메커니즘 역할을 한다. 모든 프론트 엔드 프로그램은 시작 메시지를 postmaster에게 보내고 postmaster 메시지의 정보를 사용하여 백엔드 프로세스를 시작한다. Autovacuum 실행기 프로세스는 테이블에서 Vacuum 작업을 실행하기 위해 Autovacuum 작업자 프로세스를 시작할 적절한 시간을 결정한다.

Autovacuum 작업자는 테이블에서 vacuum 작업을 실행하는 실제 작업자 프로세스이다. 실행 프로그램에서 예약한 대로 데이터베이스에 연결하고 카탈로그 테이블을 읽고 Vacuum 작업을 실행할 테이블을 선택한다.

Autovacuum 시작 프로그램 프로세스는 데이터베이스의 테이블을 계속 모니터링하고 테이블이 Autovacuum 임계값에 도달한 Vacuum 작업에 적합한 테이블을 선택합니다. 임계값은 아래와 같은 매개변수를 기반으로 한다.

l  autovacuum_vacuum_threshold, autovacuum_analyze_threshold : 매개변수는 각각 autovacuum autoanalyzer 대해 예약할 테이블의 최소 업데이트 또는 삭제 수를 결정한다. 기본값은 50이다.

l  autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor : 매개변수는 각각 autovacuum autoanalyzer 대해 예약할 테이블에 대해 변경이 필요한 테이블의 백분율을 결정한다. autovacuum_vacuum_scale_factor 기본값은 0.2(20%)이고 autovacuum_analyze_scale_factor 0.1(10%)이다. 테이블의 수가 너무 많지 않은 경우 기본 값을 사용해도 되지만, 많은 수의 행이 있는 테이블의 경우에는 빈번한 Vacuum 발생할 있어 적절한 값으로 조절하는 것이 좋다. 데이터베이스 내에서 테이블이 일부 존재하는 경우 구성 파일보다 테이블 수준에서 이러한 매개변수를 설정하는 것이 좋다.

 

임계값 계산은 아래 공식을 사용할 있다.

vacuum threshold = vacuum base threshold + vacuum scale factor * number of live tuples

 

l  Vacuum base threshold – autovacuum_vacuum_threshold

l  Vacuum scale factor – autovacuum_vacuum_scale_factor

l  Number of live tuples – The value of n_live_tup from pg_stat_all_tables view

 

Autovacuum 실행기는 자체적으로 Autovacuum 작업자 프로세스를 시작할 없으며 postmaster 프로세스에 의해 수행된다. 런처는 Autovacuum 공유 메모리 영역에 데이터베이스에 대한 정보를 저장하고 공유 메모리에 플래그를 설정하고 postmaster에게 신호를 보낸다. postmaster Autovacuum 작업자 프로세스를 시작한다. 새로운 작업자 프로세스는 공유 메모리에서 정보를 읽고 필요한 데이터베이스에 연결하고 Vacuum 작업을 완료한다.

postmaster 작업자 프로세스 시작에 실패하면 공유 메모리에 플래그를 설정하고 런처 프로세스에 신호를 보낸다. postmaster 신호를 읽고 실행기는 postmaster에게 신호를 전송하여 작업자 프로세스 시작을 다시 시도한다. (postmaster 작업자 프로세스를 시작하지 못하는 것은 로드 메모리 압력이 높거나 이미 실행 중인 프로세스가 너무 많기 때문일 있다).

Autovacuum 작업자 프로세스가 Vacuum 작업으로 완료되면 런처에 신호를 보낸다. 런처가 작업자로부터 신호를 받으면 런처가 깨어나Vacuum 테이블 목록이 공유 메모리에 너무 많으면 다른 작업자를 시작하려고 시도한다. 이는 다른 작업자가 해당 테이블에 대한 Vacuum 잠금을 기다리는데 차단되는 것을 방지하기 위한 것이다. 또한 다른 작업자가 방금 정리를 완료하여 공유 메모리에 이상 기록되지 않은 테이블을 Vacuum하지 않도록 테이블을 Vacuum하기 직전에 pgstats 테이블의 데이터를 다시 로드한다.

PostgreSQL 일반적인 오해는 Autovacuum 프로세스가 I/O 증가시킨다는 것이다. 따라서 많은 사람들이 Autovacuum 프로세스를 완전히 끄도록 선택한다. 이러한 행동은 데이터베이스 운영 초기 단계에서는 효과적인 솔루션처럼 보일 있지만 데이터베이스 크기가 증가하기 시작하면 데드 튜플이 차지하는 공간이 빠르게 증가하고, 테이블 디스크 공간 증가와 함께 데이터베이스 속도가 느려지기 때문에 권장하지 않는다.

 

 

[Autovacuum 장점]

통계 업데이트

PostgreSQL ANALYZE 데몬은 테이블의 통계를 수집하고 계산한다. 쿼리 플래너는 이러한 통계를 사용하여 쿼리 계획을 실행한다. 정보는 ANALYZE 데몬에 의해 계산 수집되며 이러한 통계를 사용하여 카탈로그 테이블에 저장된다. 그런 다음 쿼리 플래너는 데이터를 가져오기 위한 쿼리 계획을 만든다. 비슷한 시나리오에서 Autovacuum off 설정되어 있으면 ANALYZE 데몬이 통계를 수집하고 계산하지 않는다. 쿼리 플래너에는 테이블에 대한 정보가 없으므로 잘못된 쿼리 계획을 작성하게 되어 비용 효율적이지 않다.

 

트랜잭션 warparound 방지

앞서 설명한 것처럼 PostgreSQL 트랜잭션 ID 트랜잭션에 숫자를 할당한다. 트랜잭션 ID 숫자이기 때문에 허용되는 최대값 최소값과 같은 제한이 있다. PostgreSQL 트랜잭션 ID 대한 명확한 숫자로 4바이트 정수를 사용한다. , 4바이트로 생성할 있는 최대 트랜잭션 ID 2^32으로 (~ 4294967296) 40 개의 트랜잭션 ID 사용할 있다. 그러나 PostgreSQL 트랜잭션 ID 1에서 2^31( ~ 2147483648)에서 회전시켜 4바이트 정수로 트랜잭션을 무제한으로 처리할 있다. PostgreSQL 트랜잭션 ID 2147483648 도달하면 트랜잭션 ID 1에서 2 변경하여 2^31까지 할당 트랜잭션을 관리하고, 이후 추가 할당 트랜잭션을 트랜잭션 ID 1 할당하여 사용하는데 이렇게 트랜잭션 ID 교체하는 작업을 warparound라고 한다.

Autovacuum 페이지의 행을 방문하여 트랜잭션 ID 고정한다. 데이터베이스 트랜잭션 ID 수명이 autovacuum_freeze_max_age 도달할 때마다 PostgreSQL Autovacuum 프로세스를 즉시 시작하여 전체 데이터베이스에서 freeze작업을 수행한다.

 

 

[Autovacuum 모니터링]

Autovacuum 효과적으로 작동하는지 확인하려면 데드 튜플, 디스크 사용량, autovacuum 또는 ANALYZE 마지막으로 실행된 시간을 정기적으로 모니터링해야 한다.

 

Dead Tuple

PostgreSQL pg_stat_user_tables 뷰를 제공하는데, 뷰는 테이블(relname) 테이블에 있는 데드 로우(n_dead_tup) 대한 정보를 제공한다. 테이블, 특히 자주 업데이트되는 테이블의 데드 수를 모니터링하면 Autovacuum 프로세스가 주기적으로 제거하여 디스크 공간을 나은 성능을 위해 재사용할 있는지 확인하는 도움이 된다. 아래 쿼리를 사용하여 데드 튜플의 수와 테이블에서 마지막 Autovacuum 실행된 시간을 확인할 있다.

SELECT
relname AS TableName
,n_live_tup AS LiveTuples
,n_dead_tup AS DeadTuples
,last_autovacuum AS Autovacuum
,last_autoanalyze AS Autoanalyze
FROM pg_stat_user_tables;

 

Table Disk Usage

테이블이 사용하는 디스크 공간의 양을 추적하면 시간 경과에 따른 쿼리 성능의 변화를 분석할 있기 때문에 중요하다. 또한 Vacuum 관련된 문제를 감지하는 도움이 있다. 예를 들어 최근에 많은 데이터를 테이블에 추가했는데 테이블의 디스크 사용량이 예기치 않게 증가한 경우 해당 테이블에 vacuuming 문제가 있을 있다.

Vacuuming 오래된 행을 재사용 가능한 것으로 표시하는 도움이 되므로 VACUUM 정기적으로 실행되지 않으면 새로 추가된 데이터는 데드 튜플이 차지하는 디스크 공간을 재사용하는 대신 추가 디스크 공간을 사용한다.

 

Last autovacuum and autoanalyzer

pg_stat_user_tables 보기는 autovacuum 데몬이 테이블에서 마지막으로 실행된 시간에 대한 정보를 제공한다. autovacuum autoanalyze 사용하여 autovacuum 데몬이 효율적으로 작동하는지 추적할 있다. 아래 쿼리는 테이블에서 실행되는 last_autovacuum last_autoanalyze 대한 세부 정보를 제공한다.

SELECT relname, last_autovacuum,last_autoanalyze FROM pg_stat_user_tables;

 

Enabling log_autovacuum_min_duration

log_autovacuum_min_duration 매개변수는 Autovacuum 프로세스가 실행한 모든 작업을 기록하는 도움이 된다. Autovacuum 지정된 시간(밀리초) 동안 실행하거나 임계값 테이블 저장 매개변수를 초과하면 작업이 기록된다. 매개변수를 150밀리초로 설정하면 150밀리초 이상 실행되는 모든 Autovacuum 프로세스가 기록된다. 또한 매개변수가 -1 이외의 값으로 설정되면 충돌하는 잠금으로 인해 Autovacuum 작업을 건너뛸 경우 메시지가 기록된다. 또한 Autovacuum 프로세스의 느린 속도에 대한 자세한 정보를 제공할 있다.

 

Enabling an Amazon CloudWatch alarm

트랜잭션 warparound 대한 Amazon CloudWatch 경보를 설정할 있습니다. 자세한 내용은 아래 링크를 참고한다.

l  Implement an Early Warning System for Transaction ID Wraparound in Amazon RDS for PostgreSQL : https://aws.amazon.com/ko/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/

또한 CloudWatch 지표를 사용하여 전체 시스템 리소스 사용량을 모니터링하고 Autovacuum 세션이 동시에 실행될 허용 가능한 범위 내에 있는지 확인할 있다.

 

 

[일반적으로 자주 겪는 Autovacuum 문제]

Autovacuum parameter tuning

Autovacuum 정기적으로 테이블의 Vacuum 프로세스를 트리거하지 않거나 효율적으로 수행되지 않는 경우 Autovacuum 매개변수 조정을 고려해야 한다. Autovacuum 프로세스는 테이블에서 VACUUM ANALYZE 명령을 자동으로 실행해야 하는 시기를 결정하기 위해 여러 구성 설정에 따라 달라진다. 아래 쿼리는 조정할 있는 Autovacuum 매개변수 목록을 제공합니다.

select category, name,setting,unit,source,min_val,max_val from pg_settings where category = 'Autovacuum' ;

 

 

Settings​​열에는 현재 구성된 값이 표시된다. boot_val열에는 기본 매개변수를 변경하지 않을 사용하는 PostgreSQL에서 설정한 Autovacuum 매개변수의 기본값이 표시된다. 이러한 Autovacuum 매개변수를 조정하면 Autovacuum 프로세스가 테이블에서 자주 효율적으로 작동한다. Autovacuum 조정에 대한 자세한 내용은 아래 링크를 참고한다.

l  A Case Study of Tuning Autovacuum in Amazon RDS for PostgreSQL : https://aws.amazon.com/ko/blogs/database/a-case-study-of-tuning-autovacuum-in-amazon-rds-for-postgresql/

 

Autovacuum skipped due to lock conflicts

테이블에서 Vacuum 실행하려면 Autovacuum 프로세스가 SHARE UPDATE EXCLUSIVE 잠금을 획득해야 하는데, 이는 트랜잭션이 동시에 SHARE UPDATE EXCLUSIVE 잠금을 보유할 없기 때문에 다른 잠금과 충돌한다. 이는 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE ACCESS EXCLUSIVE 같은 다른 잠금 모드에서도 동일하다.

SHARE UPDATE EXCLUSIVE 잠금은 SELECT, UPDATE, INSERT 또는 DELETE 차단하지 않으며 아래 잠금이 있는 트랜잭션만 차단한다.

l  SHARE UPDATE EXCLUSIVE – Acquired by VACUUM (without FULL), ANALYZE, CREATE INDEX CONCURRENTLY, REINDEX CONCURRENTLY, CREATE STATISTICS, and certain ALTER INDEX and ALTER TABLE variants.

l  SHARE – Acquired by CREATE INDEX (without CONCURRENTLY).

l  SHARE ROW EXCLUSIVE – Acquired by CREATE TRIGGER and some forms of ALTER TABLE.

l  EXCLUSIVE – Acquired by REFRESH MATERIALIZED VIEW CONCURRENTLY.

l  ACCESS EXCLUSIVE – Acquired by DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL, and REFRESH MATERIALIZED VIEW (without CONCURRENTLY) commands. Many forms of ALTER INDEX and ALTER TABLE also acquire a lock at this level.

따라서 트랜잭션이 테이블에 대한 이러한 잠금 하나를 유지하라는 요청과 함께 제공되고 Autovacuum 데몬이 이미 해당 테이블 하나에서 Vacuum 작업을 실행 중인 경우, 다른 트랜잭션이 잠금을 취할 있도록 Vacuum 작업을 즉시 취소한다. 유사하게, 트랜잭션이 이미 테이블에 대한 ACCESS EXCLUSIVE 잠금을 보유하고 있는 경우 Autovacuum 해당 테이블을 Vacuuming에서 건너뛴다. Autovacuum 프로세스는 다음 반복에서 Vacuum 작업을 실행하기 위해 건너뛴 테이블을 유지한다.

 

Autovacuum action skipped due long-running transactions

PostgreSQL MVCC 개념을 기반으로 하기 때문에 하나 이상의 트랜잭션이 오래된 버전의 데이터에 액세스하는 경우 Autovacuum 프로세스는 데드 튜플을 정리하지 않는다. 데이터가 삭제되거나 업데이트되기 전에 생성된 데이터의 스냅샷에서 트랜잭션이 작업 중인 경우 Autovacuum 해당 데드 튜플을 건너뛰고 해당 데드 튜플은 다음 반복에서 Vacuum 된다. 이런 케이스는 일반적으로 데이터베이스의 장기 실행 트랜잭션에서 발생한다. 데이터베이스에서 장기 실행 트랜잭션을 찾으려면 아래 쿼리를 실행한다. 예제 쿼리는 5분이상 실행되고 있는 쿼리를 나타낸다.

SELECT now()-query_start as Running_Since, pid, datname, usename, application_name, client_addr , left(query,60) FROM pg_stat_activity WHERE state in ('active','idle in transaction') AND (now() - query_start) > interval '5 minutes';

 

Autovacuum 데드 튜플을 건너뛰게 있으므로 모니터링의 일부로 트랜잭션 세션의 유휴 상태(idle in transaction) 포함하는 것이 좋다.

 

 

[Autovacuum 모범 사례]

Allocating memory for autovacuum

maintenance_work_mem 파라미터는 Autovacuum 성능에 영향을 미치는 중요한 파라미터이다. Autovacuum 프로세스가 데이터베이스의 테이블을 스캔하는 사용할 메모리 양을 결정하고 Vacuum 필요한 ID 보유한다.

매개변수를 낮게 설정하면 Vacuum 프로세스가 테이블을 여러 스캔하여 Vacuum 작업을 완료하므로 데이터베이스 성능에 부정적인 영향을 미친다.

작은 테이블이 많은 경우 autovacuum_max_workers 많이 할당하고 maintenance_work_mem 적게 할당한다. 테이블(100GB 이상) 있는 경우 많은 메모리와 적은 수의 작업자 프로세스를 할당한다. 가장 테이블에서 성공하려면 충분한 메모리가 할당되어야 한다. autovacuum_max_workers 할당한 메모리를 사용할 있다. 따라서 작업자 프로세스와 메모리의 조합이 할당하려는 메모리와 동일한지 확인해야 한다.

 

인스턴스의 경우 maintenance_work_mem 1GB 이상으로 설정하면 많은 수의 데드 튜플이 있는 테이블을 Vacuuming하는 성능이 크게 향상된다. 그러나 Vacuum 메모리 사용을 1GB 제한하는 것이 좋다. 패스에서 1 7,900 개의 데드 튜플을 처리하기에 충분하다. 그보다 많은 데드 튜플이 있는 테이블을 Vacuuming하려면 테이블 인덱스를 여러 통과해야 하므로 Vacuum 훨씬 오래 걸릴 있다. maintenance_work_mem 바이트를 6으로 나누어 단일 패스에서 Vacuum 처리할 있는 데드 튜플 수를 계산할 있다.

autovacuum_work_mem 또는 maintenance_work_mem 매개변수를 설정하면 Autovacuum 작업자 프로세스가 사용해야 하는 최대 메모리 크기가 설정된다. 기본적으로 autovacuum_work_mem -1 설정되며 이는 Autovacuum 작업자 프로세스에 대한 메모리 할당이 maintenance_work_mem 설정을 사용해야 함을 나타낸다.

 

Amazon RDS 파라미터의 기본값은 아래와 같이 계산된 KB 적용되어 있다.

GREATEST({DBInstanceClassMemory/63963136*1024},65536).

 

자세한 내용은 아래 링크를 참고한다.

l  Common DBA tasks for Amazon RDS for PostgreSQL : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory

l  A Case Study of Tuning Autovacuum in Amazon RDS for PostgreSQL : https://aws.amazon.com/ko/blogs/database/a-case-study-of-tuning-autovacuum-in-amazon-rds-for-postgresql/

 

Reducing the chances of transaction ID wraparound

일부 사용 사례에서는 조정된 Autovacuum 설정도 트랜잭션 ID warparound 방지할 만큼 공격적이지 않다. 문제를 해결하기 위해 Amazon RDS에는 autovacuum 파라미터 값을 자동으로 조정하는 메커니즘이 있다. 적응형 Autovacuum 파라미터 조정이 활성화된 경우 Amazon RDS CloudWatch 지표 MaximumUsedTransactionIDs 750,000,000 또는 autovacuum_freeze_max_age 값에 도달할 Autovacuum 파라미터 조정을 시작한다.

Amazon RDS 테이블이 계속해서 트랜잭션 ID warparound 향하는 경향이 있을 Autovacuum 대한 매개변수를 계속 조정한다. 조정은 warparound 피하기 위해 Autovacuum 많은 리소스를 할당한다. Amazon RDS 다음과 같은 Autovacuum 관련 파라미터를 업데이트한다.

l  autovacuum_vacuum_cost_delay autovacuum 프로세스가 제한을 초과할 대기하는 지정된 시간(밀리초)이다. 기본값은 20밀리초이다.

l  autovacuum_vacuum_cost_limit Autovacuum 프로세스를 휴면 상태로 만드는 누적 비용으로 기본값은 200이다.

l  autovacuum_work_mem Autovacuum 작업자 프로세스에서 사용하는 최대 메모리 양이다. 기본값은 -1 maintenance_work_mem 값을 사용해야 함을 나타낸다.

l  autovacuum_naptime 주어진 데이터베이스에서 Autovacuum 실행 사이의 최소 지연을 지정한다. 라운드에서 데몬은 데이터베이스를 검사하고 해당 데이터베이스의 테이블에 대해 필요에 따라 VACUUM ANALYZE 명령을 실행한다. 지연은 단위로 측정되며 기본값은 1분이다. 매개변수는 postgresql.conf 파일이나 서버 명령줄에서만 설정할 있다.

 

Amazon RDS 기존 값이 충분히 공격적이지 않은 경우에만 이러한 파라미터를 수정한다. 이러한 파라미터는 DB 인스턴스의 메모리에서 수정되며 파라미터 그룹에서는 변경되지 않는다. Amazon RDS 이러한 Autovacuum 파라미터를 수정할 때마다 Amazon RDS API 통해 AWS Management 콘솔에서 있는 영향을 받는 DB 인스턴스에 대한 이벤트를 생성한다. MaximumUsedTransactionIDs CloudWatch 지표가 임계값 아래로 반환되면 Amazon RDS 메모리의 Autovacuum 관련 파라미터를 파라미터 그룹에 지정된 값으로 재설정한다.

 

Setting autovacuum at table level

글로벌 Autovacuum 설정을 기반으로 증가하는 PostgreSQL 환경에서 테이블은 효과적으로 Vacuum되지 않고 작은 테이블은 자주 Vacuum되는 것을 있다. 이러한 시나리오를 피하기 위해 다음 단계에 따라 테이블 수준에서 Autovacuum 매개변수를 설정할 있다.

1.        데이터베이스에서 테이블을 나열한다.

2.        많은 수의 변경 사항이 발생한 테이블을 나열한다.

3.        어떤 테이블에 'n_dead_tup' 수가 많은지 확인한다.

4.        테이블이 마지막으로 자동 분석 자동 진공 처리된 시간을 확인한다.

5.        테이블 수준에서 Autovacuum Autoanalyze 매개변수를 변경한다.

 

 

[참고자료]

l  Amazon Aurora : https://aws.amazon.com/ko/rds/aurora/

l  정기적인 Vacuum 작업 : https://www.postgresql.kr/docs/9.4/routine-vacuuming.html

l  MVCC : https://en.wikipedia.org/wiki/Multiversion_concurrency_control

l  Free Space Map(FSM) : https://www.postgresql.org/docs/current/storage-fsm.html

l  Visibility Map (VM) : https://www.postgresql.org/docs/current/storage-vm.html

l  Understanding autovacuum in Amazon RDS for PostgreSQL environments : https://aws.amazon.com/ko/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/

l  AWS RDS for PostgreSQL Vacuum Tuning : https://catalog.us-east-1.prod.workshops.aws/workshops/2a5fc82d-2b5f-4105-83c2-91a1b4d7abfe/en-US/3-intermediate/vacuum-tuning

l  Visibility Map Problems : https://wiki.postgresql.org/wiki/Visibility_Map_Problems

l  Cost-based Vacuum Delay : https://www.postgresql.kr/docs/9.4/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST

l  Automatic Vacuuming : https://www.postgresql.org/docs/current/runtime-config-autovacuum.html

l  Implement an Early Warning System for Transaction ID Wraparound in Amazon RDS for PostgreSQL : https://aws.amazon.com/ko/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/

l  A Case Study of Tuning Autovacuum in Amazon RDS for PostgreSQL : https://aws.amazon.com/ko/blogs/database/a-case-study-of-tuning-autovacuum-in-amazon-rds-for-postgresql/

l  Common DBA tasks for Amazon RDS for PostgreSQL : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory

 

 

 

 

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

 

 

AWS, Aurora, PostgreSQL, Autovacuunm, Vacuum

[AWS Aurora] Aurora Parallel Query 활성화 방법 특징

 

l  Version : AWS Aurora

 

Amazon Aurora MySQL 병렬 쿼리는 데이터 집약적인 쿼리 처리에 수반되는 I/O 컴퓨팅의 일부를 병렬화 하는 최적화 작업이다. 병렬화되는 작업은 스토리지로부터 검색, 추출, 어떤 행이 WHERE JOIN절의 조건과 일치하는지 판단한다. 데이터 집약적인 작업은 Aurora 분산 스토리지 계층의 여러 노드에 위임(푸시다운)되고 병렬 쿼리가 없으면 쿼리가 스캔한 모든 데이터를 Aurora MySQL 클러스터(헤드노드)내의 단일 노드로 가져오고 거기에서 모든 쿼리 처리를 수행한다. 병렬 쿼리 기능을 설정하면 Aurora MySQL 엔진이 힌트 또는 테이블 속성과 같은 SQL 변경 필요 없이 쿼리에 따라 자동으로 병렬화 여부를 판단한다.

 

데이터베이스를 생성할 [Engine Version]에서 [Hide filters] 확장하여 parallel query 기능을 활성화할 있다.

 

기본적으로, 병렬 쿼리를 사용하지 않을 경우 Aurora 쿼리에 대한 처리는 원시 데이터를 Aurora 클러스터 단일 노드(헤드 노드) 전송한다. 그런 다음 Aurora 해당 단일 노드의 단일 스레드에서 해당 쿼리에 대해 추가되는 모든 처리를 수행한다. 병렬 쿼리를 사용할 경우, 이러한 I/O 집약적이고 CPU 집약적인 작업의 대부분이 스토리지 계층의 노드로 위임된다. 행은 이미 필터링되고 값은 이미 추출되어 전송된 상태로, 결과 집합의 간소화된 행만 다시 헤드 노드로 전송된다. 성능 혜택은 네트워크 트래픽의 감소, 헤드 노드에서 CPU 사용량의 감소, 스토리지 노드 전체에서 I/O 병렬화로부터 비롯된다. 병렬 I/O, 필터링 프로젝션의 양은 쿼리를 실행하는 Aurora 클러스터의 DB 인스턴스 수와 무관하다.

 

 

아래는 위에서 설명한 병렬 쿼리 사용의 장점을 목록으로 정리한 것이다.

l  여러 스토리 노드에 걸친 물리적 읽기 요청을 병렬화 하여 I/O 성능 개선

l  네트워크 트래픽 감소 : Aurora 전체 데이터 페이지를 스토리지 노드로부터 헤드 노드로 전송한 다음 후에 불필요한 행과 열을 필터링 하지 않고 결과 집합에 필요한 값만 포함된 간소화된 튜플을 전송한다.

l  푸시 다운, 필터링 WHERE 절에 대한 프로젝션으로 인한 헤드 노드에 대한 CPU 사용량 감소.

l  버퍼 풀에서의 메모리 압력 감소 : 병렬 쿼리에 의해 처리된 페이지는 버퍼풀에 추가되지 않으므로 데이터 집약적인 스캔 버퍼 풀에서 자주 사용되는 데이터가 제거될 가능성이 감소.

l  기존 데이터에 대한 장기 실행 분석 쿼리 수행이 유용해진 덕분에 추출, 변환, 로드(ETL) 파이프라인에서 데이터 중복의 잠재적 감소.

 

*주의*
Aurora MySQL 병렬 쿼리의 아키텍처는 다른 데이터베이스 시스템에서 이름이 유사한 기능의 아키텍처와 다르다. Aurora MySQL 병렬 쿼리는 SMP(Symmetric Multi Processing) 포함하지 않아, 데이터베이스의 CPU 용량에 의존하지 않는다. 병렬 처리는 쿼리 조정자 역할을 하는 Aurora MySQL 서버와는 독립적인 스토리지 계층에서 일어난다.

 

Aurora MySQL에서 병렬 쿼리를 사용하기 위해서는 가지 사전 조건 제한 사항이 있다. 해당 내용은 버전에 따라 지원되는 내용이 다르고, 향후 버전 업데이트에 따라 변경될 가능성이 크기 때문에 자세한 내용은 아래 링크의 내용을 직접 참고한다.

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

 

Aurora MySQL 3 버전 부터는 해시조인(Hash Join) 기본적으로 설정되어 있다. optimizer_switch 구성 설정의 block_nested_loop 플래그를 사용하여 설정을 비활성화 있다. Aurora MySQL 3버전에서는 Aurora_disable_hash_join 옵션은 사용되지 않는다.

 

Aurora MySQL 1.23 또는 2.09 이상 버전에서는 병렬 쿼리 해시 조인 설정이 기본적으로 해제되어 있다. 부분을 활성화하기 위해서는 클러스터 구성 파라메터 aurora_disable_hash_join=OFF 설정한다.

 

버전 1.23 이전의 Aurora MySQL 5.6 호환 클러스터의 경우 해시 조인은 병렬 쿼리 클러스터에서 항상 사용할 있다. 경우 해시 조인 기능에 대해 어떤 작업도 수행할 필요가 없다. 이러한 클러스터를 버전 1 또는 버전 2 상위 릴리스로 업그레이드하는 경우 해시 조인도 설정해야 한다.

 

병렬 쿼리를 사용하려면 테이블 속성이 ROW_FORMAT=Compact 또는 ROW_FORMAT=Dynammic 설정을 사용해야하기 때문에 INNODB_FILE_FORMAT 구성 옵션에 대한 변경 사항이 있는지 확인해야한다. 옵션을 변경할 때에는 항상 변경 전후에 대한 성능 문제가 발생할 있으므로 반드시 워크로드 테스트를 진행할 있도록 한다.

 

앞에서도 언급하였지만 병렬 쿼리를 이용하기 위해 어떤 특별한 조치를 수행할 필요는 없다. 필수적 요구사항을 충족한 후에는 쿼리 옵티마이저가 특정 쿼리에 대하여 병렬 쿼리를 사용할지 여부를 자동으로 결정하기 때문이다. 쿼리가 실행될 병렬 쿼리로 실행되었는지 유무는 EXPLAIN 명령을 실행하여 실행계획을 통해 확인할 있다.

아래 예시는 해시 조인이 설정되어 있지만 병렬 쿼리가 해제되어 있어 병렬 쿼리가 아닌 해시 조인으로 실행계획이 표시되었다.

 

병렬 쿼리가 설정된 후에는 해시 조인 실행 parallel query 라고 표시된 것을 확인할 있다.

 

Aurora MySQL 클러스터가 병렬 쿼리를 실행할 버퍼풀을 사용하지 않기 때문에 VolumeReadIOPS 값이 증가할 있다. 따라서 쿼리는 빠르기 실행되지만 이렇게 최적화된 프로세싱은 읽기 작업 관련 비용을 증가시킬 있다. 병렬 쿼리 모니터링에 대한 카운터는 아래 링크에서 병렬 쿼리 모니터링섹션을 참고할 있도록 한다. 카운터는 DB 인스턴스 수준에서 추적된다. 서로 다른 엔드포인트로 연결된 경우 DB 인스턴스가 자체의 고유한 병렬 쿼리 집합을 실행하기 때문에 사로 다른 지표가 표시될 수도 있다. 또한 리더 엔드포인트가 세션마다 서로 다른 DB 인스턴스에 연결된 경우에도 서로 다른 지표가 표시될 수도 있다.

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

 

병렬 쿼리는 InnoDB 테이블에만 적용된다. Aurora MySQL에서는 임시 테이블 사용시, 임시 저장소로 MyISAM 사용하기 때문에 임시 테이블을 포함하는 내부 쿼리 단계에서는 병렬쿼리를 사용하지 않는다. 그리고 실행 계획으로는 Using temporary라고 표시된다.

(MySQL 8.0 부터는 임시 테이블이 디스크에 저장될 InnoDB 스토리지를 사용하도록 개선되어 있다.)

 

 

[참고자료]

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

l  https://aws.amazon.com/blogs/aws/new-parallel-query-for-amazon-aurora/

 

 

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

 

 

AWS, Aurora, Aurora Parallel Query, 오로라 병렬처리, 병렬 쿼리, Aurora Optimize, 오로라 최적화

[AWS Aurora] Aurora Global Database 사용한 Cross-Region 장애조치

 

l  Version : AWS Aurora

 

Amazon Aurora Global Database 여러 AWS 리전에 걸쳐 있고 대기 시간이 짧은 글로벌 읽기를 지원하기 때문에, 전세계 지역에서 실행되는 애플리케이션들은 가까운 리전의 Aurora Global Database에서 서비스를 제공받기 때문에 안정적이며 빠른 서비스를 제공할 있다. 또한 Aurora Global Database 데이터를 마스터링하는 하나의 기본 AWS 리전 최대 5개의 읽기 전용 보조 AWS 리전으로 구성되기 때문에, AWS 리전에서 장애 발생시 신속하게 다른 리전으로 복구할 있다.  Aurora Global Database 아래와 같은 장점을 가지고 있다.

l  로컬 대기 시간으로 글로벌 읽기 : 세계에 지사를 두고 있는 경우, Aurora Global Database 사용하여 기본 AWS 리전에서 정보의 주요 소스를 최신 상태로 유지할 있다. 다른 리전의 사무실은 로컬 지연 시간을 사용하여 해당 리전의 정보에 액세스할 있다.

l  확장 가능한 보조 Aurora DB 클러스터 : AWS 리전에 읽기 전용 인스턴스(Aurora 복제본) 추가하여 보조 클러스터를 확장할 있다. 세컨더리 클러스터는 읽기 전용이므로 단일 Aurora 클러스터에 대하여 일반적인 제한인 15개가 아닌 최대 16개의 읽기 전용 Aurora 복제본 인스턴스를 지원할 있다.

l  기본 DB클러스터에서 보조 Aurora DB 클러스터로의 빠른 복제 : Aurora Global Database에서 수행되는 복제는 기본 DB 클러스터의 성능에 거의 영향을 미치지 않는다. DB 인스턴스의 리소스는 애플리케이션 읽기/쓰기 워크로드 처리 전용이다.

l  리전 전체의 운영 중단으로부터 복구 : 보조 클러스터를 사용하면 기존 복제 솔루션보다 적은 데이터 손실( 낮은 RPO) 새로운 기본 AWS 리전에서 Aurora Global Database 보다 신속하게( 낮은 RTO) 가용 상태로 만들 있다.

 

 

Aurora Global Database 리전의 기본(Primary) Aurora 클러스터와 다른 리전의 보조(Secondary) Aurora 클러스터로 생성된다. Aurora 글로벌 데이터베이스는 Aurora 전용 스토리지 계층의 전용 인프라를 사용하여 리전 복제를 처리한다. 스토리지 계층의 전용 복제 서버가 복제를 처리하므로 시스템 로드 중에도 데이터베이스 성능을 저하시키지 않으면서 향상된 복구 가용성 목표를 달성할 있다. Aurora Global Database 물리적 스토리지 수준 복제를 사용하여 동일한 데이터 세트로 기본 데이터베이스의 복제본을 생성하므로 논리적 복제 프로세스에 대한 종속성이 제거된다. 아래 그림은 기본(Primary) 보조(Secondary) 리전에 걸쳐 있는 Aurora 클러스터가 있는 Aurora 글로벌 데이터베이스이다.

 

Aurora Global Database복제과정은 아래와 같다.

1.       Aurora 클러스터의 기본 인스턴스는 Primary 리전의 스토리지 노드, 복제본 인스턴스 복제 서버에 병렬로 로그 레코드를 보낸다.

2.       Primary 리전의 복제 서버는 로그 레코드를 Secondary 리전의 복제 에이전트로 스트리밍한다.

3.       복제 에이전트는 Secondary 리전의 스토리지 노드 복제본 인스턴스에 병렬로 로그 레코드를 보낸다.

4.       Secondary 리전의 복제 서버는 스토리지 노드에서 로그 레코드를 가져와 동기화 한다.

 

Aurora 스토리지 시스템은 단일 리전 내의 3 가용 영역에 걸쳐 6개의 데이터 복사본을 자동으로 유지 관리하고 데이터 손실 없이 정상적인 가용 영역에서 데이터베이스 복구를 자동으로 시도하므로 내구성과 가용성이 크게 향상된다. 쓰기 쿼럼은 6 복사본 4개의 승인이 필요하고 읽기 쿼럼은 보호 그룹의 6 구성원 3개이다. 데이터는 최종 사용자에 대한 성능 영향 없이 실시간으로 Aurora 사용하여 Amazon Simple Storage Service(Amazon S3) 지속적으로 백업된다.

 

아래 그림은 기본 리전에서 여러 보조 리전으로 물리적 스토리지 수준 아웃바운드 복제가 있는 Aurora 글로벌 데이터베이스를 나타낸다.

 

Aurora 글로벌 데이터베이스를 사용하여 보조 리전에서 최대 5개의 보조 리전과 최대 16개의 읽기 전용 복제본을 구성할 있다. 보조 클러스터는 기본 클러스터 다른 보조 클러스터와 다른 리전에 있어야 한다.

 

Aurora 글로벌 데이터베이스를 사용하면 장애조치에 대한 가지 접근 방식 중에서 선택할 있다.

l  관리형 계획 장애조치 : 기본 DB 클러스터를 Aurora 글로벌 데이터베이스의 보조 리전 하나로 재배치 한다. 기능을 사용하면 RPO 0(데이터 손실 없음)이고 다른 변경을 수행하기 전에 보조 DB 클러스터를 기본 클러스터와 동기화한다. 자동화된 프로세스의 RTO 일반적으로 수동 장애조치의 RTO보다 적다.

l  계획되지 않은 수동 장애조치 : 계획되지 않은 중단에서 복구하기 위해 Aurora 글로벌 데이터베이스의 보조 데이터베이스 하나로 교차 리전 장애조치를 수동으로 수행할 있다. 수동 프로세스의 RTO 계획되지 않은 중단에서 Aurora 글로벌 데이터베이스를 얼마나 빨리 수동으로 복구할 있는지에 따라 다르다. RPO 일반적으로 단위로 측정되지만 오류 발생 네트워크 전체의 Aurora 스토리지 복제 지연에 따라 다르다.

 

 Aurora Global Database사용시 수동 장애조치가 어떻게 이루어지는지 살펴보자.

 

기본 리전에서 Writer 인스턴스에서 읽기 쓰기를 수행하고 읽기 전용 복제본에서만 읽기를 수행하는 Aurora 클러스터에 연결된 애플리케이션과 보조 리전에서 읽기 전용 복제본에서 읽기만 수행하는 Aurora 클러스터에 연결된 애플리케이션이 있다. Amazon Route 53 (CNAME 레코드) 장애조치 재구성으로 인해 애플리케이션을 다시 연결하기 위해 수행해야 하는 수동 작업의 양을 최소화하기 위해 Aurora 리더 라이터 엔드포인트를 가리키도록 생성된다.

 

 

전체 지역의 인프라 또는 서비스를 기본 지역에서 사용할 없게 되거나, 잠재적은 성능 저하 또는 격리 문제가 발생할 경우, 보조 클러스터를 기본 클러스터로 승격하도록 수동으로 장애조치를 시작하거나 스크립트를 작성할 있다. 장애조치 RPO 의해 수량화된 잠재적 데이터 손실을 이해할 있어야 한다.

 

장애조치가 완료되면 승격된 리전(이전 보조 리전) 새로운 기본 Aurora 클러스터 역할을 하며 1 이내에 전체 읽기 쓰기 워크로드를 처리할 있으므로 애플리케이션 가동 시간에 대한 영향이 최소화된다. 이전 기본 리전의 인프라 또는 서비스를 사용할 있게 되거나 리전을 추가하면 계획되지 않은 중단 중에 애플리케이션에서 읽기 워크로드만 가져오는 새로운 보조 Aurora 클러스터 역할을 있다.

 

 

[참고자료]

l  Amazon Aurora Global Database  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

l  Cross-Region disaster recovery using Amazon Aurora Global Database for Amazon Aurora PostgreSQL : https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-using-amazon-aurora-global-database-for-amazon-aurora-postgresql/

 

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

 

 

AWS, Aurora, Aurora Global Database, Cross-Region Replication, 오로라 글로벌 데이터베이스, 글로벌 장애조치

[AWS Aurora] Aurora 스토리지 특징 요약

 

l  Version : AWS Aurora

 

Amazon Aurora 스토리지는 SSD(Solid State Drive) 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장된다. 클러스터 볼륨은 동일한 AWS 리전에 속한 가용 영역의 데이터 사본으로 구성되어 있다.

l  Aurora Storage Engine : https://sungwookkang.com/1488

 

가용 영역에서 데이터는 자동으로 복제되기 때문에 디스크 결함으로 인한 데이터 손실 가능성을 최소화 한다. 또한 클러스터 볼륨을 구성하는 디스크 볼륨에서 장애를 자동으로 감지한다. 예를 들어 볼륨 세그먼트에 결함이 발생하면 Aurora 즉시 해당 세그먼트를 복구한다. Aurora 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능하다. 결과적으로 Aurora 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어든다. 복제 양은 클러스터의 DB 인스턴스 수와 관계없다.

 

Aurora 클러스터 볼륨에는 모든 사용자 데이터, 스키마, 객체, 내부 메타데이터(시스템 테이블, 바이너리 로그 ) 포함되어 있다. Aurora 공유 스토리지 아키텍처는 데이터를 클러스터의 DB 인스턴스와 독립적으로 만든다. DB 인스턴스를 추가할 복사본을 만들지 않으므로 빠르게 추가가 가능하다. 대신에 DB 인스턴스는 이미 모든 데이터를 포함하는 공유 볼륨에 연결된다. 클러스터에서 기본 데이터를 제거하지 않고 클러스터에서 DB 인스턴스를 제거할 있다. 전체 클러스터를 삭제하는 경우에만 Aurora 데이터를 제거한다.

 

데이터베이스의 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장된다. Aurora 클러스터 볼륨의 최대 크기는 DB 엔진 버전에 따라 128TiB 또는 64TiB까지 확장될 있지만 요금은 사용한 공간에 대해서만 청구된다. Aurora 데이터가 제거되면 해당 데이터에 할당된 공간을 재사용 하게 된다. 데이터 제거의 예로는 테이블 삭제 또는 자르기 등이 있다. 이렇게 스토리지 사용량이 자동으로 줄어들면 스토리지 요금을 최소화 있다. 하지만 이미 할당된 공간이 축소된 것은 아니다.  Aurora MySQL 2.09.0 1.23.0, Aurora PostgreSQL 3.3.0 2.6.0 부터는 테이블이나 데이터베이스를 삭제하는 등의 방법으로 Aurora 데이터가 제거되면 비슷한 양만큼 할당된 전체 공간이 감소한다.

 

여기서 주의할 점은 임시테이블의 데이터는 로컬 DB 인스턴스에 저장되며 최대 크기는 사용하는 인스턴스 클래스에 따라 다르다.

 

Aurora 전원이 꺼진 데이터베이스를 가동하거나 결함 발생 이후 다시 시작할 버퍼 캐시를 워밍한다. Aurora 인메모리 페이지 캐시에 저장된 기존 공통 쿼리 페이지를 이용해 버퍼풀을 미리 로드한다. 경우 웜업을 우회할 있기 때문에 성능이 향상되는 이점이 있다. Aurora 페이지 캐시는 데이터베이스가 아닌 별도 프로세스로 관리되기 때문에 데이터베이스와 상관없이 유지된다.  자세한 내용은 아래 링크를 참고 한다.

l  InnoDB Cache warming : https://sungwookkang.com/1486

 

 

[참고자료]

l  Amazon Aurora 스토리지 안정성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html

l  InnoDB Cache warming : https://sungwookkang.com/1486

l  Aurora Storage Engine : https://sungwookkang.com/1488

 

 

 

 

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

 

 

AWS, Aurora, Aurora Storage, 오로라 스토리지

[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지

 

l  Version : AWS Aurora

 

Amazon Aurora DB Cluster 하나 이상의 DB 인스턴스와 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성된다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로 가용 영역에는 DB 클러스터 데이터의 사본이 있다.

l  기본 DB 인스턴스 : 읽기 쓰기 작업을 지원하고 클러스터 볼륨의 모든 데이터 수정을 실행한다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있다.

l  Aurora 복제본 : 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원한다. Aurora DB 클러스터는 기본 DB 인스턴스에 대해 최대 15 까지의 Aurora 복제본을 구성할 있다. Aurora DB 기본 인스턴스를 사용할 없는 경우 자동으로 Aurora 복제본으로 자동 장애조치 한다.

 

 Amazon Aurora 일반적으로 단일 인스턴스 대신에 DB 인스턴스 클러스터와 관련된다. 연결은 특정 DB 인스턴스에서 처리한다. Aurora 클러스터에 연결하면 지정한 호스트 이름과 포트가 엔드포인트(endpoint)라는 중간 핸들러를 가리킨다. Aurora 엔드포인트 메커니즘을 사용하여 연결을 추상화 한다. 따라서 일부 DB 인스턴스를 사용할 없을 모든 호스트 이름을 하드코딩 하거나, 연결을 다시 라우팅하고 로드 밸런싱을 하기 위한 자체 로직을 작성할 필요가 없다.

 

Aurora 엔드포인트 유형에는 클러스터 엔드포인트, 리더 엔드포인트, 사용자 지정 엔드포인트, 인스턴스 엔드포인트로 가지 종류가 있다. 엔드포인트에 대한 특징을 살펴보자.

 

[클러스터 엔드포인트 (Cluster endpoint)]

Aurora DB 클러스터의 클러스터 엔드포인트(또는 Writer endpoint) 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결된다. DDL 등의 쓰기 작업을 수행할 있는 유일한 엔드포인트 이다. Aurora DB클러스터에는 클러스터 엔드포인트 하나와 기본 DB 인스턴스 하나가 있다. 삽입, 업데이트, 삭제 DDL 변경을 비롯하여 DB 모든 쓰기 작업에 대해 클러스터 엔드포인트를 사용한다. 또한 읽기 작업에도 클러스터 엔드포인트를 사용할 있다. 클러스터 엔드포인트는 장애조치를 지원한다. 아래는 Aurora MySQL DB 클러스터의 엔드포인트를 나타낸 예제이다.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

 

장애조치 메커니즘에서 DB 인스턴스가 클러스터의 읽기/쓰기 기본 인스턴스가 되도록 승격하면 클러스터 엔드포인트가 가리키는 물리적 IP 주소가 변경된다. 어떤 형식의 연결 풀링이나 기타 멀티플렉싱을 사용하는 경우, 캐싱된 DNS 정보의 TTL(Time To Live) 플러시 하거나 줄이도록 준비한다. 이렇게 하면 사용할 없게 되었거나 장애 조치 이제 읽기 전용인 DB 인스턴스에 읽기/쓰기 연결 설정을 시도하지 않아도 된다.

 

[리더 엔드포인트 (Reader endpoint)]

Aurora DB 클러스터의 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결시 로드 밸런싱을 지원한다. 읽기 작업에 대한 요청을 복제본에서 처리하기 때문에 기본 인스턴스에 대한 오버헤드를 줄일 있다. 또한 클러스터의 Aurora 복제본 수에 비례하여 동시에 SELECT 쿼리를 처리할 있도록 용량을 확장할 있다. Aurora DB 클러스터에는 리더 엔드포인트가 1개씩 있다. 클러스터에 하나 이상의 Aurora 복제본이 포함된 경우 리더 엔드포인트는 Aurora 복제본 사이의 연결 요청을 로드 밸런싱 한다. 경우 해당 세션의 SELECT 같은 읽기만 실행할 있다. 클러스터에 기본 인스턴스만 있고 Aurora 복제본이 없는 경우 리더 엔드포인트는 기본 인스턴스에 연결한다. 경우 엔드포인트를 통해 쓰기 작업을 수행할 있다. 아래는 Aurora MySQL DB 클러스터의 리더 엔드포인트를 나타낸 예제이다.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

 

RDS Proxy 통해서도 Aurora 클러스터용 추가 읽기 전용 엔드포인트를 생성할 있다. 이러한 엔드포인트는 Aurora 리더 엔드포인트와 동일한 종류의 로드밸랜싱을 수행한다.

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

 

  

[사용자 지정 엔드포인트 (Customer endpoint)]

Aurora 클러스터의 사용자 지정 엔드포인트는 선택한 DB 인스턴스 집합을 나타낸다. 엔드포인트에 연결하면 Aurora 로드 밸런싱을 수행하고 그룹에서 연결을 처리할 인스턴스 하나를 선택한다. 엔드포인트가 참조하는 인스턴스를 정의하고, 엔드포인트가 어떤 목적으로 사용되는지 결정한다. 사용자 지정 엔드포인트는 클러스터를 생성할 자동으로 생성되지 않으며, 프로비저닝된 Aurora 클러스터에 대해 최대 5개의 사용자 지정 엔드포인트를 만들 있다. Aurora Serverless 클러스터에는 사용자 지정 엔드포인트를 사용할 없다.

사용자 지정 엔드포인트는 DB 인스턴스의 읽기 전용 기능 또는 읽기/쓰기 기능 이외의 다른 조건을 기반으로 로드 밸런싱된 데이터베이스 연결을 제공한다. 예를 들어 특정 AWS 인스턴스 클래스 또는 특정 DB 파라메터 그룹을 사용하는 인스턴스에 연결할 사용자 지정 엔드포인트를 정의할 있다. 또는 보고서 생성 등과 같은 일회성 쿼리 같은 것을 저용량의 내부 서버로 보내고, 고용량 인스턴스로는 프로덕션 트래픽을 보낼 있다.

사용자 지정 엔드포인트와 연결된 모든 DB인스턴스로 연결이 이동할 있기 때문에 해당 그룹내의 모든 DB 인스턴스가 일부 유사한 특성을 공유하는지 확인하는 것이 좋다. 그렇게 하면 성능, 메모리 용량 등이 해당 엔드포인트에 연결하는 모든 사람에게 일관되도록 보장할 있다. 기능은 모든 Aurora 복제본을 동일한 클러스터에 유지하는 것이 적절하지 않은 특수한 종류의 워크로드가 있는 고급 사용자를 위한 것으로 사용자 지정 엔드포인트를 통해 연결에 사용되는 DB 인스턴스를 예측할 있다. 사용자 지정 엔드포인트를 사용할 경우 일반적으로 해당 클러스터에 리더 엔드포인트를 사용하지 않는다. 아래는 Aurora MySQL DB 클러스터의 사용자 지정 엔드포인트를 나타낸 예제이다.

myendpoint.cluster-custom-123456789012.us-east-1.rds.amazonaws.com:3306

 

사용지 지정 엔드포인트의 이름은 최대 63글자 까지 가능하다. 사용자 지정 엔드포인트 이름에는 클러스터 이름이 포함되지 않기 때문에, 클러스터 이름을 바꿀 경우 엔드포인트 이름을 변경할 필요가 없다. 동일한 리전에 있는 이상의 클러스터에 동일한 사용자 지정 엔드포인트 이름을 재사용할 없다. 사용자 지정 엔드포인트에 특정 리전 내의 사용자 ID 소유한 클러스터 전체에서 고유한 이름을 부여한다. 장애 조치 또는 승격으로 인해 DB 인스턴스가 기본 인스턴스와 Aurora 복제본 간에 역할을 변경해도 Aurora 정적 목록 또는 제외 목록에 지정된 DB 인스턴스를 변경하지 않는다. 예를 들어 READER 유형의 사용자 지정 엔드포인트에는 Aurora 복제본 이었다가 이후 기본 인스턴스로 승격된 DB 인스턴스가 포함될 있다. 사용자 지정 엔드포인트 유형 (READER, WRITER 또는 ANY) 따라 해당 엔드포인트를 통해 수행할 있는 작업의 종류가 결정된다. Aurora 복제본을 사용할 없게 경우에도 사용자 지정 엔드포인트와는 연결된 상태로 유지된다. 예를 들어 이상이 있거나, 중지되었거나, 재부팅 되더라도 사용자 지정 엔드포인트의 일부로 유지된다. 그러나 클러스터가 다시 사용할 있게 때까지 기존 엔드포인트를 통해 연결할 없다.

 

[인스턴스 엔드포인트 (Instnace  endpoint)]

인스턴스 엔드포인트는 Aurora 클러스터에 있는 특정 DB 인스턴스에 연결된다. DB 클러스터의 DB 인스턴스에는 각각 고유한 인스턴스 엔드포인트가 있다. 그러므로 DB 클러스터의 현재 기본 DB 인스턴스에 대해 인스턴스 엔드포인트 하나가 있고, DB 클러스터의 Aurora 복제본마다 인스턴스 엔드포인트 하나가 있다.  클러스터 엔드포인트 또는 리더 엔드포인트의 사용이 부적합한 시나리오에서 인스턴스 엔드포인트가 DB 클러스터에 대한 연결을 직접 제어한다. 예를 들어 어플리케이션에서 워크로드 유형에 따라 더욱 세분화된 로드 밸런싱이 필요할 경우 애플리케이션 속성에 따라 각기 다른 Aurora 복제본에 연결한 읽기 워크로드를 분산 시킬 있다. 아래는 Aurora MySQL DB 클러스터의 DB 인스턴스 엔드포인트 예제이다.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

 

고가용성이 중요한 클러스터의 경우 라이터 엔드포인트를 읽기/쓰기 또는 범용 연결에 사용하고 리더 엔드포인트를 읽기 전용 연결에 사용한다. 라이터 리더 엔드포인트는 인스턴스 엔드포인트보다 DB 인스턴스 장애조치를 관리한다. 인스턴스 엔드포인트와 달리 라이터 리더 엔드포인트는 클러스터의 DB 인스턴스를 사용할 없게 되면 연결된 DB 인스턴스를 자동으로 변경한다. 인스턴스 엔드포인트 연결을 관리하는 자체 애플리케이션 로직을 설계하는 경우, DB 인스턴스의 결과 집합을 수동으로 또는 프로그래밍 방식으로 가져올 있다. 그런 다음 장애 조치 이후 인스턴스 클래스를 확인하고 해당 인스턴스 엔드포인트에 연결하면 된다.

 

 

 

[참고자료]

l  Amazon Aurora DB 클러스터 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

l  Amazon Aurora 연결관리 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

 

 

 

 

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

 

 

AWS, Aurora, Aurora Connection Management, Aurora 클러스터 연결, 오로라 클러스터 연결, 오로라 엔드포인트, Aurora endpoint

 

[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, 사전탐지, 장애방지, 장애대응

[AWS RDS] Performance Insight DB부하의 원인 찾기

 

l  Version : Performance Insight

 

AWS RDS 데이터베이스를 사용할 , 데이터베이스 인스턴스의 성능 지표 로그를 CloudWatch에서 수집하여 여러 성능 지표에 대한 모니터링을 진행할 있다. 하지만 슬로우 쿼리, 대기정보, 세션별 쿼리 실행 데이터베이스를 운영하기 위해 조금 자세한 정보를 확인하려면 RDS 성능 개선 도우미(Performance Insight) 사용할 있다.

 

성능 개선 도우미를 사용하려면 DB 인스턴스 또는 다중 AZ DB 클러스터에서 활성화 해야한다. 필요에 따라 활성/비활성이 가능하며, 상태 변경 재부팅 또는 장애조치가 발생하지 않는다. 성능 개선 도우미를 사용하면 에이전트가 실행되는데 이때 약간의 오버헤드가 발생하기 때문에 DB 로드가 높은 경우 수집 빈도를 조절하여 사용할 있도록 한다.

 

성능 개선 도우미는 콘솔에서 쉽게 설정이 가능하며 AWS CLI RDS API 통해서도 설정이 가능하다.

 

성능 개선 도우미의 활성화에 대한 자세한 내용은 아래 공식 문서를 참고 한다.

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

 

성능 개선 도우미에 액세스 하려면 IAM(Identity and Access Management) 적절한 권한이 있어야 한다. IAM 대한 정책은 아래 문서를 참고한다.

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

 

성능 개선 도우미의 대시 보드는 기본적으로 마지막 1시간 동안 수집된 데이터를 표시한다.

 

대시보드는 아래와 같이 부분으로 나눌 있다.

l  카운터 지표 : 특정 성능 카운터 지표의 데이터를 표시

l  DB 부하 차트 : DB 부하와 DB 인스턴스 용량을 비교하여 최대 vCPU 선으로 표시

l  상위 항목(Top Item) : DB 로드에 기여하는 상이 차원을 표시

 

부분에 대한 자세한 내용은 아래 링크를 참고한다.

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

 

대시보드 화면의 데이터베이스 로드(Database load) 차트에서는 병목 현상에 대한 정보를 확인할 있다. 어떤 데이터베이스 로그가 최대 CPU(Max CPU) 선을 상회하는지 확인할 있고 어떤 작업이 DB 부하를 차지하는지 보여준다. 아래 그림에서는 로그 파일 동기화 대기 시간이 대부분의 DB 부하를 차지한다. 그리고 LGWR all worker groups 대기 시간도 높다. TOP SQL 차트는 로그 파일 동기화 대기의 원인에 사용된 SQL 구문인 COMMIT 문을 보여준다.

 

TOP SQL 에서는 데이터베이스 로드에 영향을 미치는 상위 SQL 쿼리가 표시된다. TOP SQL 탭에서는  SQL 통계(SQL Statistics) 대기별 로드(AAS), SQL 정보, 환경설정 정보 등을 확인할 있다.

 

SQL 통계 (SQL Statistics) SQL 쿼리에 대한 성능 관련 지표이다. 초당 실행 횟수 초당 처리된 행을 표시한다.

 

 

대기 시간별 로드(Load by waits AAS) 상위 로드 항목과 연결된 데이터베이스 로드의 비율을 나타낸다. 예를 들어 DB 로드 차트를 대기 상태별로 그룹화 있다. 쿼리가 영향을 미치는 대기 상태의 정도를 크기, 세그먼트 컬러 코드로 표시한다.

 

 

SQL 정보에서는 TOP SQL 실행된 쿼리와 SQL ID, Support Digest ID등을 확인할 있다.

 

환경설정에서는 수집되는 항목을 설정 있다.

 

 

위에서 나열한 항목의 자세한 내용은 아래 공식 문서를 참고 한다.

l  상위 SQL(Top SQL) 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.html

 

 

기본적으로 TOP SQL 테이블의 행에는 SQL 문에 대해 500 byte SQL 텍스트가 표시된다. SQL 문이 500byte 이상인 경우 성능 개선 도우미 대시보드에서 해당문을 열어 많은 텍스트를 있다. 경우 최대 4KB까지 표시된다. 또한 쿼리를 다운로드 있다. TOP SQL 텍스트에 대한 자세한 내용은 아래 문서를 참고 한다.

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

 

 

성능 개선 도우미를 사용할 있는 RDS 엔진 버전은 지속적으로 업데이트 되므로 항상 최신의 정보를 확인할 있도록 아래 링크의 공식 문서를 참고한다. 현재 Aurora 서버리스는 성능 개선 도우미를 지원하지 않는다.

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

성능개선 도우미는 대부분의 리전에서 사용 가능하며, 아래 링크를 참고한다.

l  AWS성능 개선 도우미를 위한 리전 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Regions.html

 

 

 

[참고자료]

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

 

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

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선

Docker Deploy

 

·         Version : Docker

 

문서는 Docker 공식 문서를 번역한 내용이며 필자의 생각과 의견이 반영되어 있습니다. 자세한 내용은 원문을 참고 바랍니다.

 

Prerequisites

Docker Deploy 학습하기 전에 아래 사항이 선행되어야 한다.

·         Docker Install : https://docs.docker.com/install/

·         Docker Orientation : http://sqlmvp.kr/221419558020

·         Docker Containers : http://sqlmvp.kr/221423910065

·         레지스트리에 푸시하여 작성한 friendlyhello이미지를 게시했는지 확인한다. 이번 포스트에서는 레지스트리에 공유된 이미지를 사용한다.

·         이미지가 배포된 컨테이너가 작동하는지 확인한다. 아래 명령어를 사용하여 컨테이너를 실행하고 정상적으로 브라우저에서 접속이 되어야 한다. Username, reop 위치는 사용자에 따라 변경하여 사용한다.

docker run -p 4000:80 username/repo:tag

http://localhost:4000

 

·         Docker Stack에서 다룬 docker-compose.yml 사본을 준비한다.

o   Docker Stack : http://sqlmvp.kr/221436710686

 

 

Introduction

이번 포스트에서는 Dockerized 애플리케이션을 실행하기 위한 가지 옵션을 살펴보고 이전까지 다루었던 내용을 정리한다.

 

Docker Enterprise

Docker Enterprise Edition 고객은 Docker Engine 안정적이고 상업적으로 지원되는 버전을 실행하며 애드온으로 DMC(Docker Datacenter)라는 최상급 관리 소프트웨어를 제공한다. Universal Control Plane 사용하여 인터페이스를 통해 애플리케이션의 모든 측면을 관리하고 Docker Trusted Registry 개인 이미지 레지스트리를 실행하고 LDAP 제공업체와 통합하고 Docker Content Trust 사용하여 프로덕션 이미지에 서명할 있다.

Docker Enterprise 자신의 서버를 가져오고 Docker Datacenter 설정하려면 기본적으로 단계가 필요하다.

·         Docker Hub에서 서버 OS Docker Enterprise 구입 : https://hub.docker.com/search/?offering=enterprise&type=edition

·         Docker Enterprise 자신의 호스트에 설치 : https://docs.docker.com/ee/end-to-end-install/

참고 : Windows서버에서 컨테이너 실행 : https://docs.docker.com/install/windows/docker-ee/

 

일단 모든 설정이 완료되고 Docker Enterprise 실행중이면 UI내에 직접 작성된 파일을 배포할 있다.

·         Deploy a multi-service app :  https://docs.docker.com/ee/ucp/swarm/deploy-multi-service-app/

 


후에 실행중인 것을 있으며 선택한 응용 프로그램의 어떤 부분을 변경하거나 작성 파일 자체를 편집할 있다.

 

 

Docker Engine – Community

Docker Engine Community 대한 설치 가능 플랫폼 확인 아래 링크에서 참고한다.

·         Docker supported platforms :  https://docs.docker.com/install/#supported-platforms

아래 명령을 사용하여 노드에 Docker Swarm 생성한다.

docker swarm init

 

아래 명령을 사용하여 stack 배포 한다.

docker stack deploy -c docker-compose.yml getstartedlab

 

아래 명령은 노드에 포함된 머신을 확인한다.

docker node ls

 

아래 명령은 서비스를 나열한다.

docker service ps <sevice>

 

지금까지 실습했던 서비스와 통신하기 위해서는 아래의 포트를 허용해야 한다.

·         많은 노드를 사용하는 경우 redis 서비스와 web 서비스간의 통신 허용

·         Hello World Visualizer 브라우저에서 엑세스 있도록 모든 작업자 노드에서 web 서비스로 인바은드 트래픽 허용

·         Manager 실행중인 서버에서 인바운드 SSH 트래픽을 허용 (클라우드 공급자에 이미 설정되어을 있음)

아래는 서비스에 대해 오픈 해야하는 포트이다.

Service

Type

Protocol

Port

web

HTTP

TCP

80

visualizer

HTTP

TCP

8080

redis

TCP

TCP

6379

 

예를들어 AWS(Amazon Web Services)에서 데이터를 redis 보존할 경우 redis 서비스가 작동하려면 manager 실행중인 클라우드 서버로 ssh하고 docker stack deploy하기 전에 /home/docker에서 /data 디렉터리를 만들어야 한다. 다른 옵션은 docker-stack.yml 데이터 경로를 manager 서버의 기존 경로로 변경하는 것이다. 예제는 단계를 포함하지 않으므로 예제 출력에서 redis서비스가 작동하지 않는다.

 

·         docker-compose.yml 파일을 변경하여 응용 프로그램의 크기를 조정하고 docker stack deploy명령을 사용하여 즉석에서 다시 docker stack deploy 한다.

·         코드를 편집하여 응용프로그램 동작을 변경한 다음 이미지를 다시 작성하고 푸시한다.

·         docker stack rm 명령을 사용하여 스택을 해제 있다.

Docker stack rm getstartedlab

 

 

 

[참고자료]

https://docs.docker.com/get-started/part6/

 

 

 

2019-01-13 / Sungwook Kang / http://sqlmvp.kr

 

 

deployproductiondatacentercloudawsazureprovideradminenterprise

+ Recent posts