| 역할 | 이름 | 책임 |
|---|---|---|
| PM | 조하영 | - 프로젝트 진행 상황 모니터링 및 관리 - 각 역할 간 커뮤니케이션 조율 - 프로젝트 일정 및 리소스 관리 - 팀 내외부와의 의사소통 및 문제 해결 |
| 애자일 코치 (AC) | 이상훈 | - 팀원들의 애로 사항 논의 및 해결 지원 - 애자일 프로세스 적용 및 지속적인 개선 지원 - 스프린트 계획 및 회고 관리 |
| 기술 리더 (TL) | 이상우 | - 기술적 문제 해결 및 방향 설정 - 시스템 아키텍처 설계 및 리뷰 - 기술적 결정을 내리고 팀원들에게 가이드 제공 - 코드 품질 관리 및 코드 리뷰 |
| 형상 및 배포 책임자 (AA) | 김도현 | - Docker, Kubernetes 등 배포 환경 설정 및 관리 - 형상 관리 및 배포 관련 문제 해결 - 서비스 안정성 및 성능 모니터링 |
| 예능 부장 | 김동욱 | - 팀 분위기 조성 및 팀원들의 고충 나누기 - 팀의 동기 부여 및 유대감 강화 - 팀 내 소통 및 협업을 위한 환경 조성 |
프로젝트 일정 : 2024년 11월 11일 ~ 2024년 11월 13일(총 3일)
이 프로젝트는 Kubernetes와 Docker를 활용하여 웹 서버의 CPU 사용량을 실시간으로 모니터링하고, 부하 발생 시 서버가 자동으로 스케일링하도록 구성하는 것이 목표입니다. 또한, 예상 부하 증가 시 관리자 페이지를 통해 수동으로 서버를 확장할 수 있는 기능을 제공합니다.
추가 기능
파이널 프로젝트를 대비해 추후 설계될 구조를 시뮬레이션 할 수 있게 구현하였다.
[목적]
Kubernetes에서 Prometheus와 Grafana를 사용하여 Docker 웹 서버의 CPU 사용량을 모니터링하고, 자동 및 수동 스케일링을 통해 부하에 유연하게 대응하는 시스템 구축.
[구성요소]
- Step.1 (요구사항) Docker 웹 서버: CPU 부하를 발생시킬 웹 서버 Docker 컨테이너 Node Exporter: Docker 컨테이너의 CPU 정보를 받아오기 위한 Exporter Prometheus: Kubernetes 클러스터와 애플리케이션의 메트릭 수집 Grafana: Prometheus 메트릭을 기반으로 시각화 및 모니터링 Streamlit 관리자 페이지: 예상 부하 증가 시 수동 스케일링을 지원하는 관리 기능
- Step.2 (최종 프로젝트 환경 구성) AirFlow: 파이널 프로젝트에서 크롤링 한 데이터를 ETL 하기 위한 프레임 워크 Spark: 파이널 프로젝트에서 생길 대용량 데이터를 병렬 처리 하기 위한 프레임 워크 Spark 모니터링: Grafana를 활용한 Spark 모니터링 Spark Auto Scale Out: CPU 제한에 따른 Warker Auto Scale Out
[주요 기능]
웹 서버에 부하를 주어 CPU 사용량 변화 모니터링 Grafana 대시보드를 통해 CPU 사용량을 시각화 이벤트 대비를 위한 수동 스케일 업/다운 기능이 있는 관리자 페이지 제공
| 요구사항 ID | 구분 | 요구사항 설명 | 중요도 | 구현 상태 |
|---|---|---|---|---|
| FR-01 | 모니터링 | 웹의 CPU 사용량 모니터링, Grafana에서 시각화 | 🔴 높음 | ✅ 완료 |
| FR-02 | 자동 스케일링 | CPU 사용량 초과 시 자동으로 스케일 업/다운 | 🔴 높음 | ✅ 완료 |
| FR-03 | 수동 스케일링 | Streamlit 페이지에서 수동 스케일링 | 🟡 중간 | ✅ 완료 |
| FR-04 | 부하 테스트 | Docker Compose로 서버 부하 테스트 | 🟡 중간 | ✅ 완료 |
| FR-05 | 데이터 수집 및 변환 | AirFlow가 정상 실행 가능 | 🟡 중간 | ✅ 완료 |
| FR-06 | 데이터 분산 처리 | Spark 모니터링 및 Manual Scale In/Out | 🔴 높음 | ✅ 완료 |
| 요구사항 ID | 구분 | 요구사항 설명 | 중요도 | 구현 상태 |
|---|---|---|---|---|
| NFR-01 | 성능 | 웹 서버 부하 발생 시 성능 저하 없이 작동 | 🔴 높음 | ✅ 완료 |
| NFR-02 | 확장성 | 웹 서버는 트래픽 증가 시 자동 스케일링되어야 함 | 🔴 높음 | ✅ 완료 |
| NFR-03 | 안정성 | 스케일링 기능이 정상 동작, 장애 발생 시 서비스 중단 X | 🔴 높음 | ✅ 완료 |
| 요구사항 ID | 구분 | 요구사항 설명 | 중요도 | 구현 상태 |
|---|---|---|---|---|
| CR-01 | 기술 스택 | Kubernetes, Prometheus, Grafana 사용 | 🔴 높음 | ✅ 완료 |
| CR-02 | 환경 설정 | 로컬 및 클라우드(Kubernetes) 환경에서 동작 | 🔴 높음 | ✅ 완료 |
| 구분 | 구현 상태 | 설명 |
|---|---|---|
| ✅ 완료 | 전체 시스템 | 모든 기능 정상 동작 |
| ✅ 완료 | 스케일링 | 자동/수동 스케일링 완료 |
| ✅ 완료 | 부하 테스트 | 정상 동작 |
| ✅ 완료 | 데이터 수집 및 변환 | Airflow 도커 실행 완료 |
| ✅ 완료 | 데이터 분산 처리 | Spark 도커 실행 완료 |
| ✅ 완료 | Spark 모니터링 | Grafana 모니터링 완료 |
| ✅ 완료 | Spark Worker Manual Scale in/out | Manual Scale In/Out 완료 |
- Kubernetes 클러스터에 Prometheus와 Grafana를 배포하여 웹 서버의 CPU 사용량을 수집하고 대시보드에서 실시간으로 확인합니다.
- Docker Compose로 웹 서버를 실행하고, 부하 테스트를 통해 CPU 사용량 변화를 관찰합니다.
- 자동 스케일링: CPU 사용량이 설정된 임계치를 넘으면 서버가 자동으로 스케일 업됩니다.
- 수동 스케일링: 관리자 페이지에서 필요에 따라 수동으로 서버 스케일 업/다운을 조정할 수 있습니다.
$ git clone git@github.com:DE32FinalTeam2/FourthProject.git$ cd airflow
$ docker compose up -d# minikube 실행
$ minikube start
$ kubectl apply -f java-deployment.yaml
$ minikube service java-service --url# 해당 docker-compose.yaml이 있는 디렉토리로 이동
# FourthProject 기준
$ cd moni
$ docker compose up -d# FourthProject 기준
$ pip install .
$ streamlit run src/fourthproject/main.py
# streamlit web 접속 (http://localhost:8501)
# manual scale In/Out# 부하 테스트
$ ab -t <테스트 지속 시간(s)> -c <동시 요청 수> http://localhost:8949/
KEEP
1. 업무 분담이 확실하게 이루어졌다.
2. 이전에 수업했던 내용들을 종합하여 복습할 수 있었다.
3. 최종 프로젝트에서 설계될 구조를 미리 학습할 수 있었다.
PROBLEM
아직 kubenetes, prometheus, exporter에 대한 이해가 부족해서 공부하면서 프로젝트를 진행하려니 시간이 다소 소모되었다.
TRY
Grafana를 활용하여 Spark 지표를 모니터링 및 시각화 하도록 개선해야겠다.
KEEP
목표와 해야할 일을 정해놓고 분업화가 원할하게 된 것
PROBELM
프로메테우스나 exporter에 대한 이해가 부족해 팀원이 자신이 한 일을 설명해주어도 이해하는데 시간이 걸림
TRY
컨테이너의 메모리 사용률이나 컨테이너의 네트워크 대역폭을 읽어올 수 있는 방법이 있다고 생각함.
단순히 네트워크 대역폭 최대치나 메모리 용량 metric을 상수로 받아오는 것 보다는 컨테이너의 각 리소스 metric을 실제로 읽어오는 방식을 시도하고 싶음
KEEP
1. 저번 프로젝트 보다 공유도 잘되고 분업도 잘된것 같다.
2. 프로젝트를 진행하는 중에 JAM이 걸리지 않아서 프로젝트 완성속도나 프로세스 진행면에서 발전된 형태를 보였다.
3. 최종 프로젝트를 대비해서 미리 체험해봐야할 오류를 경험한 듯한 느낌이다 .
PROBLEM
1. 내가 일에 참여한 시간에 비해서 내 퍼포먼스가 좀 별로였다.
2. 아직 새로운 영역의 기술을 사용하거나 기존 사용하던 기술에 조금 더 발전된 테크닉을 적용시키는데 어려움이 있는 것 같다.
TRY
1. 사람이 빠져도 진행될 수 있는 팀을 구현하기 위해서 일정을 프로젝트 적용 (기술 + 태스크) 병렬형태로 짜봤으면 좋겠다.
업무 진행상황, 어려움을 겪고있는 상황이나 진행이 잘 되지 않는 상황을 ISSUE로 적극적으로 공유해봤으면 좋겠다.
KEEP
분업이 잘된 느낌이고 공유가 잘됐다.
PROBLEM
spark 등 툴에 대한 정확한 이해도가 부족해서 트러블 슈팅시간이 좀 걸렸다.
전반적으로 학습이 더 필요하다는 느낌을 많이 받았다.
TRY
전체적인 아키텍처를 사용하고자 하는 기술을 더해 구상할 수 있는 능력을 많이 길러야겠다.
KEEP
새로 배운 것을 프로젝트에 적용해본다는 점에서 의미 깊었다.
PROBLEM
코드에서의 문제가 없었으나 실행이 되지 않는 이유를 코드에서만 찾는 경향이 있다.
TRY
문법 이슈 외에 다른 환경설정 사항들도 고려해볼 것
- Grafana 대시보드 개선: Spark 성능 지표 추가 및 대시보드 개선
- 알림 시스템 설정: 성능 이상 발생 시 알림 받도록 설정
- 클러스터 상태 모니터링: 각 노드 상태 실시간 추적
- CPU 사용량에 따른 수동 Warker 스케일링 구현
- 스케일링 정책 설정: 임계치 확인 및 수동 스케일 아웃
- 에러 핸들링 및 로깅 개선: 장애 시 알림 및 로그 기록
- 부하 테스트 환경 개선: 다양한 시나리오 테스트 추가
- CI/CD 파이프라인 설정: 자동 배포 파이프라인 추가