반응형

전체 글 310

Intel Turbo Boost 끄고 CPU 발열 잡기

Overview개발이나 빌드 작업 중 CPU 온도가 90도 이상 치솟는 경험을 한 적 있나요? 특히 여름철이나 발열에 취약한 노트북 환경에서는 Intel Turbo Boost 기능이 오히려 성능 저하나 시스템 다운의 원인이 되기도 한다. 이번 글에서는 Intel Turbo Boost 비활성화를 통해 CPU 발열 문제를 해결한 실제 사례를 소개한다. `sensors` 명령어로 확인한 온도 변화와 적용한 설정 과정을 정리했다. 문제 상황Gitlab Runner가 Kubernetes에서 실행 될때 팬 소음이 과하게 발생하고, 시스템이 눈에 띄게 느려지기 시작했다.이상 징후를 감지한 후 sensors 명령어로 온도를 확인해 본 결과Package id 0: +93.0°CCore 0~7: ..

Trouble Shooting 2025.06.30

트랜잭션(Transaction)과 동시성 제어(Concurrency Control)

Overview오늘은 데이터베이스 트랜잭션(Transaction)과 동시성 제어(Concurrency Control) 개념에 대해 알아보려고 한다. 트랜잭션은 데이터베이스에서 작업을 원자적으로 실행하는 단위이며, 여러 사용자가 동시에 접근할 경우 충돌을 방지하는 동시성 제어 기법이 필요하다.이번 글에서는 트랜잭션의 개념과 실행 방식, 그리고 대표적인 동시성 제어 기법인 MVCC(Multi-Version Concurrency Control)과 Locking(잠금) 방식을 비교해 보자.       1️⃣ 트랜잭션(Transaction)이란? 트랜잭션은 데이터베이스에서 하나의 논리적 작업 단위를 의미한다.트랜잭션 내의 모든 작업이 성공적으로 완료되거나, 하나라도 실패하면 전체가 롤백(Rollback)되어야 한..

Database 2025.06.26

Fluent Bit → OpenSearch 중복 로그 이슈

OverviewEKS 환경에서 Fluent Bit을 통해 OpenSearch로 로그를 전달할 때, 같은 로그가 중복으로 저장되는 문제를 경험한 적이 있는가? 우리도 비슷한 문제를 겪었다. 로그 내용과 타임스탬프가 완전히 동일한데도 OpenSearch에는 두 번씩 저장되어 지표나 검색 결과가 과도하게 부풀려지는 현상이 반복되었다. 조사 결과, 각 로그가 서로 다른 `_id` 값을 가지고 있어 OpenSearch가 이를 서로 다른 문서로 인식하고 있었던 것이 원인이었다. 이 글에서는 Fluent Bit의 설정만으로 이 문제를 해결한 실제 사례를 공유한다. 특히 `_id` 충돌이 아닌, 내용은 동일하지만 `_id` 가 달라 중복 저장되는 현상에 대해 설명하고, 이를 Generate_ID 설정으로 해결한 과정을..

Trouble Shooting 2025.06.23

MLOps 라이브러리: NumPy, Pandas, Scikit-Learn

