[1권 - 12장] 채팅 시스템 설계

[KimH4nKyul]

채팅 시스템 설계 파트를 공부하며 토론해 볼 내용을 정리 해봅시다!

[KimH4nKyul]

[경험 공유]
채팅 서비스를 만들어 본 경험이나 웹 소켓을 사용해 본 경험이 있나요?

[KimH4nKyul]

[소켓 연결 재시도] @yonghanyoon

• 모바일(iOS) 이슈 -> 애플리케이션 종료 후 일정 시간 지나고 다시 켰을 때, 안돌아가는 이슈가 있었다. <- 애플 자체 문제였다.
• 클릭 이벤트로 다시 연결 시켜주는 걸로 해결했다.

[KimH4nKyul]

알림 시스템, 지도 대시 보드에 단말 아이콘 표시 해야 하는데, 계측값이 임계값을 넘으면 상태가 변경되어야 했음 @hyojin202406
-> 변경 시 클라이언트 CSS를 변경해야 했음
-> 웹 소켓 설정, 채널명(채널 분리 관리 -> 전체/특정) 등을 관리하고 설계해야 함

[KimH4nKyul]

카카오 모빌리티에서 웹 소켓 사용 사례를 허재코치님께 공유 받아보자

[hyojin202406]

https://www.youtube.com/watch?v=sbRO8E5Kqp0&ab_channel=kakaotech

[Cheondongmin]

[질문 아님, 궁금해서 정리 한 것]

종단간 암호화란?..

종단간 암호화(End-to-End Encryption; E2EE)는 발신원부터 수신원까지 정보의 암호화를 유지한 채로 전송하는 방식이다.
E2E(End-to-End) 암호화라고도 부른다.

일반적인 온라인 메시지는:

• 친구한테 편지 쓰고 우체부 여러 명 거쳐서 전달하는 것과 비슷함
• 중간에 우체부들이 편지 열어볼 수 있음
• 보통 인터넷 통신이랑 비슷함

종단간 암호화된 메시지:

• 특수 보안 금고에 메시지를 보관하는 것과 동일함
• 발신자와 수신자만이 암호키 보유중임
• 중간 서버나 관리자도 내용 확인 불가함
• WhatsApp, Signal 등이 해당 방식 사용중임

장점:

• 메시지가 중간에 누가 읽거나 바꿀 수 없음
• 받을 사람만 내용 볼 수 있음
• 개인정보랑 대화 내용 완전 안전함

단점:

• 키 분실시 메시지 복구 불가함
• 시스템 구축 비용이 높음
• 법적 요구시 메시지 제출 어려움
• 악의적 사용자간 통신 모니터링 불가함
• 백업 시스템 구축이 복잡함

결론: 종단간 암호화는 대화 시작할 때부터 끝날 때까지 숨겨주는 디지털 금고 같은 것
중간에 아무도 볼 수 없고 보내는 사람이랑 받는 사람만 볼 수 있음

[yonghanyoon]

채팅이력 저장소에 대해 NoSQL를 선호한다고 한다.
페이스북은 HBase를 사용하고 디스코드는 카산드라를 사용한다고 한다.

그걸 Redis나 몽고DB로 구현했을 때의 문제점이 있을까?

[KimH4nKyul]

이 부분은 레디스나 몽고만의 고유한 특성에 대해서 조사가 필요할 거 같기도 함.
결국에는 채팅 이력이라고 하는 고유 특성을 갖는 데이터의 이용 행태를 파악해 써야 한다고 했을 때, NoSQL이 적절한 이유와 함께 각 NoSQL 제품군 간에 비교를 해봐야 할 듯

• 사용자당 하루 수백~수천 건 메시지 생성
• 비정형 데이터임 (스키마가 없는 텍스트 데이터의 특징 + 이미지 + 링크 등)
• 시간 순서대로 안정적으로 저장할 수 있어야 함
• 파레토 법칙에 따른 읽기 패턴(최근꺼만 조회함)

[KimH4nKyul]

Redis를 사용하기 어려운 이유 생각해 봤을 때,
휘발성이라는 특성에 있을거 같음 -> AOF로 백업이 가능하긴 하나 이게 얼마나 유효한지는 잘 모르겠음
또한, 캐시까지 고려해야 했을 때 가용할 수 있는 리소스에 대한 낭비는 없는 지 체크해 볼 필요가 있음

[KimH4nKyul]

카산드라는 와이드 칼럼 스토어로 분류되는데, 이 키워드로 공부 진행해 보면 좋을거 같음

[KimH4nKyul]

MongoDB의 경우에는 KV는 아니고 Document니까 본질적으로 다른게 아닐까라는 생각? -> KV와 Document의 차이도 알아보면 좋을거 같음

