[가상 면접 사례로 배우는 대규모 시스템 설계 기초 2] 2장 - 주변 친구1장의 근접성 서비스는 사업장 위치를 다뤘다. 사업장 주소는 거의 바뀌지 않는 정적인 데이터였다. 2장의 주변 친구는 다르다. 사용자는 계속 움직이고, 위치는 몇 초 단위로 바뀐다. 자주 바뀌는 위치를 어떻게 실시간에 가깝게 친구들에게 전달할 것인가가 이번 장의 핵심이었다.1단계: 문제 이해 및 설계 범위 확정면접관과 합의한 조건은 다음과 같았다.'주변'의 기준은 반경 5마일이고, 이 값은 설정할 수 있다.거리는 친구 사이의 직선 거리로 계산한다. 강이나 도로 같은 장애물은 고려하지 않는다.전체 사용자 10억 명 중 10% 정도가 주변 친구 기능을 쓴다.사용자의 위치 이동 이력은 따로 보관한다. 나중에 머신러닝 등에 쓸 수 있다...

[대규모 시스템 설계 기초 2] 1장. 근접성 서비스근접성 서비스(Proximity Service)는 현재 위치를 기준으로 가까운 음식점, 호텔, 주유소 같은 시설을 찾아주는 서비스다. 지도 앱의 "내 주변 검색"이나 "가장 가까운 k개 주유소 찾기" 같은 기능이 여기에 해당한다.1단계. 문제 이해 및 설계 범위 확정최대 허용 반경은 20km 이다.사용자가 UI에서 검색 반경을 변경할 수 있다.사업장 소유주가 사업장 정보를 시스템에 추가/삭제/갱신할 수 있고, 다음날까지 변경된 정보가 반영된다.사용자의 이동속도는 빠르지 않아서, 상시적으로 페이지를 갱신할 필요는 없다.주어진 반경 내의 사업장만 대상으로 하고, 시간이 남으면 주어진 범위 안에 사업장이 많지 않은 경우를 어떻게 처리할지 고민해보자.요구사항요..

비관적 락, 낙관적 락, 분산 락을 다 써보고 나서야 정리했다지난 글 마지막에 커넥션 풀 데드락 얘기를 했다. 한 스레드가 커넥션 두 개를 잡으려다 서로 물려서 멈추는 상황이었다. 그걸 정리하다 보니 다음 질문이 자연스럽게 따라왔다. 애초에 락은 왜 걸고, 어떤 락을 골라야 하는 걸까.마침 내가 한 프로젝트들에 서로 다른 락이 들어가 있었다. 짠팟에서는 중복 챌린지를 막으려고 DB 비관적 락을 걸었고, Keepit에서는 AI 요약이 중복 실행되는 걸 막으려고 Redis 분산 락을 썼다. 당시엔 "이게 맞는 것 같아서" 골랐는데, 왜 그게 맞았는지 설명해보라고 하면 말이 막혔다. 그래서 이번에 제대로 정리했다.락은 왜 필요한가동시성 문제의 본질은 대부분 갱신 손실(Lost Update) 이다.스레드 A: ..

JWT 토큰 기반 인증인데 왜 세션 쿠키가 날아가는 걸까? Spring Security의 SecurityContext 저장 메커니즘을 파헤쳐보자.1. 문제 발견프론트엔드 개발자로부터 이런 피드백을 받았다. "배포 환경에서 보니까 쿠키를 통해 세션 ID, 그리고 리퀘스트 헤더에 액세스 토큰을 같이 보내네요. 토큰 + 세션 기반이 중복으로 처리되고 있는 것 같습니다. 저희는 토큰 기반이기 때문에 세션은 필요 없지 않을까 싶습니다." 우리 프로젝트는 Spring Boot + JWT 토큰 기반 인증 구조다. SessionCreationPolicy.STATELESS로 세션을 사용하지 않도록 설정했고, OAuth2 인가 요청도 세션 대신 쿠키에 저장하는 HttpCookieOAuth2AuthorizationReque..

4장. 처리율 제한 장치의 설계처리율 제한 장치(rate limiter)클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제안한다. API 요청 횟수가 제한 장치에 정의된 임계치(threshold)를 넘어서면 추가로 도달한 모든 호출은 처리가 중단(block)된다.사용자는 초당 2회 이상 새 글을 올릴 수 없다.같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다.같은 디바이스로는 주당 5회 이상 리워드(reward)를 요청할 수 없다. API에 처리율 제한 장치를 두면 좋은점DOS(Denial of Service) 공격에 의한 자원 고갈을 방지비용 절감서버 과부하 방지3장에서 배운 시스템 설계 4단계 접근법을 적용..