• 프로젝트명 : 앗! 티켓팅 홈런보다 쉽다! (CGV 가을 야구 LIVE 티켓팅 시스템)

• 프로젝트 기간 : 2025.08.08 ~ 2025.08.29 (3주)

• 프로젝트 배경

  • CGV의 스포츠 생중계 및 콘서트 스트리밍 서비스 수요 증가와 2025년 프로야구 1,000만 관중 시대를 맞아, 포스트시즌 생중계 시 발생할 대규모 트래픽을 처리할 수 있는 견고한 인프라가 필요

• 프로젝트 목표

  • 대기열 시스템 구현: Redis와 Kinesis를 활용하여 접속 폭주 상황 제어
  • 고가용성 및 안정성: 동시 접속 인원 10만 명 트래픽 처리 목표
  • 재해 복구(DR): 서울 리전 장애 시 도쿄 리전으로 즉시 전환, RTO(복구 목표 시간) 5분 이내, RPO(복구 목표 시점) 1초 미만 달성

정호원	나영민	이명규	임세희	홍수빈
@ONE0x393	@skdudals99	@lmg5615	@Sehi55	@sss654654
DevOps, Infra	DevOps, Infra	Monitoring, Infra	Infra, FullStack	Infra, FullStack

전체 아키텍처는 운영계(Prod), 개발계(Dev), QA, DR(Disaster Recovery) 환경으로 분리하여 구성하였으며, 운영계와 개발계는 서울 리전(ap-northeast-2), DR은 도쿄 리전(ap-northeast-1)에 구축

운영계는 **가용성(High Availability)**과 보안을 최우선으로 설계

• 트래픽 처리: Route53과 CloudFront를 거친 트래픽은 WAF를 통해 악성 요청이 차단되며, Ingress ALB를 통해 EKS Pod로 전달
• 보안: 허가된 트래픽만 Pod에 접근할 수 있도록 Network Policy를 적용
• 데이터베이스: 데이터 정합성을 위해 Aurora Global DB를 사용하며, 대기열 처리를 위한 Redis와 메시지 스트리밍을 위한 Kinesis Data Streams가 배치
• 오토스케일링: 트래픽 폭주에 대비해 KEDA(이벤트 기반)와 Karpenter(노드 프로비저닝)를 적용

개발계는 비용 효율성과 네트워크 격리에 중점을 두고 설계

• 비용 절감: Aurora DB 대신 상대적으로 저렴한 Amazon RDS를 사용
• 보안 접근: 개발자는 Client VPN을 통해서만 접근 가능하며, GitLab과 같은 내부 리소스는 Transit Gateway(TGW)를 통해 연결
• 배포: GitLab CI를 통해 빌드된 이미지는 PrivateLink를 통해 보안이 유지된 상태로 ECR에 전송

서울 리전 장애 시 서비스의 연속성을 보장하기 위해 도쿄 리전에 구축

• 전환 시나리오: 장애 발생 시 Route53이 이를 감지하고 EventBridge와 Step Functions를 트리거하여 자동 복구 절차를 실행
• 복구 자동화: 'DB 승격(Writer 전환) -> ArgoCD 배포 -> RDS Proxy 생성' 과정이 병렬로 수행되어 RTO 시간을 단축
• 이미지 동기화: ECR Cross-Region Replication을 통해 최신 서버 이미지가 항상 도쿄 리전에 동기화

대규모 트래픽(동시 접속 10만 명)을 안정적으로 처리하기 위해 대기열 시스템을 구축

• Redis: 대기열 상태 관리 및 빠른 처리를 담당
• Kinesis Data Streams: SQS 대비 높은 처리량(Throughput)과 메시지 보존 기능을 제공하여 트래픽 폭주 시에도 안정적인 메시지 처리가 가능하여 선택
• Auto Scaling:
  • KEDA: Redis 대기열 길이, Cron(시간대) 등 사용자 체감 부하를 기준으로 Pod를 확장
  • Karpenter: Cluster Autoscaler보다 빠른 속도로 노드를 프로비저닝하여 급격한 트래픽 변화에 대응
  • RDS Proxy: 오토스케일링으로 인한 DB 커넥션 병목을 해소하기 위해 도입

보안성이 강화된 GitLab과 GitOps 방식의 ArgoCD를 활용하여 파이프라인을 구축

보안 통제를 위해 외부 노출 위험이 적은 GitLab을 개인 서버에 구축하여 사용

• 과정: Commit&Push -> GitLab Runner 실행 -> SonarQube(코드 스멜 분석) -> Dependency Check(취약점 분석) -> Docker Build -> ECR Push

운영 환경과 개발 환경의 특성에 맞춰 두 가지 워크플로우를 운영

• 모든 환경 (Prod/QA): ArgoCD가 GitLab 저장소의 변경 사항을 감지하여 Sync를 맞추는 Pull 방식 배포
• 개발계 (Dev): 빈번한 배포를 지원하기 위해 ImageUpdater를 도입, ECR에 새 태그가 감지되면 자동으로 배포되도록 구성

Datadog & CloudWatch: EKS 내부 자원(Pod, Node)과 AWS 인프라 상태를 통합 모니터링하며, Slack으로 실시간 알림을 전송

데이터 손실 방지 및 빠른 복구를 위해 이중 백업 체계를 마련

• AWS Backup: GitLab이 구동되는 EC2 인스턴스를 3시간 주기로 백업
• Velero: Kubernetes 리소스 및 설정을 Namespace 별로 S3에 스냅샷 형태로 저장하여 클러스터 마이그레이션을 지원