[KimH4nKyul]

"채팅 이력과 같은 단순 시계열 데이터는 Document Store의 풍부한 기능이 오히려 오버헤드가 될 수 있으며, Wide-Column Store의 단순하고 효율적인 모델이 더 적합할 수 있음" by ChatGPT

[KimH4nKyul]

[아파치 주키퍼를 서비스 탐색 용도로 사용하는 이유와 사례, 그리고 간단한 구현 방안에 대해서]

분산 환경에서 인스턴스가 동적으로 생성되고 제거된다. 이 때, 서비스간 통신을 위해서는 각 인스턴스의 위치(Host와 Port)를 실시간으로 파악해야 한다.

이를 위해 인스턴스의 상태와 구성 정보를 중앙에서 관리해 줄 필요가 생긴다.

서비스 디스커버리는 다음과 같은 기능을 제공해 준다.

• 서비스 등록/해제 자동화
• 서비스 상태 모니터링 및 장애 감지
• 구성 정보의 중앙화된 관리

// 서비스 등록
public class ServiceRegistry {
    private ZooKeeper zk;
    private String servicePath = "/services";
    
    public void registerService(String serviceName, String serviceEndpoint) {
        // 임시(ephemeral) 노드로 서비스 등록
        String path = servicePath + "/" + serviceName;
        zk.create(path, serviceEndpoint.getBytes(), 
                 ZooDefs.Ids.OPEN_ACL_UNSAFE,
                 CreateMode.EPHEMERAL_SEQUENTIAL);
    }
    
    public List<String> discoverService(String serviceName) {
        // 서비스 조회
        String path = servicePath + "/" + serviceName;
        List<String> children = zk.getChildren(path, true);
        return children.stream()
                      .map(this::getServiceData)
                      .collect(Collectors.toList());
    }
}

서비스 디스커버리의 실제 사용 사례는 다음과 같다.

• 넷플릭스 유레카
• 아파치 Dubbo

서비스 디스커버리는 CAP중 CP를 보장한다. 구현시 고려사항은 주키퍼 앙상블의 크기(3-5대 권장) 외에 아래와 같다.

• 2-20초 정도의 세션 타임아웃
• 노드당 1MB 이하 유지의 데이터 크기
• 수만 개까지 안정적 처리를 요구하는 노드 수

[KimH4nKyul]

[중앙화된 서비스 탐색이 SPOF가 되지 않을까?]

이 때문에, 주키퍼 클러스터를 구성해야 하고, 탐색을 이용하는 인스턴스(클라이언트 인스턴스)는 로컬 캐시를 활용해 볼 수 있을 거 같다.

[KimH4nKyul]

또한, 더 높은 가용성을 위해 지역 분산을 고려할 수도 있을 거 같다. (예를 들어, 서로 다른 데이터 센터 내에 디스커버리를 배치하기 등) + 적절한 타임아웃과 재시도 정책 사용

[Cheondongmin]

WebSocket vs WebRTC for Chat Systems?

책보면서 계속 의문이 든 점..

책에서는 계속 WebSocket으로 설계하던데, WebRTC를 쓰면 어떨까?
WebRTC가 P2P 연결이니까 서버 부하도 줄일 수 있을 것 같은데...

장점:

• 서버 부하 감소 (P2P니까)
• 실시간성 더 좋음 (중간 서버 거치는 것보다 당연히)
• 미디어 스트리밍도 잘 됨 (ㄹㅇ) (화상채팅 쉽게 추가 가능)

근데 쓰다보니깐 문제점들...

확장성 이슈

• 그룹채팅방은 어떻게 해야하지..? (구현 가능할 것 같긴한데 정리 필요..)
  N:N 연결이면 클라이언트 부하가 너무 심해질듯 (사실 클라쪽이라 알빠노긴 한데 사용자 경험에 불편함 줄듯)
  메시지 history 관리는 어떻게 할것인지

신뢰성

• 클라이언트 하나가 오프라인되면?
  메시지 유실 가능성 있음
  결국 서버에 무상태 서비스로 백업은 해야할 것 같음 (근데 이건 웹소켓도 마찬가지 아닌가)

내가 생각한 결론:

• WebRTC는 1:1 채팅이나 화상통화에는 최고겠지만,
  일반적인 채팅 시스템을 위한 베스트 솔루션인지는 의문

  다른분들의 의견도 듣고싶습니다.

[KimH4nKyul]

[재밌는 힌트]
https://github.com/decentralized-identity/aries-rfcs/tree/main/concepts/0046-mediators-and-relays#summary

[KimH4nKyul]

https://aca-py.org/latest/gettingStarted/ACA-PyAgentArchitecture/

