THE NICOLE🌱

DB 일일 점검 자동화 시스템의 POC를 진행하면서, 처음에는 데이터베이스 3대를 대상으로 파이프라인을 만들었습니다. 매일 아침 정해진 시각에 지표를 수집하고, 이상을 탐지하고, 그 결과를 HTML 리포트로 만들어 메일로 보내는 흐름이었습니다. 3대가 잘 돌아가고 나니, 다음 목표는 자연스럽게 "그럼 나머지 전체 인스턴스에도 똑같이 적용할 수 있는가"가 되었습니다. 전체 규모는 약 190대였고, 그 190대를 10명의 담당자에게 각자 맡은 것만 골라 보내야 했습니다.이 글은 그 확장 작업을 어떻게 설계하고 배선했는지를 정리한 기록입니다. 단순히 "숫자를 3에서 190으로 늘렸다"가 아니라, 기존 3대 흐름을 하나도 건드리지 않으면서 190대를 얹을 수 있도록 만든 구조에 대한 이야기입니다. 코드가 어떻게..

핵심 요약DB 일일 점검 리포트를 처음에는 몇 대만 대상으로, 한 통의 메일에 전부 담아 보냈습니다. 그런데 점검 대상이 수백 대로 늘면서 한 통에 다 담을 수 없게 됐습니다. 게다가 인스턴스마다 담당자가 다르고, 한 인스턴스를 회사 담당자와 협력사 담당자가 함께 관리하는 구조였습니다.그래서 "담당자(수신자) 단위로 리포트를 나눠, 각자 자기 담당분만 받아보게" 하는 라우팅 계층을 만들었습니다. 이 글은 그 과정을 처음부터 끝까지, 실제 코드와 함께 정리한 것입니다.큰 줄기는 다섯 단계입니다.지저분한 담당자 매핑 엑셀을 표준 한 시트로 정제한다.표준 시트를 읽어 인스턴스 목록을 만든다(제외·무효 이메일·직급 정리 포함).인스턴스 목록을 담당자 기준으로 뒤집어 수신자별로 묶는다.담당자 한 명분 리포트를 조..

핵심 요약요즘 DB 일일 점검을 자동화하는 프로젝트를 하고 있습니다. 매일 아침 DB 상태를 점검해서 이상한 게 있으면 리포트로 뽑아 주는 시스템인데요. 이상을 탐지하는 건 룰베이스(임계값)와 PCA(비지도 이상탐지) 로 하고 있었습니다.탐지까지는 잘 되는데, 그 옆에 붙는 "원인 추정 / 권장 조치" 문구가 그동안 템플릿(정해진 문구 매핑) 이라 아쉬웠습니다. 그래서 이번에 그 진단 문구를 LLM(클로드)이 생성하도록 기능을 추가했습니다. 검증은 무료 LLM으로 하고, 운영은 AWS Bedrock의 클로드로 갈 계획입니다.제가 이 기능을 붙이면서 제일 신경 쓴 원칙은 이 세 가지였습니다.판단(무엇이 이상인가) 은 그대로 코드(룰 + PCA)가 한다.해석(원인·조치) 만 LLM이 그 탐지 결과를 받아 자..

핵심 요약오랜만에 개발 클러스터의 ML 잡 에이전트(Kafka 컨슈머)를 다시 켰습니다. 그게 전부였습니다. 그런데 약 4분 뒤 노드가 DiskPressure=True 로 떨어지면서 Jenkins·ArgoCD·MLflow·서빙까지 거의 모든 파드가 축출되거나 Pending 으로 무너졌습니다.원인은 한 줄로 말하면 이렇습니다. 컨슈머가 커밋해 둔 오프셋이 만료돼 없었고, 설정이 earliest 였던 탓에, 토픽에 보존돼 있던 과거 학습 실행 커맨드 22건을 한꺼번에 다시 소비했습니다. 에이전트는 그 커맨드들을 충실히 처리했고, 그래서 학습 잡 22개가 거의 동시에 살아나 각자 약 650MB짜리 이미지를 동시에 내려받기 시작했습니다. 단순 합산으로 약 14GB. 평소 여유가 20GB도 안 되던 단일 노드의 ..

핵심 요약1편에서 "왜 그냥 안 되는가"(RHEL 6.5 = GLIBC 2.12 = 최신 라이브러리 거부)를 정리했습니다. 이번 편은 실제로 자체완결 번들을 만든 과정입니다.핵심은 RHEL 6.5와 같은 GLIBC 2.12 환경(manylinux2010 도커 이미지)에서 빌드하는 것입니다. 윈도우나 최신 우분투에서 만들면 GLIBC가 높아 RHEL 6.5에서 안 돕니다.만드는 동안 함정이 여럿 있었습니다. ① 도커의 Python이 실제 파일이 아니라 심볼릭 링크였던 것(번들이 196KB로 나옴) ② RHEL 6.5에 없는 비표준 라이브러리 2개를 같이 담아야 했던 것 ③ 검증 환경(CentOS 6 컨테이너)이 세그폴트로 죽은 것 등입니다.라이브러리 로드뿐 아니라 앱이 끝까지 도는지(수집→탐지→리포트), ..

