봉황대 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가 매우 높은 빈도로..

현재 진행하고 있는 프로젝트에서 이벤트 조회 기능을 구현하며, 이 기능에 부하를 주었을 때 어떤 문제가 발생하는지를 확인하고 여러 가지 기법들을 적용해 보며 해결하게 되었다. 이 과정을 통해서 배웠던 것들을 여기에 정리하고자 한다. 상황 설명각 이벤트에는 이벤트의 시작 시각(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건의 데이터가 저장되어 ..

[ 211106 6주차 강의 정리 ] + 워크북 & 스터디 내용 추가 (211113) * 복습 API = HTTP Method + URI 5주차 강의 중.. 2021.11.07 - [Computer Science/Server] - API / HTTP Packet / HTTP Method 리소스 식별 시 URN (Uniform Resource Name) - 이름 / URL - 위치 URN은 거의 사용하지 않기 때문에 URI ≒ URL라고 해도 무방 ❖ REST API 1. REST Representation State Transfer 강의 - HTTP로 정보를 보낼 때, URI를 어떻게 설계하고 어떤 메소드를 사용할 것인지 표준으로 정해놓은 약속 웹 애플리케이션 간 데이터 통신을 허용하는 API를 구축하는..

[ 211030 5주차 강의 정리 ] + 워크북 & 스터디 내용 추가 (211106) ❖ API 1. 정의 : Application Programming Interface 응용 프로그램(Application)에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든(Programming) 인터페이스(Interface) * Interface 1주차 워크북 중.. 1. 인터페이스 : 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템 5주차 강의 - 서로 다른 개체 끼리의 상호작용을 돕는 시스템 2. GUI (Graphical User Interface) : 사용자가 편리하게 사용할 수..

[ 211016 4주차 강의 정리(3) ] + 워크북 & 스터디 내용 추가 (211031) ❖ Key * 예시 홍길동과 홍길딩은 쌍둥이! 둘의 나이와 주소는 중복되기 때문에 이 값들을 통해서는 누가 누구인지를 구별할 수 없음 각각을 비교할 수 있는 속성(Attribute)은 이름! → Key 1. 정의 : DB에서 다른 튜플들과 구별할 수 있는 유일한 기준이 되는 속성 주어진 Relation에서 모든 인스턴스 가운데 유일함(Uniqueness)을 보장해 주는 하나 이상의 속성의 집합 2. 특성 ❏ 유일성 (Uniqueness) : 하나의 키 값으로 하나의 튜플을 유일하게 식별할 수 있어야 한다 ❏ 최소성 (Minimality) : 키를 구성하는 속성 하나를 제거하면 유일하게 식별할 수 없도록 꼭 필요한 ..