[기술 설계 명세서 Ver.1] 멀티 클라우드 기반 실시간 채팅 마이크로서비스
Part 1: 프로젝트 개요 및 아키텍처 원칙
1.1. 프로젝트 비전 및 목표
기존의 AWS 서버리스 기반 블로그 플랫폼을 보완하는 독립적인 실시간 채팅 마이크로서비스를 구축하는 것을 목표로 한다. 이 프로젝트는 단순한 기능 추가를 넘어, 다음과 같은 핵심 기술 역량을 확보하고 증명하기 위한 전략적 학습 프로젝트이다.
-
기술 목표:
- 컨테이너 오케스트레이션: Docker와 Kubernetes(k8s)를 사용하여 애플리케이션의 배포, 확장, 복구를 자동화한다.
- 멀티 클라우드 및 IaC: Terraform을 사용하여 AWS 외의 클라우드 플랫폼(Azure/GCP)에 인프라를 코드로 구축하고 관리한다.
- 고성능 백엔드: Go 언어를 사용하여 높은 동시성을 처리하는 실시간 통신 서버를 개발한다.
- 시스템 관측 가능성: Prometheus와 Grafana를 통해 시스템 메트릭을 수집하고 시각화하여 데이터 기반 운영 능력을 확보한다.
-
전략 목표:
- 역량 강화: 기존 "서버리스 아키텍처" 전문성에 더해, "컨테이너 오케스트레이션 아키텍처" 역량을 학습하여 기술 스펙트럼을 확장한다.
- 아키텍처 설계 능력 증명: 문제(실시간 통신)의 특성에 맞춰 최적의 기술 스택(Go, k8s)을 선택하고, 그 설계 의도를 명확히 설명할 수 있는 역량을 갖춘다.
1.2. 핵심 아키텍처 설계 원칙
- 마이크로서비스 아키텍처 (MSA): 채팅 서비스는 기존 블로그 서비스와 완벽하게 독립된(decoupled) 마이크로서비스로 구축된다. 두 서비스는 잘 정의된 API(URL 및
<iframe>)를 통해서만 통신한다. - 클라우드 네이티브 (Cloud-Native): 애플리케이션은 Docker 컨테이너로 패키징되고, 인프라는 Terraform으로 관리되며, Kubernetes를 통해 동적으로 운영된다.
- 느슨한 결합 (Loose Coupling): 블로그와 채팅 서비스의 연동은
<iframe>을 통해 이루어져, 기술적 독립성과 배포 자율성을 보장한다. - 점진적 개발: 로컬 개발(Phase 1) -> 클라우드 인프라 구축(Phase 2) -> 배포 자동화(Phase 3) -> 모니터링 및 고도화(Phase 4) 순서의 안정적인 로드맵을 따른다.
Part 2: 기술 스택 및 선택 이유
| 카테고리 | 선택 기술 | 선택 이유 (The "Why") |
|---|---|---|
| 백엔드 언어 | Go | 고루틴(Goroutine)을 통한 우수한 동시성 처리 성능으로, 수많은 WebSocket 연결을 적은 리소스로 관리하기에 최적. |
| 프론트엔드 | React (Vite) | 기존 기술 숙련도를 활용하여 개발 속도를 확보하고, 백엔드 신기술 학습에 집중. Vite는 가볍고 빠른 개발 경험 제공. |
| 실시간 통신 | WebSocket | HTTP 폴링/롱 폴링 대비, 매우 낮은 지연 시간과 높은 효율성으로 진정한 양방향 실시간 통신을 구현하기 위한 표준 기술. |
| 컨테이너 | Docker | 개발 환경과 운영 환경의 차이를 없애고, 어떤 클라우드 플랫폼에서든 동일하게 실행되는 표준화된 배포 단위를 만들기 위함. |
| 오케스트레이션 | Kubernetes (AKS/GKE) | 컨테이너의 자동 복구, 확장, 무중단 배포를 통해 고가용성 및 탄력성을 확보. 관리형 서비스를 통해 초기 학습 곡선 완화. |
| 클라우드 플랫폼 | Azure / GCP | AWS 외의 메이저 클라우드 플랫폼 경험을 통해 멀티 클라우드 관리 역량을 확보. |
| 인프라 (IaC) | Terraform | 클라우드 중립적인 업계 표준 IaC 도구. 단일 코드로 여러 클라우드의 리소스를 관리하는 멀티 클라우드 전략의 핵심. |
| 모니터링 | Prometheus & Grafana | 시스템 및 애플리케이션 메트릭을 직접 수집하고 시각화하여, 데이터 기반의 운영 및 문제 해결 능력을 내재화. |
| CI/CD | GitHub Actions + Argo CD | CI(빌드/테스트)와 CD(배포)의 책임을 분리하고, Git을 "신뢰할 수 있는 단일 진실 공급원"으로 사용하는 GitOps 배포 철학 구현. |
| 데이터베이스 | PostgreSQL (관리형) | 기존 NoSQL(DynamoDB) 경험에 더해, 관계형 데이터베이스(SQL)의 모델링 및 쿼리 역량을 확보하여 기술 스펙트럼 확장. |
Part 3: 총괄 로드맵 및 단계별 실행 계획
Phase 1: 로컬 환경에서 핵심 기능 완성 (Build the Core)
- 프로젝트 셋업: 신규 Git 저장소 및 pnpm workspace (
frontend/backend) 구성. - 백엔드 개발 (Go): 기본적인 WebSocket 서버 및 채팅방(Room) 로직 구현.
- 프론트엔드 개발 (React/Vite): WebSocket 통신을 하는 기본 채팅 UI 구현.
- 컨테이너화 (Docker):
Dockerfile및docker-compose.yml을 작성하여, 로컬에서 전체 시스템을 컨테이너로 실행.
Phase 2: 클라우드 인프라 골격 구축 (Build the Stage)
- 클라우드 설정: Azure/GCP 계정 준비 및 Terraform 인증 설정.
- IaC 작성 (Terraform): 네트워크, 컨테이너 레지스트리(ACR/GCR), 관리형 Kubernetes 클러스터(AKS/GKE), 관리형 PostgreSQL 데이터베이스 리소스를 코드로 정의.
- 인프라 배포:
terraform apply를 통해 클라우드에 실제 인프라 생성.
Phase 3: GitOps 기반 배포 자동화 (Automate the Show)
- CI 파이프라인 구축 (GitHub Actions):
git push시, 코드를 테스트하고 Docker 이미지를 빌드하여 컨테이너 레지스트리에 푸시하는 워크플로우 작성. - Kubernetes 배포 명세 작성:
Deployment,Service,Ingress,HPA등 k8s 리소스를 YAML 파일로 정의하여 Git에서 관리. - CD 파이프라인 구축 (Argo CD): k8s 클러스터에 Argo CD를 설치하고, Git 저장소의 YAML 파일 변경사항을 클러스터에 자동으로 동기화(배포)하도록 설정.
Phase 4: 관측 가능성 및 최종 통합 (Observe and Connect)
- 모니터링 스택 구축: Go 백엔드에
/metrics엔드포인트를 노출. k8s 클러스터에 Prometheus를 배포하여 메트릭을 수집하고, Grafana로 시각화 대시보드 구축. - 블로그 연동:
chat.jungyu.store서브도메인을 k8s Ingress에 연결. 기존 블로그 프로젝트의 게시물 상세 페이지에<iframe>을 사용하여 채팅 서비스를 임베드. - 기능 고도화: 백엔드와 PostgreSQL을 연동하여 대화 기록을 영구적으로 저장하고, 사용자 재방문 시 프로필(닉네임, 아바타)을 유지하는 기능 구현.
