cw-infra는 CJ CloudWave 부트캠프 최종 프로젝트의 Infrastructure repository입니다.
본 프로젝트는 올리브영의 올영세일과 같은 이커머스 대규모 할인 이벤트 상황을 가정하고, 주문 요청이 급증하는 시나리오에서 대기열 기반 처리와 Kubernetes autoscaling을 결합해 대용량 트래픽을 안정적으로 처리하는 AWS EKS 기반 인프라 아키텍처를 구축하는 것을 목표로 진행했습니다.
이커머스 환경에서는 특정 이벤트 시작 시점에 사용자가 한꺼번에 몰리며 상품 조회, 장바구니, 주문 요청이 급증할 수 있습니다. 이를 대비하기 위해 이벤트 시작 전에는 KEDA Cron Scaler를 활용해 주요 서비스 Pod를 선제적으로 증설하고, 이벤트 진행 중에는 queue lag 또는 metric 증가에 따라 KEDA/HPA 기반으로 Pod를 자동 확장하는 구조를 설계했습니다. Pod 증가로 기존 Node 리소스가 부족해질 경우 Karpenter가 workload에 맞는 Node를 자동 프로비저닝하도록 구성했습니다.
인프라는 Terraform으로 VPC, EKS, IAM 등 주요 AWS 리소스를 IaC로 관리했으며, Kubernetes 리소스는 ArgoCD 기반 GitOps 방식으로 관리했습니다. 외부 트래픽은 Route 53, CloudFront, WAF, ALB, Ingress를 거쳐 EKS 서비스로 라우팅되도록 설계했고, Prometheus, Grafana, Loki, Tempo 기반 observability 구조를 통해 서비스와 클러스터 상태를 관측할 수 있도록 구성했습니다.
본 프로젝트는 부트캠프 기간 동안 실제 AWS EKS 환경에 배포하여 검증했으며, 현재는 비용 관리를 위해 클라우드 리소스를 삭제한 상태입니다.
CloudWave는 Frontend, Backend, Infrastructure, AIOps 영역으로 나누어 진행한 팀 프로젝트입니다.
cw-infra는 이 중 Infrastructure 영역을 담당하는 저장소입니다.
Infrastructure 영역의 주요 목표는 다음과 같습니다.
- AWS EKS 기반 Kubernetes 운영 환경 구성
- Terraform을 활용한 AWS 인프라 리소스 IaC 관리
- ECR 이미지를 EKS에서 실행하기 위한 Kubernetes manifest 구성
- ArgoCD 기반 GitOps 배포 구조 설계
- KEDA Cron Scaler 기반 이벤트 전 Pod 선제 증설 구조 구성
- KEDA/HPA 기반 Pod autoscaling 구조 구성
- Karpenter 기반 node provisioning 구조 구성
- Route 53, CloudFront, WAF, ALB, Ingress 기반 외부 트래픽 진입 구조 설계
- Prometheus, Grafana, Loki, Tempo 기반 observability 구조 구성
- 운영계, 개발계, DR 환경을 분리한 인프라 아키텍처 설계
본 프로젝트는 올리브영의 올영세일과 같은 이커머스 대규모 할인 이벤트 상황을 가정했습니다.
- 이벤트 시작 전, 트래픽 증가가 예상되는 시간대에 주요 서비스 Pod를 미리 증설합니다.
- 이벤트가 시작되면 사용자의 상품 조회, 장바구니, 주문 요청이 급격히 증가합니다.
- 주문 요청은 queue 기반 구조를 통해 완충하고, consumer/application Pod가 비동기적으로 처리합니다.
- queue lag 또는 metric이 증가하면 KEDA/HPA가 이를 감지해 Pod 수를 자동 확장합니다.
- Pod 증가로 기존 Node 리소스가 부족해지면 Karpenter가 workload 요구사항에 맞는 Node를 자동 프로비저닝합니다.
- Prometheus, Grafana, Loki, Tempo 기반 observability 구조를 통해 서비스와 클러스터 상태를 관측합니다.
- Kubernetes 리소스 변경은 ArgoCD 기반 GitOps 방식으로 추적 및 동기화합니다.
| Area | Tech |
|---|---|
| Cloud | AWS |
| Container Orchestration | AWS EKS, Kubernetes |
| Container Registry | AWS ECR |
| IaC | Terraform |
| GitOps | ArgoCD |
| CI/CD | GitHub Actions |
| Deployment | Helm, Kubernetes Manifest |
| Autoscaling | KEDA, HPA, Karpenter |
| Networking | Route 53, CloudFront, AWS WAF v2, ACM, ALB, VPC, Public/Private Subnet, NAT Gateway, VPC Endpoint, OpenVPN |
| Storage / Static Hosting | Amazon S3 |
| Database / Cache | Amazon RDS, Amazon Aurora MySQL, ElastiCache, DynamoDB |
| Messaging / Streaming | AWS MSK |
| Monitoring / Observability | Prometheus, Grafana, Loki, Tempo, Athena, S3 |
| Alerting / Automation | AWS Lambda, Slack, Amazon Bedrock |
| Disaster Recovery | Multi-AZ, DR Region, Aurora MySQL, S3, DynamoDB |
| IAM / Security | IAM, IRSA, Security Group |
Traffic
│
▼
Route 53
│
▼
CloudFront
│
├── AWS WAF v2
└── ACM
│
▼
ALB
│
▼
AWS EKS
│
├── Backend API / Application Pods
├── ArgoCD
├── KEDA / HPA
├── Karpenter
└── Grafana
│
├── AWS MSK
├── ElastiCache
└── RDS / Aurora MySQL
Autoscaling Flow
├── KEDA Cron Scaler
│ └── 이벤트 시작 전 Pod 선제 증설
├── KEDA
│ └── metric 또는 queue lag 증가에 따른 Pod autoscaling
└── Karpenter
└── Node 리소스 부족 시 EC2 Node 자동 프로비저닝
Monitoring
├── Prometheus
├── Grafana
├── Loki
├── Tempo
├── Athena / S3
├── Lambda
├── Bedrock
└── Slack
CI/CD & GitOps
├── GitHub Actions
├── ECR
├── ArgoCD
└── EKS
DR
├── Route 53
├── Internet Gateway
├── ALB
├── NAT Gateway
├── EC2
├── Aurora MySQL
├── ECR
├── S3
└── DynamoDB
운영계는 외부 사용자의 이벤트 트래픽을 안정적으로 처리하는 것을 목표로 설계했습니다.
- Route 53을 통한 도메인 라우팅
- CloudFront 기반 CDN 구성
- AWS WAF를 통한 웹 트래픽 보호
- ALB를 통한 EKS 서비스 트래픽 라우팅
- Public / Private Subnet 분리
- NAT Gateway 기반 Private Subnet outbound 경로 구성
- AWS MSK, ElastiCache, RDS/Aurora MySQL 등 backend dependency 구성
- ECR 접근을 위한 VPC Endpoint 구성
- OpenVPN 기반 private resource 접근 경로 구성
개발계는 개발자가 변경 사항을 빠르게 배포하고 검증할 수 있도록 구성했습니다.
- GitHub Actions 기반 CI/CD
- ECR을 통한 container image 저장
- ArgoCD 기반 GitOps 배포
- EKS 개발 클러스터 구성
- OpenVPN을 통한 private resource 접근
- RDS, ElastiCache 등 개발용 dependency 구성
- VPC Endpoint 기반 AWS private service 접근
DR 환경은 장애 상황에서 핵심 서비스를 복구할 수 있는 구조를 목표로 설계했습니다.
- 별도 Region 기반 DR 구조
- Multi-AZ subnet 구성
- ALB, EC2, Aurora MySQL 기반 복구 환경
- ECR, S3, DynamoDB 등 핵심 리소스 연동
- Route 53 기반 트래픽 전환 가능성 고려
모니터링 구조는 서비스와 인프라 상태를 관측하고, 이상 징후를 운영자가 빠르게 인지할 수 있도록 구성했습니다.
- Prometheus를 통한 metrics 수집
- Grafana를 통한 dashboard 구성
- Loki를 통한 log aggregation
- Tempo를 통한 tracing 구조 검토
- Athena / S3 기반 log query 및 분석 구조 검토
- Lambda, Bedrock, Slack을 활용한 알림 및 운영 자동화 구조 검토
- Terraform으로 VPC, EKS, IAM 등 AWS 인프라 리소스를 생성합니다.
- 애플리케이션 이미지는 ECR에 저장합니다.
- GitHub Actions를 통해 애플리케이션 build 및 image push 과정을 자동화합니다.
- ArgoCD를 EKS 클러스터에 설치하고
root-app.yaml을 최초 1회 적용합니다. - 이후 Kubernetes 리소스 변경은 직접
kubectl apply하지 않고 Git push를 통해 관리합니다. - ArgoCD가 Git repository의 desired state를 감지하고 EKS 클러스터에 자동 동기화합니다.
- 이벤트 트래픽에 대비해 KEDA Cron Scaler로 주요 서비스 Pod를 선제적으로 증설합니다.
- queue lag 또는 metric 증가 시 KEDA/HPA가 Pod를 자동 확장합니다.
- Pod 증가로 Node 리소스가 부족해질 경우 Karpenter가 Node를 자동 프로비저닝합니다.
본 프로젝트에서는 Git을 Kubernetes 리소스의 단일 진실 공급원으로 사용하기 위해 다음 규칙을 적용했습니다.
- 클러스터에 직접
kubectl apply금지 root-app.yaml최초 1회만 수동 적용- 이후 모든 Kubernetes 리소스 변경은 Git push로만 진행
- ArgoCD 이후 모든 Kubernetes 리소스는 각 파트 담당자가 Git으로 관리
- Sync 에러 발생 시 클러스터에서 수동 수정하지 않고 YAML 수정 후 Git push
prune=true,selfHeal=true를 활용해 Git 상태와 클러스터 상태를 일치시킴
gitops/apps 하위에 새로운 애플리케이션 디렉터리를 생성합니다.
gitops/apps/my-service/
해당 디렉터리에 배포에 필요한 Kubernetes 리소스를 작성합니다.
예시:
deployment.yaml
service.yaml
ingress.yaml
values.yaml
Helm을 사용하는 경우 values.yaml을 함께 관리합니다.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-service
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/CloudWave-4/cw-infra
targetRevision: main
path: gitops/apps/my-service
destination:
server: https://kubernetes.default.svc
namespace: my-service
syncPolicy:
automated:
prune: true
selfHeal: truegit add .
git commit -m "feat: add my-service"
git push origin mainkubectl get applications -n argocd또는 ArgoCD UI에서 동기화 상태를 확인합니다.
Kubernetes 리소스를 수정할 때는 클러스터에서 직접 수정하지 않고, Git repository의 YAML 파일을 수정한 뒤 push합니다.
YAML 수정 → Git push → ArgoCD 자동 동기화
금지하는 작업:
kubectl edit
kubectl apply -fArgoCD의 selfHeal 정책으로 인해 클러스터에서 수동 수정한 내용은 Git 상태로 되돌아갑니다.
애플리케이션을 삭제할 때는 apps 디렉터리에서 해당 애플리케이션 폴더를 삭제한 뒤 push합니다.
gitops/apps/my-service/ 삭제 → Git push → ArgoCD prune
prune=true 설정으로 인해 Git에서 삭제된 리소스는 클러스터에서도 자동 삭제됩니다.
- Terraform 코드는 Git에 push합니다.
- Terraform state는 S3 backend를 사용해 관리합니다.
tfstate파일은 Git에 업로드하지 않습니다.- Terraform 변경은 담당자만 수행합니다.
terraform destroy는 리소스 의존성을 고려하여 신중하게 수행합니다.
VPC, EKS, IAM 등 주요 AWS 리소스를 Terraform으로 관리했습니다.
Terraform state는 S3 backend를 사용하여 관리하고, tfstate 파일이 Git에 포함되지 않도록 구성했습니다.
Kubernetes 리소스를 Git repository에서 관리하고, ArgoCD가 이를 EKS 클러스터에 자동 동기화하도록 구성했습니다. 초기 root application 적용 이후에는 Kubernetes 리소스를 직접 수정하지 않고 Git push 기반으로 변경을 반영하도록 운영 규칙을 정했습니다.
ECR에 저장된 애플리케이션 이미지를 EKS에서 실행할 수 있도록 Kubernetes manifest와 Helm chart 구조를 구성했습니다.
올리브영의 올영세일과 같은 이커머스 이벤트성 트래픽을 가정하여 선제 확장과 반응형 확장을 함께 고려했습니다.
- KEDA Cron Scaler를 활용해 이벤트 시작 전 주요 서비스 Pod 선제 증설
- Helm values에서
timezone,start,end,desiredReplicas를 설정해 특정 시간대의 Pod 수 조정 - queue lag 또는 metric 증가에 따라 KEDA/HPA 기반 Pod autoscaling
- Pod 증가로 Node 리소스가 부족해질 경우 Karpenter 기반 Node 자동 프로비저닝
- 트래픽 감소 후 Pod 및 Node 축소를 통한 비용 효율성 고려
주문 요청이 한 번에 몰리는 상황에서 backend가 모든 요청을 즉시 처리하지 않고, queue 기반으로 요청을 완충하는 구조를 고려했습니다.
- 주문 요청 급증 시 queue를 통해 처리량 조절
- Consumer Pod가 queue message를 비동기적으로 처리
- Consumer 처리량보다 요청량이 많아질 경우 queue lag를 scaling signal로 활용
- AWS MSK 기반 message streaming 구조 고려
서비스와 인프라 상태를 관측하기 위해 Prometheus, Grafana, Loki, Tempo 기반 observability 구조를 검토 및 구성했습니다.
- Prometheus 기반 metrics 수집
- Grafana 기반 dashboard 구성
- Loki 기반 log aggregation
- Tempo 기반 tracing 구조 검토
- Athena / S3 기반 log analysis 구조 검토
장애 상황에 대비하여 별도 Region 기반 DR 구조를 설계했습니다.
- DR Region 내 VPC 구성
- Multi-AZ subnet 구성
- ALB, EC2, Aurora MySQL 기반 복구 환경
- S3, DynamoDB 등 핵심 데이터 리소스 고려
- Route 53 기반 트래픽 전환 가능성 검토
본 프로젝트는 Frontend, Backend, Infrastructure, AIOps로 역할을 나누어 진행한 팀 프로젝트입니다.
- Frontend:
cw-frontend - Backend:
cw-backend - Infrastructure:
cw-infra - AIOps:
cw-aiops
부트캠프 기간 동안 실제 AWS EKS 환경에 배포하여 검증했으며, 현재는 비용 관리를 위해 AWS 리소스를 삭제한 상태입니다.
이 저장소에는 인프라 구성 방식, GitOps 배포 구조, 운영 규칙이 남아 있습니다.