들어가며 개인적으로 요즘 개발 트렌드에서 Spring Data JPA가 공식이 되었다고 생각될 만큼, 개발자들이 ORM(Object Relational Mapping)이라는 것을 많이 사용합니다. 하지만 많이 사용하는 것과 잘 사용하는 것은 명백히 다르다고 생각합니다. 실제로 Spring Data JPA, JPA, Hibernate의 관계와 배경을 설명할 수 있는 사람이 몇이나 될까요? 최근에 Spring Data JPA를 사용하여 개발하는 도중 Spring Data JPA는 기본적인 구현체들을 극단적으로 추상화시키고 있다는 생각이 들었습니다. Spring Data JPA 공식 문서에서는 Spring Data JPA에 대해서 다음과 같은 정의를 내놓았습니다. 더 큰 Spring Data 제품군의 일부인 ..

들어가며 분산 락을 구현하는 방법은 Zookeeper, Redis 등 여러가지 방법들이 있습니다. 다만, Zookeeper나 Redis를 이용하여 분산 락을 구현하게 되면 인프라 구축에 대한 비용도 무시할 수 없습니다. 하지만 MySQL에서는 분산 환경에서의 락을 구현하기 위한 자체 락을 제공합니다. 이는 네임드 락(Named Lock)이라고 불리며, MySQL에서만 지원되는 락입니다. 분산 락의 사용량이 추가적인 비용을 들일만큼 크지 않다면 MySQL이 제공하는 락을 사용하는게 적절하다고 생각합니다. Named Lock 살펴보기 MySQL이 제공하는 네임드 락을 사용하기 위해서는 관련 함수를 사용해야 합니다. 함수의 종류와 설명은 다음과 같습니다. GET_LOCK(String, timeout) 입력받은..

들어가며 지난 글에서 JPA가 알아서 동시성 이슈를 해결해주는 모습을 보였지만, 어디까지나 운이라는 결론을 내렸습니다. 이어서 어드민 페이지 동시성 이슈를 직접 해결해보겠습니다. 두 번의 갱신 분실 문제 JPA가 동시성 문제를 파악하고 예외를 던져주는 행위가 운이라고 했는데, 이는 영속성 컨텍스트를 계속 동기화 시켜주는 부분을 제거하면 곧 바로 동시성 문제가 다시 발생하기 때문입니다. 여기서 말하는 동시성 문제란 두 번의 갱신 분실 문제를 뜻하는데, 아래와 같이 3가지 상황이 존재합니다. 최초 커밋만 인정하기 : 첫 번째로 커밋한 트랜잭션의 변경 사항만 반영하고, 마지막 트랜잭션의 변경 사항은 무시한다. 마지막 커밋만 인정하기 : 마지막으로 커밋한 트랜잭션의 변경 사항만 반영하고, 첫 번째 트랜잭션의 변..

들어가며 이번 글에서는 팀 프로젝트의 어드민 페이지에서 데이터 수정에 관련한 동시성 이슈를 알아보려고 합니다. 저희 서비스의 관리자 페이지는 유저들에게 직접적으로 보이는 식품 데이터를 생성/수정/삭제할 수 있는 기능을 제공합니다. 선착순 시스템 등과 갑자기 많은 트래픽이 몰리진 않겠지만, 유저와 사료를 파는 브랜드에게 직접적인 영향이 가는 영역이기 때문에 한 번 발생하게 된다면 서비스 운영에 치명적으로 작용할 수 있습니다. 어떤 문제가 발생할까 그렇다면 만약 2명의 어드민이 동시에 하나의 식품을 수정하게 된다면 어떤일이 발생할까요? 아래는 사료 데이터를 수정하는 메서드 2개를 동시에 실행하는 테스트 코드입니다. 저는 처음에 낙관적 락과 비관적 락을 모두 사용하지 않은 상태였기 때문에 두 번의 갱신 분실 ..

커넥션 풀(Connection Pool)이란? 커넥션 풀은 데이터베이스와 연결된 커넥션을 미리 만들어 놓고 이를 pool로 관리하는 것입니다. 즉, 필요할 때마다 풀의 커넥션을 꺼내 사용하고 반환하는 기법입니다. 이처럼 미리 만들어 놓은 커넥션을 이용하면 Connection에 필요한 비용을 줄일 수 있기 때문에 DB에 빠르게 접근할 수 있습니다. 또한 커넥션 풀을 사용하면 커넥션 수를 제한할 수도 있어서 과도한 접속으로 인한 서버 자원 고갈을 방지할 수 있습니다. HikariCP란? SpringBoot를 사용해본 사람이라면 한 번쯤은 이름을 들어보셨을텐데요. HikariCP는 가벼운 용량과 빠른 속도를 가지는 JDBC 커넥션 풀 프레임워크입니다. SpringBoot는 커넥션 풀 관리를 위해 기본적으로 H..

