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

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

커넥션 풀이랑 스레드 풀, 면접 준비하다가 제대로 정리했다면접 스터디에서 이런 질문을 받았다."톰캣 스레드가 200개인데 커넥션 풀이 10개예요. 요청 200개가 동시에 들어오면 어떻게 되나요?" 커넥션 풀이 뭔지, 스레드 풀이 뭔지는 당연히 안다고 생각했는데 이 질문 앞에서 멈칫했다. 둘을 각각은 알고 있었지만 같이 놓고 생각해본 적이 없었다. 그래서 이참에 제대로 정리했다.풀이 왜 필요한가부터커넥션 풀과 스레드 풀은 이름만 비슷한 게 아니라 해결하려는 문제가 똑같았다.만드는 비용이 비싼 자원을 매번 새로 만들지 말고, 미리 만들어두고 빌려 쓰자는 것이다.DB 커넥션 하나를 새로 만들 때 실제로 뭐가 일어나는지 보면 왜 비싼지 감이 온다.TCP 3-way 핸드셰이크를 하고, DB 프로토콜 핸드셰이크를 ..

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

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