[Prometheus] Prometheus 구조 및 개념

 

l  Prometheous

 

Prometheus(프로메테우스) 모니터링 시스템은 오픈 소스 기반의 모니터링 시스템으로 Kubernetes(쿠버네티스) 활성화 함께 많이 사용되고 있다. 물론 쿠버네티스 환경 외에도 일반적인 온프레미스 환경에서도 사용이 가능하여 많은 인기를 끌고 있다.  현재 CNCF(Cloud Native Computing Foundation)에 소속되어 있다.

 

프로메테우스는 구조가 간단하며, 운영이 쉽고 강력한 쿼리 기능을 가지고 있다. 간단한 텍스트 형식으로 메트릭 데이터를 쉽게 익스포트 할 수 있으며, key-value 형식의 데이터 모델을 사용한다. 수집된 데이터는 Grafana(그라파나)를 통해 시각화를 제공한다.

 

프로메테우스는 순전히 숫자로 된 시계열을 기록하는 데 적합하다. 기계 중심 모니터링과 고도로 동적인 서비스 지향 아키텍처 모니터링 모두에 적합하다. 프로메테우스는 중단 중에 신속하게 문제를 진단할 수 있도록 하는 시스템으로서 안정성을 위해 설계되어있으며, 각 프로메테우스 서버는 독립형으로 동작하며, 네트워크 스토리지 또는 기타 원격 서비스에 의존하지 않는다.

 

대부분의 모니터링 시스템은 타켓 서버(모니터링 대상 서버)에 에이전트를 설치하여 중앙의 모니터링 수집 서버로 push(푸시) 하는 방식인데, 프로메테우스는 pull(풀) 방식을 사용하여 데이터를 수집한다. 즉 모니터링 대상 서버에 exporter(익스포터)라는 에이전트가 실행되어 있으면, 주기적으로 에이전트에 접속하여 데이터를 가져오는 방식이다.

 

l  Jobs / Exporter : 프로메테우스가 모니터링 데이터를 가져갈 수 있도록 타겟 서버에 설치되는 에이전트 이다. 서버 상태를 나타내는 Node exporter, DB의 상태를 나타내는 SQL Exporter 등 다양한 커스텀 익스포터들이 개발되어 사용되고 있다. 익스포터 자체는 특별한 기능을 수행하지 않는다. 프로메테우스의 요청이 있을 때 그 시점에 메트릭을 수집하여 http get 방식으로 리턴한다. 히스토리를 저장하지 않기 때문에 시점의 값만 알 수 있다.

l  Pushgateway : Pushgateway는보안상의 이유로 프로메테우스가 직접 익스포터에 연결 할 수 없을 때, Proxy Forwarding을 사용하여 메트릭 데이터를 수집할 수 있도록 해주는 서비스이다. Application 이 pushgateway 에 메트릭 데이터를 푸쉬하면, 프로메테우스 서버가 pushgateway 에 접근해 메트릭 데이터를 풀 하는 방식으로 동작한다.

l  Alertmanager: Alertmanagr는 메트릭에 대한 특정 룰을 설정하고 그 규칙을 위반하는 사항에 대해 알람을 전송하는 역할을 한다. 예를들면 “CPU 사용률이 50% 이상일때 알람을 보낸다.” 라고 룰을 설정하면, 수집된 CPU 메트릭의 값이 50 이상일때 알람을 발송한다.

l  Service discovery : 프로메테우스는 기본적으로 풀 방식을 사용하여 모니터링을 하기 때문에 모니터링 대상 서버의 목록을 유지하고 있어야 한다. 쿠버네티스 환경처럼 오토스케일이 발생할 경우, 타겟 서버의 IP가 가변적이어서 수집할 서버의 목록을 확인할 수 없는 경우가 많다. 이런 경우 모니터링 대상 목록을 관리하기 위해 서비스 디스커버리를 사용하여 유지한다.

l  Retrieval : 익스포터로 부터 주기적으로 메트릭을 수집하는 모듈이며, 서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오는 역할도 수행하는 컴포넌트이다.

l  HDD/SDD : 수집된 데이터는 프로메테우스 서버의 로컬 메모리와 디스크에 저장된다. 단순하고 사용이 쉬운 방면, 별도의 데이터베이스가 없으므로 확장이 불가능하다.

l  Data visualization : 저장된 메트릭은 PromQL 쿼리 언어를 사용하여 조회가 가능하다. 또한 외부 API나 프로메테우스 웹콘솔을 사용하여 visualization 을 구성할 수 있다.

 

프로메테우스 서버는 독립적인 구조로 운영되기 때문에, 많은 수의 모니터링 서버에서 대량의 메트릭을 수집할 때 프로메테우스 서버의 시스템 리소스가 부족할 경우 확장이 불가능한 구조로 되어 있다. 또한 프로메테우스 서버가 다운되거나 설정 변경으로 인한 재시작시 메트릭이 저장되지 않고 유실되는 문제가 있다. 이러한 문제를 수정하기 위해 프로메테우스 서버를 다양한 형태로 구성 및 운영하기 위한 노하우가 필요 하다. 이 부분은 다른 포스트에서 다루어 본다.

 

 

 

참고자료 :

https://prometheus.io/docs/introduction/overview/

 

 

2023-06-28 / Sungwook Kang / https://sungwookkang.com

 

 

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스

저작자표시 비영리 변경금지

'SW Engineering > DevOps, SRE' 카테고리의 다른 글

[Prometheus] Prometheus Thanos 아키텍처 살펴보기  (0) 2023.06.29
[Prometheus] Prometheus 확장 및 내구성을 위한 다양한 구성 방법들  (0) 2023.06.28
Kubernetes 장점  (0) 2021.07.31
Kubernetes 마스터 노드, 워커 노드  (0) 2021.07.29
SRE (Site Reliability Engineering) 역할  (0) 2020.05.14

[스마트팜] Arduino IDE 설치 및 세팅 (with ESP32 보드)  

 

스마트팜을 제어하기 위해 사용된 아두이노 IoT 시스템을 개발하기 위한 환경 세팅에 대해서 알아본다. 필자의 스마트팜에 사용된 환경은 Arduino IDE 와 ESP32 보드를 사용하였으므로 이번 포스트에서는 IDE 설치 및 보드에 대한 드라이버 설치까지의 과정을 다룬다.

(다른 보드를 사용한다면 드라이버만 다를 뿐 설치 방법은 동일하다.)

 

Arduino IDE를 다운받기 위해서 아래 주소로 접속하여 OS에 맞는 설치 버전을 선택한다.

l   https://www.arduino.cc/en/software

 

 

 

필자의 경우 Windows 11환경에서 설치를 진행하였으며, 설치 스크린샷 또한 Windows 환경에서 캡처한 것이다. OS에 맞는 설치 파일을 클릭하면 다운로드 페이지로 이동되는데, 이때 다운로드만 하려면 “JUST DOWNLOAD”를 선택하고, 기부 후 다운로드 하려면 “CONTRIBUTE & DOWNLOAD”를 선택한다.

 

 

설치 파일을 다운로드 하고, 실행하면 설치 과정이 진행된다. 사용권 계약에서 “동의함”을 선택한다.

 

 

설치 옵션에서, 필요한 사용자를 선택 한 후 다음을 클릭한다. 필자의 경우 누구나 IDE를 실행할 수 있도록, 모든 사용자 옵션을 선택하였다.

 

 

다시 한번 사용권 계약 단계에서 “동의함”을 선택한다.

 

 

사용자 환경에 따라 설치 위치를 선택한다. 필자는 기본 경로 그대로 사용하였다.

 

 

설치가 진행된다.

 

 

설치 과정에서 추가로 필요한 소프트웨어 팝업이 나타나면 설치를 진행한다. 사용자 상태에 따라 해당 설치 과정이 나타나지 않을 수 있는데, 해당 단계가 나타나지 않으면 이 포스트 하단에 USB 드라이버 추가 설치 과정이 있으니 참고할 수 있도록 한다.

 

 

설치가 완료되면 아래와 같은 화면이 나타나며, 마침을 클릭하면 Arduino IDE가 실행된다.

 

 

Arduino IDE 가 실행될 때, 아래와 같이 Windows 보안 경고가 나타나면 “액세스 허용”을 선택한다.

 

아래 그림처럼 Arduino IDE가 실행된 것을 확인할 수 있다.

 

 

지금까지는 Arduino IDE 툴만 설치된 상태이다. ESP32보드를 연결하려 해당 보드에 대한 드라이버를 설치해야 한다. [파일] – [환경설정]을 클릭한다.

 

 

추가적인 보드 매니저 URLs에서 우측의 버튼을 클릭한다.

 

 

팝업이 나타나면 아래 URL을 입력하고, 확인을 클릭한다.

l   https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json

 

 

속성 창에서 확인을 클릭하면 해당 변경사항이 적용된다.

 

 

[Tool] – [Board] – [Board Manager]를 선택 한다.

 

 

검색창에서 “ESP32”를 입력하면 설치할 수 있는 패키지가 검색되며, 필요한 버전을 선택하여 설치한다. 필자의 경우 최신 버전을 선택하여 설치하였다. Output창에서 설치 과정을 확인할 수 있다.

 

 

패키지 인스톨이 완료되었으면, [Too] – [Board] – [esp32] – [ESP32 Dev Module]를 선택한다. 사용자의 보드에 따라 적절한 디바이스를 선택하면 된다.

 

 

모듈이 선택되고 나면, [Tool] 메뉴에서 선택된 모듈에 대한 정보를 확인할 수 있다.

 

 

 

USB 드라이버 설치 :

Arduino IDE 툴에서 Port 선택이 안되는 경우에는 시스템에서 USB 드라이버 설치가 정상적으로 설치되지 않았을 가능성이 크다. 윈도우에서는 장치관리자에서 아래와 같이 확인할 수 있다.

 

 

아래 사이트에서 OS에 적합한 드라이버를 다운로드한다.

l   https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers?tab=downloads

 

 

다운로드 받은 경로로 드라이버 업데이트를 진행한 다음, 정상적으로 설치가 되면 아래와 같이 포트 번호를 확인할 수 있다.

 

 

지금까지 설치과정으로 IDE 설치 및 드라이버 설치가 완료된 상태로, 이제 사용자에게 필요한 프로그램을 작성하고 보드에 업로드 할 수 있는 환경이 준비완료 되었다.

 

2023-06-10 / Sungwook Kang / http://sungwookkang.com

 

 

