본문으로 건너뛰기

시스템 아키텍처 상세

1. 핵심 설계 원칙​

  • 확장성 (Scalability)
    • 마이크로서비스 아키텍처 채택
    • 서비스별 독립적 스케일링
    • 멀티 AZ 구성으로 고가용성 확보
  • 신뢰성 (Reliability)
    • 무중단 배포 아키텍처
    • 자동 장애 복구
    • 데이터 지속성 보장
  • 실시간성 (Real-time)
    • 이벤트 기반 아키텍처
    • Redis Pub/Sub 기반 실시간 메시징
    • WebSocket 연결 풀링

2. AWS 서비스 구성​

2.1 컴퓨팅 서비스​

  • Amazon ECS (EC2 기반)
    • 클러스터 구성: ChatAppCluster
    • 인스턴스 타입: t3.small
    • 오토스케일링 구성 (min: 2, max: 4)
    • CPU 사용률 70% 기준 스케일링

2.2 컨테이너 관리​

  • Amazon ECR
    • chat-chat-http: API 서버 이미지
    • chat-chat-ws: 채팅 서버 이미지
    • chat-chat-notification: 알림 서버 이미지
    • 이미지 라이프사이클 관리 (최근 3개 유지)

2.3 데이터베이스​

  • Amazon DocumentDB
    • 엔진 버전: 5.0.0
    • 인스턴스 클래스: db.t3.medium
    • 스토리지 암호화 활성화
    • 자동 백업 구성
  • Amazon ElastiCache for Redis
    • 노드 타입: cache.t2.micro
    • 실시간 데이터 처리
    • Pub/Sub 메시징

2.4 스토리지 및 미디어 서비스​

  • Amazon S3
    • 채팅방 미디어 저장소
    • 접근 제어 정책 적용

2.5 네트워킹​

  • Amazon VPC
    • CIDR: 10.0.0.0/16
    • 가용영역: 2개
    • 퍼블릭 서브넷: 10.0.1.0/24, 10.0.2.0/24
    • 프라이빗 서브넷: 10.0.3.0/24, 10.0.4.0/24
    • NAT Gateway 구성
  • Application Load Balancer
    • HTTPS 리스너 (포트 443)
    • HTTP → HTTPS 리다이렉션
    • 호스트 기반 라우팅
    • SSL/TLS 인증서 통합
  • Route 53
    • DNS 호스팅 영역 관리
    • 서브도메인 구성:
      • api.streetcoder.club
      • chat.streetcoder.club
      • notification.streetcoder.club

2.5 보안 및 인증​

  • AWS Secrets Manager
    • MongoDB 접속 정보 관리
    • 자동 비밀번호 로테이션
    • URI 자동 구성
  • AWS Systems Manager Parameter Store
    • 알림 서버 설정 관리
    • 환경별 구성 값 저장
  • AWS Certificate Manager
    • SSL/TLS 인증서 관리
    • ALB HTTPS 리스너 연동

2.6 모니터링 및 로깅​

  • Amazon CloudWatch
    • ECS 서비스 로그 수집
    • 컨테이너 로그 관리 (보존기간 14일)
    • CPU 사용률 모니터링
    • 알람 설정

2.7 IAM 및 권한 관리​

  • IAM Role
    • ECS Task Execution Role
    • Lambda Execution Role
    • ECS Instance Role
    • 최소 권한 원칙 적용

3. 서비스 아키텍처​

3.1 Stateful 서버의 수평 확장 전략​

3.1.1 WebSocket 서버의 Stateful 특성​

  • 각 서버가 클라이언트와의 WebSocket 연결을 로컬 메모리에서 관리
  • 서버별로 독립적인 연결 상태 보유
  • 단순 수평 확장 시 메시지 전달 보장 불가

3.1.2 이벤트 기반 메시지 브로드캐스팅​

  • Redis Pub/Sub을 활용한 글로벌 이벤트 전파
    • 모든 WebSocket 서버가 Redis의 'globalEvents' 채널 구독
    • 메시지 발생 시 Redis를 통해 모든 서버에 전파
    • 각 서버는 로컬에 보유한 세션에만 메시지 전달
  • 세션 관리 최적화
    • RoomSessionManager: 채팅방별 WebSocket 세션 매핑 관리
    • UserSessionManager: 사용자별 WebSocket 세션 매핑 관리
    • 주기적인 세션 정리로 메모리 누수 방지

3.2 마이크로서비스 구성​

3.2.1 API Server (HTTP)​

  • 기능
    • HTTP API 엔드포인트 제공
    • 사용자 인증/인가
    • 채팅 관련 API 제공
  • 특징
    • Stateless 설계로 자유로운 수평 확장
    • JWT 기반 인증으로 세션 관리 부담 최소화

