배경주문과 결제에는 굉장히 많은 이벤트들이 존재한다.재고, 포인트, 쿠폰등등의 이벤트들이 존재한다.현재는 이것들이 하나의 트랜잭션에서 동작을 하고 있다.각각의 책임을 분리하기 위해서는 어떻게 해야할까?커멘드와 이벤트커멘드와 이벤트는 뭐가 다를까.. 이것들은 각각 커멘드는 명령이고, 이벤트는 사건이라는 뜻을 가지고 있다.예를 들어, 주문, 결제, 쿠폰, 재고, 포인트라는 등장인물이 존재한다고 생각해보자.내가 선택한 부분은주문 -> 쿠폰 등록결제 -> 포인트 사용결제 -> 재고 차감결제 -> 주문 완료요렇게 작성이 되어진다. 가장 맨위로 예시를 들어보면 주문이 쿠폰은 명령일까 사건일까? 주문 입장에서 쿠폰 도메인한테 명령을 보내는 것이 맞을까? 아니면 주문 입장에서 쿠폰 생성은 하나의 사건일 뿐인걸까?명령과..
배경PG사가 도입이 되었다. 원래 같으면 feign을 사용할지 restTemplate를 사용할지 결정만하고 그걸 사용했었던거 같다.하지만 그리 간단한 문제가 아니었다. 서킷 브레이커라고 들어는 봤나??사실 서킷 브레이커는 전기 쪽에서 나온 용어라 알고 있다. 서킷 브레이커를 한글로 다시 말하면 회로 차단기다.실생활로 예시를 들면, 우리가 스위치를 통해 불을 키고 끄는것을 하게 되면 방에 불이 켜지고 꺼지고를 반복한다. 이것이 서킷 브레이커다.하지만 설정들이 생각보다 헷갈렸다. 그것을 기록해 두면 조금더 편할거라 생각해 기록해둔다.나의 설정나의 설정은 다음과 같다.resilience4j: circuitbreaker: instances: # 'pg-payment' 라는 이름의 서킷 브레이커 설정..
언제 인덱스를 거는 것이 좋을까?책에 있는 인덱스를 생각해보면 인덱스는 A~Z 혹은 ㄱ~ㅎ으로 되어 있다.만약 인덱스가 뒤죽박죽이라면 책에서 정보를 쉽게 찾을 수 없을 거다.고로 인덱스를 건다는 건 어떤 의미일까 데이터를 쉽게 찾는다는 소리인데그게 뒤죽박죽 되어 있다면 의미가 없지 않을까 생각이 문득 들었다.보통 정보를 찾을때, 큰 정보 -> 중간 -> 작은 순서대로 정보를 찾는다.그래야 리소스를 최대한 줄일 수 있기 때문이다.카더널리티가 작은곳에 많다고 해서 작은곳에만 인덱스를 걸면 절대 안된다.아니 의미가 없다.왜냐하면 큰곳에서 데이터를 뒤지고 작은곳을 뒤져야 하는데어차피 큰 곳은 인덱스가 걸리지 않았다.그렇담 인덱스는 안 탈거고 의미가 없지 않을까?어찌 되었든 인덱스를 걸려면 어떤 데이터로 가장 먼..
이번엔 조회 성능을 개선하기 위해 이것저것 적용해본거 같다.인덱스도 적용해보고반 정규화도 해보고캐싱도 해봤다.인덱스를 사용하면서 쿼리 플랜을 사용하고 그게 어떤지 분석까지 해보았다.다만 글에서는 그러한 부분들이 보이지 않아서 조금 아쉽다는 느낌이 들었다.단순히 사진만 찍어서 올렸었는데 모르는 사람들이 봐서는 그래서... 어쩌자는 거지?라는 반응이 나올 수 도 있을거 같다라는 생각이 든다.물론 k6를 통해 얼마나 향상이 되었는지도 테스트 해보고 그걸 AI로 분석까지는 했다.하지만 세세하게 진행하지 못한점이 좀 아쉽다는느낌이 든다.또한, 인덱스를 건다고 해서 단순히 성능이 기하급수적으로 올라가는건 아니었다. 오히려 잘못 사용하면 성능이 떨어질 수도 있다.인덱스는 흔히들 책에서 쉽게 내용을 찾을 수 있는 정보..
인덱스 적용브랜드 Id만 인덱스를 거는 경우는 어떨까? 생각보다 속도는 비슷하게 나오는듯하다.요렇게 나왔는데 이건 안 거는거랑 비슷한거 같다라는 생각이 들었다.그래서 좋아요를 기준으로 시도해보자.좋아요를 하니 생각보다 빨라졌긴했지만 그렇다고해서 의미있는건지는 잘 모르겠다. 복합 인덱스로 설정하고 다시 설정해보자.놀랍게도 product_status에 대한 rows값이 1로 줄었다는것을 알 수 있었다.그러면 더 나아가서 stock도 최적화를 한다 생각하면 stock도 productId를 인덱스로 걸면 어떨까?rows가 반토막 난거말고는 딱히 특징이 없었다.하지만생각만큼 쿼리 속도는 빠르지 않았다.이유가 뭘까? (신기하군.. _. ;;)음.. 근데 신기하게도api로 쐈을때는 속도는 빨라졌다.계속 날려보니 0...
