All

템플릿과 Role 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 - Chap3. 반복문과 핸들러 - Chap4. 템플릿과 Role 이전 포스팅에서 모듈로 고정된 설정 파일을 배포하고, handler로 변경 시에만 reload하는 패턴을 실습했습니다. 이번에는 Jinja2 템플릿으로 노드별 맞춤 설정을 생성하고, Role로 playbook을 구조화하는 방법을 다룹니다. 템플릿 (Jinja2 + template 모듈) Chap 3에서 모듈로 nginx 설정을 배포했습니다. 그런데 을 각 노드의 호스트명으로 다르게 설정하고 싶다면? 같은 파일을 3개 만들 수는 없습니다. copy vs template Helm의 디렉토리에서 으로 값을 주입하는 것과 동일한 개념입니다. 다만 Helm은 Go template이고, Ansible은 Jinja2(Python)라는 차이가 있습니다. 문법이 비슷해서 혼동할

반복문과 핸들러 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 - Chap3. 반복문과 핸들러 - Chap4. 템플릿과 Role 이전 포스팅에서 변수와 조건문으로 playbook을 유연하게 만들었습니다. 이번에는 반복문(loop)으로 여러 패키지를 한 번에 처리하고, 핸들러(handler)로 설정 변경 시에만 서비스를 reload하는 패턴을 실습합니다. 반복문 (loop) Chap 2에서 작성한 은 패키지를 하나만 설치합니다. 여러 패키지를 설치하려면 어떻게 해야 할까요? loop 없이 하면 패키지마다 task를 복사해야 합니다. 쿠버네티스에서 동일 구조의 Pod을 여러 개 만들기 위해 Deployment의 를 쓰듯, Ansible에서는 으로 해결합니다. loop 사용 - — 리스트를 순회 - — 현재 반복 요소를 참조하는 예약 변수 💡 예약 변수 은 사용자가 정의하는 변수가 아니라, Ans

변수와 조건문 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 이전 포스팅에서 nginx를 설치하는 playbook을 작성했습니다. 이번에는 패키지명을 하드코딩하지 않고 변수(vars)로 관리하고, 조건문(when)으로 상황에 따라 task 실행을 분기하는 방법을 실습합니다. 변수 (vars) Chap 1에서 작성한 을 다시 보겠습니다. 라는 패키지명이 여러 곳에 하드코딩되어 있습니다. 다른 패키지를 설치하려면 playbook 전체를 수정해야 합니다. 변수로 리팩토링 - — play 레벨에서 변수를 정의 - — Jinja2 문법으로 변수를 참조 ⚠️ 따옴표 필수 를 사용할 때는 반드시 따옴표로 감싸야 합니다. YAML 파서가 를 객체 시작으로 인식하여 문법 오류가 발생하기 때문입니다. 변수 정의 방법 변수를 정의하는 방법은 여러 가지입니다. Helm으로 비유하면 이렇습니다: 우선순위도 비슷합니다.

Ansible 실습 환경 구성과 첫 Playbook 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 Ansible은 에이전트 없이 SSH만으로 서버를 관리하는 자동화 도구입니다. 이번 포스팅에서는 Docker 기반 실습 환경을 구성하고, 인벤토리와 설정 파일의 역할을 이해한 뒤, 첫 Playbook으로 nginx를 설치해봅니다. 실습 환경 아키텍처 Docker Compose로 control 노드 1대 + managed 노드 3대를 구성합니다. Ansible은 에이전트리스(agentless) 구조입니다. managed 노드에 별도 소프트웨어를 설치하지 않고, control 노드에서 SSH로 접속하여 작업을 수행합니다. 쿠버네티스에서 kubelet이 각 노드에 설치되어야 하는 것과 달리, Ansible은 SSH 접속만 가능하면 됩니다. 4개 컨테이너는 브릿지 네트워크로 연결되며, control 노드에서

