최신 글
개요500만개의 레코드에서 키워드 기반 문자열 검색을 수행했을 때, 속도가 저하되는 문제를 MySQL의 Full-Text Search를 통해 해결해보려 한다. 개선 결과 기존 API 처리 시간 1185ms → 564ms로 약 52% 성능 개선이 이뤄졌다.  기존 쿼리의 문제점아래는 기존에 사용하던 쿼리이다. 키워드를 기반으로 post 테이블을 검색한다.explain select *from post pjoin category c on c.category_id = p.category_category_idwhere p.title like '%**:keyword**%' and p.region_region_id in (**:region_ids**) and p.status not in ('HIDE', ..
이슈 내용개발자가 제어할 수 없는 요소에 대한 테스트 용이성과 직접적으로 의존하면 안 되는 모듈의 클래스를 의존하고 있진 않은지 테스트하기 위해 인터페이스를 두고 테스트 더블을 직접 구현할 수 있도록 설계했다. 코드의 크기가 작을 때는 아무런 문제가 되지 않았지만, 기능과 의존성이 추가될 때마다 직접 구현할 테스트 더블이 증가했고 이는 생산성 저하와 더불어 테스트 전체의 크기가 커지는 영향을 미쳤다. 해당 문제가 발생한 이유와 해결방법에 대해 정리해보려 한다.  테스트 더블을 직접 구현한 이유Mockito 라이브러리를 사용하면 쉽게 테스트 더블을 생성할 수 있다. 하지만 이전 프로젝트에서 적용해본 결과 비즈니스 로직에서 bootstrap, framework 모듈의 클래스를 직접 의존하진 않는지 파악할 수..
https://github.com/f-lab-edu/used-trading-market GitHub - f-lab-edu/used-trading-market: [당근마켓 모티브] 개인 간 거래 플랫폼 API 서버[당근마켓 모티브] 개인 간 거래 플랫폼 API 서버. Contribute to f-lab-edu/used-trading-market development by creating an account on GitHub.github.com중고 거래 API 서버에 Kafka를 적용하고 이벤트를 통해 비동기적으로 로직을 처리하려고 한다. 아래의 사진은 프로젝트 RDB의 일부이다. Member 테이블은 Post, Region 테이블을 참조하고 있다. Post는 Member를 통해 작성자의 Region을 간접..
· CS
개요네트워크 시스템에서 처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치이다. 예를 들어 HTTP 통신을 수행하는 클라이언트와 서버가 존재한다고 가정해보자. 서버는 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한하고 싶을 수 있을 것이다. API 요청 횟수가 제한 장치에 선언된 임계치를 넘어서면 해당 클라이언트의 다음 요청은 block 되며 버려지거나, 추후 처리를 위해 큐에 보관된다. 요청이 block된 경우 HTTP status code 429 - Too many requests 를 응답한다. 또한 아래의 HTTP 헤더 값을 사용하여 클라이언트에게 적절한 정보를 응답할 수 있다.X-Ratelimit-Remaining: 윈도 내 남..
· 일기
⌜오브젝트⌟가 쓰여진 이유프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다. 이 책은 객체지향 패러다임에 대한 책이다. 이 책의 목적은 객체지향 패러다임이 제시하는 프로그래밍 패러다임을 설명하는 것이다. 객체지향 패러다임이라는 용어를 사용할 때, 어느정도 유사한 그림을 머릿속에 그릴 수 있는 기반을 제공할 것이며, 객체지향에 대한 오해를 제거하고, 객체지향 프로그래밍을 하는 개발자들이 동일한 규칙과 표준에 따라 프로그램을 작성할 수 있게 할 것이다. 도서를 학습하며하루에 약 6~8시간 꼬박 일주..
· 일기
⌜오브젝트⌟라는 도서를 읽기 전에 내가 자바를 공부하고 지금까지 약 1년 5개월, 자바 기본 서적 2권, ⌜객체지향의 사실과 오해⌟, ⌜스프링 입문을 위한 자바 객체지향의 원리와 이해⌟, ⌜클린 아키텍처⌟, ⌜마이크로서비스 패턴⌟ 및 다수의 도서들과 여러 자바 및 스프링 강의을 듣고, 설계해본 경험을 바탕으로 객체지향에 대해 간단하게 나의 생각을 정리해보려 한다. 객체 지향은 뭘까? 객체를 통한 프로그래밍을 지향한다는 의미이다. 객체란 뭘까? 상태와 행위를 가지고 자신의 상태를 자신이 관리하며, 행위를 통해 의사소통하는 데이터의 집합이다. 상태란 뭘까? 자신이 관리하는 데이터이다. 행위란 뭘까? 자신의 상태를 변경하거나, 외부에게 건네 줄 데이터를 메서드를 통해 제공하는 것이다. 왜 객체를 지향해야 하는..
· Database
일단 데이터베이스의 성능 튜닝의 관건은 어떻게 디스크 I/O를 줄일 것이냐 일 때가 상당히 많다. CPU나 메모리는 대부분 전자식 장치지만 하드 디스크 드라이브는 기계식 장치이다. 그래서 데이터베이스 서버에서는 항상 디스크 장치가 병목이 된다. 물론 플래시 메모리를 장착하여 디스크의 성능을 높인 SSD를 장착한다면 병목은 하드 디스크 보다는 줄어들겠지만, 디스크의 헤더를 움직이지 않은 순차 데이터 처리의 경우에는 두 디스크가 큰 성능 차이를 보이진 않는다. 인덱스란?인덱스는 디스크 혹은 메모리에 저장되어 있는 레코드에 빠르게 접근하기 위해 "정렬된" 데이터들이다. 인덱스는 정렬되어 있어야 한다 라는 중요한 특성을 가진다. 인덱스가 정렬되어 있지 않다면 인덱스의 데이터가 늘어남에 따라 탐색속도는 점점 저하..
· CS
단일 모델의 단점 주문 내역 조회 기능을 구현한다고 가정한다. 주문 내역은 여러 애그리거트의 정보를 가져와야 한다. Order에서 주문 정보, Product에서 상품 정보, Member에서 회원 정보, Payment에서 결제 정보 등 여러 애그리거트의 정보를 한 데 모아 응답해줘야 한다. 이렇게 조회를 위해 여러 애그리거트의 데이터가 필요한 경우 구현 방법을 고려해봐야 한다. 애그리거트를 사용하는 경우 각 애그리거트는 애그리거트ID 라는 식별자를 통해 참조하기에 Eager Loading 전략을 사용할 수 없다. 이는 한번의 SELECT를 통해 조회에 필요한 모든 데이터를 불러올 수 없다는 의미이므로, 무의미한 I/O를 발생시켜 성능 오버헤드가 발생할 수 있다. 그렇다고 애그리거트간 참조를 객체 레퍼런스를..
· CS
이벤트 이벤트는 여러 애그리거트에 걸처 처리해야하는 작업이 하나의 트랜잭션으로 묶일 필요가 없는 경우 사용하기 좋은 데이터 처리 방법이다. 예를 들어 주문 취소 및 환불 프로세스는 순차적으로 실행되어야 하지만 실제로 트랜잭션으로 묶여 처리될 필요는 없다. 주문 취소는 주문 도메인의 영역이고, 환불은 결제 도메인의 영역으로 분리되어 있다고 가정한다. 시스템 간 강결합 문제 만약 주문 취소와 환불이 하나의 트랜잭션으로 묶이는 경우를 생각해보자. 사용자로부터 주문 취소 요청이 들어왔을 때, 표현 계층은 주문 애그리거트의 상태를 주문 취소로 변경하고, 해당 주문의 결제 정보를 찾아 환불 프로세스를 진행한다. 포인트제도 처럼 결제가 완벽하게 애플리케이션의 내부에서 진행된다면 문제가 없을 것이다. 하지만 보통 결제..
· CS
애그리거트의 동시성 문제와 트랜잭션 관리 주문 애그리거트의 루트 엔티티인 Order 클래스가 존재한다고 가정한다. 또, 주문 애그리거트는 주문 상태가 배송 상태가 아닌 경우에만 배송지를 변경할 수 있다는 정책이 존재한다. 만약 하나의 주문 애그리거트에 대해 관리자 스레드가 주문 상태를 배송으로 변경함과 동시에 고객 스레드가 배송지를 변경한다면 문제가 발생할 것이다. 예를 들면 위와 같이, 관리자가 주문 레코드를 읽고(1), 그 다음 고객이 주문 레코드를 읽는다(2). 해당 상태에서는관리자와 고객 모두 본인이 원하는 변경(주문승인 → 배송중, 경기도 → 강원도)이 가능한 상태이다. 여기서 관리자가 먼저 배송승인 상태를 배송중 상태로 변경(3)하고 커밋했다면? 해당 애플리케이션의 주문 정책에 따르면 고객은 ..
· CS
도메인? 도메인은 어떤 문제를 소프트웨어로 해결하고자 하는 영역이다. 온라인 서점을 예로 들 수 있다. 하나의 도메인은 하위 도메인으로 나눌 수 있다. 온라인 서점은 회원, 주문, 배송, 결제 등의 도메인으로 나누어진다. 각 도메인의 하위 도메인의 이름이 같다고 해서 같은 도메인이라고 착각하면 안된다. 서로 다른 하위 도메인은 같은 용어를 사용할 뿐, 전혀 다른 의미와 데이터 정보를 가지고 있을 수 있다. 요구사항을 올바르게 이해하고 도메인을 잘 설정하려면 개발자와 전문가가 함께 이야기 해야 한다. 개발자도 도메인 지식을 갖추고 있어야 도메인 전문가가 요구한 것에 가까운 제품을 만들 수 있다. 처음 도메인 모델을 구성할 때 빠지기 쉬운 함정은 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것..
· CS
Blocking I/O vs Non-Blocking I/O blocking I/O 와 non-blocking I/O의 차이는 특정 시스템(OS, 웹 서비스, DB 인스턴스 등)에 요청 후 응답을 기다리는 시점에 스레드가 block되어 응답을 받을 때까지 기다리냐(Syncronous), block되지 않고 다른 일을 처리하냐(Asyncronous)의 차이이다. 즉, Blocking I/O는 입출력 작업을 동기적으로 처리하는 것, Non-Blocking I/O는 입출력 작업을 비동기적으로 처리하는 것이다. Non-Blocking I/O 에서 응답을 확인하는 방법 여기서 의문이 생길 것이다. Blocking I/O는 요청 및 응답을 동기로 처리하기에 스레드는 요청한 뒤 응답을 기다리다가 받아서 나머지 작업을 ..
· CS
여러 서비스에서의 Message기반 비동기 호출 아키텍처를 구성할 때, Message Driven Architecture, Event Driven Architecture의 선택지가 존재한다. 여기서 Message와 Event의 차이를 정리해보려 한다. 메시징 메시징은 서비스가 메시지를 서로 비동기적(메시지 브로커를 사용하는 경우와 통상적인 경우)으로 주고받는 통신 방식이다. 보통 메시징 기반 애플리케이션은 서비스 사이에 Message Brocker(대표적으로 Kafka, RebbitMQ)를 두어 비동기 통신을 구현하지만, 서비스가 직접 서로 통신하는 BrockerLess 아키텍처도 존재한다. BrockerLess 아키텍처는 통신할 애플리케이션이 가용중이 아니라면 내부적으로 큐를 두는 방식 등을 통해 메시..
문제 JAVA 17, Spring Boot 3.2 멀티 모듈 구조에서 각 모듈간의 의존성을 제대로 선언해놓고 실행했음에도 모듈에서 다른 모듈의 소스 정보를 못 읽어오는 이슈가 발생했다. 해당 문제를 해결하기 위해 애플리케이션 실행 지점에 다른 모듈의 객체를 생성하는 간단한 코드를 넣어 확인해보았다. 소스코드와 IDE 상에는 분명히 domain 모듈의 Product 클래스가 import 되어 있는데, 컴파일러가 Product 클래스를 import 하는 시점에 오류가 발생한다. 해당 프로젝트는 내가 예전에 작성하고 테스트까지 끝마쳤던 소스코드를 그대로 가져와서 동일한 환경으로 재구성 한 것이라 완벽하게 동일한 소스코드와 의존성을 가지고 있다. 이전의 프로젝트는 오류없이 정상적으로 실행되니 참 답답한 상황이 ..
🥕 이번 당근 클론 프로젝트에서는 기존에 자주 사용하던 MVC 구조가 아닌 헥사고날 아키텍처를 적용해보려 한다. 따라서 먼저 배경 지식을 습득후 간단한 예제 코드를 통해 헥사고날 아키텍처에 대해 익숙해지려 한다. 이전 포스팅과 이어집니다. MVC 구조에서 헥사고날 아키텍처로 🥕 이번 당근 클론 프로젝트에서는 기존에 자주 사용하던 MVC 구조가 아닌 헥사고날 아키텍처를 적용해보려 한다. 따라서 먼저 배경 지식을 습득후 간단한 예제 코드를 통해 헥사고날 아키텍처 hyunsb.tistory.com 이번에는 이전 포스팅에서 설명한 MVC 구조에서 싱글 모듈 헥사고날 아키텍처를 적용한 API 서버를 멀티 모듈로 마이그레이션 해보려 한다. 싱글 모듈의 한계점은 명확하게 존재한다. 모든 로직이 하나의 dependen..
hyunsb
개발일기