[yonghanyoon]

[채팅 시스템을 보다가 궁금해짐]
HBase나 카산드라같은 것들을 실제로 사용해본 경험이 있다면 당신의 이야기를 듣고 싶습니다.

[KimH4nKyul]

@yw7148 뤼이드에서 사용한다고 들었는데, 공유 부탁드립니다 ㅎㅎ

[yw7148]

@KimH4nKyul 저희는 사실 그냥 문제 풀이 로깅용으로 쓰고 있어요...
저희는 CIS(Contents Interaction State)라고 하는데 사용자가 문제 풀 때 어떤 선택지를 골랐고 얼마나 걸렸고 등의 데이터를 저장하는 데에 쓰고 있습니다.

[hyojin202406]

라운드 로빈 로드 밸런싱 환경에서는 클라이언트가 처음 요청을 보낸 서버와 이후 메시지를 받을 서버가 다를 수 있기에 롱폴링이 적절하지 않을 수 있다면 웹소켓은 이 약점을 보완할 수 있을까?

• 웹 소켓은 클라이언트와 특정 서버 간의 연결을 유지할 수 있다.
• 서버 장애 발생 시 연결을 다시 맺어야 하는 문제
• 특정 서버에 부하가 몰리는 문제
• 서버 간 세션을 공유해야 하는 문제

해결 방법:
Sticky Session, 메시지 브로커, WebSocket 전용 로드 밸런서 같은 추가적인 솔루션이 필요함

궁금증:
로드 밸런싱 환경에서는 웹소켓만으로 해결하려 하지 말고, 서버 간 상태 공유 전략을 함께 고려해야 한다는데 어떻게 해야할까?

[hyojin202406]

로드 밸런서가 클라이언트를 무작위로 다른 서버에 연결할 수 있기 때문에 문제가 발생할 수 있지 않을까?

[KimH4nKyul]

헤더를 이용한 위치 지정 + 중앙 채팅 DB(DB의 경우 분산 고려) 정도가 적절할 거 같은데, 더 좋은 솔루션이 있는 지 리서치 해봐야 할 거 같음!

[durara021]

저장소로서 서버의 DB가 아닌 로컬 스토리지를 사용하는 방식을 함께 고려해보는건 어떨까요?

[KimH4nKyul]

자기 대화방 상태만 관리하면 되니까, 정책을 미리 정의해 두고 사용하면 고려해봄 직 할 거 같음

[KimH4nKyul]

예를 들어, 카카오톡 모바일 버전과 PC 버전에서 기록되는 대화 내역 이슈 @durara021 @Cheondongmin

[cruellaDev]

기기별로 “부분 동기화”만 할 수 있음

1. 서버 보관 정책
   어떤 메신저(특히 카카오톡 등)는 기기 간 메시지 이력을 전부 서버에 보관하지 않는다.
   예: 새로 설치한 PC 카카오톡에서 “이전에 휴대폰에서만 보던 메시지”를 통째로 불러오지 못하는 구조.
   이로 인해 한쪽 기기에는 오래된 메시지가 남아 있어도, 새로 로그인한 기기에는 그 대화 내용이 전부 동기화되지 않을 수 있다.

2. 부분 로딩(Partial Sync) 방식
   기기에 따라 최근 N개 메시지만 서버에서 받아오는 식으로 동작.
   오래된 메시지(특히 수천~수만 건 이상)가 누락될 수 있고, 이를 다시 로딩하는 기능이 제한적이면 “동일 대화방인데 메시지가 없는 것”처럼 보임.

3. 로컬 캐시 의존
   어떤 기기는 기기가 접속한 이후 메시지만 로컬에 쌓아둠.
   서버가 과거 메시지 전체를 재전송하지 않으면, 새로운 기기로는 과거 내역을 전부 볼 수 없게 됨.

실제 예시

1. 카카오톡
   모바일이 원본이고, PC 카톡은 “모바일과 동시에 로그인돼 있어야” 메시지 동기화가 비교적 잘 된다.
   그래도 오래된 메시지는 서버에 없거나, 부분만 동기화되어 “PC에는 대화가 잘려 보이는” 문제가 발생할 수 있다.

2. 디스코드
   일반적으로 클라우드에 메시지를 다 저장하므로, 여러 기기 간 동기화가 잘 되는 편.
   하지만 오프라인이던 기간의 메시지 알림이 누락되거나, 특수 채널/암호화 등으로 인해 일부 메시지가 안 보일 수도 있다.

3. 라인, 텔레그램 등
   라인은 기기마다 “초기 대화 내역은 안 보이는” 부분이 있을 수 있고, 텔레그램은 기본 채팅(클라우드 채팅)은 완전 동기화되지만, 시크릿 채팅은 해당 기기에만 국한되는 식.