📦 Docker Hub 제한 탈출 — 온프레미스 Nexus Registry 구축기 Docker Hub의 Free 플랜에서는 Private Repository를 1개만 생성할 수 있다. 서비스가 하나일 때는 문제가 없지만, backend와 frontend처럼 이미지가 2개 이상 필요해지면 유료 플랜을 고려하거나, 자체 Registry를 운영해야 한다. 이 글에서는 온프레미스 Kubernetes 클러스터에 Nexus Repository Manager를 배포하고, 기존 Docker Hub 기반 CI/CD 파이프라인을 Nexus로 전환한 과정을 정리한다. 기존 구조와 문제점 기존에는 Jenkins(Kaniko)가 Docker Hub에 이미지를 push하고, 클러스터가 Docker Hub에서 pull하는 구조였다. 이 구조의 문제: - Private Repository 1개 제한 (Free 플랜): backend, frontend 두 이미지를 private으로 관리할 수 없음 - Pull

🤖 Claude Code란? Claude Code는 Anthropic이 공식으로 제공하는 CLI(Command Line Interface) 기반의 AI 코딩 어시스턴트다. 터미널에서 직접 실행하여 코드베이스를 이해하고, 파일을 편집하고, 명령어를 실행하며, 복잡한 소프트웨어 엔지니어링 작업을 자연어로 수행할 수 있다. 기존의 채팅 기반 AI 도우미와 달리, Claude Code는 로컬 환경에서 직접 동작하며 파일 시스템, Git, 쉘 명령어 등에 접근할 수 있어 실질적인 개발 작업을 수행할 수 있다는 점이 가장 큰 차별점이다. ⚡ 주요 특징 1. 터미널 네이티브 IDE 플러그인이 아닌 터미널에서 직접 실행되므로, 어떤 개발 환경에서든 사용할 수 있다. VS Code, JetBrains, Vim 등 에디터에 종속되지 않는다. 2. 코드베이스 전체 이해 프로젝트의 파일 구조를 탐색하고, 코드를 읽고, 의존성 관계를 파악한다. 단순히 열려 있는 파일만 보는 것이 아니라 프로젝트 전체 컨

Kubernetes + Jenkins + ArgoCD로 검색엔진을 포함한 블로그 CI/CD 파이프라인 구축기 지금 이 글을 보고 있는 이 블로그는 온프레미스 Kubernetes 클러스터 위에서 돌아가고 있다. 사실 블로그 하나 띄우는 데 Kubernetes까지 필요하냐고 물으면, 솔직히 필요 없다. Vercel에 올리면 5분이면 끝난다. 근데 나는 이 블로그를 인프라 놀이터로 쓰고 싶었다. 코드를 push하면 이미지 빌드부터 배포, 검색 색인 갱신까지 자동으로 돌아가는 파이프라인을 직접 만들어보고 싶었고, 실제로 만들었다. 이 글에서는 이 파이프라인이 어떤 아키텍처로 구성되어 있고, 각 설계 결정에 어떤 이유가 있었는지를 실제 매니페스트와 함께 다뤄보려 한다. 전체 아키텍처 먼저 전체 그림을 보자. 핵심은 두 개의 Git 저장소가 역할을 분리한다는 것이다: - blog-new: 애플리케이션 소스코드. Next.js 앱, 마크다운 콘텐츠, Jenkinsfile, ES 색인 스크립트가

엘라스틱서치 데이터 핸들링

