[Project] On-Prem Multi-Node Observability System & Analyzer AI Agent - 1️⃣ 프로젝트 개요 및 기술 스택 선정
이번 상반기에 수료한 부트캠프(현대오토에버 모빌리티 SW스쿨 - 클라우드) 에서 진행한 최종 프로젝트의 구축 과정을 적어보고자 합니다.
(정신이 매우 없었기에 최종 결과물을 만든 후에 구축 과정기를 적게 되네요..ㅜ)
개요
- 프로젝트 기간: 2026년 4월 13일 ~ 6월 29일
- 프로젝트 주제: 오픈스택을 활용한 클라우드 제공 플랫폼 구축
- 팀 구성: 5인
- 맡은 역할: 팀장, Observability, Analyzer AI Agent
부트캠프의 꽃(?) 최종 프로젝트를 무사히 마쳤습니다. 프로젝트 기간이 짧으면서 길었던 것 같습니다. 기깔나는 인프라 프로젝트를 해보고 싶은 욕심에 정말 많은 노력을 들였던 프로젝트였던 것 같습니다..하하
주제 선정부터 정말 많은 공을 들였습니다. 동아리 활동과 오픈소스 활동을 하며 인연을 맺은 10명의 현직자분들에게 실제 현업에서 겪는 문제점이나, 중요하게 생각하는 부분을 많이 여쭤보았습니다. (백엔드, 시스템 엔지니어, 데브옵스, SRE 등 다양한 직군의 현직자분들에게 각 분야의 이야기를 들어보고 공통점을 찾고자 했습니다!)
각 분야에서 중요하게 다루는 부분과 실제로 겪으신 문제점(장애)들을 공유 받았고, 서로 다른 분야임에도 공통적인 요소로 "HA, DR" 을 언급해주셨습니다.
🤔 HA, DR이 뭔가요..?
HA(High Available), DR(Disaster Recovery) 의 약자로 각각 고가용성, 재해 복구를 의미합니다.
(인프라 분야를 공부하면서 종종 봤던 용어들인데, 이번 기회에 각각의 용어가 무엇을 의미하는지 자세히 알아보았습니다.)
HA(High Available) - 고가용성
- 시스템이 "중단 없이(또는 아주 잠깐의 중단만으로) 계속 서비스를 제공할 수 있는 상태"
- 핵심 원리: 이중화(Redundancy)와 자동 이관(Failover)
DR(Disaster Recovery) - 재해 복구
- 지진, 화재, 대규모 정전, 전쟁, 또는 데이터 센터 전체가 마비되는 "거대한 재해 상황에서 시스템과 데이터를 다시 살려내는 것"
- 핵심 원리: 원격지 백업과 복구 시나리오
간단하게 SW / HW 장애가 발생했을 때 시스템이 중단되지 않고 계속 서비스를 제공할 수 있는 능력이라고 이해를 했습니다.
이를 잘 보여주기 위해서 온프렘 노드(부트캠프 제공 데스크탑) 이중화, 하이브리드 클라우드, 장애 시나리오 시연, 관측 시스템 등의 도입을 논의하고 주제를 구체화했습니다.
이를 바탕으로 다양한 아이디어가 나왔고, 수차례의 회의와 수차례의 멘토링을 통해 "OpenStack 기반 클라우드 제공 플랫폼 구축" 이라는 주제를 선정하게 되었습니다. 구현 과정과 동작 방식은 다르지만, 이미 홈랩 클러스터로 사용자에게 인스턴스를 제공하는 프로젝트를 진행하고 있었기에 OpenStack 구축보다 Observability 구축에 집중하고자 하였습니다.
🔭 Observability
기술 스택 선정 이유 -> 구축 과정 -> Alert -> 분석 AI Agent 순으로 정리를 해보겠습니다.
기술 스택 선정 이유
- Collector: OpenTelemetry Collector
- Metric Server: VictoriaMetrics
- Log Server: Grafana Loki
- Dashboard: Grafana
⚙️ Collector: Prometheus vs OpenTelemetry Collector
관측 대상(온프렘 노드)의 Metric과 Log를 수집하는 수집기의 스택 선정을 먼저 진행 했습니다.
다른 프로젝트에서 많이 사용했던 Prometheus와 클라우드 네이티브 진영에서 핫한(?) OpenTelemetry Collector를 고민했습니다.
(OpenTelemetry를 한 번쯤은 꼭 사용해보고 싶었지만, 기술 스택 선정 이유의 타당성은 필수이기에 조사를 통해 두 기술 스택을 비교해보았습니다.ㅋㅋㅋ)
(더 많은 이유가 있겠지만) 비교 및 조사를 해보니 왜 요즘 OpenTelemetry가 각광 받는지 알 것 같습니다.
우선 원격 관측 방식으로 옵저버빌리티 시스템을 구축하고자 했기에 원격 관측 - Push Protocol 지원 여부가 중요했습니다. 또 초기 설계 당시 Metric과 Log 두 시그널을 수집하고자 하였는데 OTel Collector의 경우 단 한 개의 Agent 만으로 세 시그널(Metric, Log, Trace)를 수집할 수 있다는 장점이 있었습니다!
결론: OpenTelemetry Collector 선정!
- 이유 1: OTLP(OpenTelemetry Protocol) 규격, 단 한 대의 Agent 만으로 Log/Metric/Trace 모두 수집 가능
- 이유 2: Push Protocol 지원 (OTLP - gRPC/HTTP 지원)
- 이유 3: 써보고 싶었음.ㅋ
(노트북 한 켠에 붙여있는 OpenTelemtry를 드디어 사용해보네요.ㅎㅎ)
⚙️ Metric Server: Prometheus vs VictoriaMetrics
이번에는 Metric Server 입니다. 메트릭 서버 또한 표준처럼 많이들 사용하는 Prometheus 와 VictoriaMetrics 스택을 비교했습니다.
VictoriaMetrics는 홈랩의 옵저버빌리티 스택을 조사하던 중 알게 된 오픈소스 기술입니다. 원격 관측에 유리하고, 리소스 비용이 상대적으로 저렴하다는 특징 정도만 알고 있었는데, 이번 기회에 Prometheus와의 비교를 위해 조사를 해보았습니다.
앞선 Collector 채택 시 "원격 관측"을 목표로 하였기에 Push Protocol 호환과 OTel Collector 와의 호환이 중요했습니다. VictoriaMetrics 설계 철학이 '원격 관측'이라고 하더군요.😳
이와 더불어 OTel Collector와의 호환성 또한 뛰어났고, 가장 중요한 "압축률 & 메모리/디스크 효율"이 높다는 장점이 있었습니다. 원격 관측을 위해 퍼블릭 클라우드(AWS)에 메트릭 서버 등을 띄울 예정이었기에 저장 효율이 좋다는 점이 크게 다가왔습니다.
결론: VictoriaMetrics 선정!
- 이유 1: 다양한 Push Protocol과 호환 (우리는 OTLP 사용)
- 이유 2: OTel Collector 와의 호환성 높음
- 이유 3: 압출률, 메모리/디스크 효율 뛰어남
.
.
.
계속 언급하는 "원격 관측"에 집착하는 이유,,
예전에 백엔드로 참여한 프로젝트에서 내장 관측 형태로 Prometheus-Grafana 를 구축한 적이 있었습니다. 인스턴스 비용이 매우 부족했기 때문에 하나의 EC2에 '백엔드 서버'와 '모니터링 서버'를 같이 띄우는...ㅎ
평상 시에는 문제 없이 관측을 잘 했지만, 인스턴스 자체가 다운되는 장애가 발생했을 때 (당연하게도) 모니터링 서버 또한 다운되어 장애 감지도 못하고, 메트릭도 날아가버린 아찔한 경험이 있었습니다.
이때 이후로 "내장 관측"을 다시는 하지 않는 사람이 되었답니다..😂
⚙️ Log Server: ElasticSearch vs Grafana Loki
마지막으로 Log Server 입니다. Elasticsearch를 현업에서 많이 사용한다고 하던데,, 비용 감당이 안 될 것 같으니 취업하고 써보는 걸로 하겠습니다..
(그래도 스택 선정을 위한 비교 및 조사는 해보겠습니다)
아무래도 Full-Text indexing을 하는 ElasticSearch의 검색력이 뛰어남을 보여주는 것 같습니다. 하지만 현재 구축한 플랫폼의 규모와 목적을 보았을 때 굳이 큰 비용을 들이면서까지 로그 검색 품질을 높일 필요는 없다고 판단했습니다.
또 로그 서버 또한 원격 관측에 맞추어 퍼블릭 클라우드(AWS)에 띄울 예정이었기에 리소스 자체의 비용이 저렴한(가벼운) Grafana Loki 가 적절하다고 생각했습니다.
(결정적으로 우리가 쓸 Log Server의 기능은 Loki에서는 모두 무료였습니다.)
OpenSearch
ElasticSearch는 비용 및 프로젝트 기간 등을 고려하여 선택하지 않았습니다만, 이를 대체할 수 있는 OpenSearch 라는 프로젝트가 있었습니다.
(작년 OSS Korea 2025 행사장에서 봤던 기억이 있네요!)
https://opensearch.org/"엘라스틱서치(Elasticsearch) 7.10.2 버전을 기반으로 포크(Fork)하여 개발된 커뮤니티 주도의 100% 오픈소스 검색 및 분석 엔진" 이라고 합니다.
프로젝트 기간 및 쌓여있는 Epic/Task 등을 고려하여 이번에는 사용하지 않았는데, 추후 기회가 된다면 OpenSearch를 사용해보면 좋을 것 같습니다.
양이 너무 많을 것 같아서 이번 포스트에서는 "프로젝트 개요 / 기술 스택 선정"까지만 정리르르 해보겠습니다. 다음 포스트에서는 Observability 구축 과정에 대해서 다뤄보겠습니다. 감사합니다.
