봉황대 in CS

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건의 데이터가 저장되어 ..

* 본 글은 ‘친절한 SQL 튜닝’ 책과 Oracle 공식 문서들을 바탕으로 작성하였습니다. (참고한 문서의 링크는 하단에 첨부)  SQL Processing 과정 중에서 Soft parse와 Hard parse는 각각 어떤 과정이고, 언제 선택되는가? 먼저 여기에서 중심이 되는 구조인 Library cache에 대해서 알아보자.  Library CacheSQL과 PL/SQL code를 재사용할 수 있도록 caching 해두는 메모리 공간이다. System Global Area(SGA) 내부 Shared pool에 위치하여, 모든 server와 background process가 공유한다.  Why caching & reusing SQL, PL/SQL codes ?왜 SQL과 PL/SQL code를 ca..