외부 API가 서비스를 마비시킬 뻔한 이야기: 가상스레드 도입기
Network I/O가 스레드를 막던 문제를 JDK 21 가상 스레드로 풀었다. 도입 중에 나타난 Thread Pinning과 Overwhelming의 원인과, 각각을 넘긴 방법을 함께 정리했다.
블로그
넥스터즈 27기 후기: 이론보다 실험, 정답은 유저에게 있었다
Nexters 26기 때 나는 유저가 아닌 내 머릿속 시나리오에 집착하고 있었다. PM으로서, 아래의 슬로건을 걸고 프로젝트를 시작했다. 우리 팀은 Schwartz의 가치 이론에 기반한 자기 발견 앱인 Loopy를 만들었다.
UPDATE 한 줄로 끝내는 동시성 문제
선착순 이벤트 시스템을 설계한다고 가정해보자. 요구사항은 아래와 같다. 100개의 재고가 있을 때 동시에 1,000명이 요청하면 어떻게 정확히 100명에게만 제공할 수 있을까? 이때 일반적으로 제시되는 해결책들은 아래와 같다.
분산 캐시 동기화 문제, Redis Pub/Sub으로 해결하기
한 화면에 날짜별 배송 계획 40~60건을 외부 API로 불러와야 해서 응답이 느렸다. Redis 캐시와 로컬 캐시로 50~100배 빨라졌지만, 서버마다 어긋나는 로컬 캐시는 Redis Pub/Sub으로 맞췄다.
실무에서 @Transactional을 제거했더니 성능이 2배 향상된 이유
Spring의 @Transactional(readOnly = true)는 dirty checking을 Manual로 바꿔 빨라진다고 알려져 있다. Elastic APM의 호출 로그에서는 불필요한 JDBC 호출 때문에 오히려 느려졌다.