## ✅ 기존 환경에서의 불편함
- 리소스 설정 (CPU, memory) 이 과하거나 부족해서 오토스케일 비효율
- CLI로 yaml 을 직접 배포하고, configmap 및 yaml 파일 수정의 불편함
## ➡️ 목표 제시:
"1주일간 부하 테스트를 통해 평균 사용량에 근거한 리소스 세팅을 찾고, Helm으로 배포를 표준화하는 것이 목표였습니다."
## ngrinder + kubecost: 부하 기반 리소스 분석
- **ngrinder**를 통해 실제 트래픽 시뮬레이션 (1주일간)
- **kubecost**로 각 서비스 pod의 CPU/Memory 사용률, 비용 추적
### 주요 인사이트:
- 특정 API 서버는 2vCPU 2Gi → 0.5vCPU 1Gi로 줄여도 무리 없음
- 반대로, signoz 서비스는 리소스를 더 필요로 함
## Helm 도입: 복잡했던 yaml 관리 탈피
- 기존에는 `kubectl apply -f` 로 여러 yaml 파일 관리
- 변수, configmap 바꿀 때마다 수동 수정 → 불편함
### ▶️ Helm 전환 작업
- Helm Chart 구성
- values.yaml에 환경별 리소스, 변수 처리
- `helm upgrade`로 손쉽게 롤링 배포
### ✅ 이점:
- 튜닝한 리소스 설정을 버전 관리로 관리 가능
- 간편한 배포 구현
## 변화 요약: 개편 전 vs 개편 후
| 항목 | 개편 전 | 개편 후 |
|------|---------|----------|
| 리소스 설정ㅤ | 대충 감으로 설정 | 측정 기반으로 최적화 |
| 배포 방식 | kubectl CLI, 수동 config 변경 | Helm Chart, values.yaml 사용 |
| 비용 | 불필요한 리소스 낭비 존재 | kubecost로 리소스 확보 |
- ##### kubecost + ngrinder 로 테스트하는 화면
- ##### helm 차트 구조
