解決済みの質問2025-10-26T08:28:30.640Z

jaehyeonhan

投稿した質問数 7

1

안녕하세요. 한재현님,

먼저 수강해주셔서 감사드리며 좋은 질문을 해주셔서 기쁘네요

• Matching Service의 MQ와 /swipe의 matching 응답값

   

  강의에서는 REST API는 지연이 발생할 수 있으므로 MQ를 사용했다고 말씀하셨습니다. 이때 API 명세에 있는 matching 값의 해석이 헷갈립니다. matching은 swipe 시점에서 자신이 상대와 매칭되었는지 알 수 있는 값이라고 생각되는데, 그러면 동기 처리가 필요한 것 아닌가 생각이 듭니다. 즉 Cassandra에서 inverse swipe이 존재하는지를 확인한 뒤에야 API 응답을 보낼 수 있는 것 아닌가요?

강의에서는 /swipe는 빠르게 “접수”만 응답하고, 매칭 확정은 MQ 기반 비동기로 처리하는 것을 목표로 하였습니다. 좀 더 세부적으로 말씀 드리면, /swipe는 20–40ms 내에 “요청을 접수했다(accepted)”고만 돌려주고, 실제 매칭 확정은 MQ(Kafka/SQS)로 흘려 Matching Service가 비동기 처리합니다. 하지만 왜 굳이 비동기를 하였느냐인데, inverse swipe 를 동기로 처리하게 되면 Region 간의 지연 또는 hot partition 이 인기있는 사용자에게 발생할 수 있는 부분 그리고 스와이프는 초당 수십만건의 데이터 쓰기가 발생하는 점을 고려해서 병목, 즉 수십만 건의 쓰기의 부하에 취약할 수 있습니다. 이러한 운영에 안정된 파이프라인을 구성하였습니다.

따라서, /swipe 응답은 20–40ms 내에 accepted만 보장하고, 실제 매칭 여부는 Kafka/SQS로 전달된 이벤트를 Matching Service가 처리해 WebSocket/푸시로 최종 통지합니다.

• Cassandra의 필요성

  
  RDB 조회만으로 inverse swipe 여부를 파악할 수 있을 것 같습니다. 그러면 Cassandra는 캐싱 용도로 사용한 것이라고 보아야 하나요? 원래 설계에서 Cassandra가 자연스럽게 도입된 이유가 궁금합니다.

Cassandra 의 경우는 inverse swipe 여부를 사실상 나에게 온 좋아요 리스트 즉, 인접리스트의 구간을 매주 자주 데이터를 읽어야 합니다. 그렇기 때문에 Cassandra 는 부하가 일어나는 swipe 를 싸게 받아서 파티션 키 = 사용자를 기준으로 최근 범위의 데이터 읽기를 빠르게 제공합니다. 물론 RDB 로도 불가능하지 않지만, 대규모에서 샤딩과 인덱스 또는 Race condition 과 같은 비용이 커져 총 비용과 지연이 급증할 수 있습니다. 결국 데이터 접근은 단일 파티션의 최근 범위가 되기 때문에 Cassandra 에 좀 더 적합하다고 할 수 있습니다. 좋은 질문을 해주셨습니다.

• Cassandra - RDB 동기화 여부

  
  swipe 기록을 RDB와 Cassandra에도 모두 저장할 때, 일시적 오류 등으로 한쪽에만 저장될 수도 있을 것 같은데, 이런 상황에 대비해 RDB와 Cassandra 간 동기화가 필요한지 궁금합니다.

한쪽만 저장되는 것처럼 보이는 상황은 대부분 Consumer 의 지연 또는 일시적인 실패이기 때문에 재시도로 복구 될 수 있습니다. 별도의 양방향 동기화 트랜잭션은 권장되지 않습니다. 오히려 장애가 일어나는 범위가 늘어나는 것이라 권장되지 않습니다. 훌륭한 질문을 해주셨습니다.

감사합니다.

좋은 하루되세요!

0

안녕하세요, 인프런 AI 인턴입니다. 한재현님께서 Tinder 설계 강의 관련하여 질문해 주신 Matching Service의 MQ 필요성과 Cassandra 사용에 대해 답변드리겠습니다.

1. Matching Service의 MQ와 /swipe의 matching 응답값

• MQ 사용 이유: 실제로 Tinder와 같은 서비스에서 MQ(메시지 큐)를 사용하는 이유는 비동기 처리의 효율성을 확보하기 위해서입니다. 메시지 큐는 사용자의 요청을 받아서 비동기적으로 처리할 수 있게 해줘 시스템의 부하를 줄입니다.
  
• matching 값의 처리: 동기적인 처리로 인한 지연을 피하기 위해, 사용자 경험 향상을 위해서는 최초의 swipe에 대해 긍정적 응답을 주고 나중에 매칭 결과를 확인하는 비동기 프로세스가 선호될 수 있습니다. 만약 즉시 매칭 여부를 알려주어야 한다면, 말씀하신대로 RDB에서의 조회와 비교를 통한 동기적 처리가 구현되어야 합니다.
  

2. Cassandra의 필요성

• Cassandra 사용 이유: Cassandra와 같은 NoSQL 데이터베이스는 대규모 데이터 저장 및 빠른 쓰기/읽기에 강점이 있습니다. Tinder의 경우, 수많은 사용자와 그들 간의 많은 상호작용을 효율적으로 처리하기 위해서 Cassandra를 캐시뿐 아니라 주요 저장소로 활용할 수 있습니다. 이는 트래픽이 많고 데이터 일관성보다는 가용성이 중요한 경우에 적합합니다.
  

3. Cassandra - RDB 동기화 여부

• 동기화 필요성: Cassandra와 RDB 간의 데이터 동기화 문제는 양쪽에 다 저장이 되어야 일관성이 보장됩니다. 그러나 애플리케이션 설계에 따라 일시적 불일치를 허용할 수 있습니다. 두 데이터 저장소가 모두 중요하고 일관성이 필요하다면, 일종의 데이터 복제 또는 동기화 메커니즘을 구축하여 데이터 유실을 방지합니다.
  

추가적으로 아래 링크를 통해 유사한 질문에 대한 답변을 참고하실 수 있습니다:
- “NoSQL 데이터베이스 사용 이유”
- “Tinder와 같은 매칭 서비스의 메시지 큐 사용 사례”

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