고객사 환경의 중앙 운영 DB CPU 이상을 추적해 라이브러리 컴포넌트 테이블의 구조·식별자·데이터 정합성 문제를 근본 원인부터 재설계
CPU 부하가 보이면 서버를 키우고 싶은 유혹이 있지만 이 작업에서는 테이블 구조와 식별자 정책까지 따라가야 했습니다. 부하가 데이터 정합성과 스키마 문제에서 비롯될 수 있었기 때문입니다.
라이브러리 컴포넌트 테이블은 제품의 여러 기능이 기대는 중심 테이블이라, 단순 튜닝보다 데이터 모델을 다시 보는 쪽이 더 오래 가는 해결책이었습니다.
고객사 환경에서 중앙 운영 DB의 CPU 이상(부하)이 관측됐습니다. 원인을 추적한 결과, 다수 패키지 생태계의 컴포넌트 정보를 담는 라이브러리 컴포넌트 테이블의 구조가 부하·정합성 문제의 근원으로 드러났습니다.
varchar) 타입 컬럼에 JSON을 그대로 저장하던 케이스(예: 라이선스 컬럼)가 존재 — 조회·가공 시 비효율과 데이터 깨짐을 유발먼저 varchar에 JSON을 저장하던 케이스를 전체 테이블 대상 전수조사해 영향 범위와 깨진 데이터 비율을 파악했습니다. 이어 식별자 충돌·대소문자 누락 같은 구조적 문제를 정리한 뒤, 스키마·인덱스·식별자 정책을 재설계해 부하와 정합성을 동시에 잡았습니다.
데이터 엔지니어링 리드로서 부하 원인 추적 → 전수조사 → 구조 진단 → 스키마·인덱스·식별자 재설계를 단독으로 수행했습니다. 증상(CPU 부하)에 대증하지 않고 라이브러리 컴포넌트 테이블의 구조적 결함을 근본 원인까지 추적해 성능과 데이터 정합성을 함께 개선했습니다.
JSON을 적재하던 컬럼의 타입 정규화와 식별자 정책 정비가 핵심 변경점.