스마트팜, Agricultural technology, Agritech, foodtech, 식물 공장, 에어로팜, 분무수경, 수경재배, 아두이노, ESP32, Arduino

 

저작자표시 비영리 변경금지

'스마트팜 일기' 카테고리의 다른 글

[스마트팜] 팜랩에 구성된 스마트팜(에어로팜) 훑어보기  (1) 2023.03.23
[스마트팜] 나는 왜 농업(스마트팜)에 관심을 가지게 되었나?  (0) 2023.03.18

[스마트팜] 팜랩에 구성된 스마트팜(에어로팜) 훑어보기

 

팜랩(이라 쓰고, 방구석 팜이라 읽는다.)에 구성된 시스템에 대한 전체적인 구조를 살펴본다. 이번 포스트는 현재 구성되어 있는 팜의 컨셉 및 전체적인 모습을 간략히 설명하고, 자세한 제작 과정은 다른 포스팅에서 하나씩 제작 과정을 다뤄 볼 예정이다.

 

참고로 글쓴이의 경우 농사를 경험 해본적이 없고, 친인척, 지인 통틀어 농사와 관련된 사람이 없기 때문에 순수하게 데이터(매뉴얼) 관점에서 재배를 도전하는 중이며, 이 프로젝트의 컨셉이 “데이터로만 농사를 지을 수 있을까?” 라는 것을 미리 알려둔다. 그래서 모든 부분을 데이터로 관리하고, 최대한 자동화 하여 사람의 손은 최소한으로 투입하는 것을 목적으로 하고 있다.

 

현재 구성되어 있는 팜은 “에어로팜”으로 “분무수경”이라고도 한다. 말 그대로 분무 방식으로 식물을 키우는 것이다. 수경재배는 대부분의 사람들이 잘 알고 있는데, 수경재배는 물에서 식물을 키우지만, 분무는 직접 뿌리에 물을 분사하여 키우는 방식이다. 여려 재배 방식마다 장단점이 있는데, 이러한 부분은 다른 포스팅에서 다뤄본다.

 

아래 사진은 현재 운영중인 나의 1호 스마트팜이다. 첫 제작은 빠르게 만들어서 시작을 해본다(?) 라는 컨셉이어서 전선 및 여러가지가 많이 정리되지 않은 상태이다. 아무래도 팜에는 물이 사용되기 때문에 전기 부분은 매우 조심해야 할 부분이다. 그래서 현재 2개의 랙을 추가하면서 전기 배선 정리 및 안전을 위해 전원부를 상단에 배치하는 등의 약간 업그레이드를 하고 있다.

 

팜을 제작할 때, 최대한 작업의 손을 덜 타기 위해 규격품을 사용하려고 노력했고, 그 결과 랙(팜)의 사이즈는 일반 공사 현장(?)에서 사용되는 표준 스펙으로 제작 되었다. 팜의 크기는 가로 200cm X 세로 90cm X 높이 200cm 로 제작되었다. 대부분의 자재들은 동네 철물점, 다이소 (정말 큰 역할 했음), 온라인 쇼핑몰을 통해서 준비하였다.

 

베드는 스티로폼을 사용하였고, 방수를 위해 PVC 패널을 내부에 장착했다. 분무를 위해 PVC파이프에 노즐을 장착하였다. 현재 상추 뿌리가 많이 자란 상태이며, 건강한 상추는 아래 사진과 같이 새하얀 뿌리를 가지고 있다. 초반에 우여곡절이 많아 뿌리가 검게 탄 상추들도 보인다.

 

 

실내이기 때문에 빛을 보강하기 위해 인공광원으로는 적청색 LED 및 주광색 LED를 사용하였다. LED 발열이 있기 때문에 방열판 역할을 할 수 있는 지지대를 사용하였다. 현재 룩스는 15000lx를 확보했지만, 태양빛을 따라 가기엔 역부족이다. 하지만 룩스를 올리려면 더 많은 조명이 필요한데, 전기세 걱정도 있지만 발열로 인한 온도 부분도 문제가 되기 때문에 추가 냉각장치 등을 고려하면 여러 시스템이 필요하게 되어 비용이 급상승한다.

 

공기중 온습도, 수온, 펌프 컨트롤등의 각종 센서 및 컨트롤러는 아두이노  ESP32 보드를 사용하였다. 이 보드의 특징은 WiFi 및 Bluetooth 모듈이 장착되어 있어, 별도의 WiFi 모듈을 장착하지 않고도 인터넷에 연결할 수 있다. 아두이노에서 중앙서버와 통신하며 데이터 전송 및 컨트롤에 대한 정보를 수신한다. 각 시스템별로 별도의 아두이노가 장착되어 운영되고 있다.

 

 

에어로팜(분무수경) 방식이기 때문에, 분무를 분사하기 위해서는 어느정도 높은 압력이 필요하다. 현재 일반 가정집 환경에서 랩을 구성하였기 때문에 압력이 높으면서 최대한 소음이 적은 제품을 선별하였다. 이 또한 국내에는 적절한 것을 찾지 못하여, 캠핑카에 사용되는 펌프를 아마존에서 주문했다. 미국에서 배송되어 배송 기간이 2주이상 소요되었는데, 국내에도 잘 찾아보면 적당한 펌프가 있으리라 생각된다. 아무리 저소음이어도 일반적으로 생활하기에는 소음으로 인해 별도 공간을 분리할 수 밖에 없다. 상대적으로 조용한것이며 절대적인 소음으로는 직접 겪어보면 옆집에 민폐가 발생할 수도 있다. 사진처럼 방음 박스를 만들고 차음재, 흡읍재 등 사용했음에도 불구하고, 펌프 진동 및 소음이 일상 생활하기에는 많이 거슬린다. (그래서 결국 식물에 방을 양도하고 워크 스페이스를 다른 방으로 옴겼다.)

 

양액 탱크이며, 현재 관수 시설이 되어 있지 않아 양액 보충 및 농도 조절은 수동으로 하고 있다. 이 부분도 자동화를 하고 싶은 마음은 있지만 일반 가정집의 방에 구성하였기에 관수 시설을 설치하기에는 여러 어려움이 있다. (심지어 현재 이 글을 쓰는 시점에는 집 인테리어를 새로 리뉴얼한지 1년 조금 지난 시점이어서 벽지나 기타 방에 있던 무언가에 어떤 문제가 생기면 …뒷말은 생략한다.)

중앙 서버 및 데이터 저장을 위한 데이터베이스는 큰 스펙이 필요하지 않기에 사용하지 않는 랩탑을 사용하였으며, Python Fast API로 서버를 만들고, DB는 SQL Server 무료버전을 사용하였다. 모니터링을 위한 대시보드는 그라파나(Grafana) 오픈소스를 사용하여 제작하였으며 실시간 모니터링을 하고 있다. 웹브라이저로 접근이 가능하기 때문에 외부에서도 모니터링 할 수 있다.

 

아직 준비 되지 않은 부분은 이상현상이 발생하였을 때, 사용자에게 알람을 푸시해 주는 기능과, 냉각 및 보온에 대한 자동화 부분이 준비 되지 않은 터라 이 부분은 향후 개선할 예정이다.

 

이 글을 보고 집에서 스마트팜을 구성하려는 사람이 있을꺼라 생각하는데, 실제로 취미로 즐기기엔 예상보다 많은 비용과 시간이 필요하다. 팜을 만들기 위한 자재비도 자재비지만, 냉각을 위한 에어컨, 히터등도 구비해야하기에 사실상 비용 부분으로 인해 접근이 쉽지 않은 부분이 있다. 또한 모든 자재를 구입해서 DIY 하였기에 노동의 시간도 많이 필요하였다.

 

 

이번 포스트에서는 전체적인 팜 구성에 대하서 살펴보았으며, 다른 포스트에서 팜의 제작과정을 다뤄 보도록 한다.

 

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

 

 

스마트팜, Agricultural technology, Agritech, foodtech, 식물 공장, 에어로팜, 분무수경, 수경재배

 

저작자표시 비영리 변경금지

'스마트팜 일기' 카테고리의 다른 글

[스마트팜] Arduino IDE 설치 및 세팅 (with ESP32 보드)  (0) 2023.06.10
[스마트팜] 나는 왜 농업(스마트팜)에 관심을 가지게 되었나?  (0) 2023.03.18

[스마트팜] 나는 왜 농업(스마트팜)에 관심을 가지게 되었나?

 

“후진국이 공업 발전을 통해 중진국이 될 수는 있으나 농업 발전 없이는 선진국이 될 수 없다”
-  사이먼 쿠즈네츠 (노벨 경제학상 수상, 1971) -

 

한국은 불과 한 세대 전까지만 해도 농업이 주류였다. 그러나 산업화 과정을 겪으면서 많은 사람들이 도시로 몰렸고, 그 결과 농업에 대한 관심 및 인구가 급격하게 줄기 시작했다. 그리고 언제부턴가 농업은 사양 산업으로 인식되었다. 이러한 현상은 비단 우리나라 뿐만 아니라 전세계적으로 산업화 과정에서 발생하는 자연스러운 현상이었다.

산업화의 발달과 함께 의식주 및 위생, 공중보건, 의료 서비스 등이 발전하면서 과거에 비해 질병으로 인한 사망자 감소와 함께 평균 수명 증가로 인해 인구 또한 지속적으로 증가할 것이라고 예상하고 있다. 유엔의 발표에 따르면 2018년 기준 세계 인구는 75억명으로 2050년에는 100억 명에 달할 것으로 예상하고 있다.

출처 : https://www.hani.co.kr/arti/science/future/1067089.html

 

하지만 자연 환경 파괴 및 지속적인 기후변화로 인해 식량 생산량은 오히려 감소하고, 저소득층은 극빈층으로 전락할 것(2016 식량농업 상황 보고서, 국제연합식량농업기구(FAO))이라는 연구 결과가 나오기도 했다. 즉 향후 세계적으로 식량 안보의 위협을 경고하고 있다.

l   2016‑2025년 OECD‑FAO 농업 전망 : https://www.oecd-ilibrary.org/sites/3b0157bb-ko/index.html?itemId=/content/component/3b0157bb-ko

 

통계청 자료(통계청, 한국의 SDGs 이행보고서 2022)에 따르면, 세계 7대 곡물 수입국인 한국의 곡물 자급률은 2020년 기준 20.2%이다. 쌀을 제외한 나머지 곡물의 자급률은 두류가 7.5%, 옥수수 0.7%, 밀 0.5% 등으로 매우 심각한 수준이다.

 

 

