prometheus 6

Helm Chart로 Spring Boot 프로덕션 배포하기, 선언적 배포

쿠버네티스에 Spring Boot 애플리케이션을 처음 올릴 때 막막한 것 중 하나가 "설정을 어디에, 어떻게 써야 하는가"다.이번 글에서는 Helm Chart를 기준으로 Spring Boot를 프로덕션에 배포할 때 필요한 설정 항목들을 하나씩 살펴본다. values.yaml 파일을 중심으로 각 설정이 왜 필요한지, 어떤 영향을 주는지를 함께 설명한다. 1. 초기 Replica 개수 설정서비스를 기동할 때 몇 개의 Pod를 띄울지 지정한다.replicaCount: 22로 설정하면 동일한 애플리케이션 Pod가 2개 생성된다. 단일 Pod로 운영하면 해당 노드에 장애가 발생했을 때 서비스가 완전히 중단되므로, 프로덕션 환경에서는 최소 2개 이상을 권장한다.다만 replicaCount는 HPA(8번 섹션)가 활..

카테고리 없음 2026.02.11

[클라우드 네이티브] 5편: Loki 메트릭부터 로그까지 통합 관측하기

1~2 편에서는 ELK 스택을 통한 로깅 아키텍처를, 3~4편에서는 Prometheus를 이용한 메트릭 고가용성을 다뤄보았다.운영을 하다가 초당 수만 줄의 로그를 처리하기 위해 Elasticsearch 클러스터를 계속 키우는 것은 비용과 운영 측면에서 큰 부담이 될 수 있다. 그래서 이번 5편에서는 저비용 고효율의 로깅 스택인 Loki를 구축해 본다. 1. Loki는 ELK와 어떤 부분이 다른지ELK의 경우 매우 강력한 도구지만, 반대로 너무 무거운 도구이긴 하다. 모든 것을 인덱싱할 것인가?ELK와 Loki의 가장 큰 차이는 "무엇을 인덱싱 하는가?"에 있다.ELK: 로그의 모든 단어를 인덱싱 한다. 검색은 빠르지만, 로그 양이 늘어나면 인덱스 크기가 비대해져 SSD 비용이 기하급수적으로 상승한다.Lo..

DevOps 2026.02.09

[클라우드 네이티브] 4편: Prometheus 메트릭 모니터링 아키텍처 구현(실전)

[클라우드 네이티브] 3편: 고가용성 모니터링(메트릭) 아키텍처 설계 전략지난 1, 2편에서는 로그 수집의 핵심인 ELK 스택을 고가용성 환경으로 구축하는 방법을 살펴보았다.로그가 서비스에서 발생하는 "기록"을 추적한다면, 이번에 다룰 메트릭(Metric)은 시스템의 "상태youseong.tistory.com지난 3편에서는 Prometheus + Thanos + Grafana 구조를 설계 수준에서 살펴봤다. 이번 글에서는 그 설계를 실제로 Helm Chart를 이용해 구현하고, 아래 두 가지를 직접 확인한다. Helm Chart 저장소 (monitoring-stack 만 사용) GitHub - youseonghyeon/k8s-blogContribute to youseonghyeon/k8s-blog dev..

DevOps 2026.02.08

[클라우드 네이티브] 3편: 고가용성 모니터링(메트릭) 아키텍처 설계 전략

지난 1, 2편에서는 로그 수집의 핵심인 ELK 스택을 고가용성 환경으로 구축하는 방법을 살펴보았다.로그가 서비스에서 발생하는 "기록"을 추적한다면, 이번에 다룰 메트릭(Metric)은 시스템의 "상태"를 숫자로 파악하는 작업이다. 메트릭 모니터링은 로그 수집과 설계 철학부터 다르다.이번 글에서는 모니터링으로 많이 사용되는 Prometheus와 Thanos, Grafana를 활용한 고가용성 모니터링 구조를 설계해본다. 1. 모니터링 아키텍처: Prometheus + Thanos + Grafana이번 설계의 핵심은 "수집은 중복으로, 조회는 통합으로"이다. 이를 위해 다음과 같이 레플리카를 구성한다.Service Monitor: 일종의 명세서로, 어디서 메트릭을 가져가야 하는지 적어놓는다.Prometheu..

DevOps 2026.02.07

서버의 생존 전략: Circuit Breaker로 장애 전파 방지하기

서버 운영 중에는 서버가 요청을 처리할 수 있는 여력이 있음에도, 의도적으로 요청을 차단해야 하는 순간이 있다.이는 특정 서비스의 문제가 전체 시스템으로 번지는 '장애 전파'를 막가 위한 필수적인 선택이다. 1. 왜 요청을 차단해야 할까? (장애 전파의 위험성)다음과 같은 서비스 구조를 가정해보자.A 서비스: 사용자 요청을 직접 받는 게이트웨이 역할 (리소스 풍부)B 서비스: 비즈니스 로직 처리 및 DB와 연결된 서비스DB: 현재 리소스 과부하 상태정상적인 요청 흐름: 사용자 -> A 서비스 -> B 서비스 -> DB 장애 발생 시나리오:DB 부하 발생: DB응답이 느려진다.B 서비스 병목: B 서비스는 DB응답을 기다리다 설정된 타임아웃(Timeout)에 걸리거나, 커넥션 풀이 고갈된다.A 서비스 장애..

Spring 2026.01.20

Grafana로 실시간 서비스 모니터링: Actuator와 Prometheus Quick Starter

많이 서비스들을 사용하고 있는 Grafana를 이용해서 서비스 모니터링을 하는 방법을 소개하겠습니다. 서비스 모니터링을 하기 위해서 아래의 것들이 필요합니다. 1. 모니터링용 데이터를 생성하는 라이브러리 : Actuator 2. 모니터링용 데이터를 저장하는 Database : Prometheus 3. 모니터링을 위한 대시보드 : Grafana 워낙 내용이 많아서 간단하게 사용하는 방법만 보고 넘어가겠습니다.  모니터링용 데이터를 생성하는 라이브러리과거에는 모니터링을 위한 데이터를 각각 만들어서 모니터링 툴의 규격에 맞춰 넣어주었지만 요즘에는 다양한모니터링 툴들이 나와서 그것들을 다 사용할 수 있는 Micrometer 를 써보겠습니다. Micrometer 는 규격화된 인터페이스이고 Prometheus, G..

DevOps 2024.08.15