유성

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

[클라우드 네이티브] 1편: 온프레미스에서 클라우드 네이티브로: 로깅 아키텍처(ELK) 설계과거 온프레미스 환경에서 고가용성을 갖춘 ELK 스택을 구축하고 유지하는 것은 꽤나 어려운 작업이였다.단순히 서버를 띄우는 것을 넘어, 인프라와 애플리케이션 사이의 수많은 '수동 연결 고youseong.tistory.com 이전 글에서는 온프레미스 환경을 클라우드 네이티브로 전환하는 이론적 배경을 살펴보았다면, 이번 실전 편에서는 Argo CD와 Helm을 통해 실제 ELK 스택을 구축하는 과정을 공유한다. 모든 인프라는 코드로 관리되며, 복잡한 설치 과정은 Helm 차트로 추상화했다. 먼저, 실습에 사용할 인프라 구축 코드를 로컬 환경으로 가져오자.# 실습 코드 클론 및 특정 커밋으로 체크아웃git clone h..

과거 온프레미스 환경에서 고가용성을 갖춘 ELK 스택을 구축하고 유지하는 것은 꽤나 큰 복잡성을 지니고 있었다.단순히 서버를 띄우는 것을 넘어, 인프라와 애플리케이션 사이의 수많은 '수동 연결 고리'를 관리해야 했기 때문이다. 이 글에서는 과거의 ELK 구성 방식과 클라우드 네이티브 환경의 ELK 구성을 비교해 본다. 1. 과거 온프레미스 환경: 운영의 발목을 잡았던 로깅의 복잡성과거 온프레미스 환경에서는 고가용성 ELK를 구성할 때 꽤 큰 복잡성을 가지고 있었다.이러한 구성에서 애플리케이션을 확장한다고 가정해 보자.애플리케이션을 확장한다는 것은 새로운 물리 서버나, VM을 할당받는 것을 의미한다.이때마다 다음과 같은 작업이 반복되었다.Filebeat 수동 배포: 새 서버가 뜰 때마다 Filebeat 설..

1. '명령'하는 배포에서 '선언'하는 배포로이전 글에서는 가장 직관적이지만, 한계 또한 명확한 '명령(Push) 방식'의 배포를 다루었다. 정답 없는 CI/CD, 우리 환경에 맞는 최적의 파이프라인 설계이 글에서는 단순한 코드 전송을 넘어, 복잡한 환경에서 어떻게 안정적이고 효율적인 CI/CD 파이프라인을 구축했는지 그 설계 과정을 공유한다. 1. CI/CD란 무엇인가?: 규모에 따른 변칙적 대응CI/CDyouseong.tistory.com 초기 단계에서는 GitHub Actions의 Runner가 클러스터에 직접 접속해 kubectl 명령을 날리는 방식이 빠르고 효율적이다.하지만 프로젝트가 커지고 인프라가 복잡해질수록 다음과 같은 치면적인 문제들에 직면하게 된다. 기존 yaml 배포 방식의 페인 포..