문제 상황 프로젝트를 진행하면서 외부 API를 사용해야 하는 기능이 있습니다. 해당 API는 깃허브에서 PR(Pull Request의 List)를 조회하는 API입니다. 해당 API는 페이지네이션을 통해 접근해야 하는데요. 공식 문서를 살펴보면 한 번에 최대 100개의 PR만 가져올 수 있습니다. 사실 PR을 모두 조회할 필요는 없었습니다. 요구사항 특성상 많아봤자 한 번에 4~5개 정도의 PR만 조회하면 되었거든요. 하지만 무료 API를 제공하는 서드파티 입장에서도 그렇게까지 구체적인 API를 제공해주지는 않더라고요. 그리고 제공할 책임 또한 없습니다. 그렇다면 사용하는 입장에서는 할 수 없이 모든 PR들을 조회하고, 해당 PR들을 애플리케이션에서 가공해야겠죠. 이 때 PR의 개수가 총 300개라면 최..

지난 글에 집고팀에서 사용하는 쿼리를 살펴보고 개선 방안들을 도출해봤습니다. 이번 글에서는 실제로 코드와 쿼리를 고쳐보고 클라이언트에서 받는 데이터까지 가공하면 어디까지 개선이 가능한지 더 자세히 살펴보겠습니다. Entity보다 DTO를 서비스 코드와 Response 프로퍼티들을 분석해본 결과, 아래와 같은 총 4개의 프로퍼티만 필요로 했습니다. pet_food_id pet_food_name brand_name pet_food_image_url public List findPagingPetFoods( List brandsName, List standards, List primaryIngredientList, List functionalityList, Long lastPetFoodId, int size )..

우아한테크코스 팀 프로젝트를 진행 중입니다. 5차 스프린트 요구사항들 중 아래와 같은 요구사항도 존재했는데요. 서비스에서 사용하는 쿼리를 정리하고, 각 쿼리에서 사용하는 인덱스 설정 서비스에서 사용하는 모든 조회 쿼리와 테이블에 설정한 인덱스 공유 인덱스를 설정할 수 없는 쿼리가 있는 경우, 인덱스를 설정할 수 없는 이유 공유 기존 쿼리를 만들 때 어느 정도 개선을 해오면서 만들었었기 때문에 평소 쿼리에 대한 고민을 많이 해보지도 않았었습니다. 실제로 쿼리 개선이 필요할 만큼 TPS가 높지도 않았고요. 또한 어떤 쿼리가 문제인지 찾아내는 과정을 위한 학습도 되어있지 않았습니다. 그래서 이번 글에서는 아무것도 모르는 상태에서 기존 쿼리를 어떻게 개선해 나갔는지 천천히 정리해나가 보도록 하겠습니다. 이번에 ..

서론 톰캣 구현 미션을 마무리할 겸 그동안 공부한 간단한 톰캣 내부 구조, Request와 Response, parser를 알아보겠다. 우선 톰캣 만들기 미션 자체의 난이도는 체감상 높았다. 워낙 관련 지식이 없기도 했고, 로우 레벨을 개발하다 보니 새로운 문법들도 많이 보였다. 필자는 원래 CS나 너무 로우 레벨의 개념들에 대해서는 내가 개발하는 서비스와 관계가 별로 없을 거라고 생각했다. 실제로 여태 그랬다. 그런데 이번 미션을 진행하면서 정말 많이 느낀 점이 기본 지식, 즉 Java, CS 등을 더 자세히 공부해야겠다는 생각이 들었다. 괜히 시니어 개발자분들이 화려하고 트렌디한 기술보다 기본을 중시하는 이유도 알 것 같았다. 또한 미션을 진행하면서 톰캣 오픈소스에 총 2개의 PR을 기여했다. 톰캣의..

조만간 있는 테코톡을 준비하기 위해서 각 성능 테스트 툴들을 사용해보려고 한다. 그 과정에서 발생하는 문제들과 사용해 본 후 장단점들을 써보려고 한다. 먼저 nGrinder를 사용해 보겠다. nGrinder 구조 nGrinder는 크게 컨트롤러(Controller)와 에이전트(Agent)로 구성되어 있다. 컨트롤러는 관리를 위한 UI와 부하 스크립트 작성, 부하 테스트 설정 등의 기능을 지원하며, 관리한 에이전트들을 승인하거나 테스트를 시작해 부하를 발생시킬 수 있도록 제어한다. 에이전트는 컨트롤러의 명령을 받아 서버에 실제 부하를 발생시킨다. 따라서 컨트롤러를 통해 에이전트에 명령을 내리면, 에이전트는 우리가 작성한 스크립트대로 타깃 서버에 부하를 발생시킨다는 것이다. Install/Excute Con..