Nick Dev

sharding을 애플리케이션 단에서 구현하려면 sharding key를 정하고 해당 key를 바탕으로 런타임 시점에서 DataSource를 정해야 된다.이의 구현 과정을 설명해보려고 한다.동적 DataSourceRouting의 필요성DB에 가해지는 부하를 줄이기 위해서 sharding을 해야겠다고 판단했다.NoSQL의 경우, DB 단에서 알어서 sharding이 일어나기에애플리케이션 단에서 설정할게 없다.하지만 현재 사용하고 있는 DB는 MySQL이기에 애플리케이션 단에서 sharding key를 기준으로 동적으로 DataSource를 결정해야 된다.sharding key 고르기userId를 sharding key로 설정했다.내 비지니스 설정 상, 대부분의 api는 로그인 후에 사용 가능하고, 로그인 ..

5줄 요약nGrinder & pinpoint로 DB에서 getConnection()이 오래 걸린다는걸 파악함커넥션 풀 개수 조절해봄(10, 15, 20개)별 차이 없었음 😢sharding을 통해 DB 부하를 절반으로 줄여봄성능 개선됨 😊현재 서버 아키텍처 및 상황클라우드는 Naver Cloud Platform을 사용 중이다.nGrinder로 가상의 유저의 행동을 스크립트로 작성하고 이를 실행해보았다.한 유저가 회원가입 -> 로그인 -> 게시물 조회 100회, 게시물 생성 5회, 좋아요 누르기 15회, 북마크 누르기 15회하고 로그아웃 한다고 가정했다.- 즉, **한 유저 당 138개의 api를 호출**하게 된다.- connection pool(cp) size는 디폴트인 10이다.- 이러한 가상의 유저..