미국의 경우 곡물자급률은 120.1%, 캐나다는 192%, 중국은 91.1%이다. 아래 그림은 2018년 세계 곡물 자급률에 대한 자료이다.

출처 : https://www.nongmin.com/323642

 

l   한국의 SDGs 이행보고서 (사회, 경제, 환경 전반에 걸친 한국의 지속가능발전 이행현황을 유엔 SDGs 지표에 근거하여 분석한 보고서) : https://kostat.go.kr/board.es?mid=a90107000000&bid=12317

 

즉, 주로 식량을 수입하는 한국의 입장에서는 주요 곡물 생산국의 상황(기후 변화, 전쟁 등)에 따라 경제적인 물가 영향은 물론이며, 식량이 무기화 되었을 때 가장 큰 타격을 입게 되는 나라 중 하나인 것이다.

 

 

지금까지의 글을 통해서 기후변화에 따른 식량 위에게 대해서 심각하게 다루었는데, 이러한 위기를 벗어나기 위해 내가 무엇인가 대단한 일을 하겠다는 것은 아니다. 다만 나라도 이렇게 관심을 가지고 있다 보면 누군가 또 이러한 문제게 관심을 가지고, 그렇게 점점 확장이 되다 보면 무언가 변화가 있지 않을까 해서이다.

그렇다면 농업에서도 왜 스마트팜에 관심을 가진것일까? 사실 농업의 중요성은 어릴 때부터 관심이 많은 분야였다. 하지만 도시에서 태어나서 도시에서 자란 나는 농사를 접할 기회가 없고 (친인척도 농사를 짓는분은 없엇음) 이미 산업화를 거쳐 정보화 시대를 살고 있는 세대이며, 가지고 있는 기술 또한 IT 이다 보니 내가 가지고 있는 기술을 농업에 활용할 수 있는 방법이 없을까 고민하다가 도심속에서도 생산이 가능한 스마트팜에 관심을 가지게 되었다. 또한 대부분 도시에서 자란 나의 세대들은 시공간 제약으로 인해 최대한 도시 환경에서 활용할 수 있는 것을 찾다보니 스마트팜에 이르렀다.

 

그래서 나는 나만의 작은 프로젝트를 진행해 보기로 했다. 생활공간의 일부를 할당하여 작은 스마트팜 연구실을 만들었다. 그리고 나는 테크의 관점에서 농업에 접근하기로 했다. 즉, 인공적인 환경에서 데이터로 식물을 키울 수 있는가에 대한 실험을 하기로 하였다. 이미 수 많은 기업들이 스마트팜을 운영하고 있고, 여러 사례 및 자료가 있지만 일반인들까지 범용적으로 적용할 수 있는 환경을 고민하고 표준화 하여 누구나 쉽게 접근을 할 수 있도록 하는 것이 목표이다. 집에서 스마트팜을 만드는 과정 및 식물을 키우는 운영 과정을 하나의 일기처럼 공유해볼 생각이다. 아래 사진은 나의 첫 스마트팜(분무수경 방식)에서 상추가 자라고 있는 모습이다.

 

 

2023-03-18 / Sungwook Kang / http://sungwookkang.com

 

 

스마트팜, Agricultural technology, Agritech, foodtech, 식물 공장, 에어로팜, 분무수경, 수경재배

저작자표시 비영리 변경금지

'스마트팜 일기' 카테고리의 다른 글

[스마트팜] Arduino IDE 설치 및 세팅 (with ESP32 보드)  (0) 2023.06.10
[스마트팜] 팜랩에 구성된 스마트팜(에어로팜) 훑어보기  (1) 2023.03.23

