인프런 커뮤니티 질문&답변

채팅 데이터는 무분별하게 요청이 많이 올 수 있는 데이터 형태 입니다.

해당 데이터 형태를 DB에 그대로 넣어주게 된다면, 요청 하나당 하나의 Tx가 발생하게 됩니다.

이러면 사실 좋은 형태가 아니에요. DB에 대한 부하가 굉장히 많이 발생 할 수 있습니다.

가장 좋은 방법은 사실상 채팅 데이터는 히스토리성 데이터이며 시간에 따른 데이터에 가깝기 떄문에 사실 다른 DB를 사용하는것이 좋습니다.

• ElasticSearch같은 부분이 있겠네요

또한 DB에 넣어주는 작업을 Bulk형태로 전송을 하는것이 좋습니다.

하나의 Tx에 여러개의 데이터를 합해서 보내는것이죠.

Kafka를 사용하지는 않아도 된다고 생각을 합니다. 해당 채팅 데이터를 다른 외부 모듈에서도 사용을 해야 한다면 Kafka를 사용하는것도 좋지만, 하나의 서버에서도 단순하게 관리 할 수 있다고 생각을 해요.

그래서 저라면 이렇게 관리가 될 꺼 같습니다.

• 물론 상황이나 좀 더 고려해야 하는 부분에 따라서 달라질 수는 있습니다.

FE -> BE -> Redis -> Loop을 통해서 Redis 데이터를 DB로 적재

질문 주셔서 감사합니다. :)

안녕하세요, 인프런 AI 인턴입니다. 마음을 녹이는 고양이님.

채팅 서버 아키텍처에서 카프카를 어떻게 활용할 수 있는지에 대해 질문해주셨군요. 이는 실제로 여러 가지 방법으로 구성될 수 있으며, 각 방법마다 장단점이 존재합니다.

1. 카프카 없이 직접 DB 저장:

   • 속도: 직접 DB에 저장함으로써 메시지 처리가 신속할 수 있습니다.
     
   • 구현 간편성: 카프카를 사용하지 않기 때문에 구현이 좀 더 단순할 수 있습니다.
     

2. 카프카 사용:

   • FE -> BE -> Kafka -> DB 흐름은 메시지를 비동기적으로 처리하여 시스템의 견고성을 높입니다.
     
   • 장점:
     
     • 메시지 손실 방지: 카프카는 메시지를 안전하게 보관하여 시스템 장애 시에도 복구가 용이합니다.
       
     • 확장성: 동시 접속자 수가 많아질 때 분산 처리로 시스템 부하를 효과적으로 분산할 수 있습니다.
       
   • 단점:
     
     • 복잡성: 시스템이 복잡해져 초기 설정과 유지보수가 까다로울 수 있습니다.
       

실제 구현에서 선택은 시스템의 요구 사항과 팀의 기술 스택에 의존합니다. 대용량 사용자 처리를 위해서는 종종 카프카와 같은 메시지 브로커를 사용하여 안정성과 확장성을 확보하는 경우가 많습니다. 이를 통해 메시지 흐름을 효율적으로 관리하고, 비동기 처리를 통해 스케일링의 이점을 누릴 수 있습니다.

다음 링크에서 비슷한 질문에 대해 다루고 있으니 참고하시기 바랍니다:
- 카프카의 이유: 카프카를 활용한 시스템 설계의 장점에 대해 깊이 있는 토론을 확인할 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.