유성

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

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

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

이 글에서는 단순한 코드 전송을 넘어, 복잡한 환경에서 어떻게 안정적이고 효율적인 CI/CD 파이프라인을 구축했는지 그 설계 과정을 공유한다. 1. CI/CD란 무엇인가?: 규모에 따른 변칙적 대응CI/CD는 배포 파이프라인으로, 프로젝트의 규모와 팀의 운영 성격에 따라 매우 유연한 구조를 가진다.필자는 이를 크게 두 가지 배포전략으로 구분한다.작고 빠른 배포: main 브랜치에 코드가 병합되는 즉시 빌드부터 실서버 배포까지 자동화되는 방식이다. 빠른 피드백이 중요한 초기 프로젝트에 적합하다.큰고 신중한 배포: 병합 시 빌드와 검증은 자동으로 수행되며, 실제 배포는 관리자의 수동 트리거를 통해 결정하는 방식이다. 안정성이 최우선인 대규모 시스템에서 주로 채택한다. 이 두 방식 모두 자동화된 파이프라인을 ..

쿠버네티스에서 데이터베이스를 운영할 때 가장 큰 고민은 "데이터의 영속성과 성능"일 것이다.이번 글에서는 로컬 디스크를 활용해 성능을 최적화하고, StatefulSet을 이용해 마스터-슬레이브 복제 구조를 자동화하는 방법을 알아보자.1. 데이터베이스 disk 전략: 왜 Local PV인가?데이터베이스는 I/O 성능이 매우 중요하다. NFS나 클라우드 기반 네트워크 스토리지(EBS 등)는 관리가 편하지만, 네트워크 지연이 발생할 수밖에 없다. DBMS가 실행되는 노드의 로컬 디스크를 직접 사용하면 네트워크 오버헤드 없이 최고의 속도를 낼 수 있고, 별도의 스토리지 비용을 아낄 수 있다.이를 위해 우리는 Local Persistent Volume을 사용한다. 2. Storage Class 설정: 지능적인 바..

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