개요 : 평소 AWS 리소스를 운영 중 Latency 지표에 대한 궁금증이 많았습니다. 디스크 I/O 1건당 평균 소요시간이라는 해당 지표는 Write처리량이 높을 때는 낮은 Latency를 점검 같은 사용량이 낮을 때는 높은 Latency 지표를 보일 때가 있었는데요. 디스크 성능 수준을 보는 해당 지표라면 처리량에 따른 Latency 수준은 같아야 하지 않나? 라는 생각이 항상 따라다녔습니다. 해당 사례에서 AWS 엔지니어분과의 질의를 통해 지표에 대한 이해를 좀 더 높일 수 있었습니다.배경 : DocumentDB 이관 배치 중 INSERT 지연판별 근거 : WriteLatency 감소 + DiskQueueDepth 급증현상이관 배치 구간의 지표가 직관과 반대 방향으로 움직였습니다.지표작업 전작업 중..

개요 : 약 20GB 규모 컬렉션의 $out 이 약 45분 소요된 원인을 확인하고, 대량 쓰기 작업의 배치 설계 기준을 정리하고자 합니다.현상컬렉션을 백업하기 위해 $out 과 mongoexport 를 수행하였으나 1시간이 넘어 중단하였습니다.항목값대상DocumentDB 5.0인스턴스db.r8g.xlarge (버퍼 캐시 약 21.3 GiB)$out 소요 시간라이브 서버 예측 : 약 1시간 30분 테스트 서버 : 2,687초 (약 45분)컬렉션 물리 크기약 25,423 MiB (3,254,153 페이지)확인 내용A. 컬렉션 사이즈가 성능에 영향을 주는지--> 영향을 줍니다. 약 15 GiB 까지 평탄하다가 버퍼 사이즈와 유사한 20 GiB 부터 성능이 급격히 감소대상 크기페이지소요ms/page소스 히트율2..