카프카 설치하기 🔍 카프카 스터디 시리즈 - Chap1. 카프카 시작하기 - Chap2. 카프카 설정하기 ⭐️ 이번 2장의 제목은 '카프카 설치하기' 이지만, 설치 방법에 대해서는 따로 다룰 가치를 느끼지 못하겠으므로 카프카 컨트롤러 노드, 메타데이터 관리, 브로커 및 컨슈머 설정 등에 대해 다루도록 하겠습니다. Zookeeper vs KRaft 앞서 에서는 Kafka가 Zookeeper 방식과 KRaft 방식으로 동작한다고 KIP-500에 대한 이야기를 포함하여 설명하였습니다. 이번 절에서는 Zookeeper, KRaft가 필요한 이유와 왜 카프카 커뮤니티가 KRaft라는 대안을 선택하게 되었는지에 대해 간략하게 알아보고자 합니다. Kafka 메타데이터 관리의 중요성 Kafka는 단순한 메시지 큐가 아닙니다. Kafka의 본질은 분산 로그 시스템이고, 분산 시스템에서 사장 어려운 문제는 데이터가 아니라 상태(state)입니다. Kafka에서 말하는 메타데이터는 source o

카프카 시작하기 🔍 카프카 스터디 시리즈 - Chap1. 카프카 시작하기 - Chap2. 카프카 설정하기 개요 카프카에 대해 제대로 공부해보고자 스터디를 시작했습니다. 이번 포스팅 시리즈에서는 서적 "카프카 핵심 가이드" 를 완독하고 카프카의 구조 및 생태계에 대한 전반적인 학습 및 각 기능의 POC를 실제로 수행하는 것을 목표로 합니다. 책의 서문에서, 유명한 과학자인 닐 디그래스 타이슨의 말을 인용합니다. "과학자들이 서로 동의하지 않는 상황이 벌어진다면, 그것은 데이터가 불충분하기 때문이다. 그리고 어떠한 데이터를 얻을 것인지를 합의하고 데이터를 얻을 수 있다면 문제는 해결된다. 내가 올든 상대방이 옳든, 아니면 둘 다 틀리든 말이다. 그제서야 우리는 그 다음으로 진행해 갈 수 있다." - 닐 디그래스 타이슨 모든 기업은 데이터로 움직이며, 우리는 이런 데이터를 얻고, 분석하고, 가공하여 단순한 데이터 이상의 것을 결과물로 산출해야만 합니다. 데이터의 모든 부분은 의미가 있

Spring Batch 성능 개선기 - N+1 문제 1. 서론 본 문서에서 다루는 배치 애플리케이션(추천 전처리 시스템)은 단순한 통계 집계가 아닌, 실제 서비스에서 사용자의 시청 이력에 기반한 개인화 푸시 알림을 빠르게 발송하기 위한 전처리 역할을 합니다. 서비스 입장에서는 수십만 명의 사용자에게 5분 이내로 추천 알림을 보내야 하고, 알림을 받은 사용자가 앱을 열었을 때 곧바로 추천 콘텐츠를 확인할 수 있어야 합니다. 하지만 알림 발송 시점마다 추천 로직을 실시간으로 실행한다면 문제가 생깁니다. 데이터베이스 I/O와 연산 비용으로 대규모 트래픽을 감당하기 어렵고, 지연도 불가피해집니다. 운영 환경에서는 마케터나 관리자들이 캠페인을 구성한 후, 특정 시간 예약 발송이나 즉시 발송을 유동적으로 선택합니다. 발송 요청 시점에야 "어느 사용자의 추천 데이터가 필요한지"가 드러나므로, 사전 계산 전략만으로는 부족합니다. 따라서 예약/즉시 여부와 무관하게 언제든 빠른 알림을 위해, 매일 자

JPA saveAll이 느린 이유와 개선 방향 💡 “JPA를 포함한 ORM은 은총알이 될 수 없습니다.” 우리는 종종 ORM을 사용하면 SQL과 트랜잭션의 복잡함에서 해방될 거라 믿습니다. ORM은 데이터를 객체로 다루는 자유를 주지만, 동시에 성능과 제어의 일부를 포기하는 대가를 요구합니다. Hibernate의 은 한 줄의 코드로 모든 걸 해결할 수 있을 것처럼 보입니다. 그러나 그 한 줄 뒤에서 ORM은 수십, 수백 개의 INSERT를 순차적으로 실행하며 JDBC의 배치 성능을 스스로 봉인하고 있습니다. 기존 은 엔티티 단위로 INSERT가 반복되어 네트워크 라운드트립과 엔티티 라이프사이클 오버헤드가 컸습니다. 로 전환하고 드라이버 배치 리라이트를 켜서 한 번의 배치로 밀어 넣으니 60초 → 7.3초로 단축됐습니다. 다대다 테이블을 매핑하는 가상의 TableMapper 엔티티의 예시를 통해 아래에 원인, 설정, 로그 차이, 주의사항을 정리하겠습니다. 배경: 기존 코드 vs 개선

