프로젝트 배경
이 프로젝트는 k-paas 서비스 개발 공모전에 출품하기 위해 만들었다. 공모전 자체는 k-paas로 분류된 클라우드 서비스를 이용하기만 하면 된다. 여기서 아이디어를 얻어, 여러 클라우드 제공 업체들을 사용 할때 한 번에 모니터링 할 수 있는 서비스가 있으면 좋겠다고 생각하여 이 방향으로 진행하게 됐다.
프론트/백엔드는 AI를 최대한 활용하였다.
목적
여러 클라우드 플랫폼의 Kubernetes 클러스터를 단일 대시보드에서 실시간 모니터링할 수 있는 통합 SaaS 서비스 개발
문제 인식
- Prometheus/Grafana 같은 오픈소스는 설치와 설정이 까다로움
- 각 클라우드 벤더별로 제공하는 모니터링 도구(AWS CloudWatch, GCP Monitoring 등)는 기능이 풍부하지만 비개발자가 사용하기 복잡함
- 멀티클라우드 환경에서 여러 콘솔을 오가며 모니터링해야 하는 불편함
시스템 아키텍처
인프라는 네이버 클라우드를 활용했고, 가장 일반적인 패턴의 아키텍처 구조로 설계하였다. 최대한 Terraform 을 활용하려 했으나, 네이버 클라우드와는 아직 호환되지 않는 부분이 있어서 콘솔을 사용해 직접 설정하였다.
데이터 흐름
사용자는 아주 기본적인 내용만을 담고 있는 회원가입을 통해 식별한다. 이후, 모니터링하고자 하는 K8s 클러스터의 Service Account가 발급하는 토큰을 통해 Kubernetes API에 접근할 수 있다. 백엔드는 이 토큰을 암호화하여 DB에 저장하고, Cron Job을 통해 주기적으로 각 클러스터의 메트릭을 수집한다.
수집된 메트릭은 PostgreSQL에 시계열 데이터로 저장되며, 프론트엔드에서 API를 호출하면 최신 데이터와 함께 과거 데이터를 조회하여 트렌드를 계산한다. 이를 파싱하여 대시보드에 그래프로 보여주는 흐름으로 작성하였다.
기술 스택
Frontend
- Next.js 15
- React 19
- TypeScript
- shadcn/ui
- Recharts
- Tailwind CSS
Backend
- NestJS
- TypeScript
- @kubernetes/client-node
- TypeORM
- JWT + bcrypt
- Node-cron
Database
- PostgreSQL (Ncloud Managed Service)
Infrastructure
- Ncloud NKS (Kubernetes)
- Docker
- Ncloud Object Storage
- Ncloud Container Registry (NCR)
- Ncloud Load Balancer
- Ncloud Certificate Manger
- AWS Route 53
DevOps
- GitHub Actions
- Terraform
핵심 기능
1. 실시간 메트릭 모니터링
- CPU 사용률: 전체 클러스터의 CPU 사용률 (%)
- Memory 사용률: 메모리 사용률 (%)
- Storage 사용률: 각 노드의 디스크 사용률
- Pod/Node 개수: 실행 중인 리소스 현황
- API 요청률: Kubernetes API 서버 부하
- Error Rate: Pod 에러 발생률
2. 트렌드 분석
- 5분 전 대비 증감률 자동 계산
- ↑ 증가 / ↓ 감소 표시
- healthy/warning/critical 상태 자동 분류
3. 시계열 차트
- 1시간 ~ 7일 범위 선택 가능
- Recharts 기반 라인 그래프
- 30초 자동 갱신
4. 멀티클러스터 지원
- All Clusters: 모든 클러스터 평균 메트릭
- 개별 선택: 클러스터별 개별 모니터링
- 무제한 클러스터 등록 가능
후기
이번 프로젝트에서는 백엔드 – 프론트 – CI/CD – 배포 까지 모든 과정을 경험해 볼 수 있었다. 프로젝트의 아이디어나 완성도 면에서 분명히 아쉬움이 많이 남기는 하지만, 실제로 배포까지 해볼 수 있었다는 점에서 상당히 의미있었다고 생각한다.
특히, 실제로 사용자의 k8s api 토큰을 입력받고 관리해야 한다고 생각을 하니, 저절로 보안쪽에 상당히 신경을 쓰게 될 수 밖에 없었다. https나 jwt , 패스워드 해시 등 연결고정과 보관 과정에서의 보안에 지속적으로 신경써야 한다고 느꼈으며, 인프라 엔지니어를 목표로 한다면 보안쪽도 당연히 학습을 더 해야 할것 같다.
프로젝트를 진행하면서 뼈저리게 느꼈던건 개발환경/배포 환경의 분리였다. 환경설정 뿐만 아니라 개발환경에서는 간략화해서 넘어갔던 부분들이 배포환경에서 문제가 됐던 부분도 많았다. 특히 이 프로젝트는 관리형 클라우드 서비스들을 적극적으로 활용했는데, 아래에서도 언급하겠지만 비용이 매우 비싸 이 환경들을 전부 세팅해놓고 개발환경을 테스트 한다는 것이 불가능하다. 다음 프로젝트에서는 본격적으로 개발을 시작하기 전에, 개발환경과 배포환경을 염두에 두고 미리 구조를 작성하는 것이 좋을 것 같다.
마지막으로, 클라우드 서비스의 이용 요금에 대해서 실제로 경험을 해보게 되었다. 관리형 서비스들이 요금이 비싼 것은 당연하지만, 실제로 사용해보니 간단한 구조임에도 불구하고 요금이 상당했다. 각각 관리형 서비스에서 최저요금을 사용했음에도 불구하고 일 2~3만원대의 요금이 발생하는 것을 확인했다. 역시 인프라 엔지니어라면, 클라우드 서비스의 요금을 최소화 하는것도 신경을 쓰게 될 수 밖에 없을 것이다.
답글 남기기