Overview“데이터는 코드만큼 중요하다.”엔지니어로서 MLOps를 도입하고 싶다면, 데이터 흐름과 모델 학습 자동화에 사용되는 핵심 라이브러리부터 정확히 이해해야 한다. 이 글에서는 MLOps 워크플로우에서 NumPy, Pandas, Scikit-Learn이 어떤 역할을 수행하고, 어디에서 쓰이며, 실제로 어떻게 사용하는지를 실전 예제와 함께 설명한다. MLOps 흐름 안에서 이 세 가지 라이브러리가 쓰이는 위치는?[데이터 수집] → [전처리/클렌징] → [학습/추론] → [평가/로깅] → [저장/배포] ↑ ↑ ↑ ↑ ↑ (Pandas) (NumPy) (S..

AI/MLOps 2025.06.19

Helmfile 완전 정복: 실무에서 Helm을 선언적으로 관리하는 방법

Overview Kubernetes 환경에서 애플리케이션을 배포할 때, Helm은 가장 널리 쓰이는 패키지 매니저이다.하지만 여러 개의 Helm 차트를 동시에 다루거나, 환경별 변수 처리를 체계적으로 하고 싶을 때는 Helm 자체만으로는 부족함을 느끼게 된다. 이럴 때 필요한 것이 Helmfile이다.Helmfile은 Helm 기반 배포를 코드처럼 선언적으로 정의하고, 여러 차트를 일괄 관리할 수 있게 해주는 도구 Helmfile을 활용하면 다음과 같은 상황을 간결하게 처리할 수 있다.여러 Helm 차트를 한 번에 배포dev/staging/prod 환경 분리 및 values 재사용GitOps/CD 도구와 통합차트 버전, 이미지 태그, 레지스트리 관리의 일관성 확보 Helmfile 설치br..

ACID와 CAP 이론 비교

Overview오늘은 트랜잭션의 ACID 원칙과 CAP 정리에 대해 알아보고,이 두 개념이 어떻게 데이터베이스와 NoSQL에 적용되는지 비교해보려고 한다.ACID 원칙은 데이터 일관성 유지를 위한 트랜잭션 설계의 핵심 개념CAP 정리는 분산 시스템에서 데이터의 가용성과 일관성의 균형을 다루는 이론  이 두 가지를 이해하면 RDBMS(관계형 DB)와 NoSQL DB 선택 기준을 명확하게 파악할 수 있다.            1️⃣ ACID 원칙이란?ACID는 데이터베이스 트랜잭션의 4가지 핵심 속성을 의미한다. ACID 원칙설명 예제A (Atomicity) - 원자성트랜잭션은 모두 실행되거나, 전혀 실행되지 않아야 함은행 송금 시, A 계좌에서 돈이 빠져나갔지만 B 계좌로 입금되지 않으면 안됨C (Cons..

Database 2025.06.12

대형 Git 리포지터리에서 CI/CD 시간을 절반으로 줄이는 법: Git Sparse Checkout 실전 적용기

Overview대규모 Git 리포지터리를 다루는 개발자라면 누구나 겪는 공통적인 문제 중 하나는 느린 git clone 속도와 불필요한 데이터 다운로드이다.특히 GitLab CI/CD 환경에서는 매번 새로운 환경에서 작업이 시작되기 때문에, 전체 프로젝트를 모두 clone하는 과정 자체가 병목이 되곤 한다. 이 글에서는 Git의 `sparse-checkout` 과 `--filter=blob:limit` 기능을 활용해,필요한 폴더만 빠르게 clone하고 불필요한 파일 다운로드를 최소화하는 방법을 소개한다.GitLab CI/CD 환경에서 직접 적용한 실전 YAML 예시도 함께 제공하니, 대용량 프로젝트를 운영 중인 팀이라면 반드시 참고해볼 만한 내용이다. 1. 문제 상황CI/CD 파이프라인을 구..

IaC/CI CD Tool 2025.06.09

정규화(Normalization)와 반정규화(Denormalization)란?

Overview오늘은 데이터베이스 정규화(Normalization)와 반정규화(Denormalization)의 개념과 적용 사례에 대해 알아보려고 한다.데이터베이스 설계에서 정규화는 데이터의 일관성을 유지하고 중복을 최소화하는 과정이며, 반정규화는 성능을 최적화하기 위해 데이터를 일부 중복 저장하는 과정이다.이 두 개념을 적절히 활용하면 효율적이고 확장 가능한 데이터베이스 설계를 할 수 있다. 정규화(Normalization)란?정규화(Normalization) 는 데이터 중복을 줄이고, 무결성을 유지하며, 데이터 일관성을 보장하는 과정이다.이를 위해 데이터를 정규형(Normal Form, NF) 이라는 특정한 형식으로 변환하여 저장한다. 정규화의 목적데이터 중복(Minimizing..

Database 2025.06.05

Helm values.schema.json 완벽 정리

Overview오늘은 Helm Chart 개발에서 유용한 기능인 `values.schema.json` 에 대해 알아보겠다. Helm은 기본적으로 `values.yaml` 파일을 통해 사용자 정의 값을 설정하게 되는데, 이 값의 유효성 검사를 자동화하고 싶을 때 `values.schema.json` 을 사용할 수 있다. Helm `values.schema.json` 은 Helm Chart에서 제공하는 값(`values.yaml`)의 스키마를 정의하는 표준 JSON Schema 파일이다. 이 스키마를 통해, 사용자가 제공하는 값이 올바른 형식과 타입을 가지고 있는지 사전에 검증할 수 있다.​     📅 관련 글Helm에 대한 내용들은 이전 포스팅을 참고하길 바란다.2022.09.06 - [Container..

배포하다 서비스 터진 적 있다면? 꼭 알아야 할 Kubernetes 전략 가이드

OverviewKubernetes Deployment Strategy는 새로운 버전의 애플리케이션을 서비스 중단 없이 안정적으로 배포하기 위한 핵심 메커니즘이다. 기본적으로 Kubernetes는 RollingUpdate 전략을 사용하여 점진적으로 Pod를 교체하지만, 사용자의 요구사항에 따라 다양한 방식의 전략을 선택하거나 커스터마이징할 수 있다. 대표적인 전략은 다음과 같다.RollingUpdate: 기존 Pod를 하나씩 교체하며 가용성을 유지 (기본값)Recreate: 모든 기존 Pod를 제거한 후 새 버전을 일괄 생성 (다운타임 발생)Blue/Green: 별도 환경을 구성하여 스위칭 기반 배포 (빠른 롤백 가능)Canary: 일부 사용자 대상으로 점진적 배포 후 트래픽 확장 (실사용 기반 검증)..

반응형