2025-capstone

작성: AI / 수정: nkey

라즈베리파이 k3s 클러스터(마스터/워커) + 모니터링/알람 + 자동 조치(승인/검증 포함) 데모를 위한 조직 레포입니다.
(Tailscale VPN 환경에서 k3s, Oracle 서버(n8n/WMS/DB), GPU 서버(Ollama/llama3)를 연동)

목차

• What’s Inside
• Docs
• Architecture
  • High-level (요약)
  • Whole-Flow
  • End-to-end Flow (상세)
  • n8n Flow
• Repositories
• Quickstart (Demo: DiskAlmostFull 알람 → 자동 조치 → 검증)
  • 1) (Master) 디스크 채우기 데모 배포
  • 2) (Master -> Service Worker) Pod exec로 디스크 채우기 / 정리 실행
  • 3) (UI) 웹 페이지에서 확인
  • 4) (Logs) 자동 조치 모듈 로그 확인
• Report / Evaluation
  • Baseline 설정
  • 실험 설계
  • 실험 결과

What’s Inside

• k3s 클러스터
  • master node: 클러스터 관리 + 매니페스트 적용(데모/모니터링 K8s 리소스)
  • worker service node: 서비스 실행 노드(디스크 채우기 데모 Pod exec)
  • worker monitor node: 모니터링 스택(Prometheus/Alertmanager/Loki/Grafana + auto action module)
• Oracle Server
  • Web Monitoring Service(WMS)
  • n8n hosting
  • PostgreSQL
• GPU Server
  • Ollama + llama3 (솔루션 생성/검증)

Docs

• 각 레포지토리별 자세한 실행/구성은 해당 레포의 README를 참고하세요.
  • rpi-master-node/README.md
  • rpi-worker-monitor-node/README.md
  • rpi-worker-service-node/README.md
  • oracle-server/README.md

Architecture

High-level (요약)

Whole-Flow

End-to-end Flow (상세)

n8n Flow

Repositories