[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] AWS Redshift Serverless 사용량을 확인하여 빌링비용 예상하기  (0) 2023.01.12
[AWS Aurora] Aurora PostgreSQL Auto Vacuum 이해하기  (0) 2022.10.27
[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징  (0) 2022.07.25
[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11

[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' 카테고리의 다른 글

[AWS] AWS Redshift 실행된 쿼리 및 Slow query 확인  (0) 2023.02.19
[AWS Aurora] Aurora PostgreSQL Auto Vacuum 이해하기  (0) 2022.10.27
[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징  (0) 2022.07.25
[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11

SQL Server DELAYED_DURABILITY 옵션으로 트랜잭션 로그 쓰기 성능 개선 하기

 

l  Version : SQL Server

 

SQL Server 데이터베이스에는 모든 트랜잭션과 각 트랜잭션에 의해 적용된 데이터베이스 수정 내용을 기록하는 트랜잭션 로그가 있다. 트랜잭션 로그는 데이터베이스의 매우 중요한 요소로 시스템 오류가 발생한 경우 데이터베이스를 일관된 상태로 다시 전환하려면 이 로그가 필요하다.

l  트랜잭션 로그 아키텍처 : https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16

 

데이터베이스에 대량의 쓰기 작업이 발생하면 트랜잭션 로그에는 변경사항을 기록하기 위해 오버헤드가 발생하면서 로그 쓰기 작업(Write Log)이 지연되는 경우가 발생한다. 로그 모니터링을 통하여 Write Log에 지연이 발생할 경우 DELAYED_DURABILITY 옵션을 사용하여 해당 문제를 개선할 수 있다. 이 옵션을 사용할 경우 트랜잭션 로그의 커밋을 기다리지 않기 때문에 워크로드의 대기 시간이 줄어들어 성능 개선은 있지만 트랜잭션 데이터를 소실할 수 있기 때문에 주의해서 사용해야 한다. 이번 포스트에서는 DELAYED_DURABILITY 옵션에 대한 특징을 살펴보고, 어떠한 경우에 사용할 수 있는지 살펴본다.

 

SQL Server는 트랜잭션 로그 파일에 데이터를 저장해야 할 때 트랜잭션 로그 파일이 저장된 디스크에 직접 데이터를 기록하지 않는다. 대신 모든 데이터는 인메모리 구조인 로그 캐시(로그 버퍼, 또는 로그 블록 이라고 불리기도 한다.) 에 직렬로 기록된다. 또한 SQL Server OS는 ACID 원칙을 준수해야 하므로 전체 로그 캐시를 디스크 하위 시스템에 저장하거나 필요한 경우 롤백 되는 트랜잭션 로그 파일로 플러시 한다. 로그 캐시의 크기는 512B ~ 64KB이다.

 

로그 캐시는 특정 조건에서 디스크로 플러시 된다.

l  트랜잭션이 커밋될 때

l  로그 캐시가 가득 차서 60KB에 도달했을 때

l  Sys.sp_flush_log가 실행될 때

l  CHECKPOINT 프로세스가 완료 되었을 때

 

SQL Server는 로그 캐시가 트랜잭션 로그 파일로 플러시 되기 시작하는 순간 WRITELOG 대기 유형에 등록되고 로그 캐시가 메모리에서 디스크 드라이브의 파일로 데이터 플러시를 완료 할 때까지 해당 시간이 누적된다. 이 누적시간이 낮을수록 트랜잭션 로그파일의 쓰기 대기 시간이 낮아 진다.

 

SQL Server에서는 기본적으로 동기 트랜잭션 커밋을 사용하기 때문에 트랜잭션에 대한 로그 레코드가 디스크에 기록된 후에만 커밋을 성공으로 보고하고 클라이언트에 컨트롤을 반환한다. 따라서 이러한 커밋이 느릴수록 클라이언트에서는 느린 응답을 받을 수밖에 없다. 동기 커밋은 아래와 같은 완전 내구성이 있는 환경의 경우 필수적으로 사용해야한다.

l  시스템에서 데이터 손실을 허용할 수 없는 경우

l  병목 현상의 원인이 트랜잭션 로그 쓰기 대기 시간이 아닌 경우

 

DELAYED_DURABILITY 옵션을 활성화 할 경우, 비동기 트랜잭션 커밋을 사용하기 때문에 트랜잭션에 대한 로그 레코드가 디스크에 기록되기 전에 커밋 성공으로 클라이언트에 컨트롤을 반환하기 때문에 클라이언트에서는 빠른 응답을 얻을 수 있다. 또한 동시 트랜잭션의 로그 I/O 경합 가능성이 낮아지고, 더 큰 청크 구성으로 디스크에 플러시하여 경합을 줄이고 처리 속도를 높일 수 있다. 비동기 커밋의 경우 아래와 같은 환경에서 사용할 수 있다.

l  약간의 데이터 손실을 허용하는 경우

l  트랜잭션 로그 쓰기 중에 병목 현상이 발생하는 경우

l  작업의 경합률이 높은 경우

 

DELAYED_DURABILITY 옵션은 데이터베이스 수준에서 트랜잭션 내구성 수준을 제어할 수 있다. 아래 스크립트는 DELAYED_DURABILITY 옵션을 데이터베이스 수준에서 변경한다.

ALTER DATABASE ... SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }

 

l  DISABLED : 기본값으로 커밋 수준 설정 (DELAYED_DURABILITY={ON|OFF})에 상관없이 데이터베이스 커밋된 모든 트랜잭션이 완전 내구성을 가진다. 저장 프로시저를 변경하고 다시 컴파일할 필요가 없다. 지연된 내구성으로 인해 데이터가 위험에 노출되지 않는다.

l  ALLOWED : 각 트랜잭션의 내구성이 트랜잭션 수준에서 결정된다. 즉 커밋 수준 설정 (DELAYED_DURABILITY={ON|OFF})에 의해 결정된다.

l  FORCED : 데이터베이스에 커밋되는 모든 트랜잭션이 지연된 내구성을 가진다. 이 설정은 지연된 트랜잭션 내구성이 데이터베이스에 유용하고 어플리케이션 코드를 변경하지 않으려는 경우에 유용하다.

 

 

아래 스크립트는 커밋 수준을 설정한다.

DELAYED_DURABILITY = { OFF | ON }

 

l  OFF : 기본값으로 DELAYED_DURABILITY = FORCED 데이터베이스 옵션을 적용하여 커밋이 비동기적이고 지연된 내구성을 갖는 경우를 제외하고 트랜잭션은 완전 내구성을 가진다.

l  ON : DELAYED_DURABILITY = FORCED 데이터베이스 옵션을 적용하여 커밋이 동기적으로 완전 내구성있는 경우를 제외하고 트랜잭션은 지연된 내구성을 가진다.

 

아래 스크립트는 저장 프로시저에 커밋 수준을 적용한 예시이다.

CREATE PROCEDURE [<procedureName>] /* parameters go here */
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER   
AS BEGIN ATOMIC WITH    
(   
    DELAYED_DURABILITY = ON,   
    TRANSACTION ISOLATION LEVEL = SNAPSHOT,   
    LANGUAGE = N'English'   
)   
/* procedure body goes here */
END

 

 

지연된 트랜잭션 내구성을 강제로 적용할 수 있도록 COMMIT 구문으로도 확장할 수 있는데, 데이터베이스 수준에서 DELAYED_DURABILITY가 DISABLED 또는 FORCED 인 경우 이 COMMIT 옵션은 무시된다.

COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name | @tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]

 

l  OFF : 기본값으로 DELAYED_DURABILITY = FORCED 데이터베이스 옵션을 적용하여 CIMMIT이 비동기 적으로 지연된 내구성을 갖는 경우를 제외하고 COMMIT 트랜잭션은 완전 내구성을 가진다.

l  ON : DELAYED_DURABILITY = DISABLED 데이터베이스 옵션을 적용하여 COMMIT이 동기적이고 완전 내구성 있는 경우를 제외하고 COMMIT 트랜잭션은 지연된 내구성을 가진다.

 

 

지연된 내구성을 사용할 경우 특정 상황에서 데이터를 손실 가능성이 있기 때문에 반드시 해당 비즈니스의 목적과 데이터베이스 성능 등을 잘 고려하여 사용 여부를 결정할 수 있도록 한다.

 

[참고자료]

l  Control Transaction Durability : https://learn.microsoft.com/en-us/sql/relational-databases/logs/control-transaction-durability?view=sql-server-ver16

l  Measure Delayed Durability impact in SQL Server 2016 and later : https://www.mssqltips.com/sqlservertip/6355/measure-delayed-durability-impact-in-sql-server-2016-and-later/

l  Get SQL Server Delayed Durability Advantages Without Configuration Changes : https://www.mssqltips.com/sqlservertip/6324/get-sql-server-delayed-durability-advantages-without-configuration-changes/

l  How to handle the SQL Server WRITELOG wait type : https://www.sqlshack.com/how-to-handle-the-sql-server-writelog-wait-type/

l  Improve SQL Server transaction log performance with Delayed Durability : https://www.sqlshack.com/improve-sql-server-transaction-log-performance-with-delayed-durability/

l  The Transaction Log (SQL Server) : https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16

l  SQL Server Transaction Log Architecture and Management Guide : https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16

 

 

 

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

 

 

 

SQL Server, MS SQL, DELAYED_DURABILITY, 트랜잭션 로그 비동기 커밋, WAL, Write Log

저작자표시 비영리 변경금지

'SQL Server > SQL Server Tip' 카테고리의 다른 글

SQL Server Failover Cluster 구성  (0) 2023.07.16
SQL Server 에서 AWS S3에 직접 백업하기  (2) 2022.10.28
VM 환경의 SQL Server에서 할당된 CPU를 모두 사용하지 못하는 현상  (0) 2020.03.04
SQL Server 복원 성능 최적화  (0) 2020.02.29
SQL Server 트랜잭션 로그 복원시 복원 시간이 오래 걸리는 현상  (0) 2020.02.28

SQL Server 에서 AWS S3에 직접 백업하기

 

l  Version : SQL Server 2022

 

SQL Server 2022부터는 데이터 플랫폼에 통합 오브젝트 스토리지를 도입하여 Azure Storage외에도 AWS S3 호환 오브젝트 스토리지도 사용할 수 있다. 즉, SQL Server에서 AWS S3로 직접 백업을 할 수 있게 되었다.

기존 SQL Server 2019의 경우 Microsoft Azure 저장소만 가능 하였다. SQL Server 2022 부터 도입된 S3 REST API는 SQL Server에서 AWS S3 직접 백업, 복원을 할 수 있어, 백업 후 이동에 따른 프로세스 단축 및 대용량 백업을 진행할 경우에도 로컬 공간이 부족하여도 백업을 진행할 수 있게 되었다.

 

지원되는 백업 종류

l  전체 백업

l  차등 백업

l  트랜잭션 로그 백업

l  복사 전용 백업 (COPY ONLY)

 

지원되지 않는 백업 종류

l  스냅샷 백업 (FILE_SNAPSHOT)

l  미러 백업 (MIRROR)

 

AWS S3버킷으로 백업 및 복원을 수행 하기위해서는 아래 정보가 필요 하다.

l  S3 버킷이름

l  S3 URI

l  S3 URL

l  IAM 액세스 ID

l  IAM 액세스 키

 

AWS IAM(Idnetity Access Management)의 정책은 사용자의 권한 또는 특정 서비스에 대해 수행할 수 있는 역할을 정의한다. SQL Server 2022에서 S3 버킷으로 직접 데이터베이스 백업을 수행하려면 ListBucket 및 PutObject 권한이 필요하다.

l  ListBucket : ListBucket 액세스는 요청의 인증된 발신자가 소유한 모든 버킷 목록을 반환한다.

l  PutObject : PutObject 액세스를 통해 버킷에 객체를 작성하고 추가할 수 있다.

 

SQL Server에서 AWS S3로 백업을 하기 위해 우선 자격증명을 만들어야 한다. 아래는 자격증명을 만드는 스크립트이다.

CREATE CREDENTIAL   [s3://<endpoint>:<port>/<bucket>]
WITH   
        IDENTITY    = 'S3 Access Key',
        SECRET      = '<AccessKeyID>:<SecretKeyID>';

 

l  [s3://<endpoint>:<port>/<bucket>] : 자격 증명 이름에는 S3 버킷 이름이 포함되어야 한다. S3://로 시작하고 접두사 HTTPS://를 제거한 후 S3 버킷 URL을 따른다.

l  IDENTITY : S3 Access Key 값으로, 자격 증명에서 S3 커넥터를 사용하고 있음을 나타낸다.

l  SECRET : 접근키 ID와 비밀 키를 콜론으로 구분하여 입력한다. 콜론 기호는 구분자 역할을 한다.  

 

 

 

백업 명령은 기존에 사용하던 백업문과 거의 동일하다. 다만 백업 위치가 DISK 가 아닌 URL을 사용한다.

BACKUP DATABASE [DatabaseName] TO URL = 'CredentialName\Backupfilename.bak'

 

 

백업 완료 후 S3를 확인해보면 백업파일이 생성된 것을 확인할 수 있다.

 

아래 스크립트는 백업하려는 데이터베이스를 여러 스트라이프된 백업 파일로 오브젝트 스토리지 엔드포인트를 사용하여 백업을 수행한다.

BACKUP DATABASE <db_name>
TO      URL = 's3://<endpoint>:<port>/<bucket>/<database>_01.bak'
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_02.bak'
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_03.bak'
--
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_64.bak'
WITH    FORMAT -- overwrite
,       STATS               = 10
,       COMPRESSION;

 

 

 

아래 스크립트는 오브젝트 스토리지 엔드포인트 위치에서 데이터베이스 복원을 수행한다.

RESTORE DATABASE <db_name>
FROM    URL = 's3://<endpoint>:<port>/<bucket>/<database>_01.bak'
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_02.bak'
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_03.bak'
--
,       URL = 's3://<endpoint>:<port>/<bucket>/<database>_64.bak'
WITH    REPLACE -- overwrite
,       STATS = 10;

 

 

데이터를 저장하려면 S3 호환 오브젝트 스토리지 공급자는 파트(Part)라 불리는 여러 블록으로 파일을 분할해야 한다. 각 파일은 최대 10,000개의 파트로 분할 수 있으며, 각 파트의 크기는 5MB ~ 20MB이다. 이 범위는 매개변수 MAXTRANSFERSIZE를 통해 T-SQL BACKUP 명령으로 제어할 수 있다. MAXTRANSFERSIZE의 기본값은 10MB 이므로 각 파트의 기본 크기는 10MB이다.  즉, 단일 백업 파일의 크기는 MAXTRANSFERSIZE가 기본값으로 설정되어 있을 경우 100,000MB이다. 백업 스트라이프가 100,000MB를 초과할 경우 아래와 같은 오류 메시지를 반환한다.

Msg 3202, Level 16, State 1, Line 161
Write on 's3://<endpoint>:<port>/<bucket>/<path>/<db_name>.bak' failed: 87(The parameter is incorrect.)
Msg 3013, Level 16, State 1, Line 161
BACKUP DATABASE is terminating abnormally.

 

단일 백업 파일의 크기가 100,000MB 보다 큰 파일을 백업 해야 할 경우 최대 64개의 URL 스트라이프 백업을 지원한다. 즉, 가능한 최대 백업 파일 크기는 10,000part * MAXTRANSFERSIZE * URL이다. 압축 백업을 사용할 경우 백업 파일 사이즈가 현저히 많이 줄어들기 때문에 백업 시 압축 옵션을 적극 활용할 수 있도록 한다.

아래 예제는 MAXTRANSFERSIZE를 사용하여 20MB으로 설정하고, 백업 시 압축 및 암호화한다.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = <password>;
GO
 
CREATE CERTIFICATE AdventureWorks2019Cert
    WITH SUBJECT = 'AdventureWorks2019 Backup Certificate';
GO
-- Backup database
BACKUP DATABASE AdventureWorks2019
TO URL = 's3://<endpoint>:<port>/<bucket>/AdventureWorks2019_Encrypt.bak'
WITH FORMAT, MAXTRANSFERSIZE = 20971520, COMPRESSION,
ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = AdventureWorks2019Cert)
GO

 

백업 및 복원 엔진에서 총 URL의 길이는 259바이트로 제한되어 있기 때문에 s3://를 제외하고 사용자의 경로 길이(호스트 이름 + 개체키)를 259 - 5 = 254글자까지 입력할 수 있다. 만약 URL 길이를 초과할 경우 아래와 같은 오류가 반환된다.

SQL Server has a maximum limit of 259 characters for a backup device name. The BACKUP TO URL consumes 36 characters for the required elements used to specify the URL - 'https://.blob.core.windows.net//.bak', leaving 223 characters for account, container, and blob names put together'

 

S3 스토리지는 SQL 호스트와 S3 서버간의 시간 차이가 15분을 초과할 때 마다 연결을 거부하고 “InvalidSignatureException”오류를 SQL Server로 보낸다. SQL Server에서는 아래와 같은 오류로 반환된다.

Msg 3201, Level 16, State 1, Line 28
Cannot open backup device '<path>'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 28
BACKUP DATABASE is terminating abnormally.

 

 

[참고자료]

l  SQL Server backup to URL for S3-compatible object storage : https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url-s3-compatible-object-storage?view=sql-server-ver16

l  SQL Server back up to URL for S3-compatible object storage best practices and troubleshooting : https://learn.microsoft.com/ko-kr/sql/relational-databases/backup-restore/sql-server-backup-to-url-s3-compatible-object-storage-best-practices-and-troubleshooting?view=sql-server-ver16

l  https://www.mssqltips.com/sqlservertip/7301/sql-server-2022-backup-restore-aws-s3-storage/

l  https://www.mssqltips.com/sqlservertip/7302/backup-sql-server-2022-database-aws-s3-storage/

 

 

 

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

 

 

 

SQL Server, MS SQL, AWS S3 backup, S3 백업, 클라우드 백업, cloud backup

저작자표시 비영리 변경금지

'SQL Server > SQL Server Tip' 카테고리의 다른 글

SQL Server Failover Cluster 구성  (0) 2023.07.16
SQL Server DELAYED_DURABILITY 옵션으로 트랜잭션 로그 쓰기 성능 개선 하기  (1) 2022.10.31
VM 환경의 SQL Server에서 할당된 CPU를 모두 사용하지 못하는 현상  (0) 2020.03.04
SQL Server 복원 성능 최적화  (0) 2020.02.29
SQL Server 트랜잭션 로그 복원시 복원 시간이 오래 걸리는 현상  (0) 2020.02.28

[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' 카테고리의 다른 글

[AWS] AWS Redshift 실행된 쿼리 및 Slow query 확인  (0) 2023.02.19
[AWS] AWS Redshift Serverless 사용량을 확인하여 빌링비용 예상하기  (0) 2023.01.12
[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징  (0) 2022.07.25
[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11

[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' 카테고리의 다른 글

[AWS] AWS Redshift Serverless 사용량을 확인하여 빌링비용 예상하기  (0) 2023.01.12
[AWS Aurora] Aurora PostgreSQL Auto Vacuum 이해하기  (0) 2022.10.27
[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11
[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지  (0) 2022.07.10

[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' 카테고리의 다른 글

[AWS Aurora] Aurora PostgreSQL Auto Vacuum 이해하기  (0) 2022.10.27
[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징  (0) 2022.07.25
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11
[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지  (0) 2022.07.10
[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결  (0) 2022.06.17

[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' 카테고리의 다른 글

[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징  (0) 2022.07.25
[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지  (0) 2022.07.10
[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결  (0) 2022.06.17
[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상  (0) 2022.05.11

[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' 카테고리의 다른 글

[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치  (0) 2022.07.24
[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11
[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결  (0) 2022.06.17
[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상  (0) 2022.05.11
[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리  (0) 2022.05.08

[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' 카테고리의 다른 글

[AWS Aurora] Aurora 스토리지 특징 요약  (0) 2022.07.11
[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지  (0) 2022.07.10
[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상  (0) 2022.05.11
[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리  (0) 2022.05.08
[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기  (0) 2022.04.25

[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' 카테고리의 다른 글

[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지  (0) 2022.07.10
[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결  (0) 2022.06.17
[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리  (0) 2022.05.08
[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기  (0) 2022.04.25
[AWS RDS] Performance Insight로 DB부하의 원인 찾기  (0) 2022.04.24

[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' 카테고리의 다른 글

[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결  (0) 2022.06.17
[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상  (0) 2022.05.11
[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기  (0) 2022.04.25
[AWS RDS] Performance Insight로 DB부하의 원인 찾기  (0) 2022.04.24
[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?  (0) 2022.04.20

[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' 카테고리의 다른 글

[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상  (0) 2022.05.11
[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리  (0) 2022.05.08
[AWS RDS] Performance Insight로 DB부하의 원인 찾기  (0) 2022.04.24
[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?  (0) 2022.04.20
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2  (0) 2022.04.18

[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 성능 개선

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리  (0) 2022.05.08
[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기  (0) 2022.04.25
[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?  (0) 2022.04.20
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2  (0) 2022.04.18
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2  (0) 2022.04.13

[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?

 

l  Version : AWS Simple Storage Service(S3)

 

AWS에서 제공하는 스토리지 서비스에는 Amazon S3(Simple Storage Service)라고 불리는 오브젝트 스토리지가 있다. Amazon S3는 여러 사용 사례에 맞춰 다양한 스토리지 클래스를 제공한다. 예를 들어 자주 액세스 하기 위해 미션 크리티컬 프로덕션 데이터는 S3 Standard에 저장하고, 액세스 빈도가 낮은 데이터는 S3 Standard-IA 또는 S3 One Zone-IA에 저장하여 비용을 절감하고, S3 Glacier Flexible Retrieval 및 S3 Glacier Deep Archive에 가장 낮은 비용으로 데이터를 보관할 수 있다. 또한 액세스 패턴을 예측할 수 없거나 자주 변경되는 경우 S3 Intelligent-Tiering에 저장하면 액세스 패턴에 따라 자동으로 4계의 액세스 계층 간에 데이터를 자동으로 이동하여 스토리지 비용을 최적화 할 수 있다.

 

Amazon S3에 버킷을 생성하고 폴더에 접근할 때 고유한 URI를 사용하게 되는데, 일반적인 URI의 형식은 s3://bucket-name/folder-name/ 형식으로 생성된다. 그런데 가끔 S3에 연결할 때 URI 형식이 조금씩 다른 s3://, s3a://, s3n:// 경우가 있다. 각 URI에 대한 차이점이 무엇인지 살펴보자. 차이점에 대해서 알아보기 전에 S3는 File System 이 아닌 Object Storage라는 점을 다시 한번 인지하고, S3에 분산 저장하는 경우 Hadoop 클라이언트를 거쳐 저장하게 된다. Hadoop는 S3N, S3A, S3 이렇게 세가지 시스템이 클라이언트를 제공한다.

 

S3N (URI 형식: s3n://)

l  S3에서 일반 파일을 읽고 쓰기 위한 기본 파일 시스템

l  안정적이며 널리 알려져 있지만 현재 업데이트가 중단된 상태

l  다른 도구로 작성된 S3의 파일에 액세스가능. 반대로 다른 도구는 Hadoop을 사용하여 작성된 파일에 액세스 가능

l  S3에서 저장할 수 있는 단일 파일 크기에 대한 5GB 제한있음

 

S3A (URI 형식: s3a://)

l  S3 Native인 s3n fs의 후속

l  Amazon의 라이브러리를 사용하여 S3와 상호 작용

l  S3a는 더 큰 파일(5GB 제한 없음), 고성능 작업 등을 지원 가능

l  s3n://URL에서 액세스할 수 있는 모든 객체는 URL 스키마를 교체하는 것만으로 s3a에서도 액세스 가능

 

S3 (URI 형식: s3://)

l  S3가 지원하는 블록 기반 파일 시스템

l  파일은 HDFS에 있는 것처럼 블록으로 저장

l  이 파일 시스템을 사용하려면 파일 시스템 전용 버킷이 필요

l  파일이 포함된 기존 버킷을 사용하거나 다른 파일을 동일한 버킷에 쓰지 않아야 함

l  이 파일 시스템에 의해 저장된 파일은 5GB보다 클 수 있지만 다른 S3 도구와 상호 운용할 수 없음

 

AWS EMR의 경우에는 별도로 EMRFS라는 파일 시스템이 존재한다. 그래서 EMR의 S3 파일 시스템과 Hadoop에서의 S3 파일 시스템은 서로 다르기 때문에 사용할 때 주의해야 한다. 따라서 ERM의 경우 S3로 사용하는 것을 권장하고 있다. 하지만 s3a의 경우 EMRFS와 호환되지 않기 때문에 오류가 발생할 수 있다.

 

자체 Hadoop을 사용하면서 데이터 저장소만 Amazon S3를 사용할 경우 S3A를 사용하면 자체 하둡에서 S3의 저장소를 연결하여 객체를 직접 읽고 쓸 수 있다.  S3A의 탄생 배경에 대해 궁금하다면 아래 블로그를 참고할 수 있다.

l  Community collaboration: The S3A story : https://aws.amazon.com/ko/blogs/opensource/community-collaboration-the-s3a-story/

 

 

[참고자료]

l  What is Amazon S3 : https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

l  Work with storage and file systems : https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-file-systems.html

l  Community collaboration: The S3A story : https://aws.amazon.com/ko/blogs/opensource/community-collaboration-the-s3a-story/

l  Enabling Amazon Simple Storage Service (Amazon S3) Access Points in Apache Hadoop S3A : https://aws.amazon.com/ko/blogs/opensource/enabling-amazon-simple-storage-service-s3-access-points-in-apache-hadoop-s3a/

 

 

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

 

 

AWS Simple Storage Service, S3, S3N, S3A, EMR, EMRFS

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기  (0) 2022.04.25
[AWS RDS] Performance Insight로 DB부하의 원인 찾기  (0) 2022.04.24
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2  (0) 2022.04.18
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2  (0) 2022.04.13
[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링  (0) 2022.04.12

[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2

-          교차 리전 자동 백업을 사용하여 RPO, RTO 효율화 하기

 

l  Version : AWS RDS for Oracle

 

지난 포스트에서는 AWS RDS for Oracle에서 교차 리전 자동 백업에 대한 개념에 대해서 알아 보았다.

l  [AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2 : https://sungwookkang.com/1500

 

이번 포스트는 교차 리전 자동 백업 Part 2로 AWS KMS로 암호화된 인스턴스를 포함하여 리전 간 자동 백업 설정 방법에 대해서 살펴본다. 자세한 내용은 원문을 참고한다.

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 2 : https://aws.amazon.com/ko/blogs/database/part-2-managed-disaster-recovery-with-amazon-rds-for-oracle-xrab/

 

AWS Management Console 또는 AWS CLI를 통해 교차 리전 자동 백업을 설정하는 것은 간단하다. 인스턴스를 생성할 때 또는 이미 생성된 인스턴스를 간단히 수정하여 교차 리전 자동 백업을 활성화 할 수 있다.

 

[교차 리전 백업 활성화]

기존 인스턴스에 교차 리전 자동 백업을 추가하려면 아래 단계로 진행한다.

1.        AWS RDS에서 RDS Oracle 인스턴스를 선택하고 수정한다.

2.        백업 세션에서 로컬 지역에 대한 백업 보존 기간을 지정할 수 있다.

3.        백업 창 아래의 확인란은 복제를 활성화하고 대상 지역 및 복제된 백업 보존 기간에 대한 메뉴를 드롭다운으로 표시한다. 대상 지역의 백업 보존기간은 소스 지역에 대해 설정된 기간과 완전히 독립적이다. 각 지역은 DR 계획을 수용하기 위해 최대 35일까지 설정할 수 있다.

4.        선택을 마친 후 변경 사항을 즉시 적용할지 또는 다음 예약된 유지 관리 기간에 적용할지 선택한다.

 

교차 리전 복제를 지원하는 리전은 지속적으로 확대되고 있으며, 현재 리전과 복제를 지원하는 리전을 확인하려면 다음 명령을 실행한다.

[ec2-user@ip-10-1-0-11 ~]$ aws rds describe-source-regions --region us-east-1

 

아래 그림은us-west-2 리전이 Amazon RDS 자동 백업 복제를 위해 us-west-1과 쌍을 이루는 것을 보여준다.

 

교차 리전 자동 백업은 AWS Key Management Service(AWS KMS) 키를 사용한 Amazon RDS 암호화를 완벽하게 지원한다. AWS KMS로 암호화된 인스턴스에서 리전간 자동 백업을 활성화 하려면 대상 리전에 있는 기존AWS KMS키 ARN (Amazon Resource Name)을 지정하여 스냅샷 데이터를 암호화해야 한다. 워크플로에 대한 다른 변경 사항은 필요하지 않다.

 

로컬 리전에서 인스턴스의 자동 백업을 확인하려면 Amazon RDS 콘솔의 탐색 창에서 자동 백업을 선택하고 현재 리전 탭에서 확인한다. 이 페이지에서 교차 리전 백업을 보고 관리할 수 있다. 복제됨 탭을 선택하여 현재 보고 있는 리전에 복제된 원격 리전의 백업을 본다. 대상 지역에서 복제된 각 백업의 복원 가능한 시간 창을 보고 지정된 인스턴스에 대해 해당 창 내의 특정 시점으로 백업 복원을 시작할 수 있다. AWS CLI에서 리전 내 복원 가능 기간 및 복제된 백업 ARN을 보려면 아래 코드를 입력한다.

[ec2-user@ip-10-1-0-11 ~]$ aws rds describe-db-instance-automated-backups --db-instance-identifier slob-saz

 

아래 그림은 코드를 실행했을 때 결과이다.

 

대상 리전에서는 이전 명령의 출력에서 얻은 자동 백업의 ARN을 지정하여 복원 창을 확인할 수 있다.

[ec2-user@ip-10-1-0-11 ~]$ aws rds describe-db-instance-automated-backups --db-instance-automated-backups-arn " arn:aws:rds:us-west-2:xxxxxxxxxxxx:auto-backup:ab-gug4ww2bbuacdji7fdqjoosprm4mnea2jqgsdpa"

 

아래 그림은 코드를 실행했을 때 결과이다.

 

 

[재해 복구 연습]

RDS Oracle 인스턴스의 소스 리전을 사용할 수 없는 재해가 발생할 경우 교차 리전 스냅샷 복원은 소스 리전에서 복원하는 것과 동일한 프로세스를 따른다. Amazon RDS는 항상 백업에서 새 인스턴스로 복원한다. Amazon RDS 콘솔, AWS CLI 또는 자동화 프레임워크 내에서 API를 호출하여 복원을 시작할 수 있다.

 

AWS 콘솔을 사용하려면 아래 단계를 진행한다.

1.        Amazon RDS 콘솔의 탐색 창에서 자동 백업을 선택한다.

2.        복제됨 탭에서 해당 인스턴스를 선택한다.

3.        작업 메뉴에서 지정 시간으로 복원을 선택한다.

 

4.        작업 흐름은 원본 리전에서 복원과 동일한 흐름을 따른다. 가장 최근의 복원 가능한 시간 내에서 초 단위까지 시간을 지정할 수 있다. 최대한 많은 데이터를 복구하려면 최근 복원 가능한 시간을 선택한다.

 

5.        DB 인스턴스 식별자를 지정해야 하며 데이터베이스 버전, 라이선스 모델, 인스턴스 이름, 인스턴스 클래스 및 크기, 단일 또는 다중 AZ, 스토리지 옵션, 인증 등을 포함하여 복원할 인스턴스의 다양한 측면을 변경할 수 있다.

아래 코드는 위 과정과 동일한 작업을 AWS CLI로 수행한다.

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-automated-backups-arn "arn:aws:rds:us-west-2:xxxxxxxxxxxx:auto-backup:ab-r2mmwuimjtv2tt7apmwl3ymi2mlfhgs5ictuexq" \
    --target-db-instance-identifier slob-saz-restore \
    --restore-time 2021-04-29T08:06:11.000-6:00

 

교차 리전 자동 백업 기능은 또한 복원된 인스턴스의 옵션 그룹에 대한 기본 선택인 xrab-<source Region>-<source options group name>-…이라는 소스 리전에서 옵션 그룹의 복사본을 생성했다. 소스 리전에서 동일한 옵션을 유지하기 위해 다른 옵션을 그룹을 지정하거나 기본값을 둘 수 있다. 또한 RestoreDbInstanceToPointInTime RDS API를 사용하여 복원을 수행할 수 있다. Amazon RDS 가 즉시 복원 작업을 시작하고 Amazon RDS 콘솔에 새 인스턴스의 상태가 생성중으로 표시된다.

 

복원 작업을 완료하는데 걸리는 시간은 선택한 복원 지점에 도달하기 위해 자동화된 스냅샷 위에 적용해야 하는 아카이브된 로그의 수에 따라 크게 달라진다. Amazon RDS는 복원을 완료한 후 인스턴스를 백업한다.

 

잠시 후 인스턴스에 사용 가능 상태가 표시된다.

 

연결 및 보안 탭에서 인스턴스 끝점을 선택하고 새 인스턴스를 가리키도록 애플리케이션을 업데이트 한다. 복원이 완료되었으면 인스턴스를 트랜잭션에 사용할 수 있다. 이제 복원된 인스턴스의 자동 백업을 다른 리전에 복제하도록 선택할 수 있다.

 

 

 

 

[참고자료]

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 2 : https://aws.amazon.com/ko/blogs/database/part-2-managed-disaster-recovery-with-amazon-rds-for-oracle-xrab/

 

 

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

 

 

AWS Oracle RDS, Automated Backup, Cross Region Backup, 교차 리전 자동 백업, DR, RTO, RPO

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS RDS] Performance Insight로 DB부하의 원인 찾기  (0) 2022.04.24
[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?  (0) 2022.04.20
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2  (0) 2022.04.13
[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링  (0) 2022.04.12
[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기  (0) 2022.04.08

[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2

-          교차 리전 자동 백업을 사용하여 RPO, RTO 효율화 하기

 

l  Version : AWS RDS for Oracle

 

AWS에서 관리형 데이터베이스로 제공하는 RDS for Oracle을 사용하면 AWS 리전 내의 데이터베이스 인스턴스에 대한 향상된 가용성과 내구성을 얻을 수 있다. 여러 리전에 걸쳐 DR 구성을 하면 미션 크리티컬한 데이터베이스를 실행할 때 읽기 전용 RDS를 사용할 수 있어, 사용자에게 더 가까운 다른 리전에서 프로덕션 읽기에 대한 워크로드를 처리할 수 있다. 또한 스냅샷과 아카이브된 redo로그를 포함하는 Oracle용 Amazon RDS 교차 리전 자동 백업을 사용하면 낮은RPO(복구 시점 목표) 및 감소된 RTO(복구 시간 목표)로 비용 효율적인 교차 리전 DR을 구성할 수 있다.

 

이번 포스트는 교차 리전 자동 백업에 대해서 2회에 걸쳐 설명하며 이번 포스트에서는 Part 1으로  개념에 대해서 설명한다.  AWS RDS for Oracle에 중점을 두었지만 AWS RDS for PostgreSQL에서도 리전 간 자동 백업을 사용할 수 있다. 자세한 내용은 원문을 참고한다.

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 1 : https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/

 

교차 리전 자동 백업은 단일 리전에서 현재 Amazon RDS 백업 및 복구 자동화에 사용하는 것과 동일한 솔루션을 제공하지만 데이터베이스 인스턴스를 복원하는데 필요한 모든 데이터를 두 번째 리전에서 즉시 사용할 수 있도록 추가 보호 기능을 제공한다. 이 기능은 Amazon RDS 자동 백업 기능을 확장하여 기본 리전에서 보조 리전으로 스냅샷 및 아카이브된 redo 로그의 자동 복제를 설정할 수 있는 기능을 제공한다.

 

Amazon RDS for Oracle에서는 12.1(12.1.0.2 v10 부터)이상의 버전에 대해 교차 리전 자동 백업을 지원한다. 이 기능은 LI(License Included) 또는 BYOL(Bring Your Own License)모델로 Oracle Database의 모든 에디션을 사용하는 Oracle용 Amazon RDS 고객에게 지원된다. BYOL 고객은 Oracle 계약을 검토하여 이 기능의 사용이 허용되는지 확인해야한다.

 

교차 리전 자동 백업을 사용하면 RDS 인스턴스가 상주하는 소스 리전에서 캡처 및 보관된 스냅샷, 아카이브된 redo 로그 백업이 자동으로 두 번째 리전에 복사된다. 그런 다음 RDS는 선택한 백업 보존 기간에 따라 스냅샷 및 아카이브 된 로그를 유지관리하여 대상 리전에서 특정 시점 복원(PITR)기능을 활성화 한다.

 

 

Amazon RDS 리전 간 자동 백업을 사용하면 대상 리전에서는 원본 리전과 다른 복구 기간을 선택할 수 있다. 그리고 원본 리전의 로그가 즉시 두 번째 리전에 복사되므로 리전 간 자동 백업을 통해서 본 사이트와 장애조치 사이트를 장거리로 분리할 수 있다. 아래는 교차 리전 자동 백업에 대한 장점이다.

l  교차 리전 자동 백업은 컴퓨팅 및 경우에 따라 다른 리전에서 PITR이 필요할 때까지 라이선스 비용을 절약하는데 도움이 되는 비용 효율적인 DR 기능이 필요한 경우에 이상 적이다.

l  교차 리전 자동 백업은 리전 간에 RDS 스냅샷을 복사하는 스크립팅에 시간과 리소스가 부족하고 수동 리전 간 스냅샷 복사 보다 낮은 RPO가 필요한 경우에도 유용하다.

l  이 기능은 수동 스냅샷을 자동으로 복제하여 스냡샷이 복원된 후 적용해야 하는 redo 로그 양을 줄여 대상 리전에서 더 낮은 RTO를 제공하는데 도움이 될 수 있다.

 

일반 작업 중에 자동 백업을 활성화하면 Amazon RDS는 5분 간격으로 인스턴스에서 생성된 아카이브된 redo 로그 복사와 함께 정의한 백업 기간 동안 RDS DB 인스턴스 스토리지의 일일 스냅샷을 만든다. 이러한 백업은 RDS DB 인스턴스가 있는 리전의 Amazon Simple Storage Service(Amazon S3)에 저장된다. 교차 리전 자동 백업을 사용하면 이러한 동일한 스냅샷 및 아카이브된 로그가 소스 리전에서 사용 가능하게 되는 즉시 두 번째 리전에 복제된다.

 

스냅샷 생성은 RDS DB 인스턴스에서 5분마다 시작되기 때문에 원본 리전의 RDS 인스턴스에 대한 일반적인 RPO는 약 5~10분이다. 원격 리전의 경우 복사 시간이 더 길기 때문에 교차 리전 백업의 RPO는 소스 리전보다 10분 이상 늦게 실행될 수 있다. redo 볼륨이 높은 데이터베이스 인스턴스는 두 번째 리전의 인스턴스에 대해 가장 최근에 복원 가능한 시간에 추가 지연이 발생할 수 있다. PITR을 완료하는 데 걸리는 시간은 스냅샷이 복원된 후 적용해야 하는 redo 로그 양에 따라 크게 달라지며, 이는 교차 리전 자동 백업의 결과로 변경할 수 없는 부분이다. 리전 내 또는 리전 간 RDS 인스턴스 복원 작업에 대해 더 낮은 RTO를 달성하려는 경우 인스턴스의 수동 스냅샷을 생성하여 복원의 redo 로그 단계의 시간을 줄일 수 있다.

 

아래 표는 Oracle용 Amazon RDS의 다양한 HA 및 DR 기능으로 얻을 수 있는 RPO 및 RTO 지표이다.

Feature RPO (근사치) RTO(근사치) Licensing
RDS Multi-AZ 0 1 to 2 minutes License Included Standard Edition Two (SE2) or BYOL SE2 or Enterprise Edition
Snapshot restore Hours < 1 hour
PITR(in-Region) using Automated Backups 5 minutes Hours
PITR using cross-Region Automated Backups 25 minutes Hours
Mounted replica promotion (in-Region) Minutes Minutes Enterprise Edition
Mounted replica promotion (cross-Region) Minutes Minutes
Read replica promotion (in-Region) Minutes Minutes Enterprise Edition + Active Data Guard
Read Replica promotion (cross-Region) Minutes Minutes

 

AWS KMS 또는 Oracle TDE(투명한 데이터 암호화)로 암호화된 RDS DB 인스턴스는 다른 리전에도 복제할 수 있다. Oracle TDE가 TDE 옵션을 통해 사용 중인 경우 Amazon RDS는 TDE 키를 대상 지역에 자동으로 복사하므로 Oracle wallet도 해당 지역에서 관리될 수 있다. AWS KMS 암호화를 지원하는 교차 리전 자동 백업은 대상 리전의 기존 AWS KMS 고객 마스터 키(CMK)를 사용하여 복제된 백업을 암호화 한다.

 

AWS KMS 암호화를 사용하여 보호되는 RDS 인스턴스에 대해 교차 리전 자동 백업을 구현할 때 대상 리전에서 암호화 작업에 사용할 KMS 키 ARN을 지정해야 한다. 이는 Amazon RDS의 기본 KMS 키가 될 수 없지만 AWS KMS는 기본 서비스 키에 대한 교차 리전 액세스를 허용하지 않기 때문에 별도의 키여야 한다.

 

교차 리전 자동 백업은 리전 간에 DB 스냅샷 및 아카이브된 redo 로그를 복사하는 동안 전송된 데이터에 대해 요금이 부과된다. 기본 리전과 보조 리전 간의 데이터 전송 요금은 해당 리전의 데이터 전송 요금을 기준으로 청구되며 스냅샷이 복사된 후 대상 리전에 저장소 요금은 표준 데이터베이스 스냅샷 요금이 적용된다. 대상 리전에 아카이브된 redo 로그를 저장 하는데는 추가 요금이 부과되지 않는다. 인스턴스, 스토리지, 데이터 전송 및 지역별 가용성에 대한 최신 요금은 Oracle용 Amazon RDS 요금을 참고한다.

l  Amazon RDS for Oracle pricing : https://aws.amazon.com/rds/oracle/pricing/

 

 

[참고자료]

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 1 : https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/

l  Amazon RDS for Oracle pricing : https://aws.amazon.com/rds/oracle/pricing/

 

 

 

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

 

 

AWS Oracle RDS, Automated Backup, Cross Region Backup, 교차 리전 자동 백업, DR, RTO, RPO

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://)에 다른 차이점은 무엇일까?  (0) 2022.04.20
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2  (0) 2022.04.18
[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링  (0) 2022.04.12
[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기  (0) 2022.04.08
[AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기  (0) 2022.04.07

[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링

 

l  Version : AWS CloudWatch, RDS for SQL Server

 

SQL Server를 운영할 때, 여러 성능 지표 모니터링은 필수이다. 그 중 하나가 데드락 모니터링이다. AWS RDS for SQL Server 환경에서 데드락 발생시 CloudWatch를 활용하면 특별한 서드파티 모니터링 도구가 없어도 발생 즉시 알림을 받을 수 있다.

 

이번 포스트는 AWS 공식 블로그 내용을 요약한 것으로 자세한 내용은 원문을 참고한다.

l  Monitor deadlocks in Amazon RDS for SQL Server and set notifications using Amazon CloudWatch : https://aws.amazon.com/blogs/database/monitor-deadlocks-in-amazon-rds-for-sql-server-and-set-notifications-using-amazon-cloudwatch/

 

데드락 발생시 아래와 같은 이벤트 로그를 확인할 수 있다. 이 로그는 온프레미스 SQL Server 또는 클라우드 환경에서의 SQL Server 모두 동일하다. 데드락이 발생하면 현재 실행중인 프로세스들은 모두 대기하게 되므로, SQL Server는 현재 데드락에 관련된 프로세스 중 하나를 강제로 종료시켜 이 문제를 해결한다. 그리고 아래와 같은 오류 로그를 기록한다.

Msg 1205, Level 13, State 51, Line 3
Transaction (Process ID xx) was deadlocked on {xxx} resources with another process
and has been chosen as the deadlock victim. Rerun the transaction

 

AWS RDS를 사용하면 데드락을 모니터링 하고 이벤트가 발생하는 즉시 Amazon SNS(Simple Notification Service)로 알림을 보낼 수 있다. 이렇게 알림 시스템을 구성할 경우 데드락 발생에 대한 알림을 자동화하고 데드락 예방을 위한 조치를 취하는데 도움이 된다. 아래는 데드락 발생시 알림을 보내는 아키텍처이지만 데드락 뿐만 아니라 다양한 오류 로그 및 사용자 정의 이벤트를 모니터링 할 수 있다.

1.        SQL Server RDS에 대한 데드락 모니터링 감지를 활성화

2.        SQL Server 오류 로그를 CloudWatch에 게시

3.        교착 상태 이벤트를 시뮬레이션

4.        필터 패턴과 CloudWatch 경보를 생성

5.        Amazon RDS 성능 개선 도우미를 사용하여 솔루션을 모니터링

 

데드락 모니터링을 활성화 하기 위해서는 파라메터 그룹에서 데드락 이벤트인 1204, 1222를 선택하고 값을 1로 설정한다. 파라메터 그룹 수정 후 적용을 위해서는 RDS 인스턴스를 재시작 해야 한다.

 

CloudWatch가 오류 로그를 모니터링 할 수 있도록 Log exports에서 Error log항목을 선택한다. 변경 사항을 적용하려면 RDS DB 인스턴스 재시작이 필요하다.

 

위 설정이 완료되고 나면 CloudWatch 콘솔에서 로그가 기록되는 것을 확인할 수 있다. 로그 그룹은 /aws/rds/instance/<Your-RDS-Instance-Name>/error 형식으로 그룹화 되어 있다.

 

Metric filter 탭에서 데드락에 대한 이벤트를 입력한다. 이때 통계에서 최소를 선택하고 0 보다 클 경우 알림이 발생하도록 설정한다. (데드락은 1건만 있어도 알림을 받아야 한다.)

 

알림이 발생했을 때 수신할 이메일을 입력하여 SNS 주제를 생성하고 나면 실제 데드락 발생시 메일로 해당 알림을 받을 수 있다.

 

 

이번 포스트에서는 CloudWatch를 사용하여 SQL Server RDS에서 발생하는 데드락에 대해서만 모니터링 하였지만, 실제 SQL Server의 오류 로그에는 매우 다양한 이벤트 로그가 기록된다. 데드락 외에도 운영에 필요한 로그를 모니터링 하여 알림을 받을 수 있도록 한다.

 

l  SQL Server DBA 체크리스트 : https://blog.naver.com/jevida/221018122813

 

 

[참고자료]

l  Monitor deadlocks in Amazon RDS for SQL Server and set notifications using Amazon CloudWatch : https://aws.amazon.com/blogs/database/monitor-deadlocks-in-amazon-rds-for-sql-server-and-set-notifications-using-amazon-cloudwatch/

 

 

 

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

 

 

AWS SQL RDS, CloudWatch, 오류로그, 이벤트 로그, 장애알림, DB 모니터링

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 2/2  (0) 2022.04.18
[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2  (0) 2022.04.13
[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기  (0) 2022.04.08
[AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기  (0) 2022.04.07
[AWS DMS] AWS DMS를 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기  (0) 2022.04.03

[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기

-          SSRS에서 Babelfish를 사용하여 쿼리 수정없이 리포트 실행 가능

 

l  Version : AWS Aurora Babelfish

 

앞에서 다루었던 AWS SCT (Schema Conversion Tool)과 AWS DMS (Database Migration Service) 서비스를 사용하여 이기종 간의 데이터베이스 스키마 전환 및 실시간 데이터베이스 마이그레이션에 대해서 살펴 보았다.

l  [AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기 : https://sungwookkang.com/1497

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

 

이렇게 이기종 데이터베이스 마이그레이션 작업이 진행되면, 기존 데이터베이스를 사용하던 애플리케이션 또한 새로운 데이터베이스에 맞게 변경 작업이 필요하다. 그런데 기업 입장에서 보면 이러한 변경에 따른 개발 리소스 비용이 증가하게 되어 부담되는 것이 현실이다. 만약 기존에 사용중인 데이터베이스가 Microsoft SQL Server이며 마이그레이션된 데이터베이스가 Aurora PostgreSQL이라면, AWS Aurora에서 제공하는 Babelfish를 사용하여 기존 SQL Server에서 사용하던 쿼리 그대로 PostgreSQL에서 사용할 수 있다. 이번 포스트에서는 AWS에서 제공하는 Babelfish에 대해서 알아본다.

 

Babelfish for Aurora PostgreSQL는 Amazon Aurora PostgreSQL 호환 에디션의 새로운 기능으로, 이를 통해 Aurora는 Microsoft SQL Server용으로 작성된 애플리케이션의 명령을 이해할 수 있다. Aurora PostgreSQL은 Babelfish를 통해 Microsoft SQL Server의 전용 SQL 언어인 T-SQL을 이해하고 동일한 통신 프로토콜을 지원한다. 따라서 원래 SQL Server용으로 작성된 앱을 최소한의 코드 변경으로 Aurora에서 사용할 수 있다. 결과적으로, SQL Server 2005 이상에서 실행되는 애플리케이션을 수정하고 Aurora로 이동하는 데 필요한 작업이 줄어들기 때문에 마이그레이션 속도를 높이고 위험을 낮추며 비용 효율성을 개선할 수 있다.

 

Babelfish는 Amazon Aurora의 기본 제공 기능으로, 추가 비용 없이 사용할 수 있으며, RDS 관리 콘솔에서 클릭 몇 번으로 Amazon Aurora 클러스터에서 Babelfish를 사용하도록 설정할 수 있다. 아래 그림은 Babelfish for Aurora PostgreSQL로 마이그레이션 되었을 때, 기존의 SQL Server에서 사용하던 애플리케이션과 Aurora PostgreSQL을 사용하는 애플리케이션이 어떻게 연결되고 통신하는지에 대한 다이어그램이다. 그림을 살펴보면, SQL Server 드라이버를 사용하는 애플리케이션은 Babelfish를 통하여 Aurora에 접근하게 되고, PostgreSQL 드라이버를 사용하는 애플리케이션은 PostgreSQL 커넥션을 사용하여 Aurora에 접근되는 것을 알 수 있다.

 

Babelfish는 Aurora PostgreSQL에 대한 SQL Server 데이터 형식, 구문 및 함수를 지원하여 T-SQL 및 Microsoft SQL Server 동작을 지원한다. 이 방법을 사용하면 Aurora는 Aurora PostgreSQL 및 SQL Server SQL 언어를 모두 지원할 수 있다. 또한 Babelfish는 SQL Server 와이어 레벨 프로토콜(TDS)을 지원하므로 SQL Server 애플리케이션이 Aurora PostgreSQL과 기본적으로 통신할 수 있다. 이렇게 하면 데이터베이스 객체, 저장 프로시저 및 애플리케이션 코드를 거의 변경하지 않고 마이그레이션할 수 있다.

 

Babelfish는 T-SQL을 완벽하게 지원하지는 않지만 Aurora PostgreSQL SQL 명령을 사용하여 이러한 명령에서 일반적으로 처리하는 많은 작업을 수행할 수 있다. 예를 들어 Babelfish에서 지원하지 않는 특정 T-SQL 명령을 정기적으로 사용이 필요할 경우 Aurora PostgreSQL 포트에 연결하고 PostgreSQL SQL 명령을 사용할 수 있다. Aurora PostgreSQL은 일반적으로 사용되는 많은 SQL Server 기능을 대체하는 기능을 제공한다.

아래 표는 Aurora PostgreSQL에서 사용 가능한 PostgreSQL 기능으로 대체할 수 있는 SQL Server 기능의 몇 가지 예시이다.

SQL Server 기능 비교 가능한 PostgreSQL 기능
SQL Server 대량 복사 PostgreSQL COPY 기능
SQL Server Group By (Babelfish에서는 지원되지 않음) PostgreSQL Group By
SQL Server JSON 지원 PostgreSQL JSON 함수 및 연산
SQL Server XML 지원 PostgreSQL XML 함수
SQL Server 전체 텍스트 검색 PostgreSQL 전체 텍스트 검색
SQL Server 지역 데이터 형식 PostGIS 확장 (지역 데이터 작업용)

 

Babelfish가 아직은 완벽히 T-SQL을 지원하는 것은 아니므로 일부 시스템 함수나 일부 SQL Server의 고유 함수는 지원되지 않는다. T-SQL 제한 사항 및 지원되지 않는 기능에 대해서는 Babelfish 버전에 따라 변경될 수 있으므로 아래 공식 문서를 참고한다. (현재 이 글을 쓰는 시점에서는 Babelfish 1.0.0과 1.1.0 두 버전이 있다.)

l  T-SQL 제한 사항 및 지원되지 않는 기능 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-compatibility.html

l  Babelfish 버전 및 버전에 따른 명령어 지원 여부 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-releases-updates.html

 

 

아래 링크는 Babelfish를  사용한 Aurora PostgreSQL 클러스터를 생성하는 방법과, MS SQL 서버 기반 앱을 Babelfish로 연결하여 MS SQL 쿼리를 실행하는 방법을 설명한다.

l  Babelfish for Aurora PostgreSQL 정식 출시 – 레거시 MS SQL 서버 기반 앱 호환 기능 제공 : https://aws.amazon.com/ko/blogs/korea/goodbye-microsoft-sql-server-hello-babelfish/

 

아래 그림은 실제로 필자가 실습한 내용으로 MS SQL Server의 AdventureWorks2016 데이터베이스를 AWS DMS를 사용하여 Babelfish for Aurora PostgreSQL로 마이그레이션 후 SSRS(SQL Server Reporting Service)에서 SQL Native Client 드라이버를 사용하여 MS SQL 쿼리를 사용하여 리포트를 생성하여 실행한 화면이다. 정상적으로 쿼리가 동작하고 리포트가 생성되는 것을 확인할 수 있다.

 

이처럼 Babelfish를 활용하면 기존의 SQL Server사용시 발생할 수 있는 라이선스 비용을 저렴한 Aurora PostgreSQL로 전환하며, 기존 애플리케이션에 대한 코드 변경을 최소화하고, 빠르고 경제적으로 플랫폼 환경을 전환할 수 있다.

 

[참고자료]

l  [AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기 : https://sungwookkang.com/1497

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

l  T-SQL 제한 사항 및 지원되지 않는 기능 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-compatibility.html

l  Babelfish 버전 및 버전에 따른 명령어 지원 여부 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-releases-updates.html

l  Babelfish for Aurora PostgreSQL 정식 출시 – 레거시 MS SQL 서버 기반 앱 호환 기능 제공 : https://aws.amazon.com/ko/blogs/korea/goodbye-microsoft-sql-server-hello-babelfish/

l  https://aws.amazon.com/rds/aurora/babelfish/?nc1=h_ls

 

 

 

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

 

 

AWS Babelfish, AWS SCT, Schema Migration, 스키마 변경, 스키마 마이그레이션, 스키마 추출, 스키마 변환, 이기종 쿼리 실행

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2  (0) 2022.04.13
[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링  (0) 2022.04.12
[AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기  (0) 2022.04.07
[AWS DMS] AWS DMS를 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기  (0) 2022.04.03
[AWS S3] AWS S3 Storage Lens  (0) 2022.03.28

[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' 카테고리의 다른 글

[AWS CloudWatch] CloudWatch를 활용한 SQL Server RDS 데드락 모니터링  (0) 2022.04.12
[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기  (0) 2022.04.08
[AWS DMS] AWS DMS를 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기  (0) 2022.04.03
[AWS S3] AWS S3 Storage Lens  (0) 2022.03.28
[AWS MySQL] AWS JDBC Driver for MySQL  (2) 2022.03.28

[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' 카테고리의 다른 글

[AWS Aurora] Babelfish를 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기  (0) 2022.04.08
[AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기  (0) 2022.04.07
[AWS S3] AWS S3 Storage Lens  (0) 2022.03.28
[AWS MySQL] AWS JDBC Driver for MySQL  (2) 2022.03.28
[AWS] What is AWS Graviton processor?  (0) 2022.03.26

[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' 카테고리의 다른 글

[AWS SCT] AWS SCT를 활용하여 이기종 데이터베이스 스키마 전환하기  (0) 2022.04.07
[AWS DMS] AWS DMS를 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기  (0) 2022.04.03
[AWS MySQL] AWS JDBC Driver for MySQL  (2) 2022.03.28
[AWS] What is AWS Graviton processor?  (0) 2022.03.26
[AWS RDS] RDS Proxy  (0) 2022.03.23

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

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS DMS] AWS DMS를 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기  (0) 2022.04.03
[AWS S3] AWS S3 Storage Lens  (0) 2022.03.28
[AWS] What is AWS Graviton processor?  (0) 2022.03.26
[AWS RDS] RDS Proxy  (0) 2022.03.23
[AWS RDS] Modify RDS instance type  (0) 2022.03.23

[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' 카테고리의 다른 글

[AWS S3] AWS S3 Storage Lens  (0) 2022.03.28
[AWS MySQL] AWS JDBC Driver for MySQL  (2) 2022.03.28
[AWS RDS] RDS Proxy  (0) 2022.03.23
[AWS RDS] Modify RDS instance type  (0) 2022.03.23
[AWS RDS] Modify RDS SQL Server Standard Edition to Enterprise Edition  (0) 2022.03.22

[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' 카테고리의 다른 글

[AWS MySQL] AWS JDBC Driver for MySQL  (2) 2022.03.28
[AWS] What is AWS Graviton processor?  (0) 2022.03.26
[AWS RDS] Modify RDS instance type  (0) 2022.03.23
[AWS RDS] Modify RDS SQL Server Standard Edition to Enterprise Edition  (0) 2022.03.22
[AWS Aurora] Aurora I/O Planning  (0) 2022.03.20

[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

저작자표시 비영리 변경금지

'AWS' 카테고리의 다른 글

[AWS] What is AWS Graviton processor?  (0) 2022.03.26
[AWS RDS] RDS Proxy  (0) 2022.03.23
[AWS RDS] Modify RDS SQL Server Standard Edition to Enterprise Edition  (0) 2022.03.22
[AWS Aurora] Aurora I/O Planning  (0) 2022.03.20
[AWS Aurora] Aurora Storage Engine  (0) 2022.03.19

+ Recent posts

티스토리툴바