어느 새 6차 미니프로젝트 후기로 돌아왔습니다...!!
이전 글이 3차 미프인데 바로 6차 미프로 돌아오게 되어 굉장히 유감스럽습니다.
그만큼 빠르고 부지런히 일정이 진행 되었습니다...
4,5차를 진행하게 되며 여러 팀원분들을 또 만나고 프로젝트를 진행했는데요.
감사하게도 팀원분들께서 팀장으로 추천해주셔서 4번째 팀장까지 완료할 수 있었습니다.
물론!!!! 우리 멋진 팀원분들이 있으셨기에 모든 것이 다 진행될 수 있었던 것이라 너무너무너무 감사드립니다.. ㅎㅎ
팀원분들과 미프가 끝나면 헐레벌떡 퇴근하기 바빠서
다같이 이야기할 기회가 없어서 아쉽습니다.. ㅠㅠ
4,5차 미니프로젝트는 React와 JAVA를 이용해 백앤드와 프론트앤드 구현 및
DB 설계와 연결 CRUD 등을 진행하였습니다.
백앤드와 프론트앤드 경험이 없는 저로서는 머리가 핑핑 돌았는데요!
다행히 팀원분이 잘 이끌어 주신 덕분에 4,5차 미프를 잘 완료하였습니다 ㅎㅎ
이번 6차 프로젝트는 4,5차에서 진행했던 도서 등록 시스템을 AWS EKS 환경으로 전환하면서
CI/CD 파이프라인부터 서비스 운영 자동화까지 구축하였습니다!
8명의 팀원으로 진행하게 되었고, 4,5차는 팀원이 동일하였으나 6차부터 새롭게 구성되어
기존의 프로젝트를 이어간다는 점이 어려움이었지만, 다행히 모든 팀원분들이 빠르게 따라잡아주셨습니다!
클라우드 또한 4,5차와 동일하게 다뤄본 적 없는 부분이었기 때문에 용어 정의나
전체적 흐름을 이해하기 위해 노력했습니다. 열심히 정리해보겠습니다!!
1. 프로젝트 개요
이번 프로젝트를 한줄로 요약하자면 아래와 같습니다.
개발자가 코드를 push하면, 사람의 개입 없이 빌드 → 배포 → 모니터링까지 자동으로 완료되는 파이프라인
기존에는 코드를 고치면 직접 빌드하고 수동으로 서버에 올리고, 재시작하는 과정을 진행했었는데 이를 모두 자동화하는 것이 목표였습니다.
1.2 기술 스택
4,5차 미니프로젝트의 후기를 작성하지 않았기 때문에 기술 스택은 이번 6차 미니프로젝트 기술 스택과 함께 작성하였습니다.
| 프론트엔드 | React 19, Vite |
| 백엔드 | Spring Boot (Java) |
| 컨테이너 | Docker |
| 오케스트레이션 | AWS EKS (Kubernetes) |
| CI/CD | CodePipeline, CodeBuild |
| 네트워크 | ALB, Ingress, AWS LB Controller |
| 모니터링 | CloudWatch Container Insights, Fluent Bit |
1.3 전체 아키텍처
GitHub에 merge하면 자동 빌드가 시작되고, 도커 이미지가 ECR에 쌓여 EKS가 그 이미지로 Pod를 갈아끼워 배포합니다.
배포된 서비스는 ALB를 통해 사용자에게 전달되고 동시에 CloudWatch가 모든 상태를 실시간으로 지켜봅니다. 이 과정에서 사람이 직접 손을 대는 과정은 없으나, 이번 프로젝트에서는 수동 승인 기능을 추가하여 배포 안정성을 추가하였습니다.
2. EKS 선정 이유
이번 미니프로젝트 전 진행되었던 클라우드 수업에서 EC2를 사용하여 수업을 진행했었습니다. 하지만 이번 프로젝트에서는 EKS를 사용하게 되었습니다. 여러 부분에서 EKS를 사용하는 것이 이번 프로젝트에 더 적합하다고 생각하여 선정하였습니다.
| EC2 단독 | EKS | |
| 서버 장애 시 | 수동 재시작 | Pod 자동 재생성 |
| 트래픽 증가 시 | 수동 서버 추가 | HPA가 Pod 자동 확장 |
| 배포 방식 | SSH 접속 수동 | YAML 선언적 배포 |
| 롤백 | 이전 버전 수동 복원 | kubectl rollout undo로 복원 가능 |
| 인프라 관리 | 서버마다 개별 설정 | 코드로 상태 관리(IaC) |
- 핵심 이유
1. 고가용성과 빠른 장애 복구 : Pod가 죽으면 쿠버네티스가 알아서 살려냅니다. 배포 실수가 일어나도 명령어 한줄로 복구 가능합니다.
2. 트래픽 급증 대비 유연한 동적 확장 : 부하에 따라 Pod와 Node를 자동으로 늘리고 줄입니다.
3. 선언적 배포(IaC) 및 인프라 코드화 : YAML에 원하는 상태를 적어두면 그대로 반영합니다. 휴먼 에러를 원천 차단 가능합니다.
EC2도 여러 장점이 있으나, 이번 프로젝트에는 위와 같은 이유로 EKS를 선정하게 되었습니다.
3. CI 단계
코드를 배포 가능한 상태로 만드는 빌드 단계입니다.
1. Github 자동화 트리거 : main 브랜치에 코드를 푸시하면 파이프라인이 자동 실행됩니다. 수동 빌드를 최소화하고 개발 생산성이 극대화됩니다
2. Docker 이미지 빌드 표준화 : Buildspec.yml을 기준으로 표준 컨테이너 환경을 조립하고, 고유한 Git Commit Hash를 태그로 붙여 정밀한 버전 추적이 가능합니다. (배포된 버전을 명확히 역추적하도록 커밋 해시를 사용합니다.)
3. ECR 보안 저장 : 빌드된 최종 아티팩트를 컨테이너 레지스트리에 저장하고 EKS 노드와의 연동으로 다운로드를 효율화 합니다.
4. CD 단계
만들어진 이미지를 실제 서비스로 배포하는 단계입니다.
1. 독립적 파이프라인 구성 : 프론트엔드와 백엔드를 개별 파이프라인으로 분리 운영하면서 배포 대상은 동일한 EKS 클러스터로 자원을 통합합니다.
2. 무중단 Rolling Update : replicas : 2의 구성으로 가용성을 확보하고 ECR 최신 이미지를 점진적으로 교체해 서비스 다운타임을 제거합니다.
- Rolling update가 무중단인 이유는 새 Pod가 헬스 체크를 통과한 뒤에야 기존 Pod를 제거하므로 항상 최소 1개 이상의 Pod가 서비스가 제공됩니다. 이를 위해 replicas를 2로 설정합니다.
3. 배포 성공 자동 검증 : kubectl rollout status 명령어로 배포 상태를 자동 추적하여 파이프라인 신뢰성을 확보합니다.
5. Ingress
외부 트래픽을 처리한느 네트워크 파트 Ingress입니다.
클러스터 외부에서 서비스로 직접 접근할 수 없고 오직 Ingress를 통해서만 트래픽이 유입되도록 보안을 강화했습니다.
내부 통신에sms ClusterIP를 기본으로 사용하며, Ingress 규칙에 따라 여러 ClusterIP 서비스로 연결합니다.
특히 AWS 로드 밸런서 컨트롤러가 작성한 Ingress.yaml 파일을 읽어 ALB를 자동으로 생성합니다.
? Ingress와 ALB의 관계
Ingress는 어떤 URL을 어디로 보낼지 정의하는 규칙서이고 ALB는 그 규칙대로 실제 트래픽을 분배하는 장비입니다.
-> Ingress를 만들면 LB 컨트롤러가 그걸 읽고 ALB를 자동으로 생성합니다.
6. CloudWatch 모니터링
6.1 모니터링 과정에서의 EC2와 EKS 차이
EC2 환경에서는 지표 수집과 로그 수집을 모두 CloudWatch Agent에서 진행하는 반면, EKS환경에서는 지표 수집은 Container Insights, 로그 수집은 Fluent bit을 사용합니다.
- Container Insights : 노드 Pod의 CPU/메모리/네트워크를 자동 수집합니다.
- Fluent Bit : 각 노드에 하나씩 배치되며 앱 로그를 수거해 CloudWatch Logs로 보냅니다.
6.2 구축
- IAM 권한 확인
Container Insights가 ColudWatch로 데이터를 보내려면 노드의 IAM역할에 아래와 같은 정책이 필요합니다.
CloudWatchAgentServerPolicy ← 지표 전송용
CloudWatchLogsFullAccess ← 로그 전송용
네트워크를 담당해주신 팀원분께서 정책 관리를 진행해주셨기 때문에 확인 후 진행하였습니다.
- 대시보드 제작
AWS가 자동 생성하는 기본 Container Insighs 화면도 있지만, 계정 내 모든 팀의 Pod가 섞여나오는 문제가 있어 다른 팀의 프로젝트와 분리를 위해 우리 팀의 대시보드를 제작했습니다.
위젯을 추가하며 여러 설정이 필요했는데, 행과 번호를 선택할 때 많이 헷갈렸던 기억이 있습니다
아래는 대시보드를 제작하면서 추가한 위젯의 목록입니다.
| 위젯 | 지표 | 유형 | 이유 |
| 노드 CPU 사용률 | node_cpu_utilization | 행 | 시간 추이 확인 필요 |
| 노드 메모리 사용률 | node_memory_utilization | 행 | 시간 추이 확인 필요 |
| 컨테이너 재시작 횟수 | pod_number_of_container_restarts | 번호 | 현재 상태 확인 |
| 실행 중 Pod 수 | node_number_of_running_pods | 번호 | 현재 상태 확인 |
| 네트워크 트래픽 | node_network_total_bytes | 행 | 시간 추이 확인 필요 |
| 앱 Pod CPU | pod_cpu_utilization | 행 | Pod별 비교 |
| 앱 Pod 메모리 | pod_memory_utilization | 행 | Pod별 비교 |
| ALB 요청 수 | RequestCount | 행 | 시간 추이 확인 필요 |
| ALB 응답 지연 | TargetResponseTime | 행 | 시간 추이 확인 필요 |
| ALB 정상 타겟 수 | HealthyHostCount | 번호 | 현재 상태 확인 |
6.4 모니터링 체계
1. Pod 자동 재생성 - Pod 장애 시 Deployment 기반 자동 복구
2. 무중단 배포 - Rolling Update로 신규 버전 배포 중 서비스 중단 최소화
3. 오토스케일링 - HPA(앱)와 Node Group(인프라) 유연한 동적 확장
4. 헬스 체크 상태 점검 - ALB Target Group 검증으로 정상 Pod로만 트래픽을 유도
5. 통합 모니터링 - CloudWatch 기반 파이프라인, 자원, 네트워크 통합 관측
추가로 CloudWatch를 이용하여 경보 기능을 넣어, CPU 점유율이 80%가 넘으면 SNS로 이메일 알람이 가도록 경보를 성정하였습니다.
로그 인사이트 쿼리로 에러 로그만 실시간 필터링할 수 있게 설정하여 에러 로그를 명확히 확인 가능하도록 설정하였습니다.
7. 부하 테스트
프로젝트의 가장 마지막 단계이자 가장 중요한 단계인 부하테스트입니다. 그동안 따로 놀던 모든 요소들을 하나의 흐름으로 연결되는 것을 실시간으로 확인했습니다.
부하 테스트 중 실제로 일어나는 단계
1. 부하 발생
↓
2. ALB가 백엔드 Pod로 트래픽 분배
↓
3. 백엔드 CPU 급등, 응답 시간은 1.1초로 발생
↓
4. HPA가 CPU 임계 초과 감지
↓
5. HPA가 백엔드 Pod 자동 증설 -> HealthyHostCount 증가
↓
6. 부하 분산 -> CPU 안정화
↓
7. 부하 종료 -> HPA가 Pod 자동 축소
| 단계 | 상태 | 결과 |
| 이전 | 평상 시 | 노드 CPU 5% 이하, 컨테이너 재시작 0회, Pod 정상 |
| 진행 | 부하 중 | 백엔드 CPU 급등·응답 지연 1.1초 → HPA 자동 증설 |
| 이후 | 안정화 | CPU 안정화, 응답 지연 정상 복귀, 재시작 0회 유지 |
전 과정에서 컨테이너 재시작 0회로 서비스가 한 번도 멈추지 않아 스케일 아웃과 스케일인이 모두 정상 작동함을 검증하였습니다.
실제 배포된 도서 관리 웹 서비스도 중단 없이 정상 작동함을 확인하였습니다.
8. 트러블 슈팅
담당했던 모니터링 파트에서 대시보드가 자꾸 끊기는 문제가 발생하였습니다. 처음엔 문제를 파악하지 못해, 어디서 문제가 생겨 Pod가 끊기는지 확인이 되지 않았습니다. 팀원들과 소통을 통해 Pod는 잘 running 중인 것을 확인하여 대시보드 측에 문제가 있음을 확인 하였습니다.
문제를 확인해보니 위젯을 Pod name을 기준으로 만들어 Pod가 재배포 될 때마다 Pod 이름 뒤의 랜덤 문자가 바뀌는 것이 원인이었습니다.
쿠버네티스에서 Pod는 수시로 생성 및 삭제되는 일회성 자원으로 모니터링의 수명이 짧은 Pod를 기준으로 하는게 아니라 Service 기준으로 설정해야 했습니다.
9. 회고
클라우드를 입문하면서 체감하게 된 것은 기능 구현보다 권한과 의존성 관리가 더 어렵다는 것입니다. 팀원분들과 함께 소통하며 권한과 의존성 관리로 인해 여러 의견을 나누고 조사한 것이 가장 기억에 남습니다.
그만큼 참여율이 가장 높았던 프로젝트라고 생각하여 기억에 오래 남을 것 같습니다. 모니터링 파트를 맡아 진행하면서 언제 무엇을 요청할지 확인하고 지속적으로 진행 상황을 파악하며 여러 팀원들과 소통하면서 힘이 되기도 했던 것 같습니다.
아쉬운 점이 있다면 경보 기능을 만들어 부하 테스트 중 CPU 점유율 경보가 오기를 바랐으나, HPA가 Pod를 자동 증설하고 부하 분산이 잘 되어 아무런 경보가 도착하지 않아 약간 아쉬움이 남습니다...
6차 미니 프로젝트에서 새롭게 만난 팀원들과 함께 빅프로젝트까지 진행하게 된 만큼 정말 잘해보고 싶습니다!!
이번 프로젝트를 진행하면서 팀합이 참 조화롭다는 생각을 했습니다.
사실 4,5차를 진행하면서 굉장히 불안형이 될 뻔했는데, 안정형 팀원분들 덕분에 버틸 수 있었습니다.
근데!! 그 팀원 분들과 제가 6차 미니프로젝트를 그리고 빅프로젝트를 같이 진행하게 된 것 아니겠어요?!
그리구 정말 개인적으루 친해지고 싶은 분과 같은 팀이 되었더용~! 좋아서 진짜 입 찢어질 뻔 했습니다 히히
팀 무슨 기준인지 모르겠지만 담당자님 나이스입니다. 이 글을 쓰고 있는 지금도 미소 가득입니다!!!
그러면 다음엔 KT 판교 빌딩 방문기로 뵙겠습니다!!
'KT AIVLE school' 카테고리의 다른 글
| AIVLE School 9기 KT 판교 빌딩 방문 (2) | 2026.06.29 |
|---|---|
| AIVLE School 미니프로젝트 3차 후기 (0) | 2026.05.20 |
| KT AIVLE school 미니프로젝트 2차 후기 (0) | 2026.05.11 |
| KT AIVLE school 미니 프로젝트 1차 후기 (0) | 2026.04.28 |
| KT AIVLE school 9기 2주차 후기 (0) | 2026.04.13 |
