랭킹이라가는건 뭘까 단순한 줄 세우기인가어떤 기술을 사용하면 효율적일까?사실 랭킹은 생각보다 쉽다.정확히 말하면 쉽게 생각할 수록 쉽게 만들 수 있는거라 생각한다.랭킹은 RDB로 하는것이 좋을까? 아니면 nosql로 하는것이 좋을까?정답은 없다고 생각한다.어떤 기술을 사용해야 한다는것은 없다고 생각한다.nosql중에는 레디스를 활용해서 데이터를 저장한다.결국 RDB랑 레디스와 비교를 하는것이 중요하다고 생각이 든다.어떤것이 더 랭킹 시스템에 어울릴수 있는지 생각할 수 있을거 같다.나는 랭킹 시스템을 레디스로 만들었는데 그 이유는 낮은 오버헤드와 읽기 성능이 좋다는 것을 높게 평가하였다.레디스는 다양한 자료구조를 지원하는데 그 중에서도 Zset을 이용하게 되었다. Zset은 레디스가 가지고 있는 낮은 오버..
배경카프카에서 수신한 정보를 토대로 계산하여 랭킹을 산출하고 있었다. 지금 보여주고 있는것이 사용자가 원하는 랭킹일까?잘 모르겠다. 실제로 운영이 되지 않는점도 크다고 생각한다. 만약 실제로 운영 된다면, 사용자들이 자주 들어오는 시간을 측정해서 가중치를 반영할 수도 있다 생각한다. 실제로 운영되는 환경이 아니기 때문에 부하테스트를 돌려서 확인하는것이 최선이지 않나 싶다.랭킹 서비스를 만들기 위해서는 데이터를 저장을 해야 한다. 그래야 그걸 통해 정보를 보여줄 수 있기 때문이다. 그래서 최대한 예상을 해서 작성해보려구 한다.수신 장치현재 카프카를 통해 데이터를 수신하고 있다.각 토픽에 맞게 메시지를 전송하고 있다.@Component@RequiredArgsConstructorpublic class Prod..
사실 카프카에 대해 잘 모르겠다. 아직..카프카가 고가용성이라고는 하지만 이게 개발자인 나에게 엄청나게 와닿지는 않았다.나야 프로듀서에서 컨슈머로 데이터만 잘 전달만 하는게 목적이기 때문이라 생각이든다.그렇다고 해서 저 부분이 중요하지 않는다는건 아니다.내가 말하고 싶은건 개발자인나에게 저것보다는 어떻게 사용할 수 있는냐가 더 중요하지 않나 생각이든다.그래서 그 부분에 초점을 맞춰서 공부를 했던거 같다.프로듀서의 개념토픽의 개념파티션키의 개념컨슈머의 개념배치 리스너 오프셋 개념..등등 여러가지 개념들을 그 초점에 맞추면서 공부를 하였다.저 개념들을 100% 전부 이해한건 아니지만 이제 시작이라 생각이 든다. 하나하나 전부 이해한것은 아니지만적어도 커다란 맥락에서 저러한 개념들을 왜 사용하는지 확실하게 이..
배경카프카는 어떤 목적으로 사용이 되어질까? 왜 하필 카프카일까?사실 반드시 카프카여야 된다는 이유는 없다고 생각한다. 카프카는 우리가 알기에는 메시지 큐정도만 알고 있는데사실 단순한 메시지 큐는 아니다. 정확히 말하면 분산 메세지 스트리밍 플랫폼이다.카프카에 대해서는 엄청나게 공부할것이 많지만 여기에서는 두 가지만 이야기를 할 예정이다. 프로듀서와컨슈머.. 프로듀서에서 메시지를 발송하고 컨슈머쪽에서 받는 그럼 시스템이다.구현하면서 생각보다 쉽지 않음을 느꼇다.어떤 부분에서 고민했는지 생각해보자.프로듀서프로듀서는 다음과 같이 작성을 하였다.public class LikeKafkaEventPublisher { private final KafkaTemplate kafkaTemplate; private f..
생각보다 이벤트에 대해 많은 고민을 하지 않았던거 같다.단순히 커멘드가 뭔지 이벤트가 뭔지 거기에 초점을 맞췄던거 같다.과연 내 프로젝트에 어떻게 이벤트를 적용할지 단순하게 생각했던거 같다.내가 생각한건주문 -> 쿠폰결제 -> 포인트결제 -> 재고좋아요 -> 집계 이렇게 생각을 했었다.이렇게 생각해도 크게 문제 될거 까지는 없지만 뭐랄까 어떤 흐름에서 어떻게 흘러가는지 그게 블로그글에 잘 드러내지 않은점이 아쉬움에 남는거 같다.그래도 잘한점은 커멘드와 이벤트를 어떻게 분리하고 고민한점은 나름 잘했던거 같다.나는 다음과 같이 커멘드와 이벤트를 분리하였다.커멘드는 특정 도메인이 타 도메인에게 메시지를 전달할것인가이벤트는 특정 도메인이 타 도메인에서 동작하는 행동을 알 수 있을까 였다.이런 기준으로 생각하니 ..
배경주문과 결제에는 굉장히 많은 이벤트들이 존재한다.재고, 포인트, 쿠폰등등의 이벤트들이 존재한다.현재는 이것들이 하나의 트랜잭션에서 동작을 하고 있다.각각의 책임을 분리하기 위해서는 어떻게 해야할까?커멘드와 이벤트커멘드와 이벤트는 뭐가 다를까.. 이것들은 각각 커멘드는 명령이고, 이벤트는 사건이라는 뜻을 가지고 있다.예를 들어, 주문, 결제, 쿠폰, 재고, 포인트라는 등장인물이 존재한다고 생각해보자.내가 선택한 부분은주문 -> 쿠폰 등록결제 -> 포인트 사용결제 -> 재고 차감결제 -> 주문 완료요렇게 작성이 되어진다. 가장 맨위로 예시를 들어보면 주문이 쿠폰은 명령일까 사건일까? 주문 입장에서 쿠폰 도메인한테 명령을 보내는 것이 맞을까? 아니면 주문 입장에서 쿠폰 생성은 하나의 사건일 뿐인걸까?명령과..
배경PG사가 도입이 되었다. 원래 같으면 feign을 사용할지 restTemplate를 사용할지 결정만하고 그걸 사용했었던거 같다.하지만 그리 간단한 문제가 아니었다. 서킷 브레이커라고 들어는 봤나??사실 서킷 브레이커는 전기 쪽에서 나온 용어라 알고 있다. 서킷 브레이커를 한글로 다시 말하면 회로 차단기다.실생활로 예시를 들면, 우리가 스위치를 통해 불을 키고 끄는것을 하게 되면 방에 불이 켜지고 꺼지고를 반복한다. 이것이 서킷 브레이커다.하지만 설정들이 생각보다 헷갈렸다. 그것을 기록해 두면 조금더 편할거라 생각해 기록해둔다.나의 설정나의 설정은 다음과 같다.resilience4j: circuitbreaker: instances: # 'pg-payment' 라는 이름의 서킷 브레이커 설정..
언제 인덱스를 거는 것이 좋을까?책에 있는 인덱스를 생각해보면 인덱스는 A~Z 혹은 ㄱ~ㅎ으로 되어 있다.만약 인덱스가 뒤죽박죽이라면 책에서 정보를 쉽게 찾을 수 없을 거다.고로 인덱스를 건다는 건 어떤 의미일까 데이터를 쉽게 찾는다는 소리인데그게 뒤죽박죽 되어 있다면 의미가 없지 않을까 생각이 문득 들었다.보통 정보를 찾을때, 큰 정보 -> 중간 -> 작은 순서대로 정보를 찾는다.그래야 리소스를 최대한 줄일 수 있기 때문이다.카더널리티가 작은곳에 많다고 해서 작은곳에만 인덱스를 걸면 절대 안된다.아니 의미가 없다.왜냐하면 큰곳에서 데이터를 뒤지고 작은곳을 뒤져야 하는데어차피 큰 곳은 인덱스가 걸리지 않았다.그렇담 인덱스는 안 탈거고 의미가 없지 않을까?어찌 되었든 인덱스를 걸려면 어떤 데이터로 가장 먼..
이번엔 조회 성능을 개선하기 위해 이것저것 적용해본거 같다.인덱스도 적용해보고반 정규화도 해보고캐싱도 해봤다.인덱스를 사용하면서 쿼리 플랜을 사용하고 그게 어떤지 분석까지 해보았다.다만 글에서는 그러한 부분들이 보이지 않아서 조금 아쉽다는 느낌이 들었다.단순히 사진만 찍어서 올렸었는데 모르는 사람들이 봐서는 그래서... 어쩌자는 거지?라는 반응이 나올 수 도 있을거 같다라는 생각이 든다.물론 k6를 통해 얼마나 향상이 되었는지도 테스트 해보고 그걸 AI로 분석까지는 했다.하지만 세세하게 진행하지 못한점이 좀 아쉽다는느낌이 든다.또한, 인덱스를 건다고 해서 단순히 성능이 기하급수적으로 올라가는건 아니었다. 오히려 잘못 사용하면 성능이 떨어질 수도 있다.인덱스는 흔히들 책에서 쉽게 내용을 찾을 수 있는 정보..
인덱스 적용브랜드 Id만 인덱스를 거는 경우는 어떨까? 생각보다 속도는 비슷하게 나오는듯하다.요렇게 나왔는데 이건 안 거는거랑 비슷한거 같다라는 생각이 들었다.그래서 좋아요를 기준으로 시도해보자.좋아요를 하니 생각보다 빨라졌긴했지만 그렇다고해서 의미있는건지는 잘 모르겠다. 복합 인덱스로 설정하고 다시 설정해보자.놀랍게도 product_status에 대한 rows값이 1로 줄었다는것을 알 수 있었다.그러면 더 나아가서 stock도 최적화를 한다 생각하면 stock도 productId를 인덱스로 걸면 어떨까?rows가 반토막 난거말고는 딱히 특징이 없었다.하지만생각만큼 쿼리 속도는 빠르지 않았다.이유가 뭘까? (신기하군.. _. ;;)음.. 근데 신기하게도api로 쐈을때는 속도는 빨라졌다.계속 날려보니 0...
TD;DR읽기 성능을 해결할 수 있는 여러 방법들중에 어떤 방법을 선택해야 효과적일까요?상품 데이터 100만건, 브랜드 10만건으로 테스트를 진행해볼 예정입니다.2.87s에서 5ms으로 성능 개선한 과정을 작성해놨습니다.어마무시시한 성능개선은 다음과 같이 진행을 하였습니다...* 이미지는 변경될 수 있습니다.데이터 세팅데이터는상품 100만건브랜드 10만건나머지는 최대한 중복이 되지 않게 설게 되어질 예정이다.이렇게 진행할 예정이다.기존에는 브랜드 4건, 100만건을 비교해봤지만 생각보다 브랜드 쪽에 4건을 인덱스로 걸어봤지만 엄청난 효과를 보지 못하였다. 실험 결과는 그대로 남길 예정이며, 최종 결과에는 반영이 되어지지 않을 예정이다.기존 테스트 url: https://b-programmer.tist..
TL;DR: 낙관락과 비관락을 고르는 기준에 대해 설명합니다.배경그 전에도 낙관락, 비관락을 해봤기때문에 금방할 줄 알았다.하지만 아니었다. 어디서 부터 문제 였을까?생각하기에는 비관락을 사용하든, 낙관락을 사용하든 똑같은 결과가 나올거라 생각했다.이론상으로 생각했을 때, 낙관락은 충돌이 적은 상황에서 사용하고 비관락은 충돌이 많은 경우에 사용한다고 한다.또, 성능적으로는 낙관락이 더 우수하다는데 그게 사실인지도 궁금해졌다.낙관락, 비관락이 뭘까?인터넷에 낙관락, 비관락을 검색하면 무수히 많은 양의 낙관락과 비관락에 대해 알려주고 있다.그런대도 잘 모르겠다.내가 생각할때 영어를 한국어를 번역이 잘못했다고 생각한다.그러면 이걸 영어로 보는것도 나쁘지 않다고 생각한다.낙관락: Optimistic Lock비관..