핵심 요약파이썬으로 만든 프로그램을 납품해야 하는데, 설치할 서버가 ① RHEL 6.5(2013년 출시, 매우 오래된 리눅스) ② 폐쇄망(인터넷 차단) ③ Python 미설치 라는 세 조건이 겹친 환경이었습니다.이 조합에서는 평소처럼 서버에서 pip install 한 방이 통하지 않습니다. 인터넷이 없고, OS가 너무 오래돼서 최신 라이브러리가 아예 실행되지 않기 때문입니다.가장 깊은 원인은 GLIBC(리눅스의 최하단 C 라이브러리) 버전입니다. RHEL 6.5는 GLIBC 2.12(2010년대 초)인데, 요즘 라이브러리는 더 높은 GLIBC를 요구해서 거부당합니다. "JDK 17로 빌드한 jar를 JDK 8에서 못 돌리는 것"과 같은 원리입니다.해결 방향은 Python 실행기 + 필요한 라이브러리 + ..

핵심 요약분산 메시징에서는 네트워크 단절·재시도·장애 때문에 메시지 유실과 중복이 생깁니다.전달 보장은 3종입니다. at-most-once(유실 가능·중복 없음), at-least-once(유실 없음·중복 가능, 실무 기본), exactly-once(둘 다 없음, 비쌈).컨슈머의 처리와 오프셋 커밋 순서가 유실/중복을 가릅니다. (커밋 먼저=유실, 처리 먼저=중복)exactly-once는 멱등 프로듀서 + 트랜잭션으로 카프카 내부에서 달성하지만, 외부 부수효과까지는 보장 못 해 컨슈머 멱등성이 결국 필요합니다.목차들어가기 전 — 카프카 기본 구조부터 짚고 가기메시지 전달은 왜 어려운가 — 유실과 중복전달 보장 3종 — at-most-once / at-least-once / exactly-once오프셋과 ..

핵심 요약사내 DB 모니터링 시스템을 만들면서, 매일 아침 사람이 눈으로 훑던 DB 점검을 자동화했습니다. 핵심은 두 가지 이상 탐지를 한 화면에 녹여 넣는 일이었습니다.룰베이스 3종 — 절대 임계 초과(그날 최고값이 경고/위험 선을 넘는가), 전일 대비 급증(일평균이 2배 이상 뛰었는가), 패턴 변화(% 지표가 전일 대비 20%p 이상 올랐는가)를 분 단위로 검사합니다. DB마다 임계값이 달라 설정 파일로 분리했습니다.비지도 학습(PCA 복원오차) — 한 달치 정상 패턴을 주성분으로 압축했다가 복원해, 평소와 다른 조합이 들어오면 복원이 잘 안 되는 성질(복원오차 증가)로 "임계는 안 넘었지만 평소와 다른 날"을 잡습니다. 단일 지표가 아니라 여러 지표가 동시에 평소 조합에서 벗어나는 조합 이상을 잡는..

목차인덱스란 무엇인가 — 풀 스캔의 고통클러스터드 인덱스 vs 보조 인덱스 (InnoDB의 핵심 구조)조인을 만나면 DB는 어떻게 움직이는가옵티마이저는 무엇을 보고 판단하는가조인 말고도 — 인덱스가 활약하는 순간들인덱스를 걸어도 안 타는 경우들 (안티패턴)정리 — 인덱스 설계 원칙1. 인덱스란 무엇인가 — 풀 스캔의 고통인덱스가 없으면 무슨 일이 벌어지는가데이터베이스에 회원 100만 명이 들어 있는 테이블이 있다고 가정해 보겠습니다. 여기서 이메일이 kim@example.com인 사람 한 명을 찾으려고 합니다.SELECT * FROM users WHERE email = 'kim@example.com';인덱스가 없다면 데이터베이스는 이 한 명을 찾기 위해 테이블의 첫 행부터 마지막 행까지 전부 다 읽어 봅..

핵심 요약최근 데이터베이스 일일 점검을 자동화하는 프로젝트를 맡게 되면서, DBA가 매일 들여다보는 모니터링 지표들을 처음부터 정리하고 있습니다. 첫 글에서 MySQL, 두 번째 글에서 Oracle을 다뤘는데, 이번 PostgreSQL이 시리즈의 마지막입니다. PostgreSQL은 같은 관계형 데이터베이스이면서도 데이터를 관리하는 방식이 앞의 둘과 또 달라서, 지표 이름에도 다른 DB에는 없는 단어들이 보였습니다. Dead Tuple, VACUUM, Age, autovacuum 같은 말이 그렇습니다. 그래서 이번에도 하나씩 정리해 두기로 했습니다.이 글에서는 PostgreSQL(및 PostgreSQL on RDS)에서 자주 보는 지표들을 ① 무엇을 의미하는지 ② 평소 어느 정도 값이 정상인지(실제 관측 ..