3.2.2 Chat Server (WebSocket)​

  • 기능
    • 실시간 양방향 통신
    • 클라이언트 WebSocket 연결 관리
    • 메시지 브로드캐스팅
  • 상태 관리
    • 로컬 세션 맵을 통한 효율적인 WebSocket 연결 관리
    • Redis Pub/Sub으로 채팅 서버 간 메시지 동기화
    • 채팅방별 구독자 관리
  • 확장성 확보
    • CPU 사용률 70% 기준 ECS 서비스 Auto Scaling (최소 2, 최대 4)
    • 서버 간 Redis Pub/Sub으로 메시지 동기화

3.2.3 Notification Server​

  • 기능
    • 비동기 이벤트 처리
    • FCM 푸시 알림 관리
    • 알림 이력 관리
  • 특징
    • Stateless 설계로 수평 확장 용이
    • Redis 구독을 통한 실시간 알림 처리

3.2.4 접속 상태 관리 Server​

  • 기능
    • 사용자 온/오프라인 상태 관리
    • 사용자 마지막 활동 시간 관리
  • 구현 방식
    • WebSocket 서버와 클라이언트 간 하트비트 이벤트 기반 상태 관리
    • WebSocket 서버가 HEART_BEAT 이벤트를 수신하면 접속 상태 관리 서버로 상태 업데이트
    • 접속 상태 관리 Server(Redis)의 Key-Value 구조를 활용한 상태 저장
    • 사용자별 독립적인 상태 관리
  • 데이터 저장 구조
    • 상태 정보: user:{userId}:status
      • Value: online | offline
      • TTL: 1분 (자동 만료)
    • 마지막 활동 시간: user:{userId}:last-active
      • Value: 타임스탬프(밀리초)
      • TTL: 없음 (이력 추적용)
  • 상태 관리 로직
    • 하트비트 수신 시마다:
      • 상태 정보를 online으로 설정 (1분 TTL)
      • 마지막 활동 시간을 현재 시간으로 갱신
    • 1분간 하트비트 미수신 시:
      • 상태 키 만료로 자동 오프라인 처리
    • 명시적 연결 종료 시:
      • 상태 키 즉시 삭제로 오프라인 처리

3.3 데이터 계층​

3.3.1 영구 저장소 (DocumentDB)​

  • 저장 데이터
    • 메시지 히스토리
    • 사용자 프로필
    • 채팅방 메타데이터
  • 특징
    • 샤딩을 통한 수평 확장성
    • 유연한 스키마로 빠른 기능 변경 대응

3.3.2 캐시 계층 (Redis)​

  • 역할
    • 실시간 메시지 브로드캐스팅 (Pub/Sub)
    • 사용자 온라인 상태 관리
    • 채팅방 포커싱 상태 관리
  • 데이터 구조
    • Pub/Sub 채널: globalEvents
    • Sorted Set: 사용자 마지막 활동 시간
    • Set: 채팅방별 현재 시청자 목록

3.4 확장성 및 성능​

3.4.1 수평 확장 지원​

  • 무상태 서비스
    • API 서버
    • 알림 서버
  • 상태 유지 서비스
    • 채팅 서버 (Redis Pub/Sub으로 상태 동기화)

3.4.2 성능 최적화​

  • 연결 관리
    • WebSocket 연결 풀링
    • 효율적인 메모리 사용
  • 메시지 라우팅
    • 채팅방 기반 메시지 필터링
    • 불필요한 메시지 전파 방지

4. 메시지 처리 아키텍처

4.1 실시간 메시지 전송 흐름​

  1. 메시지 생성 및 이벤트 발행 (HTTP API 서버)
    • 클라이언트가 HTTP API 서버로 메시지 생성 요청합니다.
  • UUID V6 형식의 메시지 ID 생성하여 채팅 메시지에 부여합니다.
  • 채팅 메시지를 DocumentDB에 저장합니다.
    • Redis Pub/Sub을 통해 두 개의 이벤트를 발행
    • MESSAGE_CREATED: global 채널에 이벤트 생성 이벤트를 발행합니다. 모든 채팅 서버들이 구독하는 채널입니다.
    • FCM_TOKEN_MESSAGE: 알림 서버가 구독합니다.
  1. 실시간 메시지 전달 (채팅 서버)
    • 채팅 서버는 redis pub/sub의 globalEvents 채널을 구독합니다.
    • 모든 채팅 서버가 MESSAGE_CREATED 이벤트 수신합니다.
    • 이벤트에 포함된 roomId를 키로 사용하여 로컬 세션 맵에서 해당 채팅방의 WebSocket 세션들을 조회합니다.
      • 채팅 서버는 각 채팅방별로 연결된 WebSocket 세션들을 관리하고 있습니다.
    • 조회된 세션들에게 메시지를 전달 (실제 전달이 발생하는 채팅 서버는 해당 roomId의 세션을 보유한 서버들뿐)
  2. 알림 처리 (알림 서버)
    • 알림 서버가 FCM_TOKEN_MESSAGE 이벤트 수신합니다.
    • 오프라인 사용자에게 푸시 알림을 발송합니다.

