Skip to content

가천 카카오 엔터프라이즈 - 메시지 분배 발송 솔루션 프로젝트

Notifications You must be signed in to change notification settings

hyeong-jun-kim/RNS-Spring

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation


Logo

Rabbit Notification Service

안정적이고 빠르게 연락을 제공해주는 서비스
가천대학교 카카오 엔터프라이즈 기업 실무 프로젝트 - 메시지 분배 발송 솔루션

RNS 프로젝트 정리 페이지 »
Send Rabbit Team 기업 실무 프로젝트 최종 보고서 »
데일리 스크럼 일지 »

팀원 소개 (Send Rabbit Team)


PM, BE : 김형준


BE, FE : 오영주


BE, FE : 신예나

RNS 프로젝트 소개

가천 카카오 엔터프라이즈 기업 실무 프로젝트 3번 과제, 메시지 분배 발송 솔루션을 주제로 구현한 프로젝트입니다.

고객별로 중계사별 분배 비율을 설정할 수 있고, 설정한 비율대로 1000MPS 이상의 성능으로 고객에게 메시지가 전달되어야하며, 메시지는 유실되지 않고 결과 조회시 모든 기록들이 보여야합니다.

현재 성능으로 1초에 5000MPS 이상이 보장되며, 과제에서 제시한 요구사항들을 모두 구현하고 디벨롭해 놓은 상태입니다.

프로젝트 수행 기간

2022년 12월 26일 ~ 2022년 2월 19일 (8주)

사용 기술

개발 환경

  • Spring Boot
  • RabbitMQ
  • Redis
  • MySQL
  • Kubenetis

CI & CD

  • Jenkins
  • ArgoCD

모니터링

  • Prometheus
  • Grafana
  • ElasticSearch
  • fluentD
  • Kibana

테스트

  • JUnit
  • Jmeter

협업 도구

  • Jira
  • Slack
  • Notion

쿠버네티스 아키텍처

  • CI&CD 적용 Pod
    • Sender Server, Receiver Server, React Pod
  • 고 가용성 확보
    • Redis Clustering (3Master-3Slave), MySQL Clustering (1Master-3Slave), RabbitMQ Clustering & Mirroring (1Disk Node, 2RAM Node)
  • 모니터링
    • 노드와 파드의 리소스 모니터링을 위해 Prometheus 및 Grafana 사용
    • 서버에서의 로그 분석을 위해 EFK 스택 사용
    • 쿠버네티스 파드 모니터링을 위해 KubeWatch 사용
    • 모든 모니터링 툴은 Slack과 연동 됨
  • HPA (Horizontal Pod AutoScaler) 적용
    • Sender Server, Receiver Server pod
    • Produce > Consume 현상 방지를 위해 Receiver 서버의 가중치를 더 크게 두었음
  • Setting & Security
    • ConfigMap을 통해 빈번하게 자주 변경되는 환경 변수, 클러스터링 정보들을 저장한 다음 config으로 배포하였음
    • 데이터베이스와 같이 민감한 정보들은 Secret을 통해 따로 배포하고, persisten volume을 mount하여서 필요한 곳에서 따로 쓸 수 있게 하였음
    • Prometheus, Kubewatch, FluentD 같이 노드와 파드의 metrics를 수집하는 파드들은, Admin 권한을 주는 것이 아닌 필요한 권한만을 파악한 후, 따로 ClusterRole과 ServiceAccount를 정의해줬음

메시지 발송 구조 아키텍처

메시지 발송 -> Sender Server -> 상태 DB 저장 (Redis) -> 사용자가 설정한 라우팅 규칙에 맞게 Message 전송 -> 해당하는 브로커 서버에서 Consume -> Receiver 서버로 Message 전송 -> Receiver 서버에서 Consume 받아 성공/실패 저장

대규모 요청 처리 프로세스

Message Queue 구조

  • 해당 큐 구조를 통해 브로커 서버가 꺼져있을시에, 다른 중계사로 보내고 모든 중계사를 다 돌았을 경우에 메시지 발송이 안되면 실패 처리하는 프로세스를 구현할 수 있다.
  • 전송 실패 시나리오 (DLX Error Handling)
    • (retryCount <= 1) KT WorkQueue Publish -> KT 중계사 꺼져있음 (Consume X) -> KT WorkQueue 10초간 대기 -> DLX 큐인 WorkDead 큐로 이동 -> Receiver 서버에서 retryCount 판별 retryCount == 1 일시, 해당 과정 다시한번 반복
    • (retryCount == 2) SKT WorkrQueue Publish -> SKT 중계사 꺼져있음 (Consume X) '' 위의 과정 반복
    • (retryCount == 3) LG WorkrQueue Publish -> LG 중계사 꺼져있음 (Consume X) '' 위의 과정 반복
    • (retryCount == 4) 처음 보낸 중계사의 브로커(KT)로 실패 처리 함, 실패 사유로 중계사 오류 및 거쳐온 중계사들을 적어서 실패 처리함

RNS 기능

발송 기능

발송 관리 기능

발송 조회 기능

RNS 관련 깃허브

RNS-React
RNS-Receiver
SMS-KT-Broker
SMS-SKT-Broker
SMS-LG-Broker
Kakao-KE-Broker
Kakao-CNS-Broker

About

가천 카카오 엔터프라이즈 - 메시지 분배 발송 솔루션 프로젝트

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 99.9%
  • Dockerfile 0.1%