[cruellaDev]

[서버가 다른 사용자의 채팅은 어떻게 이뤄지는가?]

(도와줘 GPT)

1. 클라이언트 → 서버: 메시지 전송

1. 클라이언트(보낸 사람)

   • 사용자 A가 “안녕?”이라는 메시지를 작성하고 서버로 전송합니다.
   • 웹/모바일 환경에서는 대개 WebSocket 연결(혹은 Socket.IO, gRPC, MQTT 등)을 사용해 실시간으로 메시지를 전달합니다.

2. 서버가 메시지 수신

   • 서버(또는 게이트웨이)가 “(sender=A, content=안녕?, room or recipient=B)” 같은 정보를 받아요.
   • 여기서 서버는 “누가 누구에게 무슨 메시지를 보냈는지” 파악합니다.

---

2. 서버 내부 처리

서버는 메시지를 받는 순간, 주로 다음 과정을 거칩니다.

1. DB 저장(혹은 메시지 큐)

   • 메시지를 영구 보관(오프라인 메시지, 이력 조회 등)을 위해 데이터베이스(혹은 키-값 저장소, NoSQL)에 기록하거나,
   • 또는 메시지 큐(Kafka, RabbitMQ 등)에 일단 넣고, 별도 워커(worker) 프로세스가 DB에 쓰는 방식을 쓰기도 합니다.
   • 이렇게 하면, 나중에 B가 접속 안 돼 있어도 메시지 이력을 조회할 수 있죠.

2. 수신 대상 파악(라우팅)

   • 서버가 “누가 받는 메시지인지” 판단:
     • 1:1 채팅이면 특정 사용자 B에게,
     • 그룹(채널)이면 그 그룹에 속한 사용자 모두에게 전달해야 합니다.

3. 부하 분산 & 고가용성

   • 여러 대 서버로 수평 확장되어 있다면, 사용자가 어느 서버에 연결돼 있는지, 메시지는 어떻게 흘러가야 하는지 샤딩(Sharding)이나 로드 밸런싱 로직이 필요합니다.
   • 예: B가 서버 2에 연결돼 있으면, 서버 1이 받은 메시지를 서버 2로 라우팅(전달)하는 식.

---

3. 서버 → 클라이언트(수신자): 메시지 전달

1. 실시간 연결(WebSocket)

   • 수신자(B)가 온라인 상태이면서 서버와 WebSocket 연결이 열려 있다면, 서버가 바로 메시지를 전송합니다.
   • “B 클라이언트”는 서버로부터 “(sender=A, content=안녕?, timestamp=……)” 형태의 데이터를 받아 화면에 표시하죠.

2. 푸시 알림

   • B가 오프라인이거나 모바일 앱이 백그라운드 상태라면, 서버는 **푸시 알림(FCM, APNs)**을 사용해 “새 메시지가 왔어요”라고 통지합니다.
   • 오프라인 시엔 메시지가 DB에 저장돼 있고, B가 다시 접속하면 오프라인 메시지를 받아볼 수 있습니다.

3. 읽음·배달 표시

   • B가 메시지를 받으면, “B가 메시지를 수신/읽음” 상태를 서버에 알려줄 수 있고, 그걸 서버가 A에게 다시 “읽음 표시” 이벤트로 전달하기도 합니다(필요한 경우).

---

4. 그룹 채팅(다수 사용자)

1. 팬아웃(Fan-out)

   • 그룹/채널에 N명이 있으면, 메시지 한 건을 N명에게 보내야 하므로, 서버가 “해당 채널의 멤버 리스트”를 참고해 한 번에 다수에게 배포(push)합니다.
   • 대규모 그룹일수록 부하가 커지므로, 서버에서 메시지 브로커 등을 통해 비동기적으로 팬아웃하기도 합니다.

2. 채널(Topic) 기반

   • 서버는 “channel:1234” 같은 식별자를 기준으로, 메시지를 pub-sub(발행-구독) 형태로 처리할 수도 있습니다.
   • 메시지가 “channel:1234”에 올라오면, 구독 중인 사용자들(연결 중이거나 온라인인 사람)에게 전송.

[KimH4nKyul]

[큐] --> [컨슈머]
컨슈머 == 서버
그럼 이 서버에서 큐를 통해 가져온 메시지 전부를 체크해가면서 채널 매칭을 해주는건가...?
컨슈머를 분산해 ...
-> S1 -> Chat 1
Q -> S2 -> Chat 2
-> S3 -> Chat3
이렇게 팬아웃해서 메시지를 소비하면 빠르게 확인하고 메시지를 전달하지 않을까?