4.2 메시지 읽음 처리 흐름​

  1. 메시지 생성 시 읽음 상태 초기화
    • HTTP API 서버에서 메시지 생성 시 현재 채팅방을 보고 있는 시청자(viewer) 목록 조회
    • 전체 채팅방 멤버에서 현재 시청자와 발신자를 제외한 사용자들을 미읽음 사용자로 설정
    • 초기 미읽음 상태와 함께 메시지 저장
  2. 읽음 상태 처리
    • 사용자가 채팅방에서 메시지를 읽으면 클라이언트가 HTTP API 서버로 mark as read API 호출
    • API 서버는 해당 사용자의 읽음 처리를 DocumentDB에 업데이트
    • API 서버는 READ_RECEIPT_UPDATED 이벤트를 Redis Pub/Sub으로 발행
    • 모든 채팅 서버가 이벤트를 수신하여 해당 채팅방의 연결된 세션들에게 전파하여 읽음 상태 업데이트
  3. 채팅방 포커스 관리
    • 사용자가 채팅방에 입장하면 클라이언트가 채팅 서버로 ROOM_FOCUSED 이벤트 전송
    • 채팅 서버는 해당 사용자를 채팅방 시청자(viewer) 목록에 추가
    • 이 시청자 정보는 이후 새로운 메시지 생성 시 초기 읽음 상태 계산에 활용
    • 사용자가 채팅방을 나가면 ROOM_UNFOCUSED 이벤트 전송하여 시청자 목록에서 제거

4.3 서버별 역할​

  1. HTTP API 서버
    • 메시지 저장과 이벤트 발행
    • 읽음 상태 관리
    • 영구 데이터 처리
  2. 채팅 서버
    • WebSocket 세션 관리
    • 실시간 메시지 라우팅
    • 사용자 상태 관리
      • 하트비트를 통한 사용자 온/오프라인 상태 관리
      • 사용자가 채팅방에 포커스를 맞추었는지 여부 관리
  3. 알림 서버
    • FCM 토큰 관리
    • 푸시 알림 발송

5. 보안 아키텍처​

5.1 네트워크 보안​

  • 보안 그룹 구성
    • ALB 보안 그룹: 80/443 포트 공개
    • ECS 보안 그룹: ALB로부터의 트래픽만 허용
    • DB 보안 그룹: 애플리케이션 서버로부터의 트래픽만 허용

5.2 데이터 보안​

  • 저장 데이터 암호화 (DocumentDB)
  • 전송 중 데이터 암호화 (TLS)
  • 보안 인증 정보 중앙화 관리

6. 기술적 차별점​

6.1 고성능 메시징 시스템​

  • 최적화된 메시지 전달
    • 메시지 브로드캐스팅 최적화
    • 효율적인 연결 풀링
    • 지능적인 메시지 라우팅

6.2 강력한 데이터 일관성​

  • 분산 시스템 동기화
    • 실시간 상태 동기화
    • 멱등성 보장
    • 이벤트 소싱 패턴 적용

6.3 인프라 자동화​

  • Infrastructure as Code
    • CloudFormation 기반 리소스 관리
    • 환경 복제 용이성
    • 버전 관리 및 롤백 지원

7. 성능 최적화​

7.1 네트워크 최적화​

  • 효율적인 트래픽 라우팅
    • 지역 기반 DNS 라우팅
    • 로드밸런서 레이턴시 최소화
    • 연결 재사용
  • 연결 풀링
    • WebSocket 연결 풀 관리
    • 데이터베이스 커넥션 풀링
    • 리소스 사용 최적화

7.2 데이터 최적화​

  • 캐시 계층화
    • 다중 레벨 캐싱 전략
    • 캐시 무효화 정책
    • 프리페칭 최적화
  • 데이터 접근 패턴
    • 효율적인 인덱싱
    • 쿼리 최적화
    • 데이터 압축

8. 모니터링 및 운영​

8.1 성능 모니터링​

  • 실시간 메트릭 수집
    • 서비스별 성능 지표
    • 리소스 사용률
    • 에러 레이트
  • 사용자 경험 모니터링
    • 메시지 전송 지연시간
    • WebSocket 연결 상태
    • API 응답시간

8.2 장애 대응​

  • 자동화된 복구 프로세스
    • 서비스 헬스체크
    • 자동 장애 복구
    • 백업 및 복원
  • 장애 격리
    • 서비스별 독립적 운영
    • 장애 전파 방지
    • 단계적 복구

9. 향후 개선 계획​

  • 성능 개선
    • ElastiCache 클러스터 확장
    • 메시지 처리 최적화
    • 캐싱 전략 개선
  • 인프라 개선
    • 글로벌 확장을 위한 CDN 도입
    • 서비스 메시 아키텍처 검토
    • 컨테이너 오케스트레이션 고도화
  • 모니터링 강화
    • APM 도구 도입
    • 상세 로그 분석
    • 알림 체계 개선