DevKim

https://devkingdom.tistory.com/233 [Linux] IO 부하를 예측하는 명령어 두가지 iotop 와 iostat 지난번에 cpu, memory의 상태를 측정하는 기본적인 명령어인 top를 정리했었다. https://devkingdom.tistory.com/232 [Linux] linux 인프라 지표 모니터링을 하기위한 명령어 top 요즘 모니터링에 대한 관심도가.. devkingdom.tistory.com sudo yum install sysstat iostat -dxm 1 -p ALL | awk '{now=strftime("%Y-%m-%d %T "); print now $0}' rrqm/s : 디바이스 큐에 대기 중인 초당 읽기 요청 건수 wrqm/s : 디바이스 큐에 대기 ..

0. 개요 - 자주 호출되고 하루동안 업데이트가 발생하지 않는 데이터를 반복해서 DB에 요청을 하는 과정을 캐시 서버를 도입하여 개선해보려고합니다. 1. 캐싱을 적용할 대상 탐색 Webtooniverse 랭킹 Naver 랭킹 Kakao 랭킹 베스트 리뷰어 추천 웹툰 베스트 리뷰 2. 스케쥴러를 사용하여 매일 자정 Cache를 초기화 @EnableScheduling @Configuration @RequiredArgsConstructor public class Scheduler { private final RedisTemplate redisTemplate; private final WebtoonService webtoonService; @Scheduled(cron = "0 0 0 * * *") public ..

[ 상황 ] 현재 웹툰 객체와 장르는 다:다 연관관계로 이루어져있으며, 중간에 join table을 두어 1:다, 다:1로 DB 구성한 상황이다. [ 문제점 ] 하나의 웹툰이 2개의 장르를 가지고 있기 때문에 Webtoon 테이블을 조회시마다 WebtoonGenre 테이블과 Genre 테이블 join하여 데이터 가져온다는 것이 문제이다. 서비스 특성상 Webtoon 테이블이 굉장히 조회가 빈번한데, 이때 계속 불필요한 쿼리문이 나가는 것을 발견했다. [ 해결 ] Querydsl에서 Result Aggregation 이라는 것을 제공한다는 것을 알게되었고 한꺼번에 list로 불러오는 코드로 단순화하게되었다. (기존) - 웹툰을 찾아온 뒤 웹툰으로 장르를 재조회하여 query 2회 발생 및 genre들을 l..

본 포스팅은 성능 테스트를 진행하면서 겪은 이슈와 이를 해결해나가며 겪은 개인적인 경험을 공유하고자 작성하였습니다. 고로 포스팅에 잘못된 점은 지적해주시면 감사하겠습니다 :) [ 공통 테스트 환경 ] - 가벼운 테스트 툴을 빠르게 사용하기 위해 Artillery를 사용하였습니다. - 2vCPU, 2GB 메모리 서버 3대로 Scale out을 하였으며 Redis 서버 사양은 1vCPU, 2GB 메모리 서버 한대입니다. [ 테스트 환경 #1 ] - 메인 페이지의 웹투니버스/네이버/카카오 랭킹 기능을 테스트하였습니다. - Redis 캐시를 이용해 각 조회 기능을 빠르게 가능하도록 구현했습니다. [ 시나리오 #0 ] -duration 300 arrivalRate 1 2. 네이버/카카오 [ 시나리오 #1 ] 1...

본 포스팅은 성능 테스트를 진행하면서 겪은 이슈와 이를 해결해나가며 겪은 개인적인 경험을 공유하고자 작성하였습니다. 고로 포스팅에 잘못된 점은 지적해주시면 감사하겠습니다 :) * 테스트는 가장 자주 호출되고, 필수적인 API 위주로 측정하였습니다. [ 과정 ] 성능 테스는 다음과 같은 순서로 진행하고자 합니다. 1. 단일 요청에 대한 Latency 확인해보자 - 만약 Latency가 기대하는 Latency보다 높다면 scale out으론 해결되지 않을 것이다. 단일 요청에 대한 Latency를 먼저 확인해보고, 결과를 바탕으로 병목을 의심해보고자합니다. - Latencty는 500ms를 기준으로 잡았습니다. 2. scale out을 해보고 - Latency는 현재 500ms 이내를 기대하고 있다. - 만..

[ 현재 프로젝트 구조의 문제점] 현재 프로젝트 구조는 이러하다. 과금 문제 때문에 jenkins → git action 으로 CI 툴을 변경했고, S3에 jar 파일을 올려 CodeDeploy에서 EC2에 배포하고 있는 상황이다. 이런 구조를 계속 가져가게된다면, 새로운 V2를 배포하기 위해서, V1 서버를 내려야하는데 이 과정에서 유저는 서비스를 이용할 수 없는 상황이다. 문제는 현재 프로젝트에서는 기능이 주기적으로 추가되고 이에 따라 배포도 빈번하게 일어나고 있기 때문에, 매번 배포시마다 사용자가 서비스를 이용하지 못하게 된다면, 유저 입장에선 서비스에 대한 신뢰도 또한 감소될 것 이라고 생각한다. 무중단 배포가 시급한 상황이었다. [ 다양한 배포 전략 ] MSA 아키텍처를 지향하고 있는 추세이다보..

[ exists 쿼리 개선 ] 해당 id의 존재 여부 확인하는 쿼리 기존의 count 쿼리 날려서 1개 이상 존재하는지 확인하는 코드에서 아래의 코드로 리팩토링 count 쿼리는 전체 데이터를 조회해야하니, 데이터가 많아질수록 성능을 기대하긴 힘들다. Data Jpa의 exists 메소드 쿼리를 사용해도 내부적으로 count 쿼리가 날라가는 것은 마찬가지이다. public boolean existsById(Long userId,Long webtoonId){ return jpaQueryFactory.from(myList) .where(myList.user.id.eq(userId), myList.webtoon.id.eq(webtoonId)) .select(myList.id) .fetchFirst()!=nul..

더 나은 배포 프로세스를 적용하기 위해 docker + jenkins로 배포해보고, jenkins + webhook으로 배포 자동화까지 간단한 실습에 적용해보면서 내부적으로 어떻게 동작하는지에 대해 생각할 수 있는 시간이었다. 과금 문제로 인해, 지금 당장은 Jenkins 대신 Github Action을 프로젝트에 적용해보려고한다. 현재 프로젝트 구조는 이렇다. 아직 캐싱 서버와, nginx는 도입하지 않았다. 필요하다고 느껴질 때 그 이유와 함께 도입할 예정이다. [ GitThub Action ] Github Action은 Github에서 바로 소프트웨어 Workflow를 자동화할 수 있는 도구이다. 간단하게 말하면 Github에서 직접 제공하는 CI/CD 도구이다. 장점 사용하면서 느꼈던 가장 장점은..