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

안녕하세요. 한재현님,

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

• 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 의 지연 또는 일시적인 실패이기 때문에 재시도로 복구 될 수 있습니다. 별도의 양방향 동기화 트랜잭션은 권장되지 않습니다. 오히려 장애가 일어나는 범위가 늘어나는 것이라 권장되지 않습니다. 훌륭한 질문을 해주셨습니다.

감사합니다.

좋은 하루되세요!

안녕하세요, 인프런 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와 같은 매칭 서비스의 메시지 큐 사용 사례”

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