☁️ Cloud & Infrastructure Architecture

[작성 규칙]

1. Why & Trade-off: 모든 기술적 의사결정에는 [주장 - 논리 - 근거]가 포함되어야 합니다.
2. Context: "우리 서비스의 트래픽/특성상 왜 이것이 최선인가"를 기록합니다.
3. History: 아키텍처가 변화하는 과정을 단계별로 기록하여, 서비스 성장에 따른 인프라 확장 능력을 보입니다.

1. 단계별 설계 문서 (Assignment Details)

과제 요구사항에 맞춰 작성된 상세 설계 문서들입니다. (제목 클릭 시 상세 페이지로 이동)

📄 [Step 1] Big Bang 방식 수작업 배포 설계

• 상황: 초기 개발 단계, 배포 자동화 부재
• Pain Point: 배포 시 5분 다운타임 발생, 사람이 직접 명령어 입력하다 실수 발생 가능성 높음
• Why Manual?: 초기 인프라 구조 단순화 및 빠른 개발 환경 세팅을 위함

📄 [Step 2] CI(지속적 통합) 파이프라인 구축 설계

• 도입 배경: 협업 인원 증가로 인한 코드 충돌 및 빌드 실패 빈번, 코드 품질 저하 우려
• 해결 방안: GitHub Actions 도입, PR 시 자동 빌드/테스트 강제화

📄 [Step 3] CD(지속적 배포) 파이프라인 구축 설계

• 도입 배경: 잦은 배포 요구사항, 수동 배포 피로도 증가, 휴먼 에러 방지
• 배포 전략: Rolling Update (또는 Blue/Green)
• 기대 효과: 버튼 클릭 한 번으로 배포 완료, 문제 발생 시 즉시 롤백 가능

📄 [Step 4] Docker 컨테이너화 배포

• 도입 배경: 환경 불일치로 이슈가 반복되고, 서버 수동 세팅이 많아 배포 실수/피로도가 큼.
• 배포 전략: 애플리케이션을 컨테이너 이미지로 표준화해 ECR에 저장하고, 각 환경에서 실행
• 기대 효과: 배포가 더 일관적/빠르고, 확장/롤백이 쉬워짐.

📄 [Step 5] Kubeadm 오케스트레이션 설계

• 도입 배경:
• 배포 전략:
• 기대 효과:

2. 인프라 개요 (Overview)

항목	내용	비고
Cloud Provider	AWS (Amazon Web Services)
Region / Zone	ap-northeast-2 (Seoul)	Zone a, c 사용
Domain	devths.com	Route53 관리
Server OS	Ubuntu 22.04 LTS
Infra 담당자	david.lee(이도연), henry.myeong(명혜성)

3. 기술 스택 및 선정 이유 (Tech Stack & Trade-offs)

분류	기술 스택	선정 이유 (Why)	대안 비교 및 한계 (Trade-off)
Compute	AWS EC2	트래픽 예측이 어렵고, 세밀한 서버 설정이 필요하여 선택	vs Lambda: Cold Start 문제와 실행 시간제한으로 배제vs ECS: 초기 설정 복잡도 오버헤드를 줄이기 위해 EC2 우선 도입
Database	MySQL 8.0	관계형 데이터 구조가 명확하고 트랜잭션 관리가 중요함	vs MongoDB: 정형화된 데이터라 NoSQL보다 RDBMS가 데이터 무결성 보장에 유리
CI/CD	GitHub Actions	코드 저장소와 통합이 용이하고 별도 서버 구축 비용 없음	vs Jenkins: 별도 마스터 노드 관리 비용 및 학습 곡선이 높아 배제
Storage	AWS S3	정적 파일(이미지)의 높은 내구성과 저렴한 보관 비용	vs EBS: 웹 서버 다중화 시 파일 공유가 어렵고 용량 확장이 번거로움

📄 기술 스택 선정 근거 더보기

4. 인프라 아키텍처 (Architecture Diagram)

4.1. 현재 아키텍처 (Current Architecture)

[Version 1.0] 현재 운영 중인 최종 아키텍처 구성도입니다.

• 주요 특징:
  • Public Subnet에 Bastion Host 배치
  • Private Subnet에 WAS 및 DB 배치로 보안 강화
  • ...

4.2. 아키텍처 변천사 (History)

서비스 확장과 과제 진행 단계에 따라 아키텍처가 어떻게 발전했는지 기록합니다.

📄[Step 1] V1 스프린트 진행상황: 단일 EC2, 프로세스 기반, Nginx, S3+Code Deploy 기반 배포

📄[Step 2] V2 스프린트 진행상황: 다중 인스턴스, Docker, ALB 도입

📄[Step 3] V3 스프린트 진행상황: 쿠버네티스 적용

5. 현재 배포 파이프라인 (CI/CD Pipeline)

5.1. 프로세스 흐름도

5.2. 파이프라인 상세 명세

단계	Trigger 조건	수행 작업 (Jobs)	산출물 (Artifact)	비고
CI (통합)	dev 브랜치 Push	1. Java 21 Setup2. Gradle Build3. Unit Test 실행	Docker Image (Tag: dev-${sha})	실패 시 Discord 알림
CD (배포)	main 브랜치 Merge	1. AWS Credentials 설정2. S3 업로드 (CodeDeploy)3. Deploy Trigger	서비스 배포 완료	무중단 배포 적용

📄[Step 1] V1 CICD: S3+Code Deploy 기반 배포

📄[Step 2] V2 CICD: ECR+Code Deploy 기반 배포

📄[Step 3] V3 CICD: Helm+ArgoCD 기반 배포

6. 보안 및 네트워크 전략 (Security & Network)

과제 요구사항에 맞춰 작성된 상세 설계 문서들입니다. (제목 클릭 시 상세 페이지로 이동)

📄 인프라 접근 제어 방식

📄 최소 권한 원칙 기반 IAM 설계 문서

7. 장애대응 및 부하테스트, 모니터링 (Monitoring & LoadTest)

모니터링 및 장애에 대해서 작성된 문서들입니다.

📄[공통]SLI/SLO 문서

• 요약: 서비스 진화(V1~V3)에 따른 단계별 SLI/SLO 지표 설정 및 변경 이력입니다.

📄[Step 1] V1 모니터링: 단일 EC2, CloudWatch 기반 배포

• 요약: 단일 인스턴스 환경에서 AWS CloudWatch를 활용한 기초 모니터링 구축 과정을 다룹니다.

📄[Step 2] V2 모니터링: 다중 인스턴스, 중앙 집중식 모니터링 도입

• 요약: Prometheus와 Grafana를 도입하여 분산된 서버의 지표를 통합 관리하는 과정을 설명합니다.

📄[Step 3] V3 모니터링: 쿠버네티스 적용

• 요약: K8s 클러스터 환경에 최적화된 모니터링 체계와 컨테이너 기반 메트릭 수집 방법을 다룹니다.

8. 마이그레이션

📄V1 DB 마이그레이션: AWS DMS 활용한 마이그레이션

• 요약: EC2에 있는 DB를 RDS로 AWS DMS를 활용하여 마이그레이션을 진행

** DB 무중단 마이그레이션(Henry)**

• 요약: PostgreSQL의 logical replica 기능을 이용한 무중단 마이그레이션 진행

9. 트러블슈팅 (Troubleshooting Log)

인프라/배포 관련 장애 발생 및 해결 기록

트러블 슈팅 보러가기