• rpi-master-node
  • k3s 매니페스트(예: k3s-manifests/disk-fill-demo.yaml, k3s-manifests/aam-deploy.yaml)
  • K8s 기반 모니터링 스택 매니페스트(k3s-monitoring/*)
  • kube-state-metrics 매니페스트(kube-state-metrics/*)
• rpi-worker-monitor-node
  • monitoring/docker-compose.yml 기반 Prometheus/Alertmanager/Loki/Grafana 구동(워커 모니터 노드)
• rpi-worker-service-node
  • 서비스 워커 노드(레포가 비어있을 수 있음)
  • 중요: 디스크 채우기 데모는 master 노드 레포의 disk-fill-demo.yaml을 배포한 뒤, service 노드에서 Pod에 exec하여 스크립트를 실행합니다.
• oracle-server
  • n8n으로 자동화 워크플로우 구현
  • PHP 기반 Laravel 프레임워크를 활용하여 개발한 웹 모니터링 서비스(WMS)

Quickstart (Demo: DiskAlmostFull 알람 → 자동 조치 → 검증)

1) (Master) 디스크 채우기 데모 배포

# master 노드에서
git clone https://nkeystudy.site/gitea/2025-capstone/rpi-master-node.git
cd rpi-master-node

kubectl apply -f k3s-manifests/disk-fill-demo.yaml
kubectl get pod -n alert-service -l app=disk-fill-demo
kubectl get svc -n alert-service

2) (Master -> Service Worker) Pod exec로 디스크 채우기 / 정리 실행

아래 명령은 Master 노드에서 실행되는 시나리오를 기준으로 합니다.

# Pod 이름 확인
POD=$(sudo kubectl get pod -n alert-service -l app=disk-fill-demo -o jsonpath='{.items[0].metadata.name}')

# 절대경로로 실행
sudo kubectl exec -n alert-service "$POD" -- /usr/local/bin/fill_disk_safe.sh /tmp/disk-fill-demo 90 1024

# 상대경로로 실행
sudo kubectl exec -n alert-service "$POD" -- fill_disk_safe.sh /tmp/disk-fill-demo 90 1024

# 수동 해결(cleanup 셸 스크립트 실행)
sudo kubectl exec -n alert-service "$POD" -- cleanup_disk.sh /tmp/disk-fill-demo

3) (UI) 웹 페이지에서 확인

• disk full alert prometheus로 확인(2_check_disk_full_demo_result_in_prometheus)

• 해결책 생성 과정 워크플로우 동작 확인(3_check_make_solution_n8n_workflow)

• 해결책 거절 및 새로운 해결책 확인(4_reject_solution_and_check_other_solution)

• 해결책 검증(5_verify_solution)

• 해결책 적용 및 결과 확인(6_apply_solution_and_check_result)

4) (Logs) 자동 조치 모듈 로그 확인

• SSH로 대상 호스트에 접속해 precheck/action 수행, 결과를 Alert API로 전달하는 흐름 확인

  • check_apply_solution_in_monitor_node(해결책 적용 수행 노드):

  • check_apply_solution_in_service_node(해결책 적용 대상 노드):

Report / Evaluation

Baseline 설정

본 프로젝트의 성능을 평가하기 위해 AI 어시스턴트를 사용하지 않는 수동/부분 자동화 운영 방식을 baseline으로 정의한다. 두 환경 모두 Prometheus/Alertmanager의 동일한 임계치 기반(alert_rule) 설정을 사용하며, 차이는 알람 이후 대응 방식에 있다.

- Prometheus/Alertmanager에서 DiskAlmostFull 임계치 기반 알람 설정
- 알람 발생 시 운영자가 Slack/이메일/웹 콘솔로 알림 수신
- 운영자가 Grafana/로그를 직접 확인하여 원인 분석
- SSH 접속 후 수동으로 명령어 실행 및 조치 수행
- 조치 결과를 엑셀/노션/위키 등에 수동 기록

제안 시스템은 동일한 알람을 n8n·WMS·AI 어시스턴트로 전달하여 remediation plan을 자동 생성하고, 운영자의 승인 후 자동 실행하는 점에서 baseline과 구분된다.

실험 설계

평가는 DiskAlmostFull 장애를 대상으로 baseline과 제안 시스템을 동일 조건에서 아래의 내용에 따라 반복 실험하여 비교한다.

구분	내용
실험환경	- Prometheus + Alertmanager + Grafana + AAM - 테스트용 서버(라즈베리파이) + n8n·WMS·AI 어시스턴트로 구성
시나리오	- 공통: 디스크 사용량을 임계치 이상까지 증가시켜 DiskAlmostFull 알람 유발 - Baseline: 운영자가 직접 분석·SSH 조치 - 제안 시스템: AI가 생성한 plan을 WMS에서 승인 후 자동 실행
평가지표	- 장애 감지 정확도: 의도적으로 유발한 장애 중 알람이 정상 발생한 비율 - 대응 지연 시간: 알람 발생 시각 ~ 첫 조치 실행 시각까지 시간 - 자동화 성공률: 자동 실행되는 모든 워크플로우가 완전히 실행된 비율 - 해결 성공률(해결책 정확도): 단일 조치로 장애가 완전히 해소된 비율

실험 결과

아래는 4가지 지표에 대한 실험결과이다. baseline과 제안 시스템 환경에서 각 10번씩 실험을 진행하였다.

평가 지표	Baseline	제안 시스템	목표치
장애 감지 정확도	100%	100%	≥ 90%
평균 대응 지연 시간	9.2분	5.3분	≤ 5min (43% 감소)
자동화 성공률	0% (자동화 미사용)	100%	≥ 80%
해결 성공률 (1차 조치로 완전 해결된 비율)	60% (수동 1차 조치)	80% (AI plan 1회)	≥ 80%

이를 통해 제안 시스템이 baseline에 비해 대응 시간 단축, 자동화 수준 향상, 해결 성공률 개선에 기여함을 확인할 수 있다.