1. 시작점: 왜 코드로 인프라를 관리하는가AWS 콘솔에서 VPC를 클릭으로 만들면 어떤 일이 벌어지는가:문제 1: "이 VPC 누가 만들었어? 설정이 왜 이래?" → 추적 불가문제 2: "dev 환경이랑 똑같이 prod 만들어줘" → 수동 반복, 실수 발생문제 3: "3개월 전 상태로 롤백해줘" → 불가능문제 4: "인프라 변경 사항 코드리뷰 해줘" → 리뷰할 코드가 없음문제 5: "이 인프라 전부 삭제해줘" → 뭘 만들었는지 기억 못함이 5가지 문제를 해결하는 것이 IaC (Infrastructure as Code) — 인프라를 코드로 선언하고,Git으로 버전 관리하고, 자동으로 생성/변경/삭제하는 방식이다. CG..
1. CI/CD란 무엇인가정의CI = Continuous Integration (지속적 통합) → 개발자가 코드를 push할 때마다 자동으로 빌드 + 테스트CD = Continuous Delivery (지속적 전달) → CI를 통과한 코드를 언제든 배포 가능한 상태로 유지 → 배포 자체는 사람이 버튼을 누름 (수동 승인)CD = Continuous Deployment (지속적 배포) → CI를 통과하면 자동으로 프로덕션까지 배포 → 사람 개입 없음 (완전 자동화)Continuous Delivery와 Continuous Deployment는 같은 약자(CD)를 쓰지만 의미가 다르다:구분Continuous DeliveryContinuous Deployment배포 시점수동 ..
1. 시작점: 우리가 쓰는 것CGV 대기열 시스템의 실시간 통계 전달 구조 (→ websocket 8절 참고):QueueProcessor (Leader Pod, 2초마다) │ ├─ Redis ZCARD × 2 → totalWaiting, totalActive │ └─ Redis PUBLISH "queue:notifications" ← Redis Pub/Sub (Pod 간 전파) │ ├─ Pod 1: MessageListener → SimpleBroker → Pod 1의 브라우저들 ├─ Pod 2: MessageListener → SimpleBroker → Pod 2의 브라우저들 └─ Pod 3: MessageListener → SimpleBroker →..
도입2에서 Redis + Kinesis 기반 대기열 시스템의 구현과 부하 테스트를 분석했다. 10만 동시 접속을 처리하기 위해 Sorted Set으로 실시간 순위를 관리하고, Kinesis로 비동기 이벤트를 처리했다. 그런데 이 코드를 어떻게 배포하는가? 개발자가 코드를 수정할 때마다 수동으로 Docker 이미지를 빌드하고, ECR에 푸시하고, kubectl apply를 실행해야 하는가?티켓팅 오픈 30분 전에 긴급 버그 수정이 필요하면 어떻게 하는가? CGV 프로젝트에서 CI/CD 파이프라인 구축은 팀원이 담당했다. 나는 구축된 파이프라인을 받아서 사용하고, Helm Chart의 values.yaml을 수정하여 배포하는 역할이었다. 이번 섹션에서는 팀원이 구축한 CI/CD 구조를 분석하고, 잘 구현된 ..
CGV 대기열 시스템: 대량 트래픽 백엔드 분석도입2.1에서 CGV 개발계 인프라를 Terraform으로 구축했다. VPC, Subnet, VPC Endpoint, Client VPN까지 네트워크 기반을 완성했다.이번 섹션에서는 그 인프라 위에서 동작하는 비즈니스 로직을 분석한다. CGV 프로젝트의 목표는 "인터파크 티켓팅처럼 순간적으로 트래픽이 폭증하는 상황"을 처리하는 것이다. 영화 개봉일에 수만 명이 동시에 예매 버튼을 누르면, 서버가 버티면서도 순번을 공정하게 배정해야 한다.담당 범위는 Spring Boot 백엔드 개발이다. 대기열 시스템, Kinesis 연동, WebSocket 로직이 dev_backend 레포지토리에 있다. 코드 스택은 Java 17 + Spring Boot 3.3.13이다.1..
도입팀 프로젝트 CGV에서 개발계 인프라 일부를 Terraform으로 담당했다. 어떤 역할을 맡았고 각 리소스를 어떻게 설계했는지 정리한다.이번 섹션에서는 CGV 개발계 인프라의 Terraform 코드를 파일별로 분석한다. VPC-Subnet.tf부터 routing.tf, sg.tf, endpoints.tf, client_vpn.tf까지 모든 코드를 검토하고, 각 리소스의 설계 의도와 트러블슈팅 과정을 다룬다.1. CGV 개발계 Terraform 담당 범위내가 Terraform으로 맡은 개발계 인프라의 범위는 다음과 같다.항목CGV 개발계Terraform 범위개발계 일부 (VPC, SG, Endpoints)EKS 생성eksctl (YAML 기반)State 관리단일 디렉토리VPC EndpointECR 4개..
DB 복제 구조 1. M-S (Master - Slave)구조: Master 1개, Slave 1개역할Master: 쓰기 전용Slave: 읽기 전용 (Master 데이터를 복제해서 사용)특징: 구조가 단순하고 명확하지만, 읽기 부하 분산이 어려움2. M-MS (Master - Multi Slave)구조: Master 1개, Slave 여러 개역할Master: 쓰기 전용여러 Slave: 읽기 전용특징: 읽기 부하 분산이 가능하여, 읽기 요청이 많은 시스템에 적합3. MM-S (Multi Master - Slave)구조: Master 여러 개, 각 Master에 따라 연결된 Slave 존재역할Master: 각각 쓰기 가능Slave: 각자의 Master에서 복제된 데이터 읽기특징: 쓰기 확장성 ↑단, 충돌 관..
What is CloudNative 확장성하나의 숫자로 표시될 수 있는 것 → Metric쿠버네티스는 Metric 기반 리소스 운영→ 쿠버네티스는 CPU, 메모리, 사용자 정의 메트릭 등을 기반으로 오토스케일링을 수행회복성선언적(Declarative) 정의!!→ 사용자가 “원하는 상태(state)”를 정의하면, 쿠버네티스가 실제 상태를 자동으로 그에 맞춤→ Pod가 죽으면 자동으로 재시작되거나 교체됨관리 편의성컨테이너? 변경관리 최소화(immutable system) → 아무리 변경을 해도 원래대로 돌아감(가장 중요한 포인트!!!) → 모든 장애의 99%는 변경으로 발생자동화쿠버네티스는 API가 굉장히 잘 지원됨자동화는 API로 이루어진다!!! → kubectl, client-go, controller,..
Docker 이미지와 Layer 개념과의 연관성Dockerfile은 각 명령마다 **Layer(층)**를 쌓아 이미지 생성각 Layer는 **해시(SHA256)**로 식별됨 → 변경 감지→ 캐시 최적화, 중복 방지, 무결성 보장 가능-> Layer와 Volume은 다르지만 공통으로 "불변성과 재사용" 개념을 가짐Volume은 Layer에 저장하지 못하는, 변경되는 데이터를 위한 공간 구조 요약Image Layer읽기 전용 (read-only)Container Layer쓰기 가능하지만 컨테이너 종료 시 삭제됨✅ Volume (외부)컨테이너 외부 저장소. 종료되어도 유지됨 도커 이미지의 Layer의 해시 값의 의미?(매우 중요!!!)→ Docker 레이어의 해시는 “해당 명령어 결과물의 고유한 식별자”..