THE NICOLE🌱

핵심 요약Spring @Component 빈은 기본이 싱글톤이라, 빈 안의 인스턴스 필드는 요청을 처리하는 모든 스레드가 함께 씁니다.공유 필드에 LinkedHashMap을 두고 여러 스레드가 동시에 초기화·put()하면 초기화 경쟁(Race Condition), 내부 구조 손상, 메모리 가시성 문제가 함께 생깁니다. 같은 파일을 읽는다고 해서 안전해지지 않습니다.ConcurrentHashMap은 put() 한 번 한 번은 안전하게 만들어 주지만, "파일 전체를 읽어 Map 전체를 바꾼다"는 작업 단위의 원자성까지는 보장하지 않습니다.해결 방법은 두 가지입니다. synchronized로 한 번에 한 스레드만 실행하게 하거나, 지역 변수 Map에 전부 채운 뒤 volatile 참조를 한 번에 교체하는 방식..

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';인덱스가 없다면 데이터베이스는 이 한 명을 찾기 위해 테이블의 첫 행부터 마지막 행까지 전부 다 읽어 봅..