코딩은 내일부터

프로젝트를 진행하면서 외부 API를 다루는 경우가 많았다. 2023.09.14 - [우아한 테크 코스(우테코)/우테코 공부] - 파사드 패턴으로 외부 API와 DB 트랜잭션 범위 분리하기 파사드 패턴으로 외부 API와 DB 트랜잭션 범위 분리하기 DB 커넥션은 개수가 제한적이므로 단위 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 커넥션의 개수는 줄어든다. 따라서 하나의 작업이(트랜잭션이 필요 없는 로직이 붙어있는 jeoninpyo726.tistory.com 위와 같이 외부 API와 비즈니스 로직을 분리하였는데 외부 API가 장애가 났을 때 전체 로직이 피해받는 부분은 똑같았다. 그래서 Resilience4j라는 장애에 강한 시스템을 만드는데 도와주는 라이브러리를 공부해보았다. Resilie..

HikariCP란 데이터베이스 커넥션 풀 프레임워크는 대표적으로 Apache Commons DBCP, Tomcat DBCP, HikariCP 등이 있다. HikariCP는 스프링부트에 기본으로 내장되어 있는 JDBC 데이터베이스 커넥션 풀링 프레임워크이다. 스프링부트는 HikariCP를 사용할 수 있는 상황에서는 항상 HikariCP를 선택한다. 이러한 HikariCP는 커넥션을 하기 전에 미리 커넥션 풀(pool)에 커낵션을 저장해두고 필요할 때마다 재사용하는데 커낵션을 맺는 과정이 비용이 크다. 그래서 이러한 커넥션 풀의 size를 적절하게 설정하는게 불필요한 리소스를 줄이고 성능향상을 기대할 수 있다. 테스트 시나리오 시나리오는 다음과 같다. 카테고리 조회 마크다운 글 올리기 카테고리에서 글 목록 ..

문제의 상황 동글 서비스는 글, 카테고리를 저장할 때 동시성을 AOP를 사용해서 제어해주고있었다. AOP를 구현할 당시에는 동글 서비스가 서버 2대 이상 띄우는 시기가 먼 미랜줄 알고 서버가 2대 이상인 환경을 별로 신경 안 쓰고 있었다. 하지만.... 이번 6차 데모데이의 요구사항 중에 무중단 배포가 있어 무중단 배포를 학습하고 구현하는 도중 다음과 같이 서버가 동시에 2대 실행되고 있는 순간이 있다는 거를 확인하였다. AOP로 동시성을 제어하는 로직이 사용할 수 없어 다른 제어방법을 생각해야 했다. 구글에 분산락을 검색해 보면 Redis를 사용하는 방법 등등 여러 방법이 나오는데 이러한 기술을 사용하면 인프라 구축하는 비용 + 기술 학습 비용 이 들어가기 때문에 프로젝트 초기부터 사용해오고 있는 My..

전쟁을 시작하기 전 처음 동글 프로젝트의 테스트코드의 개수는 104개, 커버리지는 50%였다. 기능구현 하는데 집중해서 테스트코드가 빈약한 상태이다.(사실 핑계 아닌 핑계..) 그래서 이번 추석연휴가 길어 테스트코드 커버리지를 올릴 생각이다. 위에 이응준님 처럼 커버리지 100%는 아니지만 80%까지를 목표를 시작했다. 그리고 동글의 자신감을 되찾아줄 예정이다! 어떻게 테스트를 작성할 것인가? 레이어를 독립적으로 테스트하기 위해 슬라이스 테스트 방식으로 진행했다. 쉽게 말해 controller, service, repository 계층 각각을 단위테스트 한다고 생각하면 된다. Repository Layer Test 먼저 Reositroy 테스트는 @DataJpaTest를 사용해서 Repositroy 테스..

이번 포스팅에서 커버링 인덱스와 N+1문제를 Fetch Join을 사용해서 개선한 과정을 작성해 보겠다!! 1. 글의 내용 가져오는 쿼리 성능 개선 프로젝트를 진행하면서 성능 최적화를 위해 “지연 로딩”(Lazy Loading)전략을 사용해서 DB의 데이터를 가져왔다. 위에 writing 도메인을 보면 writing이라는 엔티티 안에 필드로 Blocks를 가지고 있다. 왜냐하면 위 사진과 같이 글 내부에 형태(h1, h2,… 리스트 등등)가 여러 개로 구성될 수 있기 때문이다. (파란색 블록이 1개의 블록을 나타낸다.) 즉, 하나의 글 안에 여러 개의 블록을 가지고 있는 1:N관계로 DB에 저장하고 있고, 블록마다 저장되는 형태도 다름으로 다음과 같이 여러 형태가 있고 Block으로 추상화를 적용하였다...

배경 상황 동글 프로젝트는 드래그 앤 드롭으로 글과 카테고리의 순서를 바꿀 수 있다. 그래서 글 과 카테고리의 순서구현을 LinkedList로 구현해서 각각의 테이블에는 next를 바라보고 있다. (각각의 글의 순서를 1,2,3 이런 식으로 저장하고 있으면 하나의 글의 순서가 변경될 때 나머지 글의 순서를 모두 변경해야 하는 문제가 있어 LinkedList로 구현하였다.) 이러한 상황에서 ngrinder로 부하테스트를 하던 중 위와 같이 순서가 마지막(next가 null)인 글이 여러 개 생성되는 것이다.. 그래서 글의 가져올 때 마지막글이 여러 개가 select 돼서 오류가 발생해서 사용자가 이러한 문제를 겪었을 때 DB에 직접 지워주지 않는 이상 그 사용자는 글을 못 가져오는 버그가 발생한다. 문제의..

DB 커넥션은 개수가 제한적이므로 단위 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 커넥션의 개수는 줄어든다. 따라서 하나의 작업이(트랜잭션이 필요 없는 로직이 붙어있는) 아무리 빨리 처리한다 해도 DBMS 트랜잭션에 포함될 필요 없다. 그리고 어느 순간 각 단위 프로그램에서 커넥션을 가지기 위해 대기해야 하는 상황에 안 좋을 수,,,,,, 위에 내용은 Real MySQL을 읽으면 나오는 내용으로 DB의 커넥션을 오래 가지고 있으면 웹 서버뿐 아니라 DB서버의 장애로 이어지는데 특히 지금 개발하고 있는 동글 서비스는 외부 API와 통신하는 로직이 많다. 만에 하나 외부 API를 요청할 때 서버와의 송수신의 문제가 생긴다면 현재 API요청 로직과 DB로 쿼리를 요청하는 로직이 섞여있어 DB서..

서론 및 버그가 일어나는 상황 동글 프로젝트를 하면서 개발서버와 실제 배포서버 2개의 서버를 사용하고 있는 상태였다.(DB서버까지 하면 총 3개다.) 회원가입 기능을 만들고 개발서버에서 1/10확률로 회원가입을 하면 똑같은 회원이 2명 생기는 거였다. 그래서 그 회원은 우리가 DB에서 1명 제거하지 않는 이상 로그인을 못하는 상황이다. 분명 OAuth로그인을 할 때 회원이 아니면 회원가입하게 로직을 구현해 놨는데 회원가입이 2번 일어나 나는 거였다. 프론트에서 말하길 react에서 api 로직을 수행하려면 useEffect라는 훅 내부에서 api 함수를 호출하는데 이 useEffect가 개발모드에서는 두 번 API가 호출된다. 그래서 이것 때문이구나 생각을 했는데 어떻게 해결해야 하는지 감이 안 왔다. ..