4 posts
복합 인덱스는 여러 컬럼을 묶어 추가하면 조회 성능이 좋아지는 기능이라고 생각하기 쉽다. 하지만 실제로는 컬럼의 개수보다 애플리케이션이 데이터를 어떤 조건으로 찾고, 어떤 순서로 정렬하며, 어떤 단위로 나누어 반환하는지가 더 중요하다. 예를 들어 다음과 같은 조회가 있다고 가정해보자. 특정 상태()의 데이터만 조회한다. 기본 키()를 기준으로 최신순 정렬한다. 페이지 단위로 결과를 반환한다. 데이터가 적을 때는 단일 인덱스만으로도 큰 문제가 발생하지 않을 수 있다. 하지만 데이터가 쌓이고 호출량이 증가하면, 데이터베이스는 인덱스를 사용하고도 최종 결과보다 훨씬 많은 데이터를 읽거나 별도의 정렬 작업을 수행하게 된다. 그렇다면 복합 인덱스는 어떤 상황에서 필요하고, 어떤 기준으로 설계해야 할까?…
우리 서비스의 주문 도메인에는 조금 특이한 특징이 하나 있다. 일반적인 상품 주문과 달리 SNS 마케팅 주문은 하나의 주문이 여러 개의 실행 단위로 쪼개진다. 예를 들어 “좋아요” 주문이 들어오면 시스템 내부에서는 다음과 같은 일들이 순차적으로 발생한다. 주문이 생성된다 결제 및 포인트 차감이 이루어진다 주문 상태가 “진행중”으로 변경된다 좋아요 작업이 여러 번에 나뉘어 실행된다 각 실행 결과가 개별 로그로 기록된다 모든 작업이 끝나면 주문 상태가 “완료”로 변경된다 이 과정에서 우리는 주문 하나를 처리하기 위해 수백, 많게는 수천 건의 실행 로그를 쌓고 있었다. 또한, 이 로그들은 단순한 디버깅 용도가 아니었다. 운영에서는 이 로그를 기준으로 주문 진행 상황을 판단했고 CS…
현재 재직 중인 회사에서는 SNS 마케팅을 하나의 상품으로 만들어 판매하는 서비스를 운영하고 있다. 기업이나 개인 사용자는 인스타그램, 블로그, 유튜브 등 다양한 SNS 채널을 대상으로 좋아요, 팔로워, 조회수와 같은 마케팅 상품을 주문할 수 있고 서비스는 이 주문을 실제 SNS 마케팅 작업으로 연결해주는 역할을 한다. 이 과정은 단순히 “주문을 하나 처리하는 것”에서 끝나지 않는다. 주문 생성 결제 및 포인트 차감 주문 상태 관리 SNS 마케팅 작업 집행 경우에 따라 외부 마케팅 솔루션 업체와의 연동 까지 이어지는 여러 단계의 처리 흐름이 존재한다. 특히, SNS 마케팅 작업은 자사에서 운영하는 서버가 직접 처리하기도 하고, 상황에 따라서는 외부 SNS 마케팅 플랫폼(공급자) 에 주문을 전달해 처리를 위임하기도 한다. 이처럼 하나의 주문이 여러 서버, 때로는 외부 시스템까지 거쳐 처리되는 구조이기 때문에 서비스 전반은 자연스럽게 마이크로서비스 아키텍처(MSA…
MikroORM 6.6.0은 눈에 띄는 대규모 기능 추가는 아니지만, “엔티티의 캡슐화와 일관성을 지켜주는 기능”이 정식 지원되었다는 점에서 상당히 의미 있는 릴리스라 생각한다. 이번 포스팅에서는 우리 팀이 채택한 컨벤션인 private 필드 + get/set accessor를 이용한 프로퍼티 관리 관점으로 이번 릴리즈 내용을 정리해보려한다. 공식 릴리스 노트 https://github.com/mikro-orm/mikro-orm/releases/tag/v6.6.0 버그 픽스가 아닌 피쳐 목록만 확인해보면 아래와 같다. core: allow control over relation filters in entity definition 기존 MikroORM에는 글로벌/엔티티 단위 필터(SoftDeleteFilter 등)가 있었지만, 특정 relation…
