개발로 자기계발

OLAP 데이터 파이프라인을 설계하며 내가 내린 결정들

운영 DB를 건드리지 않는 분석 파이프라인을 AWS 서버리스로 구축하면서 갈림길마다 무엇을 왜 골랐는지를 정리한 개인 회고다."이렇게 하면 된다"는 튜토리얼이 아니라, "왜 이 선택이었나"에 대한 기록이다.시작점: 문제는 정해져 있었다운영 DB에서 무거운 집계 쿼리가 돌면 거래 처리가 느려진다 — 이건 답이 정해진 문제다. 분석 데이터를 운영 DB 밖으로 빼는 것. 고민은 "무엇으로 빼고, 무엇으로 분석하고, 무엇으로 보여줄 것인가"였고, 이 글은 그 선택의 기록이다.전체 그림은 이렇게 됐다.운영 DB(RDS) ─▶ S3 Data Lake(raw→cleaned→analytics) ─▶ Glue ETL ─▶ Athena ─▶ QuickSight하지만 처음부터 이 그림은 아니었다. 몇 개는 도중에 바뀌었다...

온프레미스 Oracle Enterprise Edition(RAC)을 RDS for Oracle Standard Edition 2로 옮기면서 갈림길마다 무엇을 왜 골랐는지를 정리한 개인 회고입니다. "이렇게 하면 된다"는 튜토리얼이 아니라 "왜 이 선택이었나"에 대한 기록입니다.(스키마·수치는 일반화한 예시이며 특정 회사·시스템과 무관합니다.)시작점: 제약이 먼저 정해져 있었다이 이관은 시작부터 세 개의 못이 박혀 있었습니다.에디션이 내려간다. EE → SE2. 위로 올리는 게 아니라 아래로 내리는 이관.관리형으로 간다. 타겟은 RDS라 OS 셸이 없다.회선이 좁다. 온프레미스와 AWS를 잇는 선이 100Mbps.보통의 "온프레미스 → 클라우드"와 다른 건 첫 번째입니다. 에디션을 내리는 순간 쓸 수 있는..

3편까지 부하와 병목을 봤습니다. 이번 4편은 PostgreSQL 4편과 짝을 이룹니다 — Aurora 읽기 복제본의 복제 지연, 그리고 PostgreSQL의 VACUUM/bloat에 대응하는 InnoDB의 UNDO 로그와 purge를 실측합니다. 여기서 두 엔진의 가장 근본적인 차이가 드러납니다.실험 환경: MySQL 8.0 / Aurora MySQL 3 / db.r6g.large (2 vCPU / 16GB) / 서울 / 1,000만 행.실험 B — Aurora MySQL 리더와 복제 지연Aurora MySQL 클러스터에 리더 인스턴스를 추가하고, writer에 쓰기 부하(16 스레드)를 주면서 reader로 읽기 부하(32 스레드)를 분산했습니다.결과 — 읽기 분산 + 복제 지연대상처리량Writer ..

2편에서는 중간 부하로 두 엔진이 대등함을 봤습니다. 이번 3편은 PostgreSQL 시리즈와 똑같이 vCPU 한계를 훌쩍 넘는 과부하를 걸어, MySQL(InnoDB)에서 무엇이 병목이 되는지 관찰합니다. 결과는 PostgreSQL과 사뭇 다르고, RDS와 Aurora가 극적으로 갈립니다.실험 환경: MySQL 8.0 / Aurora MySQL 3 / db.r6g.large (2 vCPU / 16GB) / 서울 / 1,000만 행.과부하 시나리오2편은 16~32 스레드였습니다. 이번엔 96 스레드로 쓰기 혼합 부하를 150초간 걸었습니다 (vCPU 2개에 48배).결과 ① — 처리량은 오히려 올라감 TPS쿼리/초평균 지연RDS206.64,132464 msAurora215.54,310445 ms스레드를 ..

1편에서는 대용량 적재를 비교하며 "인덱스 생성(랜덤 쓰기)에서 Aurora가 2배 빠르다"는 걸 봤습니다. 이번 편에서는 실제 OLTP 부하를 걸어 처리 성능과 DB Load를 비교합니다.실험 환경은 1편과 동일: MySQL 8.0 / Aurora MySQL 3 / db.r6g.large (2 vCPU / 16GB) / 서울 / 데이터 1,000만 행.부하 도구 — sysbenchMySQL 표준 벤치마크 도구인 sysbench를 씁니다. (PostgreSQL의 pgbench 대응.) 1편에서 언급했듯 sysbench의 본 목적이 바로 이 run(부하 테스트) 입니다.시나리오sysbench 모드스레드시간쓰기 혼합oltp_read_write16120초읽기 전용oltp_read_only32120초💡 sys..

지난 RDS vs Aurora PostgreSQL 시리즈에 이어, 이번엔 MySQL로 같은 실험을 합니다. 같은 질문: "RDS와 Aurora, 대용량 데이터를 넣을 때 어떻게 다른가?" — 를 MySQL(InnoDB) 관점에서 봅니다.그런데 이번 1편에는 벤치마크할 때 꼭 알아야 할 함정 하나가 등장합니다. "측정 도구를 잘못 고르면 엔진 차이가 아예 안 보인다"는 교훈입니다.실험 환경 (PostgreSQL 시리즈와 동일 기반)항목값엔진MySQL 8.0 (RDS) / Aurora MySQL 3 (8.0 호환)인스턴스db.r6g.large (2 vCPU / 16GB)리전서울 (ap-northeast-2)데이터 규모약 1,000만 행 (~1.3GB)PostgreSQL 때와 인스턴스·리전·네트워크를 동일하게..

3편까지는 부하와 병목을 봤습니다. 이번 4편은 운영에서 꼭 마주치는 두 가지 — Aurora 읽기 복제본의 복제 지연과 PostgreSQL 테이블 bloat·VACUUM을 실측합니다.실험 환경: PostgreSQL 16.14 / db.r6g.large (2 vCPU / 16GB) / 서울 리전 / 데이터 1,000만 행.실험 B — Aurora 리더 추가와 복제 지연구성기존 Aurora 클러스터에 리더(읽기 복제본) 인스턴스를 1대 추가했습니다. 이제 클러스터는 이렇게 구성됩니다:엔드포인트용도예시Writer(클러스터) 엔드포인트읽기/쓰기...cluster-...Reader 엔드포인트읽기 전용(리더로 분산)...cluster-ro-...💡 Aurora는 writer와 reader가 같은 분산 스토리지를..

문제 상황통계 정보 수집(Gather Stats) 이후로 추정되는 시점부터 특정 쿼리들의 실행계획이 Full Scan으로 바뀐 것으로 보임그 결과 direct path read(캐시 우회 디스크 직접 읽기)가 폭증EBS 처리량 버스트 크레딧(EBSByteBalance%)이 100% → 37%까지 소진부하 쿼리에 인덱스를 생성해 INDEX RANGE SCAN으로 유도, 이후 크레딧은 100%로 회복볼륨은 이미 gp3(500 MiBps) 로 충분했고, 진짜 병목은 인스턴스(r6i.large)의 EBS baseline 대역폭(~81 MB/s) 이었음1. 증상: 갑자기 떨어지는 EBSByteBalance%RDS for Oracle을 운영하던 중, CloudWatch의 EBSByteBalance% 지표가 오후 2..