백엔드 시스템의 성능을 최적화하는 과정에서 가장 가성비가 좋고 즉각적인 효과를 볼 수 있는 기술은 단연 ‘캐싱(Caching)‘입니다. 관계형 데이터베이스(RDBMS)는 디스크 I/O를 기반으로 동작하기 때문에 물리적인 속도의 한계가 명확하며, 트래픽이 몰릴 경우 병목 현상의 주범이 됩니다. 반면 Redis와 같은 인메모리(In-Memory) 저장소는 RAM에 데이터를 저장하고 처리하므로, 디스크보다 수백 배 빠른 접근 속도를 제공합니다. 하지만 “Redis를 도입했다”는 사실만으로 모든 … 더 읽기
지난 포스팅에서 우리는 JPA의 낙관적 락과 비관적 락을 통해 데이터베이스 레벨에서 동시성 문제를 해결하는 방법을 배웠습니다. 하지만 서비스의 규모가 커져 서버가 한 대가 아닌 여러 대(Scale-out)가 되는 순간, 자바의 synchronized 키워드나 단일 애플리케이션 내부의 락은 무용지물이 됩니다. 각 서버의 메모리가 독립적이기 때문입니다. 물론 데이터베이스의 비관적 락(Pessimistic Lock)을 사용하면 서버가 여러 대여도 동시성을 제어할 수 있습니다. 하지만 DB … 더 읽기
백엔드 개발자가 로컬 환경에서 혼자 개발하고 테스트할 때는 절대 마주칠 수 없는, 하지만 운영 환경에 배포되자마자 서비스의 신뢰도를 바닥으로 떨어뜨리는 무서운 문제가 있습니다. 바로 ‘동시성 이슈(Concurrency Issue)‘입니다. 가장 대표적인 예가 ‘재고 관리 시스템‘입니다. 재고가 딱 1개 남은 인기 상품이 있다고 가정해 봅시다. 이 상품을 구매하기 위해 사용자 A와 사용자 B가 0.001초의 차이로 동시에 ‘구매’ 버튼을 … 더 읽기
지난 포스팅에서 우리는 MSA 및 모바일 환경에서의 확장성을 위해 JWT(Json Web Token) 기반의 인증 아키텍처를 선택하는 것이 유리함을 확인했습니다. 하지만 동시에 JWT가 가진 치명적인 약점인 ‘한번 발급되면 서버가 제어할 수 없다(Stateless)’는 딜레마에 대해서도 논의했습니다. 만약 유효기간이 긴 Refresh Token이 해커에게 탈취당한다면 어떻게 될까요? 해커는 그 토큰이 만료될 때까지 유유히 Access Token을 재발급받으며 사용자의 계정을 마음대로 … 더 읽기
웹 서비스의 규모가 커지고 아키텍처가 모놀리식(Monolithic)에서 마이크로서비스(MSA)로 진화함에 따라, 개발자들이 가장 먼저 마주하는 난관 중 하나는 바로 ‘인증(Authentication) 시스템의 설계‘입니다. 과거 단일 서버 시절에는 별다른 고민 없이 사용하던 세션(Session) 방식이, 서버가 여러 대로 늘어나고 도메인이 분리되는 통합 계정 환경에서는 확장성의 발목을 잡는 주범이 되기도 합니다. 이에 대한 대안으로 JWT(Json Web Token)가 표준처럼 자리 잡았지만, JWT가 만능열쇠는 아니며 … 더 읽기