개발로 자기계발

RDS vs Aurora PostgreSQL 비교 실험 (4)

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가 같은 분산 스토리지를..

Oracle 통계 수집 후 EBS 처리량 크레딧이 바닥친 이유

문제 상황통계 정보 수집(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..

RDS vs Aurora PostgreSQL 비교 실험 (3)

1편·2편에서는 "정상 범위" 부하를 봤습니다. 이번 3편은 반대로 vCPU 한계를 훌쩍 넘는 과부하를 일부러 만들어, DB가 무엇을 기다리며 느려지는지(대기 이벤트)를 관찰합니다.실험 환경은 동일: PostgreSQL 16.14 / db.r6g.large (2 vCPU / 16GB) / 서울 리전 / 데이터 1,000만 행.과부하 시나리오정상 부하(2편)는 16~32 clients였습니다. 이번엔 96 clients로 쓰기 혼합 부하를 150초간 양쪽에 동시에 걸었습니다. vCPU가 2개뿐인데 96개 클라이언트가 달려드니, 세션들이 자원을 기다리며 줄을 서게 됩니다.결과 ① — TPS는 떨어지고 지연은 폭증TPS평균 지연RDS605158.6 msAurora503190.8 ms2편 정상 부하(16c)에서..

1편에서는 두 엔진에 1,000만 행을 적재하며 CloudWatch 지표를 비교했습니다. 이번 편에서는 실제로 부하를 걸어 처리 성능과 DB Load를 비교합니다.실험 환경은 1편과 동일합니다: PostgreSQL 16.14 / db.r6g.large (2 vCPU / 16GB) / 서울 리전 / 데이터 1,000만 행.먼저, TPS가 뭔가요?TPS = Transactions Per Second, 초당 처리한 트랜잭션(작업) 수입니다.데이터베이스가 1초에 몇 건의 작업(조회/삽입/수정 등)을 완료했는지를 나타내는 처리량(throughput) 지표입니다.높을수록 좋습니다. "이 DB가 초당 2,000건을 처리한다"처럼 씁니다.함께 보는 지표가 지연시간(latency) 입니다. 이건 "한 건이 끝나는 데 걸..

한눈에 보기subprocess.run(timeout=8)은 제한 시간을 넘기면 TimeoutExpired를 발생시킨다.파드 신원 검증 타임아웃은 요청 거부로 처리하되, executor 프로세스는 종료되지 않아야 한다.예외를 ValueError로 변환하면 검증은 fail-closed로 유지하면서 실행 프로세스를 살릴 수 있다.문제 상황호스트 전용 작업을 실행하기 전에 파드 신원을 확인하는 로직이 있었다. 이 함수는 내부적으로 kubectl get pods를 호출해 대상 파드 정보를 조회한다. 호출에는 Kubernetes 요청 제한 시간과 subprocess 제한 시간이 함께 설정돼 있었다.기존 코드에서는 subprocess.run() 호출 중 발생하는 subprocess.TimeoutExpired를 처리하..

왜 이걸 하게 됐나DBA로 일하다 보면 "RDS랑 Aurora 중에 뭐가 더 나아요?"라는 질문을 자주 받습니다. 그런데 고객사 운영 환경을 직접 부하 테스트할 수는 없습니다. 그래서 테스트 계정에 RDS PostgreSQL과 Aurora PostgreSQL을 똑같은 스펙으로 띄우고, 동일한 데이터를 넣어 직접 비교해보기로 했습니다.이번 1편은 그 첫 단계 대용량 데이터를 적재하면서 두 엔진의 차이가 어디서 나타나는지를 CloudWatch 지표로 관찰한 기록입니다.실험 환경공정한 비교를 위해 두 엔진을 완전히 동일한 조건으로 맞췄습니다.항목값엔진PostgreSQL 16.14인스턴스db.r6g.large (2 vCPU / 16GB)리전서울 (ap-northeast-2)적재 도구pgbench 17.10데이터..

만든 이유프로젝트마다 아키텍처 다이어그램을 그리는 건 생각보다 시간을 잡아먹습니다. draw.io 열어서 AWS 아이콘 찾고, 하나씩 배치하고, 선 연결하고, 라벨 달고. 서비스 7 ~ 8개짜리 간단한 구성도에도 20 ~ 30분은 금방 갑니다.AI 코딩 도구를 쓰면서 "아키텍처도 말로 설명하면 간단한 초안이라도 그려주면 좋겠다"는 생각이 들었습니다. 그래서 어떤 LLM이든(Kiro, Claude Code, Codex, Grok) 동일하게 동작하는 전역 스킬을 만들었습니다."API Gateway → Lambda → DynamoDB 구조 그려줘" 한마디면 draw.io 파일이 생성됩니다.뭘 하는 스킬인가/aws-arch-diagram은 두 가지 방식으로 동작합니다:자연어 입력 — "CloudWatch → S..

왜 만들었나운영 DB에서 슬로우 쿼리가 터지면 DBA가 직접 세션을 열어 확인하고, 실행계획을 뜯어보고, 개발자한테 "여기 인덱스 태워야 합니다" 하고 전달합니다. 이 과정이 건당 짧으면 10분, 길면 30분 넘게 걸립니다. 하루에 여러 건 들어오면 튜닝 분석에만 반나절이 가버리죠.이 시간을 줄여보고 싶었습니다. 알람이 올라오면 세션 스캔부터 실행계획 분석, 튜닝 권고문 작성까지 AI가 대신 해주면 — 제가 검토만 하면 되니까요. Amazon Bedrock의 Claude 모델을 붙여서 이 파이프라인을 자동화했습니다.현재 Oracle, MySQL, PostgreSQL, MSSQL, DocumentDB 5개 엔진에서 돌아가고 있고, 분석 결과는 Google Chat으로 바로 떨어집니다.전체 구조두 개의 La..