인프런 커뮤니티 질문&답변
작성한 질문수
좋아요 배치 처리 로직과 실제 API 동작 차이에 대해 질문드립니다
해결된 질문
작성
·
10
·
수정됨
0
안녕하세요, 강의 잘 듣고 있습니다!
이전 'Set과 집합연산' 강의 중 예시로 들었던 인스타그램처럼 많은 사용자가 있는 대규모 플랫폼에서 빈번하게 발생하는 좋아요 같은 요청을 부하 방지를 위해 Batch 방식으로 묶어 보낸다는 설명을 들었습니다.
그런데 실제 인스타그램 웹 환경에서 네트워크 로그를 확인하며 테스트해 보니, 좋아요를 빠르게 연타할 경우(예: 1초 내 6회) 클릭 횟수만큼 즉시 API(GraphQL) 요청이 발생하는 것을 확인했습니다.
제가 찾아본 바로는 데이터 정합성과 실시간성을 위해 클라이언트에서 즉시 요청을 보내는 것 같은데, 그렇다면 강의에서 언급하신 '일괄 처리(Batching)'는 클라이언트 단의 구현보다는 서버 내부(메시지 큐나 캐시 활용 등)에서 처리하는 방식이 더 보편적인 것인지 궁금합니다.
추가로 클라이언트 단에서 디바운싱이나 배치 처리를 통해 API 요청 횟수를 조절할 경우, 필연적으로 'UI 업데이트와 실제 API 호출 사이의 시간차'가 발생하게 됩니다. 이때 사용자가 좋아요를 누른 직후(API가 호출되기 전) 브라우저를 닫거나 앱을 종료하면, UI 상으로는 성공한 것처럼 보였으나 실제 DB에는 반영되지 않는 데이터 불일치 현상이 발생할 것 같습니다.
실무에서는 이런 '이탈 상황에서의 데이터 정합성'을 어느 수준까지 고려하여 설계하는지 강사님의 조언을 듣고 싶습니다.
감사합니다.
답변 2
1
안녕하세요
클라이언트단 구현과 서버단 구현은 사실 정답이 있는 주제는 아닙니다. 클라이언트에서 막는 것은 서버까지 가는 요청의 총 숫자를 줄여 원천 차단에 의의가 있지만 반대로 정상적인 활동까지 막을 수도 있습니다. 또는 복잡한 예외 처리가 생길 수도 있겠죠.
제가 강의에서 이야기했는지 제 유튜브에서 얘기 했는지 정확히 기억은 나지 않지만, 대표적으로 farming 게임이 클라이언트단에서 모아서 처리하는 예에 해당합니다. 클래시오브클랜과 같은 게임을 해보셨을지 모르겠으나, 해당 게임은 접속하면 광산에 쌓인 골드를 클릭해 수집하고, 엘릭서를 수집합니다. 사용자의 대부분이 그 활동을 하죠. 아주 극소수의 사용자만 몇몇 광산의 골드와 엘릭서를 누락해서 수집할 수 있지만 대부분은 접속하자마자 그동안 쌓인 자원을 수집합니다. 그게 가장 효율적인 패턴이라 그렇죠.
그럴 때 여러번의 클라이언트 요청이 아닌 모아서 처리하는게 오래전부터 사용됐던 패턴이고, 이를 웹 클라이언트에서도 전략적으로 활용할 수 있습니다. 생각하신대로 서버측에서도 처리해도 괜찮은 전략입니다. DB에 너무 많은 짧은 I/O를 발생시키는 것은 서비스가 커질 수록 치명적일 수 있기 때문에 캐시 서버를 둬서 캐시된 데이터를 일정 사이클마다 처리한다던지 하는 방향으로 해결할 수도 있습니다.
인스타그램에서 테스트해보신 건 매우 좋은 습관입니다. 여러 서비스를 탐방하시면서 어떤 시점에 어떤 요청이 발생하는지, 묶어서 발생하는 경우가 있는지, 지속적으로 보시다보면 더 높은 수준의 자신만의 통찰을 얻으시리라 생각합니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 김진규님.
질문 주신 ‘좋아요’ 요청의 일괄 처리(Batching)와 인스타그램의 실시간 API 요청에 대한 부분은 매우 흥미로운 주제입니다. 대규모 플랫폼에서의 데이터 처리 방법론에 대해 잘 이해하고 계시는 것 같습니다.
클라이언트와 서버 측면에서의 Batching
클라이언트 측 Batching:
- 클라이언트는 사용자의 요청을 일정 시간 동안 모아서 한 번에 서버로 보낼 수 있습니다. 이를 통해 불필요한 네트워크 요청을 줄이고 효율성을 높일 수 있습니다.
- 그러나 이 방법은 실시간성을 요구하는 경우에는 적용하기 어려울 수 있습니다. 특정 상황에서는 사용자의 즉각적인 피드백이 중요한 요소로 작용합니다.
- 클라이언트는 사용자의 요청을 일정 시간 동안 모아서 한 번에 서버로 보낼 수 있습니다. 이를 통해 불필요한 네트워크 요청을 줄이고 효율성을 높일 수 있습니다.
서버 측 Batching:
- 서버 측에서는 메시지 큐나 캐시를 사용하여 들어오는 요청을 일시적으로 저장하고, 일정 시점에 일괄 처리하는 구조를 사용할 수 있습니다.
- 이런 방식은 적합한 인증, 데이터 정합성 유지, 대량 트래픽 제어 등에 유리합니다.
- 서버 측에서는 메시지 큐나 캐시를 사용하여 들어오는 요청을 일시적으로 저장하고, 일정 시점에 일괄 처리하는 구조를 사용할 수 있습니다.
인스타그램과 같은 플랫폼에서의 처리
- 인스타그램같이 인기 있는 플랫폼에서는 실시간 피드백 제공의 중요성이 높고, 사용자 경험이 최우선되어야 합니다.
- 즉시 API 요청을 처리하면서 실시간성을 유지하는 것이 사용자 경험 측면에서 더 유리할 수 있습니다.
- 클라이언트 단에서 디바운싱을 적용하지 않는 대신, 서버 측에서 부하를 최소화하는 다양한 기술적 조치(예: Load Balancer, CDNs, Caching)가 있을 것입니다.
강의에서 설명한 Batching은 일반적인 방법론을 설명한 것으로 실제 서비스에서는 여러 요소에 따라 상황에 맞게 최적화된 방식을 선택할 수 있습니다.
관련된 질문을 통해 더 많은 인사이트를 제공할 수 있습니다:
- 실행 컨텍스트 깊이 파헤치기에서는 JavaScript의 이벤트 루프와 같은 비동기 이벤트 처리를 상세히 설명하고 있어, 데이터 처리 방식에 대한 이해를 돕습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.