Rand_Chat 프로젝트의 소프트웨어 아키텍처를 정의
인스턴스 현황
백엔드 - 회원서버: EC2 1대백엔드 - 매칭서버: EC2 2대백엔드 - 채팅 웹소켓 서버: EC2 2대백엔드 - 채팅 I/O 서버: EC2 2대프론트엔드 서버: EC2 1대NGINX 서버: EC2 1대RDS: 1대 (master+read_only)ElastiCache-redis: Single-Node 1대
부하에 따른 대비책
스케일아웃:- AWS EC2 인스턴스만 추가 시 빠른 스케일 아웃가능 ( 자동 배포 )
- ElastiCahce-redis 클러스터모드로 변경가능
RDS 마스터노드와읽기복제본을 나누어 라우팅함으로써 데이터베이스 부하 분산
스케일업: 스케일 아웃 제한 시 EC2 및 AWS 자원스케일 업 고려로드밸런싱: 라운드로빈 방식 로드밸런싱으로 부하를 분산 ( 채팅,매칭서버에 해당 )ElastiCache를 통해 캐싱을 적극 활용하여 I/O부하를 줄인다배포 프로세스에성능테스트를 추가한다.(2024-12-14 계획중)웹소켓 서버에서의 I/O 작업부하를 줄이기 위해I/O를 담당하는 인스턴스추가 및 서버간WebClient를 통한 통신
재난에 따른 대비책
서비스별 독립 배포: 하나의 인스턴스가 장애가 났을 시 다른 인스턴스 대체가능 및 다른 서비스에 영향이 가지않음RDS 장애 시읽기복제본 자동 승격- 인메모리에 지속적 장애 발생 시
ElastiCache를클러스터모드로 변경하여 고가용성 보장
보안 대비책
Nginx리버스 프록시를 통해 분산되는 자원에 대한 정보를 보호https / SSL적용 (certbot)jwt토큰을 통해 인증과 인가를 구현하고 , 이 외에도 특정 서비스에 특별한 인증이 필요하다면 커스텀 토큰을 발급하여 활용AWS 키값,properties값 노출 절대금지 (깃허브액션 secret변수 활용)- VPC , 보안그룹 활용
시스템 아키텍처
- 전략 및 흐름
Nginx인스턴스가 모든 요청을 받고Https 요청전환한다.엔드포인트에 따라 각 서비스별로라우팅(리버스 프록시)한다.매칭서버,채팅서버는부하분산을 위한라운드 로빈 방식의로드밸런싱을 한다.- 기본적으로 모든 인스턴스는
도커환경에서 실행된다.- 프론트엔드 인스턴스는
별도의 Nginx를 포함하고 있으며 ,빌드된 파일을 프론트엔드Nginx에서 반환한다.- 파일작업은
S3를 통해 이루어진다.관계형 데이터베이스 I/O 작업은 기본적으로마스터로 라우팅되며 ,읽기작업은Read-Only로 라우팅된다.캐싱데이터 관련 작업은 먼전ElastiCache를 찌르고 ,캐시 미스일경우에는관계형 데이터베이스에서반환후 캐싱을 한다.- 비즈니스로직 관점에서
응답개선을 위해특정로직은비동기로 RDB에 저장하는 방식이 포함된다.(EX : 채팅메시지 영구저장)- 백엔드 서버가
MSA 방식을 유지,웹소켓 서버의 부하부담을 줄이기 위해 WebClient를 통한 API통신을 한다.
📘 2025/07/15 첨언 — 쿠버네티스를 학습하며 느낀 점
쿠버네티스를 공부하면서, 과거 내가 설계했던 구조에 대해 다시 돌아보게 되었다.
• 여러 EC2 인스턴스에 동일한 서비스 컨테이너를 하나씩 띄우는 방식은 고가용성(HA) 측면에서는 유효한 설계였다.
서비스 장애를 EC2 단위로 격리할 수 있었기 때문이다.
• 하지만 오케스트레이션, 자동 복구, 트래픽 라우팅, 자원 효율성 같은 측면에서는 비효율적인 설계였다는 것을 알게 되었다. 실제로는 하나의 EC2에 여러 컨테이너를 밀도 있게 배치하는 편이 리소스 낭비를 줄일 수 있었다.
• 당시엔 쿠버네티스와 같은 컨테이너 오케스트레이션 도구가 없었고, 수동으로 EC2 + Docker + nginx 등을 구성했기 때문에 틀린 설계는 아니었지만, 확장성과 유지보수 관점에서 한계가 분명했다.
백엔드