개요 : maxTimeMS 를 지정하였음에도 쿼리가 중단되지 않는 원인을 확인하고 정리하고자 합니다.현상maxTimeMS 를 5,000ms 로 지정한 aggregate 쿼리가 약 15초 동안 수행되고도 중단되지 않는 것을 확인하였습니다.항목값대상db.collection지정한 maxTimeMS5,000 ms실제 수행 시간(millis)14,974 ms (약 15초)planSummaryCOLLSCANnreturned38 건수집된 profile 로그입니다. [실측]{ "ns": "db.collection", "command": { "aggregate": "collection", "pipeline": [ { "$match": { "collection.col1": { "$exists": t..

개요 : Performance Insights 의 DocumentLock 대기 이벤트가 증가한 원인을 확인하고 정리하고자 합니다. 현상특정 클러스터에서 UTC 2026-04-04 17:30:28 경 profile 로그상 INSERT 쿼리가 평소 대비 지연되는 것을 확인하였습니다.같은 시점 Performance Insights 에서 DocumentLock 대기 이벤트로 INSERT 가 증가하는 것을 확인하였습니다.공식 문서에는 DocumentLock 이 "동일한 문서에 대한 동시 쓰기 횟수가 많으면 발생" 한다고만 기술되어 있습니다.그런데 해당 시점의 INSERT 는 증분 _id 를 사용하였으므로 동일 문서에 대한 동시 쓰기로 보기 어려웠습니다.다만 인덱스로 사용하는 필드에 대하여 동일한 값의 INSERT..

개요Aurora PostgreSQL 의 메이저버전 업그레이드를 진행하면서 확인하였던 내용을 정리하였습니다.대상은 논리복제를 사용하고 있는 클러스터, 미사용하고 있는 클러스터로 나누어져 있으며논리복제를 사용하는 경우 AWS의 블루그린 배포를 사용하지 못하여 자체적으로 처리하였으며논리복제를 사용하지 않는 경우 AWS의 블루그린 배포를 사용하여 진행하였습니다.작업 절차는 논리복제를 사용하는 자체 구성에 대하여 작성하였으며 하단에 블루그린 배포를 사용하는 경우의 차이점, 유의사항을 추가하였습니다.Aurora PostgreSQL 14.6 → 16.8목적 EOS 로 인한 메이저버전 업그레이드방식 Aurora Clone 기반 자체 논리 복제 구성 아래 내용은 QA 서버를 대상으로 진행하였습니다.대상 구성대상 DB 1..

개요 : Aurora 비용 관리 측면에서 데이터 유지보수에 대한 개발팀과의 논의 중 클러스터의 스토리지 사용량은 DELETE 로는 사용량이 줄지 않고 DROP 으로만 줄어드는 것에 대하여 좀 더 깊은 이해를 가지고 싶어 DBMS별 DELETE와 DROP의 처리 방식이나 차이에 대하여 알아두고자 합니다 처음 가졌던 추측은SQL SERVER에서 경험했던 것 처럼 DELETE 로 처리되면 논리적인 크기만 확보되고 SHRINK 등의 작업 없이는 물리적인 크기는 확보되지 않는 것이 아닐까. DROP은 파일 단위를 삭제 (Innodb의 경우 옵션에 따라 다르지만)하여 바로 회수가 되는 것 아닐까였습니다 DELETE 동작 방식. MySQL InnoDBDELETE 는 행을 즉시 제거하지 않고 delete-marked ..

개요기본적으로 대소문자 구분을 하는 PostgreSQL에서 대소문자 구분 없이 데이터를 조회할 방법이 있을지에 대한 검토입니다. DB 생성 옵션Aurora PostgreSQL은 파라미터로 Collate를 지정할 수 없습니다.다만 생성할 때 CLI를 사용하면 지정이 가능합니다.create-db-cluster[--availability-zones ][--backup-retention-period ][--character-set-name ][--database-name ]다만 지정 가능한 값은 C, en_US.UTF-8 로 CI, CS 의 옵션이 없어서 대소문자 구분과는 큰 관련이 없습니다대소문자 구분 없애는 방법 리스트 방법인덱스 사용Like 구문1LOWER() / UPPER() 함수함수형 인덱스 필요가능2..

개요 : Aggressive Vacuum의 영향도를 줄이기 위해 Vacuum Freeze 배치를 설정했던 과정을 정리합니다.Aurora PostgreSQL 대형 테이블 Aggressive Vacuum 운영 전략수백 GB 이상의 대형 테이블에서 Transaction ID Wraparound를 방지하면서서비스 영향을 최소화하는 VACUUM FREEZE 배치 운영 방법을 정리합니다.테이블 사이즈가 증가할 수록 Tuple 수는 증가하게될 때 Vacuum 트리거를 조정하여 상대적으로 Vaccuum이 자주 동작하게 하면 일반 Lazy Vacuum의 영향도는 일정하더라도 Eager 방식의 Vacuum의 영향도는 해소가 되지 않습니다.AutoVacuum의 autovacuum_freeze_max_age 기준에 도달하면 ..

개요 : Aurora 환경에서만 익숙해져있어서 Onpremise 환경의 특징도 알아두고자 베이스한 내용을 공부하고자 함[PostgreSQL On-Premise] Phase 1 — 설치 및 파일시스템 구조Aurora와의 핵심 차이Aurora 관리 영역On-Premise에서 직접 해야 할 것initdb 자동 실행initdb 직접 실행, --data-checksums 설정파일 구조 비가시화$PGDATA 구조 이해 및 직접 관리Parameter Grouppostgresql.conf + pg_hba.conf 직접 관리프로세스 추상화각 프로세스 역할 이해, OOM 대응OS 튜닝 AWS 담당vm.swappiness, HugePages 등 직접 설정1-1. initdb — 클러스터 초기화initdb -D /var/li..

개요 : Aurora PostgreSQL 표준화를 진행하면서 확인하였던 파라미터에 대한 정리입니다.Aurora PostgreSQL 파라미터 표준값 정리 — OLTP 환경 기준Aurora PostgreSQL을 운영하면서 파라미터 표준값을 정립하는 과정에서 확인한 내용들을 정리합니다.환경 기준: 4 vCPU / 32GB (r6g.xlarge), OLTP, max_connections 36001. Aurora 파라미터의 특수성Aurora 파라미터를 다룰 때 두 가지 개념을 구분해야 합니다.Aurora 기본값이 자동 계산되는 파라미터: 수정은 가능하지만 Aurora가 인스턴스 메모리/vCPU 기반으로 최적값을 자동 계산합니다. 기본값이 대부분의 경우 적절하며, 변경 시 의도치 않은 성능 저하가 생길 수 있어 주..