SubwayChat - 부산 지하철 이용객을 위한 실시간 채팅 및 정보 공유 서비스

프로젝트 멤버

이름	담당 파트
이한홍	게시판 API 개발, 도커를 사용해서 클라우드에 배포 및 HA 구성 담당. 그리고 제안서 및 중간 보고서 작성.
박준형	Redis 를 사용한 채팅 API 개발. 그리고 최종 보고서 작성.
김민종	Thymeleaf 를 사용한 화면 개발 담당. 그리고 PPT 와 시연 영상 제작.

프로젝트 소개

SubwayChat은 부산 지하철 각 호선별로 마련된 익명 채팅방을 통해 정보 공유와 일상 대화를 즐길 수 있는 서비스입니다. 사용자는 익명성을 보장받으며 채팅방에 참여할 수 있고, 지역 커뮤니티 활동을 위한 게시판을 통해 맛집 홍보와 추천 같은 활동도 할 수 있습니다.

(배포 주소: http://20.39.188.176:8080)

관련 기술

(1) 웹소켓

웹소켓(WebSocket)은 웹 브라우저와 서버 간에 양방향 통신을 가능하게 하는 기술입니다. 기존의 HTTP 통신 방식이 클라이언트가 서버에 요청을 보내고 서버가 응답하는 요청-응답 패러다임에 기반을 둔 것과 달리, 웹소켓은 한 번의 연결 설정 후 지속적이고 실시간의 데이터 교환을 할 수 있습니다. 이러한 특성 때문에 웹소켓은 채팅 애플리케이션, 금융 거래 플랫폼, 실시간 게임, 실시간 알림 서비스 등 실시간 상호작용을 요구하는 다양한 웹 애플리케이션에 널리 사용됩니다.

웹소켓의 주요 특징

양방향 통신: 클라이언트와 서버가 연결된 세션 동안 양쪽 모두에서 데이터를 동시에 보내고 받을 수 있습니다.
실시간성: 웹소켓을 통해 서버와 클라이언트 간의 통신이 실시간으로 이루어집니다.
전이중 통신(Full-Duplex): 웹소켓 연결은 전이중이므로, 데이터는 두 방향으로 동시에 움직일 수 있습니다.
오버헤드 감소: 웹소켓은 연결을 맺은 후 추가적인 헤더 없이 데이터를 교환할 수 있어, 기존 HTTP 통신에 비해 통신 오버헤드를 상당히 줄일 수 있습니다.

(2) STOMP

STOMP (Simple/Streaming Text Oriented Messaging Protocol)는 간단한 텍스트 기반의 메시징 프로토콜로, 스프링 프레임워크에서 웹소켓을 통한 메시지 브로커를 쉽게 구현할 수 있도록 지원합니다. STOMP는 클라이언트와 서버 간의 메시지 교환을 위해 설계된 프로토콜로, 자바스크립트, Python, Ruby 등 다양한 언어에서 사용 가능합니다. 이 프로토콜은 웹소켓을 통한 양방향 통신 기능을 활용하여 실시간 웹 애플리케이션을 구현하는 데 유용합니다.

STOMP는 다음과 같은 방식으로 메시지를 교환합니다:

구독 (Subscribe): 클라이언트는 특정 대상(destination)을 구독하여, 해당 대상으로부터 메시지를 수신합니다.
발행 (Publish): 서버나 다른 클라이언트가 구독된 대상에 메시지를 발행할 수 있습니다.

스프링에서 STOMP를 사용하면 다음과 같은 다양한 메시지 브로커를 쉽게 통합할 수 있습니다:

RabbitMQ
ActiveMQ
Redis

(3) Redis

Redis (Remote Dictionary Server)는 고성능의 키-값(key-value) 저장소로, 데이터를 메모리에 저장함으로써 빠른 데이터 접근 속도를 제공합니다. 오픈 소스이며, 네트워크를 통해 접근 가능한 인-메모리 데이터 구조 서버로도 사용됩니다. Redis는 단순한 키-값 저장소를 넘어서 다양한 데이터 구조를 지원하는 것이 특징입니다. 이러한 데이터 구조에는 문자열(Strings), 리스트(Lists), 맵(Maps, Hashes), 집합(Sets), 정렬된 집합(Sorted Sets) 등이 포함됩니다.

(3-1) 캐싱

데이터베이스 쿼리 결과, 세션 정보 등 자주 접근하는 데이터를 캐시하여 애플리케이션의 응답 속도를 향상시킬 수 있습니다.
저희 프로젝트에선 채팅방의 메시지를 캐싱했습니다.

(3-2) Redis의 인메모리 특성과 데이터 지속성

Redis가 모든 데이터를 RAM에 저장하기 때문에, 전원이 꺼지거나 시스템이 예기치 않게 다운되었을 때, 메모리의 데이터는 손실됩니다. 이는 데이터의 영속성에 큰 리스크를 만듭니다. Redis는 이를 완화하기 위해 다음과 같은 데이터 지속성 옵션을 제공합니다:

RDB (Redis Database Backup): 정해진 간격으로 메모리의 스냅샷을 디스크에 저장합니다. 이 방법은 성능에 큰 영향을 주지 않고 백업할 수 있는 이점이 있지만, 마지막 백업 이후의 데이터는 여전히 손실될 위험이 있습니다.
AOF (Append Only File): 모든 쓰기 연산을 디스크에 로그로 기록합니다. Redis 서버가 다시 시작될 때, 이 로그 파일을 읽어 데이터를 복원합니다. AOF는 데이터 손실의 위험을 최소화하지만, 파일 크기가 커질 수 있고 성능 저하가 발생할 수 있습니다.

(3-3) Redis Sentinel과 고가용성

Redis Sentinel은 Redis 서버의 고가용성을 보장하기 위해 설계된 시스템입니다. Sentinel 시스템은 다음과 같은 주요 역할을 수행합니다:

장애 감지
자동 장애 복구
시스템 모니터링

- Master Node: 현재 활성화되어 있는 메인 Redis 서버입니다. 모든 데이터 쓰기 작업과 주요 읽기 작업을 처리합니다.

- Slave Nodes: Master Node의 데이터를 복제받아서 보관하는 백업 서버들입니다. 주로 읽기 요청을 분산 처리하고, Master Node에 장애가 발생했을 때 Master의 역할을 대체할 수 있습니다.

- Sentinel Nodes: Redis 서버들의 상태를 모니터링하고, 네트워크 분할이나 서버 장애 같은 문제를 감지하여 자동으로 복구 작업을 수행합니다. Sentinel 노드들은 장애 감지, 구성 변경, 클라이언트에게 현재 Master의 정보를 제공하는 역할을 합니다.

(4) Sentinel Node의 중요성과 홀수 권장 이유

Redis Sentinel 시스템에서는 일반적으로 홀수 개의 Sentinel 노드를 사용하는 것이 권장됩니다. 이는 다음 두 가지 주요 이유 때문입니다:

(4-1) 쿼럼과 다수결

Sentinel 시스템에서 중요한 결정을 내릴 때, 예를 들어 Master 노드의 장애를 선언하고 새로운 Master를 선출할 때, 쿼럼을 형성하여 다수결로 결정을 내립니다. 홀수 개의 Sentinel 노드가 있을 경우, 항상 명확한 다수 의견이 형성되어 결정이 더욱 명확하고 신속하게 이루어질 수 있습니다.

(4-1) 분할 내성

네트워크 분할(Network Partition) 상황에서 홀수 개의 노드는 더 높은 내성을 제공합니다. 네트워크가 분할되어 일부 노드가 서로 통신할 수 없게 되더라도, 더 많은 노드가 있는 쪽에서는 여전히 유효한 쿼럼을 형성하고 운영을 계속할 수 있습니다.

이러한 구조는 Redis 데이터베이스를 운영하는데 있어 고가용성을 보장하며, 자동 장애 복구를 통해 서비스의 중단 없이 데이터를 안전하게 관리할 수 있도록 돕습니다.

아키텍쳐 구조

ERD

HA 구성 in Azure

SubwayChat은 HA를 위해 Azure 가상 머신 스케일 세트(VMSS)를 사용하여 트래픽 부하를 처리하고, 시스템의 가용성을 보장하고 있습니다.
Azure VMSS와 로드 밸런서를 통해 여러 가상 머신 인스턴스에 트래픽을 분산시키며, CPU 사용률을 모니터링하여 자동으로 스케일링합니다.

저희는 메트릭 기준 크기 조정 모드를 사용하여 설정하였고. 이 모드는 특정 메트릭(여기서는 CPU 사용률)을 기반으로 자동으로 인스턴스 수를 조절합니다. CPU 사용률이 70%를 초과할 경우 가상 머신 인스턴스를 하나 추가하도록 설정되어 있습니다. 반대로, CPU 사용률이 20% 이하로 떨어지면 가상 머신 인스턴스를 하나 줄이도록 설정하였습니다.

그리고 경고 규칙을 통해 CPU 사용률 70%가 초과하면, 알람이 발생하도록 구현하였습니다.

사용 가이드 (로컬)

이 가이드는 프로젝트를 시작하고 실행하는 데 필요한 단계를 안내합니다. 아래 지침을 따라 진행해 주세요.

저장소 복제하기 프로젝트를 시작하려면 먼저 GitHub에서 프로젝트의 저장소를 로컬 컴퓨터로 복제합니다. 다음 명령어를 사용하여 저장소를 복제할 수 있습니다:

git clone https://github.com/pnuCloud/SubwayChat.git
cd SubwayChat/src/WAS

데이터베이스 설정 이 프로젝트는 MySQL 데이터베이스를 사용하며, SubwayChat 데이터베이스를 포트 3306에서 생성해야 합니다. 데이터베이스를 생성하기 위해 MySQL을 사용하는 경우 다음 SQL 명령어를 사용할 수 있습니다:

CREATE DATABASE SubwayChat;

서버 실행 데이터베이스 설정 후, 프로젝트 디렉터리 내에서 서버를 실행해야 합니다. 다음 명령어를 사용하여 서버를 시작할 수 있습니다:

./gradlew bootRun

또는, 빌드된 JAR 파일을 사용하여 서버를 실행할 수 있습니다:

java -jar build/libs/SubwayChat-0.0.1-SNAPSHOT.jar

애플리케이션 접속 서버가 실행되면, 웹 브라우저를 통해 애플리케이션에 접속할 수 있습니다. 다음 URL을 브라우저의 주소창에 입력하세요:

http://localhost:8080

이제 SubwayChat을 사용할 준비가 완료되었습니다. 애플리케이션을 탐색하고 기능을 사용해 보세요!

사용 가이드 (도커)

MySQL, Redis 실행 우선, Docker compose를 사용해서 MySQL과 Redis를 실행시킵니다.

cd SubwayChat/src/WAS
docker-compose up -d

Docker 이미지 빌드 다음으로, Dockerfile을 사용해서 Spring boot를 빌드 합니다.

docker build -t hoyaii/subwaychat .

Docker 컨테이너 실행 Spring boot가 빌드 되면, 컨테이너를 실행시킵니다.

docker run -d -p 8080:8080 --network forpaw_be_network hoyaii/forpaw

애플리케이션 접속 서버가 실행되면, 웹 브라우저를 통해 애플리케이션에 접속할 수 있습니다.

(로컬에서 도커 실행)
http://localhost:8080

(클라우드에서 도커 실행)
http://20.39.188.176:8080

시연 영상

SubwayChat.mp4

SubwayChat 활용 방안

SubwayChat은 부산 지하철 호선별 익명 채팅 서비스로, 사용자가 지역 커뮤니티 내에서 소통하고 정보를 교환할 수 있는 플랫폼을 제공합니다. 이 서비스를 통해 가능한 다양한 활용 방안을 소개합니다.

(1) 지역 기반 정보 공유

교통 정보 공유
- 사용자들은 지하철 운행 지연, 시간 변경, 지하철 칸 내 사람 밀집도를 포함하여 지역 내 교통 상황에 대한 정보를 실시간으로 공유할 수 있습니다.
안전 정보
- 긴급 상황이나 안전에 관련된 중요 정보를 공유함으로써 지역 사회의 안전을 향상시킬 수 있습니다.

(2) 지역 사회 활성화

이벤트 공유
- 지역 행사, 축제, 모임 등의 정보를 공유하고 홍보하여 지역 사회의 참여와 활동을 촉진할 수 있습니다.
공공 서비스 정보
- 지역 공공 서비스, 편의시설, 재활용 센터의 위치 및 이용 방법 등을 공유하여 주민들의 생활 편의를 돕습니다.

(3) 상업적 활용

맛집 및 상점 홍보
- 지역 내 맛집, 상점, 소매점 등의 홍보가 가능하며, 사용자들은 추천하고 싶은 장소를 공유하고, 할인 정보나 특별 이벤트를 알릴 수 있습니다.
광고 및 마케팅
- 지역 기반의 광고를 실시하여 특정 지역의 사용자들을 대상으로 상품이나 서비스를 마케팅할 수 있습니다.

(4) 사회적 상호작용

익명 피드백과 토론
- 사용자들은 익명성을 보장받으며 다양한 주제에 대해 자유롭게 의견을 나눌 수 있습니다. 이는 정치, 사회적 이슈에 대한 토론을 가능하게 하며, 다양한 의견을 수렴할 수 있는 플랫폼을 제공합니다.
비상 상황 네트워크
- 자연재해나 긴급 상황 발생 시, 지역 커뮤니티가 서로 도움을 요청하고 지원할 수 있는 통신 채널로 활용될 수 있습니다.

JunHyeong-99/SubwayChat