학습 키워드Unit Test / Integration Test / E2E Test테스트 Pyramid테스트 커버리지 vs 유의미한 테스트유닛테스트라는건 뭘까?서비스단에서? 컨트롤단에서? 음 아무래도 상관없으려나유닛테스트는 단위테스트라고 하며그림을 보면 알수 있듯이 단위 테스트는 테스트 피라미드 바닥에 존재하며 굉장히 많은 수 가 있다는 것을 알 수 있습니다.이는 간단하게 작성이 되어진다는 뜻이 되어집니다.이전 포스트에서도 말했었지만 테스트코드는 굉장히 중요합니다. 그렇다는 이야기는 e2e를 하든 통합을 하든 유닛을 하든작성을 하는것이 좋습니다. 여기서 중요한 사실은 유닛테스트가 양이 제일 많다는 것입니다. 그렇다는건 유닛테스트를 중점으로 테스트코드를 짜야 된다는 뜻이 됩니다.그리고 그림에서 보면 알 수 ..
배경카프카에서 수신한 정보를 토대로 계산하여 랭킹을 산출하고 있었다. 지금 보여주고 있는것이 사용자가 원하는 랭킹일까?잘 모르겠다. 실제로 운영이 되지 않는점도 크다고 생각한다. 만약 실제로 운영 된다면, 사용자들이 자주 들어오는 시간을 측정해서 가중치를 반영할 수도 있다 생각한다. 실제로 운영되는 환경이 아니기 때문에 부하테스트를 돌려서 확인하는것이 최선이지 않나 싶다.랭킹 서비스를 만들기 위해서는 데이터를 저장을 해야 한다. 그래야 그걸 통해 정보를 보여줄 수 있기 때문이다. 그래서 최대한 예상을 해서 작성해보려구 한다.수신 장치현재 카프카를 통해 데이터를 수신하고 있다.각 토픽에 맞게 메시지를 전송하고 있다.@Component@RequiredArgsConstructorpublic class Prod..
배경카프카는 어떤 목적으로 사용이 되어질까? 왜 하필 카프카일까?사실 반드시 카프카여야 된다는 이유는 없다고 생각한다. 카프카는 우리가 알기에는 메시지 큐정도만 알고 있는데사실 단순한 메시지 큐는 아니다. 정확히 말하면 분산 메세지 스트리밍 플랫폼이다.카프카에 대해서는 엄청나게 공부할것이 많지만 여기에서는 두 가지만 이야기를 할 예정이다. 프로듀서와컨슈머.. 프로듀서에서 메시지를 발송하고 컨슈머쪽에서 받는 그럼 시스템이다.구현하면서 생각보다 쉽지 않음을 느꼇다.어떤 부분에서 고민했는지 생각해보자.프로듀서프로듀서는 다음과 같이 작성을 하였다.public class LikeKafkaEventPublisher { private final KafkaTemplate kafkaTemplate; private f..
배경주문과 결제에는 굉장히 많은 이벤트들이 존재한다.재고, 포인트, 쿠폰등등의 이벤트들이 존재한다.현재는 이것들이 하나의 트랜잭션에서 동작을 하고 있다.각각의 책임을 분리하기 위해서는 어떻게 해야할까?커멘드와 이벤트커멘드와 이벤트는 뭐가 다를까.. 이것들은 각각 커멘드는 명령이고, 이벤트는 사건이라는 뜻을 가지고 있다.예를 들어, 주문, 결제, 쿠폰, 재고, 포인트라는 등장인물이 존재한다고 생각해보자.내가 선택한 부분은주문 -> 쿠폰 등록결제 -> 포인트 사용결제 -> 재고 차감결제 -> 주문 완료요렇게 작성이 되어진다. 가장 맨위로 예시를 들어보면 주문이 쿠폰은 명령일까 사건일까? 주문 입장에서 쿠폰 도메인한테 명령을 보내는 것이 맞을까? 아니면 주문 입장에서 쿠폰 생성은 하나의 사건일 뿐인걸까?명령과..
배경PG사가 도입이 되었다. 원래 같으면 feign을 사용할지 restTemplate를 사용할지 결정만하고 그걸 사용했었던거 같다.하지만 그리 간단한 문제가 아니었다. 서킷 브레이커라고 들어는 봤나??사실 서킷 브레이커는 전기 쪽에서 나온 용어라 알고 있다. 서킷 브레이커를 한글로 다시 말하면 회로 차단기다.실생활로 예시를 들면, 우리가 스위치를 통해 불을 키고 끄는것을 하게 되면 방에 불이 켜지고 꺼지고를 반복한다. 이것이 서킷 브레이커다.하지만 설정들이 생각보다 헷갈렸다. 그것을 기록해 두면 조금더 편할거라 생각해 기록해둔다.나의 설정나의 설정은 다음과 같다.resilience4j: circuitbreaker: instances: # 'pg-payment' 라는 이름의 서킷 브레이커 설정..
언제 인덱스를 거는 것이 좋을까?책에 있는 인덱스를 생각해보면 인덱스는 A~Z 혹은 ㄱ~ㅎ으로 되어 있다.만약 인덱스가 뒤죽박죽이라면 책에서 정보를 쉽게 찾을 수 없을 거다.고로 인덱스를 건다는 건 어떤 의미일까 데이터를 쉽게 찾는다는 소리인데그게 뒤죽박죽 되어 있다면 의미가 없지 않을까 생각이 문득 들었다.보통 정보를 찾을때, 큰 정보 -> 중간 -> 작은 순서대로 정보를 찾는다.그래야 리소스를 최대한 줄일 수 있기 때문이다.카더널리티가 작은곳에 많다고 해서 작은곳에만 인덱스를 걸면 절대 안된다.아니 의미가 없다.왜냐하면 큰곳에서 데이터를 뒤지고 작은곳을 뒤져야 하는데어차피 큰 곳은 인덱스가 걸리지 않았다.그렇담 인덱스는 안 탈거고 의미가 없지 않을까?어찌 되었든 인덱스를 걸려면 어떤 데이터로 가장 먼..
인덱스 적용브랜드 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비관..
TL;DR거의 처음 설계를 하면서 왜 설계를 하는지에 대한 고민을 가지고 mermaid라는 툴을 통해 설계를 시도해보는 글입니다.들어가며지금까지 개발을 해오면서 설계를 제대로 했는지 생각해봤다.ERD말고는 만든 기억이 없다.그렇다고 해서 제대로 만들지는 않았던거 같다.그려면 왜 그렇게 하지 않았을까?그야 편하니까..개발자의 시선이 아닌 비 개발자의 시선으로 개발자를 바라본다면 '종이'가 아닌 '코드'를 먼저 작성한다고 생각한다.난 아직도 비 개발자의 시선으로 개발자를 바라보고 있는것이 아닌가그래서 당연하게 먼저 IDE를 키고, 코드를 작성하는거 같다.솔직히 아직 잘 모르겠다. 설계를 해서 직접적으로 얻은 이득은 아직 잘 와 닿지는 않는다.그럼에도 설계를 공부하고 해보는 이유는시도를 안 해봤기 때문에 어렵..
개요오늘도 평화롭게 코드를 작성하고 있었어요..저희 팀은 organazation으로 같이 코드를 관리하고 있기에 팀원들의 코드를 염탐해 봤습니다.그런데!!처음보는 코드를 발견하였습니다. 그건 바로 Embedded 요건 멀까?찾아보니 JPA에서 임베디드 타입을 제공하는 방법이었습니다.~~~~~이걸 활용하면 단위 테스트를 사용할때, 생성자 파라미터의 갯수를 줄일 수 있을꺼 같다!!!생각해보니...기존에 사용했었던 빌더 패턴도 생성자 파라미터 갯수를 줄일 수 있지 않나??갑자기 궁금해졌다. 뭐가 좋은걸까???그래서 뭘 테스트 했는데.초반에 다음처럼 단위 테스트를 작성하고 싶었습니다.String userId = "userI123456";CoreException result = assertThrows(CoreEx..
TDD를 학습하다보면 테스트 더블이라는 말이 나온다. 그렇다면 테스트 더블은 테스트를 두번하는걸까?gpt한테 물어보니 이 용어는 영화 용어에서 스턴트 더블에서 왔다고 한다.그리고 찾아보니 더블이 두배라는 뜻이 있지만 대역이라는 뜻이 있다고 한다.그럼 뜻을 다시 해석해보면 테스트를 하기 위해 대역을 쓰는거라고 이해하면 될거 같다.요런 관점에서 생각을 해본다면테스트 더블에는 총 5가지의 대역들이 존재한다.mock, spy, stub, fake, dummy요렇게 5가지가 있다고 한다.이제 대역이라는 것을 바탕으로 생각을 해보면mock은 구현에 대한 대역spy는 구현에 대한 대역stub은 값에 대한 대역fake은 구현에 대한 대역dummy는 값에 대한 대역요렇게 나눌수 있을거다.근데 이상한건 구현3에 값이2개다..