현재 상황 : 게시물 생성 시, feed 목록 구성 및 Elasticsearch DB에도 게시물 저장해야 함비동기 처리를 하지 않았다면....@Transactionalpublic void insertPost(CreatePostReq createPostReq, Long userId) { PostDTO newPost = PostDTO.builder() .contents(createPostReq.getContents()) .userId(userId) .createDate(LocalDateTime.now()) .updateDate(LocalDateTime.now()) .build(); // 1. 게시물 저장 postMapper.ins..

게시물 관련 정보들을 캐시했을 때와 하지 않았을 때의 성능(응답속도)을 비교해보자!!게시물 조회 로직에 캐시를 적용해야하는 이유유저가 게시물 단건 조회 시 아래와 같이 많은 정보를 모아서 리턴한다.게시물 정보이미지 정보게시물의 댓글 정보게시물 작성자 유저 정보이 정보들을 모두 DB에 질의해서 모아서 게시물 종합 정보를 리턴한다.문제점위 경우, posts/100 으로 게시물을 하나 조회하게 되면 DB에 최소 4번의 쿼리를 날려야 된다.SNS 도메인 특성 상, WRITE보단 READ의 비중이 훨씬 크기 때문에 READ의 성능을 개선할 필요가 있다.그래서 각 정보들을 Redis에 캐시해놓고 캐시된 데이터들을 조합해서 리턴하도록 코드를 리팩토링했다.각각 따로 캐시해놓고 조합해서 리턴하는 이유는 조합된 데이터를..

부하 테스트란...?실제 서비스 시작하기 전에, 현재 구축한 서버에서 어느정도 유저를 커버할 수 있는지, 대략 어느 시점부터 서버에 에러가 발생하기 시작하는지 알기 위해 부하를 부어보는 테스트다.실제 서비스할 서버 환경과 동일한 환경에서 부하를 늘려가면서 부어본다.⭐ nGrindernGrinder란?!네이버에서 진행한 오픈 소스 기반 플젝서버 부하 테스트를 위한 도구서비스 전에 서버가 얼마나 많은 사용자를 수용할 수 있는지 요청을 전송해봄으로써 서버의 성능을 측정해볼 수 있음nGrinder 주요 기능스크립트 레코딩웹 브라우저에서 사용자 동작을 녹화해 테스트 스크립트를 생성할 수 있음jpython을 사용해 스크립트 작성 가능분산 테스트다수의 agent 머신을 사용해 대규모 테스트 수행 가능실시간 모니터링테..

현재 상황게시물의 좋아요 개수는 무조건 캐시에 쓰고 이를 5분 마다 DB에 스케쥴링으로 반영하고 있다근데 현재 코드에서는 동시에 2개의 thread가 같은 좋아요 요청을 한다면 둘 다 잘 실행되어서 캐시에 좋아요 기록이 2개 남고, 좋아요 개수도 2개 증가한다둘 중 하나만 실행되고, 나머지 하나는 이미 좋아요를 눌렀습니다~라는 에러를 던져야 한다내 생각내가 공부했을 때, Redis는 Single Thread로 동작하기 때문에 동시성 이슈가 안생길 거라고 착각했다.사실 반은 맞고 반은 틀린 말이였다예를 들어 4번 post의 좋아요 개수가 10개라고 하자 이때 동시에 10개의 thread가 4번 post의 좋아요 개수를 1씩 증가시킨다고 하면single thread이기에 race condition 없이 10..

템플릿 메서드 패턴이란?정의상위 클래스에서 공통 로직을 수행하는 템플릿 메서드 구현하고이를 구현하는 하위 클래스에서 구현을 강제하는 abstract method를 두거나선택적으로 오버라이딩할 수 있는 hook method를 두는 패턴상위 클래스의 견본 메서드에서 하위 클래스가 구현하거나 오버라이딩한 메서드들을 호출하는 패턴내 프로젝트에 이 패턴을 어쩌다가 도입하게 되었는가...현재 상황초기 개발 시에는 게시물의 이미지들을 로컬에 저장하고 이미지 정보들(저장 경로, 원본 파일 이름)은 DB에 저장되도록 개발그리고 추후에 이미지 저장을 S3로 옮길 계획이였기에 ImageServie라는 interface를 두고 구현 클래스로 LocalImageService 클래스를 구현해 사용 중이였다시간이 흘러 이미지 저장..

@Cacheable이란?springframework의 어노테이션으로 메서드에 target은 메서드이고메서드의 리턴 값을 편리하게 캐시해주는 것이때, @cacheable은 특정 캐시(Redis) 등에 종속되지 않은 추상화된 기능이기에 캐시를 변경하여도 애플리케이션 코드에 영향을 주지 않는다동작 방식Spring AOP 방식으로 프록시 패턴을 통해 메서드의 반환 값을 자동으로 캐시해주는 방식이다.간단하게 Spring AOP와 프록시 패턴에 대해 알아보자정의Spring AOPAspect-Oriented Programming (관점 지향 프로그래밍)의 줄임말관점을 바탕으로 모듈별(메서드별)로 중복해서 나오는 횡단 관심사(cross concern)을 메서드로 걷어내고, 해당 관심사를 필요로 하는 곳에 해당 메서드를..

피드 push model?!push model이란?SNS의 피드를 구성하는 방법 중 하나pull model 도 있음A가 신규 게시물을 작성하면 A 팔로워들의 피드 목록에 신규 게시물 ID를 push하는 방식으로 피드를 구성⭐ kafka를 도입하는 이유신규 게시물 작성 과 팔로워들의 피드 목록에 신규 게시물 ID를 push 로직은 서로 다른 관심사임동기적으로 처리할 시 팔로워들이 많다면 각 팔로워들의 피드 목록에 push하는 로직이 오래 걸려서 게시물 생성 로직이 너무 오래 걸림그렇기에 두 로직을 동기적으로 처리하지 말고 kafka의 메시지 큐를 활용해 비동기적으로 처리메시지 큐는 kafka말고도 RabbitMQ도 있는데 왜 Kafka 써?Kafka가 MQ보다 분산 처리, 시스템에 적합kafka 설정1. ..

✅ 무한 스크롤 도입무한 스크롤이란?아래로 스크롤 하다가 컨텐츠의 마지막 요소를 볼 즈음 다음 컨텐츠가 있으면 불러오는 방식❓ 무한 스크롤 방식 도입 이유페이스북, 인스타 피드 처럼 아래로 계속 스크롤 하면서 보는 기능을 구현하고 싶어서 도입✅ 커서 기반 페이징📌 오프셋 기반 페이지네이션의 문제점1. UX 저하id가 10~6까지 5개 게시물을 읽고, 다음 페이지 읽기 전 3개의 게시물이 추가 되었을 경우오프셋 기반에서는 다음 페이지 요청 시 id가 8~4 인 게시물을 요청하게 된다 (위에 게시글이 3개 추가되서)이런 경우, id가 8, 7, 6인 게시물은 다음 페이지에서 중복되어 보이게 된다2. 성능 저하select *from postorder by id desclimit 10offset 1000000..