Role: BE, Infra & DevOps Lead — 인프라 아키텍처 설계∙구축 | CI/CD | 모니터링 체계 구성
Period: 2025.02 – 2025.03
Team: 4인
Link: [GitHub]
1. 프로젝트 소개
CINEBOX는 실시간 좌석 점유와 예매가 발생하는 영화 예매 서비스를 가정하고 구축한 프로젝트입니다.
이 프로젝트에서 집중한 것은 단순히 서비스를 Kubernetes 위에 배포하는 것이 아니라, 환경 차이와 수동 배포로 인한 운영 리스크를 줄이고, 운영 상태를 관측 가능한 구조로 만드는 것이었습니다.
서비스 규모가 커질수록 운영 리스크는 코드 자체뿐 아니라 환경별 설정 차이, 수동 반영, 추적되지 않는 변경, 클러스터 내부 공통 컴포넌트 문제에서도 발생할 수 있다고 보았습니다. 그래서 CINEBOX에서는 Dev/Prod 환경을 Git 기준으로 분리하고, 모니터링을 통해 설계 판단을 검증하며, 장애 발생 시 원인을 단계적으로 좁힐 수 있는 운영 기반을 만드는 데 초점을 맞췄습니다.
[이미지 1] CINEBOX 아키텍처
2. 왜 운영 기준을 Git으로 일원화했는가
Dev와 Prod 환경을 동시에 운영하면서, kubectl 중심의 수동 반영을 계속하면 실제 클러스터 상태와 저장소의 상태가 어긋날 수 있다고 판단했습니다.
•
환경 드리프트
kubectl apply로의 직접 반영은 실제 클러스터 상태와 Git 코드베이스가 달라집니다. Dev에서 검증한 설정이 Prod에 동일하게 반영된다는 보장이 사라집니다.
•
배포 이력 부재
누가 언제 무엇을 배포했는지 추적할 방법이 없으며, 배포 이력이 명확하지 않으면 문제 발생 시 원인 추적이 어려워질 수 있습니다.
따라서 운영 기준을 Git으로 일원화함으로써 모든 변경이 커밋과 PR 단위로 남고, 클러스터 상태 또한 정의된 상태로 수렴시킬 수 있는 상태로 만들었습니다.
3. 배포를 어떻게 재현 가능하게 만들었는가 — GitOps & Delivery
Kustomize 기반 환경 분리
Dev와 Prod 환경의 설정 충돌을 줄이기 위해 Kustomize의 Base/Overlay 구조를 사용했습니다.
k8s-manifests/
├── base/ # 공통 리소스 정의
└── overlays/
├── dev/ # Dev 환경 설정
└── prod/ # Prod 환경 설정
Plain Text
복사
Base에는 공통 리소스를 정의하고, Overlay에는 환경별 설정만 덮어쓰도록 구성했습니다. 이를 통해 Dev와 Prod 간 설정 충돌을 줄이고 환경별 차이를 명확히 나눌 수 있었습니다.
GitHub Actions + ArgoCD 역할 분리
CI와 CD의 책임을 분리했습니다.
•
GitHub Actions: 이미지 빌드, 테스트, ECR Push, Manifest 버전 업데이트
•
ArgoCD: Git 저장소 변경 감지, Kubernetes 리소스 동기화, 배포 상태 수렴
배포 흐름은 다음과 같습니다:
GitHub main/develop branch push
→ GitHub Actions 이미지 빌드 및 ECR Push
→ Manifest 이미지 태그 업데이트
→ ArgoCD 변경 감지
→ Dev / Prod 환경별 동기화
이 구조를 통해 Git 상태를 기준으로 배포 재현성과 환경 일관성, 변경 추적성을 확보하는 GitOps 기반 운영을 할 수 있었습니다.
4. 운영 상태를 어떻게 설계 검증에 활용했는가 — Observability & Design Validation
모니터링 체계 구성
Prometheus, Grafana, Loki를 활용해 인프라와 애플리케이션 상태를 함께 확인할 수 있는 관측 체계를 구성했습니다.
구분 | 구성 |
Metric | Prometheus → Grafana |
Log | Promtail → Loki → Grafana |
수집 지표•
CPU∙Memory∙Node Disk I/O 등 시스템 메트릭
•
HTTP 응답 시간 및 상태값
•
Method별 요청 빈도
•
로그 레벨
•
도메인별 요청 패턴
[이미지 2] Node Metrics
[이미지 3] Application Metrics
[이미지 4] Application Logs
설계 타당성 검증
영화 예매 서비스는 예매∙결제와 같은 쓰기 요청도 존재하지만, 영화 목록 조회, 상영 정보 조회, 좌석 상태 확인처럼 조회성 요청이 더 자주 발생할 것으로 예상했습니다. 이를 바탕으로 RDS Read Replica를 분리해 조회 트래픽을 Replica에서 처리하도록 설계했습니다.
이후 모니터링을 통해 movie 도메인의 GET 요청이 트래픽이 집중되는 흐름을 확인할 수 있었습니다. 모니터링을 통해 설계 결정의 타당성을 확인하는 수단으로 기능한 경험이었습니다.
5. 인프라를 어떻게 코드로 관리하고 비용을 최적화했는가 — IaC & Cost Optimization
Infrastructure as Code
인프라를 반복적으로 생성하고 삭제해야 하는 프로젝트 상황이 있었기 때문에, AWS 인프라를 Terraform으로 코드화해 재현성을 확보했습니다.
cinebox-terraform/
├── vpc.tf # VPC, Subnet, Routing Table, NAT
├── eks.tf # EKS Cluster, Node Group
├── rds.tf # RDS MySQL, Read Replica
├── elasticache.tf # ElastiCache Redis
├── bastion.tf # Bastion EC2
├── variables.tf
├── outputs.tf
└── provider.tf
Plain Text
복사
비용 최적화와 Trade-off
비용 제약이 있던 프로젝트 안에서 비용과 운영 안정성 사이의 균형을 고려해 아키텍처를 설계했습니다.
NAT InstanceNAT Gateway 대신 NAT Instance를 선택해 비용을 줄였습니다. 단일 장애점이 존재한다는 Trade-off가 있었지만, 프로젝트 규모와 트래픽 수준을 고려했을 때 비용 절감 효과가 더 크다고 판단했습니다.
S3 Gateway EndpointPrivate Subnet에서 S3로 접근하는 트래픽은 Gateway Endpoint를 통해 라우팅했습니다. 이를 통해 NAT를 거치지 않아 외부 노출 경로 제거, 트래픽 비용 절감, 지연시간 감소 효과를 얻었습니다.
CloudFront + S3이미지 조회가 빈번한 서비스 특성을 고려해 CloudFront로 S3 콘텐츠를 캐싱했습니다. 엣지 캐싱으로 이미지 조회 응답속도를 개선하고 S3 트래픽 비용을 절감했습니다.
6. 장애를 어떻게 추적해 해결했는가 — RCA
Issue. CoreDNS Taint 충돌로 인한 RDS 연결 실패
상황애플리케이션 Pod가 RDS와 연결하지 못하고 CrashLoopBackOff 상태가 반복되는 문제가 발생했습니다.
원인 추적문제를 단계적으로 좁혀갔습니다.
1.
RDS 설정, Security Group, 환경변수 확인 → 설정상 문제 발견되지 않음
2.
endpoint 기반 연결 실패에 주목 → DNS 해석 문제 의심
3.
CoreDNS Pod 상태 확인 → Pending 상태 발견
4.
노드 Taint와 CoreDNS Toleration 확인 → 모든 노드에 Taint 적용, CoreDNS에는 해당 Taint에 대한 Toleration이 없음
결과적으로 애플리케이션과 RDS의 직접적인 설정 문제가 아닌, 클러스터 내부의 CoreDNS가 스케줄링되지 못한 것이 원인이었습니다.
해결CoreDNS Deployment에 필요한 tolerations를 추가해 CoreDNS가 노드에 정상 스케줄링될 수 있도록 수정했습니다. 이후 애플리케이션과 RDS 간 연결이 정상화되었습니다.
7. 어떤 결과를 만들었는가
CINEBOX를 통해 배포 파이프라인을 구성하는 것에만 머무는 것이 아닌 안정적인 서비스 운영 기반을 만듦으로써 개발과 운영 간의 사이를 좁힐 수 있었습니다.
영역 | 변화 |
배포 재현성 | Kustomize + ArgoCD 기반 Dev/Prod 환경 분리 |
환경 일관성 | 수동 kubectl 반영 → Git 기준 선언적 배포 |
변경 추적성 | 배포 이력과 설정 변경을 Git commit으로 기록 |
설계 검증 | Read Replica 설계 → 모니터링으로 요청 패턴 검증 |
운영 가시성 | Prometheus·Grafana·Loki 통합 관측 체계 구성 |
비용 최적화 | NAT Instance, S3 Gateway Endpoint, CloudFront 기반 비용 절감 |
장애 대응 | CoreDNS 스케줄링 문제를 규명하고 RDS 연결 장애 해소 |