배경(Problem)
•
정보가 여기저기 흩어져 있음
공연이나 팬미팅 정보랑 후기가 여러 앱이나 사이트에 나뉘어 있어서 한 번에 찾기 불편함.
•
믿을 수 있는 정보 찾기 어려움
광고나 가짜 후기 때문에 실제 다녀온 사람의 솔직한 후기를 구분하기 힘듦.
•
팬들끼리 소통하기 어려움
기존 서비스는 일정이나 예매 정보만 알려주고, 팬들끼리 자유롭게 이야기할 공간은 부족함.
•
트래픽 집중성
인기 아티스트의 공연 정보가 업데이트되거나 이벤트가 발생하면 초단위로 대규모 사용자가 유입됨을 가정할 수 있음
•
가용성 확보
단순한 커뮤니티를 넘어, 갑작스러운 트래픽 속에서도 사용자에게 끊김 없는 경험을 제공하는 것이 이 프로젝트의 가장 큰 기술적 목표임
서비스 소개(Solution)
StageLog는 여기저기 흩어져 있던 공연 정보와 후기를 한곳에 모아 사용자들이 더 쉽게 접근할 수 있도록 만든 서비스입니다. 단순히 정보를 제공하는 데 그치지 않고, 실제 관람객들이 서로 경험을 나누고 소통할 수 있는 공간을 제공하는 데 초점을 두었습니다.
또한 단순한 기획 수준을 넘어, 클라우드 환경에서 실제로 운영이 가능한 수준의 인프라까지 직접 구축했습니다.
1. 사용자 중심의 핵심 기능
공연 팬들이 겪는 흩어져 있는 정보와 신뢰성 문제를 아래 세 가지 핵심 기능으로 해결합니다.
[사용자 인터페이스]
•
메인 페이지: KOPIS API 기반의 최신 인기 공연 정보를 비주얼 배너와 리스트로 제공합니다.
•
공연 상세 페이지: 공연 기간, 장소, 캐스팅 정보와 함께 카카오맵 API를 활용한 위치 정보를 표시합니다.
•
공연별 커뮤니티: 각 공연별로 독립된 게시판을 운영하여 실시간 현장 정보 공유와 동행 구인을 지원합니다.
•
마이페이지: 내가 작성한 후기와 관심 공연을 한곳에서 관리하며 서비스 내 성장 수치를 확인합니다.
[실시간 공연 데이터 큐레이션]
•
KOPIS API 연동을 통해 매일 수만 건의 공연 데이터를 자동 수집 및 가공
•
EventBridge와 Lambda를 사용해 매일 오전 8시, 8시 30분에 데이터 저장
•
OPENAI API를 통한 데이터 가공화(ex. 아티스트 명)
[알림 서비스]
•
자신이 작성한 글에 댓글이나 리액션이 달렸을 때 사용자에게 알림을 전달
•
알림 서비스의 부하가 메인 서버에 영향을 주지 않도록 AWS SQS 메시지 큐를 활용하여 비동기 구조로 설계
•
알림 데이터 특성에 맞게 NoSQL 타입의 DynamoDB 사용
아키텍처 및 핵심 기능
백엔드 아키텍처
•
모놀리식 아키텍처를 MSA 아키텍처로 리팩토링
•
각 서비스들에 대한 진입점은 Internal ALB로 한정
•
Auth 서비스는 AWS Lambda로 분리
•
인증 처리와 보호가 필요한 API를 구분해서 관리하기 위해 API Gateway를 사용했습니다.
DB 구성
•
비용/운영 복잡도를 고려하여 1개의 RDS내에 각 서비스가 사용하는 3개의 스키마로 분리
•
여러 곳에서 함께 사용하는 데이터나 자주 조회되는 데이터는 빠르게 꺼내 쓸 수 있도록 ElastiCache Redis를 사용
Outbox 패턴
•
서비스에서 어떤 작업이 발생하면, 그 결과를 바로 외부로 보내지 않고 먼저 데이터베이스(outbox 테이블)에 함께 저장합니다. 이후 별도의 워커가 이 데이터를 읽어서 이벤트를 비동기로 전달하는 방식
•
각 서비스가 발생한 이벤트를 각 스키마에 저장한 뒤 워커가 비동기 발행
CI/CD
•
CI(지속적 통합): 개발자가 코드를 커밋하면 GitHub Actions가 빌드 후 이미지를 Amazon ECR에 저장하고, Helm 차트 설정을 GitOps 저장소에 업데이트합니다.
•
CD(지속적 배포): Argo CD가 GitOps 저장소의 변경 사항을 감지하여, Helm을 통해 최신 상태의 애플리케이션을 Amazon EKS 클러스터에 자동으로 동기화(배포)합니다.
•
단일 진입점: 하나의 루트 앱이 여러 자식 앱을 관리하게 하여, 여러개의 리소스를 단일 진입점에서 제어 및 배포 자동화
•
계층적 관리: plaforms/ dev-application 역할 분리, 각 App이 하위 App들을 감시
무중단 배포 Blue-Green
•
autoPromotionEabled: false (Green 배포 완료상태)
◦
Blue 계속 운영 가능
◦
Green 테스트 가능
◦
문제가 없을 경우 전환
•
autoPromotionEabled: true (Blue → Green 전환 완료)
◦
events-svc 트래픽 전환
◦
Green 서비스 운영
◦
Blue 제거
로그 파이프라인 구축
•
수집: Fluent Bit DaemonSet으로모든 컨테이너 로그 파일 수집
•
가공: Namespace / Pod / container 메타데이터 매핑
•
저장 및 조회: Loki에 적재 및 Grafana에서 탐색/시각화
•
파이프라인 검증: Fluent Bit 자체의 정상 동작 확인
•
EKS 런타임 검증: Stagelog 서비스 로그 조회
모니터링 구축
•
인프라 가시성 확보: Node Exporter와 Kube-state-metrics를 연동하여, 클러스터 전체 리소스(CPU/Mem)부터 개별 Pod 단위의 세부 지표까지 실시간으로 시각화했습니다.
•
장애 대응 및 최적화: 네트워크 트래픽 추이와 리소스 할당량(Limit) 초과 상태를 한눈에 파악하여, 병목 구간 해소 및 인프라 비용 최적화의 근거로 활용 가능합니다.
•
kubecost: 클러스터 비용 가시화 및 최적화 포인트 식별
•
Alertmanager: Discord Webhook 연동 실시간 알림
Karpenter
•
지능형 프로비저닝
Pending 상태의 파드 요구사항을 기반으로 필요한 리소스를 실시간 분석하고, EC2 Fleet API를 통해 약 1분 내로 적절한 노드를 자동으로 프로비저닝하도록 구성했습니다.
•
비용 및 효율 최적화(Consolidation)
클러스터 내 유휴 자원을 지속적으로 탐지하고, 파드를 더 적합한 크기의 노드로 재배치하여 리소스 낭비를 줄이고 인프라 비용 효율을 개선했습니다.
•
부하 테스트(k6)
◦
부하수준: 1분 1000명(서서히 증가) → 3분동안 4000명까지 증가 → 2분 유지 → 1분동안 0으로 하락
◦
설정: HPA, Karpenter
•
Targets 수치가 130~150%을 기록하며 모든 Rollout의 Replicas를 최대치인 5개까지 스케일 아웃
•
HPA가 늘린 파드들을 수용할 수 있는 CPU 자원이 부족해지며, Karpenter가 신규 노드를 생성함
•
테스트 후(Consolidation)
•
Targets 수치가 다시 1%로 떨어지며 모든 Rollout의 Replicas를 최소치인 1개로 스케일 인
•
HPA에 의해 파드 수가 감소하면서 노드에 여유 CPU 자원이 발생하고, Karpenter가 불필요한 노드를 종료함
활용 라이브러리 및 개발 환경
구분 | 사용 기술 |
Frontend | React, TypeScript, Vite, Tailwind CSS, Context API, Axios |
Backend | Django, AWS Lambda (Auth) |
Database | MariaDB (RDS), AWS ElastiCache (Redis), DynamoDB (Notifications) |
Infrastructure | AWS (EKS, VPC, ALB, CloudFront, S3, SQS, EventBridge) |
DevOps | Terraform, Helm, GitHub Actions, ArgoCD, Docker |
Monitoring | Prometheus, Grafana, Loki, Fluent Bit (PLG Stack), Kubecost |
Load Test | k6 |
트러블 슈팅
Terraform을 활용한 인프라 계층화 설계 및 비용 최적화
•
문제 상황: 비용이 많이 들고 관리도 불편
EKS 클러스터나 NAT Gateway 같은 리소스는 사용하지 않을 때도 계속 비용이 발생해 전체적으로 비용 구조가 비효율적
•
해결 방안
인프라를 한 번에 관리하지 않고, 리소스의 수명 주기와 변경 빈도에 따라 4단계로 나누어 관리하는 구조를 도입
계층 | 명칭 | 설명 및 특징 |
Layer 0 | 설정 관리 (Bootstrap & Metadata) | SSM Parameter Store에 애플리케이션 설정값과 환경변수를 따로 저장해, 인프라를 삭제하더라도 중요한 설정값은 그대로 유지되도록 분리 |
Layer 1 | 영구 리소스 (Permanent) | VPC, S3, DNS처럼 데이터 유실 위험이 있고 항상 유지되어야 하는 리소스를 별도로 분리 |
Layer 2 | 운영 환경 (EKS & Platform) | EKS 클러스터, 노드 그룹, NAT Gateway처럼 비용이 큰 리소스를 이 계층에 배치 (필요하지 않을 때는 이 부분만 삭제하거나 축소해 전체 비용의 대부분을 절감) |
Layer 3 | 유동 리소스 (Ephemeral) | API Gateway와 VPC Link처럼 클러스터 상태에 따라 바뀌는 리소스를 분리 |
인증 서비스의 Lambda 분리
•
문제 상황: 인증 서비스가 외부 인증 API(OAuth 등) 통신 시 발생하는 NAT Gateway 데이터 처리 비용 누적
•
해결 방안
◦
인가(Authorization) 계층을 EKS 밖으로 완전 분리하여 AWS Lambda로 구축
◦
클러스터 진입 전 API Gateway + Lambda에서 인증을 처리하여 내부 트래픽 감소 및 NAT 비용 절감
◦
트래픽 폭증 시 즉각적인 람다 인스턴스 확장 가능
팀 소개
Project Leader / Frontend / Infrastructure
•
주요 역할: 프로젝트 리딩, 프론트엔드 개발, 클라우드 인프라 설계
•
상세 역할
◦
프론트엔드: React 기반 개발 및 Repository/브랜치 운영, Figma를 활용한 와이어프레임 및 실제 화면 구현, 사용자 플로우 설계
◦
인프라: VPC 및 EKS 설계, Karpenter를 활용한 클러스터 최적화
Backend / Infrastructure
•
주요 역할: 백엔드 API 설계 및 구현, 데이터베이스 분리
•
상세 역할
◦
백엔드: Django 기반 API 설계 및 구현, FE와 API 스펙 합의, 회원가입/로그인/마이페이지 E2E 담당, 예외 처리 및 테스트
◦
인프라: MSA 전환을 위한 백엔드 리팩토링, DB 논리 및 물리 분리 작업, AWS Lambda를 사용하여 API Gateway 수준에서 토큰을 검증하는 커스텀 인증 로직을 구현
Backend / Infrastructure / Monitoring
•
주요 역할: 백엔드 핵심 기능 개발, 메시징 시스템 설계
•
상세 역할
◦
백엔드: 게시글/댓글 CRUD 및 행사별 게시판 흐름 구현, 페이지네이션 및 쿼리 구조 담당
◦
인프라: SQS(Simple Queue Service) 설계 및 배포
◦
모니터링: 로그 파이프라인(Loki, Fluent Bit 등) 튜닝
DB / ETL / Monitoring
•
주요 역할: DB 아키텍처 설계, ETL 프로세스 구축, 통합 모니터링
•
상세 역할
◦
데이터/ETL: DB 테이블 및 관계 확정, 조회 성능(인덱스) 기준 설정, OpenAI API를 활용한 아티스트 활동명 추출 및 데이터 적재
◦
모니터링: 통합 모니터링 체계 구축 및 Kubecost를 이용한 비용 관리 체계 수립
DB / ETL / CI/CD
•
주요 역할: 데이터 동기화, 인프라 배포 자동화
•
상세 역할
◦
데이터/ETL: 외부 공연 데이터(KOPIS API) 정기 동기화 구현, 중복 제거 및 Upsert 담당
◦
CI/CD: GitHub Actions와 ArgoCD를 연동하여 코드 커밋부터 배포까지의 전 과정을 자동화, 파이널 단계에서 ArgoCD를 활용해 서비스 중단 없이 새 버전을 배포하는 환경을 구성