봉황대 in CS

안녕하세요 ? 매우 오랜만에 작성하는 회고글이네요 ㅎ.ㅎ 갑작스러운 근황을 전하자면 너무나도 운 좋고 감사하게도 신입으로 토스페이먼츠의 서버 개발자 포지션에 합류하게 되었습니다.그리고 최종 합격 이후 약 2주가 지난 지금, 입사를 코앞에 두고 있습니다. 사실 합격 후기를 작성하는 것이 많이 조심스러웠습니다. 저는 학부 3학년 때까지 서버 개발 공부를 해왔지만 도중에 데이터베이스 내부 엔진 연구로 틀어서 대학원까지 입학했었는데요, 이를 중단하고 다시 서버 개발로 돌아왔다는 특이한 이력이 있어서 아무래도 제 개인적인 이야기들이 이 글에 긴 호흡으로 담길 것 같습니다. 그래도 제가 이 기간 동안 어떤 생각과 마음가짐을 가지고 있었는지를 기록해두고 싶었고 (인간의 기억력에는 한계가 있으니 .. + 예전에 기록..

Redis & Local cache를 통한 조회 성능 개선기에서 활성(active) 이벤트 조회 기능에 대하여 총 세 단계를 거침으로써 성능 개선을 이루었다.0. DB에서 직접 조회 by. Table full scan (평균 TPS : 31.3)1. DB에서 직접 조회 by. Index range scan (평균 TPS : 101.5)2. Caching : Redis cache (평균 TPS : 9.8)3. 2-level caching : Local cache + Redis cache (평균 TPS : 619.2) 이 글에서 중점으로 다룰 부분은 2번, Redis를 단일 Cache server로 둔 경우에 대해서이다. 부하 테스트를 하면서 시스템을 모니터링하는 중에 이 경우에서만 GC가 매우 높은 빈도로..

* 본 글은 ‘JVM 밑바닥까지 파헤치기’ 책과 Oracle 공식 문서들을 바탕으로 작성하였습니다. (참고 문서의 링크는 하단에 첨부) 이전 포스팅에서는 Garbage collection의 기본 개념과 JVM의 메모리 할당 전략에 대해서 알아보았다. 이번 글에서는 GC를 수행하는 주체인 Garbage collector들에 대해서 작성하고자 한다. 각 컬렉터들이 GC와 관련하여 풀고자 하는 문제들은 무엇이 존재하며 이들을 어떤 방식으로 해결하고자 하는지를 중점으로 알아보자. Oracle JDK 7 ~ 11 Garbage CollectorsG1 컬렉터 설명 전, 이쪽에 묶인 가비지 컬렉터들은 세대(generation) 단위로 영역을 구분하며, 그들의 크기와 수가 고정되어 있는 Heap memory layou..

* 본 글은 ‘JVM 밑바닥까지 파헤치기’ 책과 Oracle 공식 문서들을 바탕으로 작성하였습니다. (참고 문서의 링크는 하단에 첨부) JVM's Structure & GCJava에서 객체 또는 배열을 생성하면 JVM의 Heap이라는 영역에서 메모리를 할당하게 된다. (The heap is the run-time data area from which memory for all class instances and arrays is allocated.) JVM을 구성하는 요소는 Heap 영역 말고도 메서드 호출과 지역 변수를 관리하는 Stack 영역, 그리고 프로그램 실행 시에 필요한 여러 공통 데이터들을 관리하는 Method 영역이 존재한다. 메모리라는 자원은 한정되어 있기 때문에 메모리 고갈 문제를 겪지..

현재 진행하고 있는 프로젝트에서 이벤트 조회 기능을 구현하며, 이 기능에 부하를 주었을 때 어떤 문제가 발생하는지를 확인하고 여러 가지 기법들을 적용해 보며 해결하게 되었다. 이 과정을 통해서 배웠던 것들을 여기에 정리하고자 한다. 상황 설명각 이벤트에는 이벤트의 시작 시각(beginTime)과 종료 시각(endTime)이 저장된다.@Getter@Entity@Table(name = "events")@NoArgsConstructor(access = AccessLevel.PROTECTED)public class Event extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; ..

Global cache vs. Local cache분산 환경에서 Global cache는 다수의 서버가 바라볼 수 있는 캐시를 말한다. 예를 들어, MSA 환경에서 Redis를 캐시 서버로 띄워놓고, 여러 서버들이 DB에 있는 원본 데이터를 조회하는 것이 아니라 Redis에 캐싱되어 있는 데이터를 조회하는 것이다. 이를 통해 DB connection 요청을 줄일 수 있으며 Redis의 빠른 조회 성능을 통해 전체 시스템의 성능도 향상할 수 있다. 하지만 이는 원래 DB로 가야 했던 요청이 캐시 서버로 옮겨진 것일 뿐이라, 만약 조회가 매우 빈번하게 발생하는 데이터인 경우에는 캐시 서버가 그 부하를 모두 견뎌야 한다. 그리고 캐시 서버에서 데이터를 가져올 때마다 서버에서 메모리 할당이 발생하고 이후 GC가..

문제 상황이벤트 목록을 조회하는 API를 구현하는 중이었다. 이벤트 목록은 자주 조회되는 데이터라, 매 순간마다 DB에 요청을 보내는 것은 비합리적이다. 한번에 얻을 수 있는 DB connection의 개수는 한정적이기 때문에 DB에게 부하를 많이 주게 되면 connection을 얻기 위해 기다리는 시간이 늘어날 수 밖에 없고, 이벤트 목록 조회 뿐만 아니라 다른 요청들도 DB에게 가게 된다면 그 파급 효과가 더욱 커지게 된다. 따라서 Redis에 캐싱해두는 전략을 사용하여 DB connection 요청을 줄이고자 하였다. (+ 이벤트 목록은 모든 사용자에게 동등하게 보이는 Global 데이터이기 때문에 Redis cache에 올려두어도 문제가 없다.) 조회 로직은 다음과 같다.1. Redis에 캐싱된..

Pagination(또는 Paging)은 데이터를 조회하는 경우, 데이터 전체를 가져오는 것이 아니라 데이터를 페이지라는 일정량으로 쪼개어 요청한 페이지에 대한 데이터만 일부분 가져오는 기법이다. 전체 데이터가 매우 많은 경우에 Pagination을 통해 DB의 부하를 줄일 수 있으며, '무한 스크롤'을 위한 조회 API 구현 시 많이 사용하는 방법이다. Pagination을 구현하는 방법에는 여러 가지가 존재하는데, 이 글에서는 Offset 기반 pagination과 Cursor 기반 pagination을 알아본다. 그리고 nGrinder를 통한 부하 테스트를 진행하여 서로를 비교하고 왜 이런 차이가 발생하는지를 정리한다.예시 상황상품(Product) table에는 300,000건의 데이터가 저장되어 ..