MySQL Prepared Statement란? Prepared Statement의 등장 배경 초창기 SQL 인터페이스에서는 모든 쿼리를 문자열로 조합해 실행했습니다. 예를 들어 같은 방식입니다. 이런 구조는 다음과 같은 문제를 가지고 있었습니다: 1. SQL Injection 취약성 2. 매번 쿼리를 파싱하고 최적화해야 하는 성능 문제 3. 타입 안전성 부족 이러한 문제를 해결하기 위해 Prepared Statement(준비된 쿼리) 개념이 등장했습니다. 미리 SQL 구조를 컴파일하고, 실행 시점에는 파라미터만 바인딩하는 방식입니다. Prepared Statement의 역사와 JDBC/Hibernate와의 관계 MySQL에서 Prepared Statement는 MySQL 4.1 (2004년) 버전부터 도입되었습니다. 이는 MySQL 서버가 처음으로 바이너리 프로토콜(Binary Protocol) 기반의 서버사이드 Prepared Statement를 지원하기 시작한 시점입니다.

🧪 Spring Batch JpaCursorItemReader에 대하여 Spring Batch에서 대량 데이터 처리를 다뤄본 개발자라면 한 번쯤 고민했을 것입니다. “JPA 기반으로 커서(Cursor)처럼 데이터를 읽을 수 있을까?” 오늘은 그 핵심 컴포넌트인 의 역사와, 왜 가 사라졌는지, 그리고 MySQL과 PostgreSQL의 커서 동작 차이까지 실제 실험 데이터와 함께 정리해보겠습니다. 1. JpaCursorItemReader의 역사 1.1 등장 배경 는 Spring Batch 4.3 (2020년경) 에 도입된 컴포넌트입니다. 그 이전까지는 JPA 환경에서 커서 기반 배치를 구현하려면 Hibernate의 를 직접 사용하거나, PagingItemReader를 우회적으로 이용해야 했습니다. 하지만 Paging 방식은 offset 기반 페이징 쿼리 특성상 큰 데이터셋에서는 성능이 급격히 저하되는 문제가 있었습니다. 그래서 Spring 팀은 “JPA 환경에서도 커서

Spring Batch에서 도중 종료시 BATCHJOBEXECUTION의 STATUS가 업데이트 되지 않는 문제 이 문서는 Spring Batch 애플리케이션에서 (안전한 종료)을 시도했음에도 불구하고, 테이블의 가 로 변경되지 않고 상태로 남아 재시작이 불가능한 문제에 대해 실제로 진행했던 트러블슈팅 과정을 중심으로 설명합니다. 1. 문제 상황 발생 배치 Job이 실행 중일 때 을 시도했습니다. 예상대로라면 테이블의 컬럼이 로 변경되어야 하지만, 실제로는 상태로 남아 있었습니다. - 예상 결과: = - 실제 결과: = 이 상태에서 동일한 파라미터로 Job을 재실행하면 Spring Batch는 해당 Job Instance가 이미 실행 중()이라고 판단하여 예외를 발생시키며 실패합니다. 2. 문제 상황 재현 = true로 하여, 애플리케이션이 실행될때 처리하도록 하려 했습니다. 이는 k8s에서 Job 파드로 처리하기 위함이었는데요, 문제는 요청 시점에 의 상태가