배경(Problem)
공연 티켓팅 서비스의 안정성과 운영 효율성을 높이기 위한 백오피스 시스템 개발 프로젝트입니다.
티켓팅 서비스는 오픈 시점에 트래픽이 폭발적으로 집중됩니다. "이런 상황에서 안정적인 서비스를 제공하려면 어떤 기술이 필요할까?" 라는 질문에서 출발했습니다. 단순히 동작하는 서비스가 아니라, 실제 운영 환경을 고려한 클라우드 네이티브 아키텍처를 설계하고 문제를 직접 경험하며 해결하고자 했습니다.
목표
•
대규모 트래픽을 처리하는 확장 가능한 아키텍처 설계
•
운영 효율화를 위한 백오피스 어드민 대시보드 개발
•
MSA 전환과 운영 자동화를 통한 DevOps 경험
•
보안, 권한 관리, 재해복구까지 고려한 실전 수준의 시스템 구축
주요 성과
•
트래픽 대응: Auto Scaling과 대기열 기반 부하 분산으로 트래픽 급증 처리
•
아키텍처 전환: 모놀리틱에서 MSA로 전환, 독립적 배포와 스케일링 구현
•
인프라 자동화: Terraform, ArgoCD를 활용한 IaC/GitOps 파이프라인 구축
•
재해복구: 멀티 리전 DR 체계로 서비스 복원력 확보
프로젝트 소개(Solution)
클라우드 퍼포먼스 최적화: 핵심 기능 구현 및 운영 편의성 확보
1.
클라이언트 페이지 및 핵심 예매 워크플로 구현
•
예매 워크플로: 좌석 선택부터 예매 완료까지의 전체 워크플로 구현
•
사용자 관리: 공연 탐색·검색 기능 및 예매 조회·취소 구현
2.
대규모 트래픽 대응 시스템
•
실시간 상태 관리: Redis를 활용한 대기열 토큰 상태 및 활성 사용자 수 실시간 관리
•
동시성 제어: 동시 좌석 선택 시 결제 우선순위 기반 좌석 배정으로 데이터 무결성 확보
3.
관리자 대시보드 및 운영 자동화
•
관리자 대시보드: 유저, 공연, 예매 목록의 직관적인 조회 및 관리 기능 구현
•
RBAC 기반 권한 제어: 개발자, DevOps, 운영팀 등 역할별 대시보드 접근 권한 구분
•
운영 자동화: Lambda + API Gateway 연동으로 어드민 대시보드에서 서버 증설 및 정책 변경 실행 (AWS 콘솔 의존도 감소)
4.
비용 최적화
•
VPC Origin 활용: CloudFront와 VPC Origin 직접 연결로 ALB 없이 아키텍처 단순화 및 비용 절감
•
NAT Instance 도입: NAT Gateway 대비 약 91% 인프라 비용 절감
자동 오류 감지와 트랜잭션 무결성 클라우드 엔지니어링: MSA 전환 및 보안 강화
1.
MSA 아키텍처 전환
•
모놀리틱 구조를 Core, Admin, Queue 서비스로 분리
•
Admin Service는 AWS Lambda 기반 서버리스로 독립 운영
2.
보안 강화
•
인증/인가 공통화: 분산된 인증/인가 로직을 Authorization Spring Starter 패턴으로 통합하여 관리 효율성 향상
•
XSS 공격 방어: LocalStorage → HttpOnly 쿠키 기반 인증으로 전환하여 JavaScript 접근 차단
3.
데이터 무결성 및 동시성 제어
•
Redis 기반 동시 접속 제한, FIFO 대기열, Heartbeat 세션 감시 구현
•
데이터 일관성 99.8%, 대기열 순서 보장률 95.2% 달성
4.
서버리스 최적화
•
AWS SnapStart 적용으로 Lambda Cold Start 12초 → 4~5초 단축
IaaS 클라우드 운영 자동화: Kubernetes 아키텍처 비교 및 DevOps 고도화
1.
Kubernetes 아키텍처 비교
구분 | AWS EKS (관리형) | Kubespray (Self-managed) |
운영 용이성 | 높음 (컨트롤 플레인 AWS 관리) | 낮음 (마스터/워커, CNI 직접 관리) |
클라우드 통합 | ECR 인증, ALB Controller 자동 연동 | Node providerID, ECR Credential 수동 구성 필요 |
적합 환경 | 빠른 확장이 필요한 클라우드 환경 | 온프레미스, 보안/규제가 강한 환경 |
기술적 성과 | DR 체계 및 GitOps 파이프라인 구축 | 네트워크·인증 문제 직접 해결로 심층 역량 확보 |
•
결론: 두 아키텍처 비교를 통해 요구 조건에 따른 인프라 선택 기준 도출
2.
IaC 및 GitOps 구축
•
Infrastructure as Code
◦
Terraform으로 VPC, EKS, RDS, ElastiCache 등 전체 인프라 코드화
◦
S3 Backend + Lockfile 활용으로 DynamoDB 없이 안전한 팀 협업 체계 구축
•
GitOps 기반 CI/CD
◦
ArgoCD + Image Updater 연동
◦
ECR 이미지 푸시 → Git 태그 자동 업데이트 → K8s 자동 배포 파이프라인 구축
3.
DevSecOps 구현
•
Falco: 커널 레벨 시스템 콜 모니터링으로 비정상 행위 실시간 탐지
•
Calico Network Policy: Pod 간 트래픽 세밀 제어 및 Zero Trust 원칙 적용
4.
멀티 리전 재해복구(DR) 자동화
•
Ansible 기반 Seoul 
Tokyo 양방향 Failover/Failback을 make dr-failover 단일 명령으로 실행
Tokyo 양방향 Failover/Failback을 make dr-failover 단일 명령으로 실행•
Private Hosted Zone으로 DB/Redis 엔드포인트 추상화 → DR 전환 시 Pod 재시작 불필요
•
Velero + S3 CRR로 K8s 리소스 복제, ECR Replication으로 이미지 동기화
•
목표 복구 시간(RTO) 10~15분 달성(RDS 제외)
5.
비용 및 성능 최적화
•
Turborepo 도입으로 프론트엔드 빌드 시간 125초 → 12초 (약 90% 단축)
•
GitHub Actions vs GoCD Self-hosted 비용 역전 지점(월 5,000분) 분석 → 조직 규모별 CI/CD 도구 선택 기준 제시
시연 영상
클라이언트 페이지
1. 좌석 예매 및 취소
2. 대기열
3. 예매 조회/취소
관리자 페이지
1.
전체 기능
2.
유저 대시보드
3.
공연 대시보드
아키텍처 및 핵심 기능
시스템 구조
•
본 시스템은 초기 모놀리식 구조에서 시작하여 3단계에 걸친 고도화를 거쳐 MSA 구조로 전환
•
3차 프로젝트에서는 동일한 MSA 애플리케이션을 두 가지 서로 다른 인프라 아키텍처 위에 배포하여 비교 분석
◦
Kubespray 클러스터팀: EC2 기반 Self-managed Kubernetes 구축
◦
EKS 클러스터팀: AWS 관리형 Kubernetes 구축
Kubespray
EKS
핵심 컴포넌트
•
Core Service (module-api)
◦
핵심 비즈니스 로직(공연, 예매, 사용자 관리) 및 영속 데이터 관리
◦
Spring Boot, PostgreSQL, Redis 사용
•
Queue Service (module-queue)
◦
대규모 트래픽 폭주 시 대기열 관리 및 예약 권한 통제
◦
Spring Boot, Redis(FIFO, 동시성 제어) 사용
•
Admin Service
◦
관리자 대시보드 백오피스 기능 제공
◦
자체 DB 없이 Core Service 데이터 조회
◦
AWS Lambda(Serverless), API Gateway, OpenFeign 사용
•
Frontend Applications
◦
Client(예매 워크플로), Admin(관리자 대시보드), Accounts(로그인 및 인증 처리) 앱으로 구성
◦
React, TypeScript, Feature-Sliced Design 사용
•
Data Layer
◦
PostgreSQL(영속 데이터), ElastiCache Redis(캐시, 세션, 큐)
◦
RDS, ElastiCache 사용
데이터 흐름
사용자 인증 흐름
•
사용자는 accounts.ddcn41.com에서 로그인 요청을 AWS Cognito로 전송
•
로그인 성공 시 서버는 HttpOnly 쿠키를 발급
•
쿠키는 Domain=.ddcn41.com 설정으로 모든 서브도메인에서 자동 공유
•
클라이언트 앱은 이 쿠키를 통해 Core Service 및 Admin Service에 인증된 API 요청
대기열 및 예매 흐름
•
클라이언트 앱에서 예매 요청 발생 시 Queue Service로 라우팅
•
Queue Service는 Redis를 사용하여 대기열 토큰 발급 및 활성 사용자 수 실시간 카운팅
•
대기열을 통과한 사용자만 Core Service의 예매 API에 접근
•
좌석 선택 및 결제 트랜잭션 수행, 결제 우선순위 기반 동시성 제어 로직 적용
관리자 운영 흐름
•
관리자가 admin.ddcn41.com에서 공연 목록 요청
•
Admin Service(Lambda)로 라우팅, OpenFeign을 사용하여 Core Service REST API 호출
•
Core Service는 PostgreSQL에서 데이터 조회 후 응답
•
서버 증설 및 정책 변경은 어드민 대시보드에서 Lambda 및 API Gateway 연동하여 실행
전체 서비스 흐름
•
사용자 → CloudFront/ALB → Kubernetes Ingress → Service → Pod → RDS/ElastiCache(Private Subnet)
핵심 기능 (1차, 2차 공통)
대규모 트래픽 대응 아키텍처 (1차)
•
트래픽 급증 시 Auto Scaling과 대기열 기반 부하 분산 구조 설계
•
무중단 예매 서비스 보장
대기열 시스템 및 동시성 제어 (1차)
•
Redis 기반 대기열 토큰을 통해 예약 권한 관리
•
동시 좌석 선택 시 결제 우선순위 기반 좌석 소유권 확보 로직 구현
운영 효율화를 위한 UI 기반 제어 (1차)
•
AWS 콘솔 의존도를 낮추기 위해 Lambda 및 API Gateway 연동
•
관리자 대시보드에서 UI 클릭만으로 서버 증설/정책 변경 명령 실행
MSA 아키텍처 전환 (2차)
•
목표: 모놀리식 백엔드 애플리케이션을 Kubernetes 도입 준비를 위한 MSA로 전환
•
순차적으로 결합도가 가장 낮은 서비스 2개를 우선 분리하여 멀티 모듈 구조로 전환
•
이후 OpenFeign 기반 모듈 간 통신을 도입하여 완전한 분리 진행
공통 인가 로직을 Spring Boot Starter로 분리 (2차)
•
목표: MSA 도입으로 인한 인가 로직 Cross-cutting concern 처리
•
Custom Spring Boot Starter + AutoConfiguration 도입
◦
implementation project(':authorization-spring-boot-starter')
◦
application.yml 프로퍼티
•
위 두 가지만 설정하면 인가 필터/빈이 자동으로 스프링 컨텍스트에 올라가도록 변경
•
MSA 추가 분리 시 로그인 관련 작업 불필요, 개발 속도 20% 향상
보안 강화 및 통합 인증 (2차)
•
XSS 방어를 위해 로컬 스토리지 대신 HttpOnly 쿠키 기반 인증 도입
•
AWS Cognito를 활용하여 인증 관리 통합
데이터 무결성 강화 (2차)
•
Redis 기반 FIFO 대기열 보장 및 Heartbeat 기반 세션 유효성 감시
•
동시성 경쟁 문제 해결, 데이터 일관성 99.8%로 향상
핵심 기능 (3차 - Kubespray)
K3d 기반 로컬 개발 환경 구성
•
목표: 로컬에서의 Kubernetes 테스트 및 개발 환경 세팅
•
클라우드 이전에 로컬에서 애플리케이션 이미지 및 네트워크 테스트 진행
•
GitOps 플로우 및 Kubernetes 리소스 동작을 쉽고 빠르게 검증
Backend CI/CD 자동화: GitOps
•
목표: 애플리케이션 개발자는 인프라를 최소한으로 신경 쓸 수 있도록 변경
•
개발 흐름: GitHub push → GitHub Actions 빌드 → ECR push → GitOps 저장소 반영 → ArgoCD 자동 배포
•
Image Updater가 ECR을 주기적으로 스캔하여 새 태그 발견 시 Manifest 자동 수정
IaC 기반 인프라 구축 (Terraform)
•
목표: AWS 인프라를 Terraform 코드로 관리하여 재현 가능하고 버전 관리가 가능한 인프라 구축
•
모듈 구조: vpc, security-groups, iam, ec2, database, secrets_manager
•
주요 특징: S3 Backend State 공유, Terraform 1.10 S3 state locking, NAT Instance Flag 파일 기반 의존성 관리
Kubernetes 클러스터 자동 배포 (Kubespray)
•
Ansible 기반 Kubespray로 Self-managed Kubernetes 클러스터 자동 배포
•
클러스터 구성: Master 1개 + Worker 2개(t3.medium), Calico CNI, containerd 런타임
•
네트워크: Pod CIDR 10.233.64.0/18, Service CIDR 10.233.0.0/18, VPC CIDR 10.0.0.0/16
AWS 서비스 통합
•
AWS Load Balancer Controller: Ingress → ALB 자동 프로비저닝 (Target Type: instance)
•
External DNS: Route53 DNS 레코드 자동 생성/삭제
•
External Secrets Operator: AWS Secrets Manager → K8s Secret 자동 동기화
•
Kubelet Credential Provider: ECR Private Registry 자동 인증, 12시간 토큰 갱신
다층 보안 아키텍처 (DevSecOps)
•
Falco: 커널 레벨 시스템 콜 모니터링(eBPF), 민감 파일 접근/권한 상승/쉘 실행 탐지
•
Network Policy: Zero Trust 원칙(기본 거부, 명시적 허용), Pod 간 트래픽 제어
•
Security Groups: ALB, Bastion, K8s Master/Worker, Calico, RDS/ElastiCache 포트별 접근 제어
백업 및 재해 복구 (Velero)
•
매일 자정 자동 백업, S3 저장, 7일 보관
•
복구: velero restore create --from-backup <backup-name> 실행으로 모든 리소스 재생성
Frontend CI/CD (GitHub Actions → S3)
•
pnpm monorepo 3개 앱(Client, Admin, Accounts) 자동 빌드 및 S3 배포
•
GitHub OIDC 기반 AWS 인증, CloudFront 자동 배포, HTTPS 강제
핵심 기능 (3차 - EKS 클러스터팀)
IaC 기반 인프라 구축 및 최적화
•
Terraform을 활용하여 AWS 인프라 전체를 코드로 정의하고 프로비저닝
•
VPC 네트워크 인프라 자동화, EKS Worker Node/RDS/Redis는 Private Subnet 배치
•
Managed Node Group으로 워커 노드 관리, OIDC Provider 설정으로 IRSA 구현 기반 마련
•
t3.medium 인스턴스에서 Pod Replica 수 최소화, CPU/Memory Request/Limit 값 조정으로 Pending/OOMKilled 방지
•
Nginx Ingress Controller 레벨에서 CORS 헤더 일괄 적용으로 관리 포인트 단일화
GitOps 기반 CI/CD 파이프라인
•
GitHub Actions: Spring Boot 애플리케이션 빌드, AWS ECR 이미지 푸시
•
Helm Chart Git 레포지토리 values.yaml에 새 이미지 태그 자동 커밋(write-back)
•
ArgoCD: Git 저장소 변경 감지 → 클러스터 자동 동기화 → 애플리케이션 배포
CI/CD 파이프라인 벤치마크 (GoCD vs GitHub Actions)
•
GitHub Organization 무료 사용량(월 3,000분) 초과 시 전략적 선택 기준 마련
•
GoCD Self-hosted 환경과 GitHub Actions 유료 플랜 비교 분석
•
Turborepo 도입으로 빌드 시간 125초 → 12초 (약 90% 단축)
•
월 빌드 시간 5,000분 초과 시 비용 역전 지점(손익분기점) 도출
멀티 리전 재해복구(DR) 자동화
•
서울(ap-northeast-2) → 도쿄(ap-northeast-1) 고가용성 DR 체계 구축
•
목표 RTO 10~15분 달성
•
Private Hosted Zone(PHZ) 기반 DNS 추상화로 애플리케이션 설정 변경 없이 DR 전환
•
Velero + S3 CRR로 Kubernetes 리소스 백업/복제
•
ECR Cross-Region Replication으로 컨테이너 이미지 실시간 동기화
•
Ansible Playbook으로 DR 전환 자동화, 단일 명령어(make dr-failover)로 전체 Failover 실행
관찰성(Observability) 확보
•
kube-prometheus-stack으로 Prometheus(메트릭 수집) + Grafana(시각화) 통합 배포
•
ServiceMonitor CRD 정의, Spring Boot Actuator 엔드포인트 스크랩
•
JVM Heap, CPU 사용량 등 핵심 지표 Grafana 대시보드 시각화
활용 라이브러리 및 개발 환경
서비스
[Frontend] React 18 + TypeScript
•
관리자 대시보드와 클라이언트 예매 워크플로 구현
•
타입 안정성 확보 및 대규모 서비스 확장 가능한 구조 설계
[Frontend] UI/Tooling
•
Figma Make를 스캐폴딩 도구로 활용해 개발 시간 단축
•
shadcn/ui와 Tailwind CSS로 일관된 디자인 시스템 적용
[Frontend] 아키텍처 & 빌드
•
Feature-Sliced Design(FSD) 도입으로 기능 단위 코드 구조 전환
•
pnpm workspace + Turborepo로 빌드 시간 90% 단축 (125초 → 12초)
[Backend] Spring Boot 3.x (Java 21)
•
순간적으로 대규모 트래픽이 몰리는 티켓팅 서비스에 적합한 고성능 프레임워크
[Backend] 데이터 계층
•
PostgreSQL 15: 영구 데이터 저장소
•
Redis 7: 캐싱, 세션 관리, 대기열 토큰 상태 관리, 활성 사용자 수 실시간 카운팅
[Backend] MSA 통신 & 인증
•
Spring Cloud OpenFeign으로 서비스 간 선언적 REST API 통신 구현
•
AWS Cognito 인증 위임 및 커스텀 Authorization Spring Starter 모듈 개발
배포 환경
[Infra] AWS 클라우드
•
VPC, EKS, RDS, Lambda, S3, CloudFront, Cognito, Route53, ECR 등 8개 이상 서비스 통합 활용
•
NAT Instance 사용으로 NAT Gateway 대비 약 91% 비용 절감
•
CloudFront + VPC Origin 직접 연결로 ALB 비용 절약
[IaC] Terraform
•
VPC, EKS/Kubespray, RDS 등 AWS 인프라 전체를 코드로 정의
•
모듈 기반 구조로 재사용성과 유지보수성 확보
•
Terraform 1.10 Lockfile 기능으로 DynamoDB 없이 안전한 팀 협업 체계 구축
[Container] Kubernetes
•
AWS EKS(관리형)와 Kubespray(Self-managed) 독립 구현 및 비교 분석
•
AWS 통합 문제(providerID, ECR 인증) 직접 해결
[자동화] Ansible
•
Kubespray 노드 구성 관리 및 멀티 리전 재해복구(DR) 자동화
•
DR Failover 프로세스를 단일 명령어(make dr-failover)로 실행
•
RTO 목표 10~15분 달성 지원
[GitOps] ArgoCD
•
ArgoCD Image Updater 연동으로 완전 자동화된 배포 체계 구축
•
ECR 이미지 푸시 → Image Updater 감지 → GitOps 저장소 자동 커밋 → K8s 클러스터 배포
[보안] Falco + Calico
•
커널 레벨 시스템 콜 모니터링으로 비정상 행위 실시간 탐지
•
Network Policy로 Pod 간 통신 제어, Zero Trust 원칙 구현
[DR] 재해복구 기반 기술
•
Route53 Private Hosted Zone(PHZ)으로 엔드포인트 추상화
•
Velero로 K8s 백업 및 복원 체계 구축
•
S3 Cross-Region Replication으로 리소스 복제
[CI/CD] GitHub Actions
•
프론트엔드/백엔드 빌드, 테스트, ECR Push CI 파이프라인 구축
•
OIDC 기반 인증으로 AWS Access Key 하드코딩 없이 보안성 강화
[모니터링] Prometheus + Grafana
•
kube-prometheus-stack으로 클러스터 및 애플리케이션 성능 실시간 관찰
•
Spring Boot Actuator 메트릭 수집 및 분석
[품질/테스트]
•
SonarQube/SonarCloud로 코드 품질 관리
•
JUnit 6(유닛), Spock(통합) 테스트
[협업/문서화]
•
GitHub Issue → Jira 단방향 동기화 워크플로우 구축
•
GitBook으로 기술 문서 자동 동기화
트러블 슈팅
MSA 도입으로 인한 인가 관련 Cross-cutting concern 발생
문제 상황
•
이전 구조에서는 각 서비스가 공통 인터페이스를 구현하면서 비슷한 코드를 세 번씩 복붙하는 형태라, 작은 수정이 서비스마다 다르게 반영되거나, 누락·오타 같은 버그가 섞이기 쉬운 구조
•
각 서비스가 개별 SecurityConfig를 가질 경우, 어느 서비스는 최신 방식, 어느 서비스는 구버전 방식이 섞이는 버전 드리프트가 발생하기 쉬움.
해결 방법
•
인가 로직을 Starter 모듈로 완전히 분리하고, JwtSecurityConfiguration에서만 필터 체인, 토큰 파서, 블랙리스트 체크 등을 구성하도록 단일 진입점을 만들었음.
•
실제 서비스 코드에서는 더 이상 Security 관련 빈을 직접 등록하지 않고, 컨트롤러에서 @AuthenticationPrincipal로 유저 객체만 받도록 인터페이스를 단순화함.
•
아래와 같은 해결 방법은 후보군에서 제외하였음
◦
service mesh / API gateway 제외
▪
네트워크 레벨이 아니라 애플리케이션 레벨의 인가가 필요
▪
주로 트래픽/보안/관측 같은 네트워크 레벨 Cross-cutting concern에 유리
◦
common 라이브러리 구조 제외 사유
▪
각 서비스가 SecurityConfig를 만들고, 필터나 빈을 직접 등록해야 함
▪
같은 패턴을 세 군데에서 반복하다보니 설정 편차·복붙 버그 가능성이 큼.
결론
•
Spring Boot Starter 방식을 도입함으로써 인가 로직의 단일 소스(Single Source of Truth)를 확보
•
새로운 마이크로서비스 추가 시 implementation project(':authorization-spring-boot-starter')와 application.yml 프로퍼티 두 가지만 설정하면 인가 필터/빈이 자동으로 스프링 컨텍스트에 올라감
•
보안 설정 누락이나 버전 드리프트 위험이 원천 차단됨
•
MSA 추가 분리 시 로그인 관련 작업을 추가로 진행할 필요가 없어 개발 속도 20% 향상 달성
•
향후 인가 정책 변경 시에도 Starter 모듈 한 곳만 수정하면 모든 서비스에 일괄 적용되어 유지보수성이 크게 개선됨
Terraform 의존성 관리 문제
문제 상황
•
Private Subnet에 배치된 EC2 인스턴스(Kubernetes Nodes)가 초기화 과정에서 외부 패키지 저장소에 접근하지 못해 user_data 스크립트 실행이 실패
•
Terraform의 depends_on은 리소스의 생성 완료만 기다릴 뿐, 리소스가 실제로 준비되었는지는 확인하지 않음
•
NAT Instance의 EC2는 생성되었지만, user_data가 아직 실행 중이어서 NAT 기능이 활성화되지 않은 상태에서 Private EC2가 생성을 시도
해결 과제
•
리소스 생성 완료와 실제 준비 완료 사이의 간극을 해소할 수 있는 방법 필요
•
NAT Instance가 완전히 기능할 때까지 Private EC2 생성을 지연시키는 방법 구현
해결 방법
•
NAT Instance의 user_data 스크립트 마지막에 준비 완료 Flag 파일 생성 (touch /tmp/nat-instance-setup-complete)
•
terraform_data 리소스와 remote-exec provisioner를 사용하여 Flag 파일이 생성될 때까지 대기
•
Private EC2는 이 terraform_data에 depends_on 설정
결론
•
리소스 생성 완료 ≠ 리소스 준비 완료
•
인프라 의존성은 기능 활성화 순서까지 고려해야 함
•
Flag 파일, Health Check 등 명시적인 준비 신호가 중요
Calico CNI 네트워크 통신 장애
문제 상황
•
Kubernetes 클러스터 구축 후 모든 Pod 간 통신이 불가능했고, DNS 해석도 실패 (NXDOMAIN 에러)
•
Calico CNI는 Worker Node 간 Pod 통신을 위해 특정 프로토콜과 포트를 사용하는데, Security Group에서 이를 차단하고 있었음
•
Calico CNI 필수 포트:
◦
TCP 179: BGP (네트워크 경로 정보 교환)
◦
UDP 4789: VXLAN (Pod 간 데이터 전송의 핵심)
◦
Protocol 4: IP-in-IP 캡슐화
•
CoreDNS도 Pod이므로 접근할 수 없어 DNS 해석이 불가능
해결 과제
•
Calico CNI가 정상 동작하기 위한 네트워크 요구사항 파악
•
Security Group 설정에서 CNI 통신에 필요한 포트 및 프로토콜 허용
해결 방법
•
Calico 공식 문서에서 네트워크 요구사항 확인
•
Security Group에 Calico 필수 포트 추가 (Master Worker 양방향)
Worker 양방향)•
kubectl get pods -A 명령으로 모든 Pod Running 확인
•
Pod 간 ping 테스트 및 DNS 해석 검증
결론
•
Overlay Network는 물리 네트워크를 통해 캡슐화되어 통신
•
Security Group은 Underlay 레벨에서 동작하므로 CNI 프로토콜 허용 필수
•
표면적 증상(DNS 실패)이 아닌 근본 원인(네트워크 차단) 찾기 중요
AWS Load Balancer Controller Target 등록 실패
문제 상황
•
Ingress 리소스를 생성해도 ALB의 Target Group이 비어있고, AWS Load Balancer Controller 로그에서 unable to resolve targets: no provider ID found for node 에러 발생
•
원인 분석:
◦
providerID 누락: Self-managed Kubernetes는 Node의 spec.providerID가 자동 설정되지 않음 (EKS는 자동)
◦
VPC/Subnet 태그 누락: ALB Controller가 어느 서브넷에 ALB를 배치할지 판단 불가
◦
EC2 태그 누락: Worker Node가 클러스터에 속한다는 표시 없음
해결 과제
•
Self-managed Kubernetes 환경에서 AWS Load Balancer Controller가 정상 동작하기 위한 필수 설정 항목 파악
•
EKS에서 자동으로 처리되는 설정들을 수동으로 구성
해결 방법
•
각 Node에 providerID 추가
•
Terraform으로 필수 태그 추가:
◦
VPC/Subnet: kubernetes.io/cluster/클러스터명 = shared
◦
Public Subnet: kubernetes.io/role/elb = 1
◦
Private Subnet: kubernetes.io/role/internal-elb = 1
◦
Worker Node: kubernetes.io/cluster/클러스터명 = owned
•
ALB Controller 재시작 후 Target Group 정상 등록 확인
결론
•
EKS와 Self-managed Kubernetes의 차이점 명확히 이해 필요
•
AWS는 태그 기반으로 리소스를 식별하고 관리
•
수동 설정은 자동화(Ansible/Terraform) 필수
AWS Load Balancer Controller Target Type "ip" 사용 불가 문제
문제 상황
•
Ingress에서 target-type: ip 설정 시 ALB의 Target Group이 비어있고 트래픽이 Pod에 도달하지 않음
•
Calico CNI는 Overlay Network를 사용하므로 Pod IP(10.233.64.0/18)는 VPC 라우팅 테이블에 존재하지 않음
•
ALB는 VPC 네트워크 레벨에서 동작하므로 Pod IP에 직접 접근할 수 없음
•
CNI별 차이:
◦
AWS VPC CNI: Pod IP를 VPC CIDR에서 할당 → ALB 직접 접근 가능 (IP 타겟 지원)
◦
Calico/Flannel: Overlay Network → ALB 직접 접근 불가 (Instance 타겟만 가능)
해결 과제
•
Calico CNI의 Overlay Network 환경에서 ALB가 Pod로 트래픽을 전달할 수 있는 대안 방식 탐색
•
VPC 네트워크와 Overlay Network 간의 통신 경로 설계
해결 방법
•
Target Type을 "instance"로 변경
•
Security Group에서 NodePort 범위(30000-32767) 허용
•
동작 흐름: ALB → Worker Node:NodePort → kube-proxy → Pod
결론
•
CNI 선택이 AWS 서비스 통합에 영향
•
Overlay Network는 유연하지만 AWS 통합에 제약
•
NodePort 방식도 충분히 활용 가능
ECR Private 이미지 Pull 실패 (401 Unauthorized)
문제 상황
•
Pod가 ECR의 Private 이미지를 Pull하지 못하고 "401 Unauthorized" 에러 발생
•
시도했으나 실패한 방법들:
◦
imagePullSecrets: ECR 토큰 12시간마다 만료 → 수동 갱신 필요 (운영 부담)
◦
Docker Credential Helper: Kubernetes 1.24부터 containerd 사용으로 Docker config 무시됨
해결 과제
•
ECR 토큰 만료 문제를 자동으로 해결할 수 있는 인증 방식 구현
•
containerd 런타임 환경에서 동작하는 ECR 인증 방식 적용
해결 방법
•
Kubelet Credential Provider 플러그인을 설치하고 구성
•
해결 단계:
◦
GitHub cloud-provider-aws Repo Clone
◦
Go가 설치되어 있지 않은 경우 빌드를 위해 설치
◦
ECR Credential Provider 바이너리 빌드 (make ecr-credential-provider-linux-amd64)
◦
바이너리를 /usr/bin/ecr-credential-provider로 이동
◦
Kubelet Credential Provider 설정 파일 생성 (/etc/kubernetes/kubelet-credential-provider-config.yaml)
◦
Kubelet 설정에 Credential Provider 바이너리, 설정 파일 경로 지정
◦
Kubelet 재시작
•
동작 원리: Pod 생성 → Kubelet → Credential Provider → EC2 IAM Role → AWS STS (12시간 토큰) → ECR 인증 → 이미지 Pull
결론
•
Container Runtime 변화(Docker → containerd)로 인증 메커니즘 변경
•
Kubelet Credential Provider가 권장 방식
•
IAM Role 기반 인증으로 credentials 하드코딩 불필요
CORS 문제와 아키텍처 선택
팀 소개
•
EKS 기반 Architecture 설계 및 구축
•
Terraform & Ansible을 활용한 인프라 IaC 구현 및 프로비저닝 자동화
•
GitOps 기반 CI/CD 파이프라인 구축 및 배포 자동화
•
PostgreSQL/Redis기반 데이터베이스 설계
•
Redis 기반 토큰 대기열 Queue 시스템 구현
•
Prometheus/Grafana 모니터링 시스템 구축
•
JWT 인증과 대기열 검증
•
Queue Service MSA 분리
•
백엔드 동시성 성능 검증
프로젝트 리뷰
프로젝트를 마무리하며 돌아보면, 기술적 지식보다 기술적 의사결정이라는 가치를 배웠습니다.
아키텍처 설계에 절대적인 정답은 없었습니다. Aurora와 RDS의 선택, Multi-AZ 구성 여부, ALB와 Nginx Ingress 사이의 고민 등 Trade-off가 존재했습니다. 중요한 것은 각 기술의 장단점을 명확히 파악하고, 현재 프로젝트 상황과 제약 조건 안에서 가장 합리적인 근거를 찾아내는 과정임을 깨달았습니다.
또한, 협업의 가치를 다시 한번 확인했습니다. 혼자였다면 더 빠르게 개발했을지 모르지만, 팀원들과 끊임없이 구조를 논의하고 코드 리뷰를 거치며 설계는 훨씬 더 견고해졌습니다. 서로의 코드를 통해 재사용성과 유지보수성을 고민하며 함께 성장할 수 있었습니다.
이번 프로젝트를 통해 저는 단순히 클라우드 도구를 사용할 줄 아는 사람에서, 제약 조건 속에서 최적의 판단을 내리고 그 기술적 근거를 명확히 설명할 수 있는 엔지니어로 성장했습니다.
•
Terraform 활용 EKS Cluster 구성 IaC 작성
•
Ansible 자동화 활용 신속한 장애복구
•
Frontend CI/CD 빌드 최적화
•
GoCD와 GitHub Action 벤치마크 비교
•
좌석 선택·예매, ASG 대시보드 및 클라우드 초기 세팅
•
프론트엔드 취약점 분석
•
프론트엔드 FSD 구조 전환
프로젝트 리뷰
세 차례에 걸친 프로젝트를 진행하면서 웹 애플리케이션 전반에 대한 이해도를 높일 수 있었습니다. 도메인을 분리하고 쿠키 기반 인증 방식을 도입했으며, 프론트엔드에서 쿠키 인증 상태에 따라 라우팅을 설정하는 과정에서 기존 서비스들의 쿠키 발급 방식을 분석하며 웹 서비스 전반에 대한 이해를 넓힐 수 있었습니다.
AWS 클라우드 환경에서 Route 53, CloudFront, API Gateway, EC2, ELB 등 다양한 관리형 서비스를 활용하고, 웹 배포를 위한 설정을 적용하는 과정을 통해 아키텍처를 구성하는 각 요소와 이들 간의 연결 방식, 그리고 보안 정책 설정에 대한 클라우드 네이티브 역량을 쌓을 수 있었습니다.
•
K8s On-premise Architecture 작성
•
Backend GitOps CI/CD
•
K3d 기반 테스트 환경
•
백엔드 초기 세팅 (공연 탐색·검색, 도메인/보안 API)
•
GitBook CI/CD, ECR 배포 자동화
•
백엔드 아키텍처, VPC Origin 구현
•
Core Service MSA 분리
•
Authorization Starter 패턴 공통 적용
•
Core & Queue 백엔드 코드 리팩토링 및 테스트 코드 작성
프로젝트 리뷰
총 3번에 걸쳐 프로젝트를 발전시켜나가면서, 어플리케이션 및 인프라의 설계, 구축, 운영, 자동화, 그리고 복구까지 전반적인 클라우드 네이티브 시스템의 흐름을 경험하며 성장할 수 있었던 과정이었습니다. 그 과정에서 팀원들과 요구사항에 따라 어떤 인프라가 더 적합한지 토의를 하며, 스스로 판단할 수 있는 기준을 세울 수 있게 된 것이 가장 큰 자산이라고 생각합니다. 모든 툴이 환경과 목적에 따라 최적의 사용처가 있다고 다시 한 번 느꼈습니다.
•
K8s On-premise Architecture 작성
•
Terraform & Ansible 작업
•
Velero 복구 자동화
•
런타임 및 어플리케이션 보안 강화
•
Role base 관리자 대시보드 API & UI
•
감사 로그, S3 연동, FE 자동 배포
•
클라우드 배포 관리
•
Admin Service MSA 분리
•
Admin Service 서버리스 전환
•
Admin & Core 백엔드 코드 리팩토링 및 테스트 코드 작성
프로젝트 리뷰
3차에 걸친 프로젝트를 진행하면서 단계별로 결과물이 발전하는 과정을 경험할 수 있어 좋았습니다.
가장 큰 배움은 삽질을 통해서만 얻을 수 있는 경험이었습니다. 수많은 시행착오를 겪으며 문제 해결 능력이 크게 향상되었습니다. 공식 문서를 읽고 로그를 분석하며 근본 원인을 찾아가는 과정이 가장 값진 성장이었습니다.
기술 선택에 있어서도 중요한 교훈을 얻었습니다. 최신 기술이나 유명한 기술을 무조건 따라가기보다는, 상황에 맞는 기술을 선택하는 것이 더 중요하다는 것을 깨달았습니다. 강사님이 말씀해주셨던 모든 상황에서 최적의 결과를 내는 만능 기술스택은 없다는 말씀이 다시 한 번 떠오르네요.
협업에서는 원활한 의사소통과 유연한 태도가 중요했습니다. 팀원들과 의견을 조율하고, 제한된 시간 안에서 우선순위를 정해 집중하는 능력이 필요했습니다.
무엇보다 좋은 팀원들과 함께할 수 있어 감사했습니다. 프론트엔드, 백엔드부터 인프라, 보안, CI/CD까지 애플리케이션 개발과 운영의 전 과정을 경험한 이번 프로젝트는 실무에서 유연하게 대응할 수 있는 기반이 될 것이라 생각합니다.