배경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비관..
원래 정해진 형식때로 작성했었는데 생각해보니 그럴 필요까지는 없을거 같다는 생각이 든다.아무튼이번엔 DDD에 대해 학습을 하였다. 대략적으로 도메인에 대해 학습할 수 있었던 시간이었던거 같다.저번주 화욜인가 수욜인가 멘토링을 끝나고 도메인이 어떤건지 고민을 해보았고그것을 같은 팀원분들께 공개 한적이 있었다.방금 확인했는데 수욜날 멘토링을 했었군요 암튼제가 어제 멘토링 끝나고 고민해봤는데요..도메인은 '재료'로 비유할 수 있을 거 같아요.예를 들어, 계란국을 요리한다고 했을때,계란,물이 도메인이라는 생각이 들었어요.도메인에서 서로 통신 하면 안된다는건재료의 순수성을 해치면 안된다는 걸로 이해가 되어집니다.이를 잘 알 수 있는 방법으로 계란과물을 합쳤을때 새로운 단어인 A로 바꿀 수 있다면A라는 도메인으로 ..