반응형 회고347 [항해 플러스 백엔드-10주차] 장애대응 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 장애 원인 파악, 개선을 통한 성능향상 tool로 비교하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 주문시 재고차감 데드락 문제를 해결한 것. 여러 개의 상품을 동시에 주문하는 경우, 트랜잭션이 자신의 자원을 가지고 있는 상태에서 다른 트랜잭션이 점유한 자원을 계속 대기하고 있으면 데드락이 발생합니다. 이 경우 해결하는 다양한 방법이 있는데 상품의 순서를 id 기준으로 정렬하는 것만으로도 데드락을 회피할 수 있습니다. 데드락이 어떤 문제이고 언제 발생하는지 시간의 흐름에 따른 그림을 그려보면서 확실히 깨달을 수 있었습니다. 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점)k6에 influxdb를 함께 사용하여 그라파나 대시보드를 만들지 못.. 2024. 12. 7. [항해 플러스 백엔드-9주차] kafka 맛보기 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 kafka로 데이터 플랫폼 전송 구현하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 요구사항에 따라 kafka를 구성해서 실제 메세지를 주고받은 것. kafka를 평소에 엄청나게 거대한 장벽으로 생각하고 넘보지도 않다가 과제를 위해 실습을 했습니다. 결론적으로 성공했습니다. 심지어 구성이 엄청 오래 걸리지도 않았습니다. 멘토님들의 좋은 강의를 기반으로 개념을 정립하고 실습하니 수월했습니다. 처음에는 별도의 프로젝트를 만들어 간단한 문자열 전송 이벤트를 구축했고, 이후 프로젝트에서 필요한 부분에 kafka 이벤트 전송을 구현했습니다. 내가 머리속으로 생각한 것들이 코드로 막힘없이 풀어내질 때 쾌감을 느꼈습니다. 와중에 잘못 알고있는 개념이나 구현 방식을 바로.. 2024. 11. 26. [항해 플러스 백엔드-8주차] index, 대규모 서비스 설계 이번 챕터를 시작하며 꼭 해내고 싶었던 목표index로 쿼리 개선하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 index의 다양한 케이스를 고려하여 테스트를 해본 것. 단순히 이런 index를 사용하면 좋습니다! 라고 단정짓는 것이 아니라 근거를 마련하기 위해 다양한 테스트를 했습니다. 테스트를 위한 데이터를 만들고 다양한 인덱스를 설정해서 테스트했습니다. dbeaver의 explain과 analyze를 활용해 얼마나 성능 측정을하고 비교했습니다. 이번 보고서를 기반으로 앞으로 회사에서도 튜닝을 적극적으로 해 볼 계획이고 스터디로 공부 및 좋은 사례 공유시간을 가지기를 기대합니다. 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점) 복합 인덱스 케이스를 테스트하지 못한 것. 1개의 테.. 2024. 11. 26. [항해 플러스 백엔드-7주차] Redis 활용 이번 챕터를 시작하며 꼭 해내고 싶었던 목표Redis를 활용하여 멱등성 결제 개선하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 Redis를 활용해 트랜잭션의 사용 범위도 줄이고 성능을 대폭 강화했습니다. 멱등성 키를 DB에서 관리하다가 Redis로 관리하니 훨씬 부하가 줄었습니다. 만약 멱등성 키 검증이 제대로 되지 않아도 주문에서 락을 활용해 유효성을 검증하기 때문에 중복 결제를 막을 수 있습니다. 하지만 결제 실패 시 재시도를 처리하는 등의 예외 전략은 더 고도화 해야 합니다. 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점) Redis 테스트를 위한 인메모리 레디스, 테스트 컨테이너를 확실하게 구분하지 못한 것. Redis를 사용하다가 테스트를 하고 싶었는데 어떻게 레디스를 테.. 2024. 11. 12. [항해 플러스 백엔드-6주차] 이커머스 동시성 제어 이번 챕터를 시작하며 꼭 해내고 싶었던 목표간단하더라도 k6 성능 테스트Redisson 락 구현하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 그림을 활용해 독자 친화적인 보고서를 만드는 것. 락을 이용한 성능 테스트도 중요했지만 트랜잭션의 범위도 중요한 과제였습니다. 프로젝트마다 구현방식이 다르기 때문에 플로우 차트를 활용해 독자들이 쉽게 파악 할 수 있도록 했습니다. 락의 종류는 어떤 것들이 있고 락을 사용한 이유가 무엇인지 근거를 제시했습니다. 또한 k6를 활용하여 락의 종류에 따른 성능을 테스트 했습니다. 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점) k6의 다양한 지표를 확인해 보는 것. p90, p95, p99등의 성능과 기타 다른 지표들이 많이 있습니다. 단순히 기준.. 2024. 11. 2. [항해 플러스 백엔드-5주차] 이커머스 고도화 이번 챕터를 시작하며 꼭 해내고 싶었던 목표테스트코드의 점진적인 개선결제 멱등성 추가 이번 챕터를 마무리하며 가장 기억에 남는 성취 요구사항 구현에만 초점을 두지 않고 중요 내용을 github Issue에 정리했습니다. 블로그를 검색하고, 생성형 AI에 물어보면 코드는 어찌어찌 짤 수 있습니다. 약 4주를 지나오며 문제가 발생해도 주변에 물어보거나 멘토님들과 소통하면 완성은 할 수 있습니다. 하지만 비슷한 상황에서 다음에 다시 문제를 마주쳤을 때 더 나은 방식으로 처리를 해야 하는데 어떻게 할 수 있을까? 고민했는데 내가 직접 나의 언어로 글을 써보는 것입니다. 물론 여러 곳의 내용들을 짜집기해서 나온 경우들이 많지만 나만의 언어와 기준을 잘 잡아가는게 중요하다는 것을 깨달았습니다. 뒷받침할 수 있는 근.. 2024. 11. 2. [항해 플러스 백엔드-4주차] 이커머스 기본 구현하기 이번 챕터를 시작하며 꼭 해내고 싶었던 목표오류 응답에 상태코드, 메세지와 함께 커스텀 에러 문자열을 보여줄 것 Fake 클래스 작성을 통한 Swagger 데이터 전달로 개선하기 멱등성을 이용하여 결제 구현하기 이번 챕터를 마무리하며 가장 기억에 남는 성취 결제/구현을 위해 Facade를 적절하게 잘 활용했고 예외도 만들었습니다. Facade를 사용하기 위해 각종 Service들을 먼저 만들었고 Facade는 작업을 조립하기만 하면 끝입니다. 미리 어떻게 구현할지 설계를 기반으로 만들다보니 고민의 시간이 줄어들어 빠르게 코딩할 수 있었습니다. 통합 테스트를 통해 동시성 테스트를 했고 같은 결제 요청에도 한번만 결제가 되도록 했습니다. 주문-결제의 순서가 단순히 서버에서만 작동하지 않고 프런트와 계속.. 2024. 10. 22. [항해 플러스 백엔드 - 3주차] 이커머스 설계 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 - DDD 기반, 동시성을 고려해 정규화된 ERD 설계하기- 다양한 케이스를 고려한 시퀀스 다이어그램 만들기- Swagger를 이용해 빠르게 mockAPI 배포하기 이번 챕터를 마무리하며 가장 기억에 남는 성취- DDD 기반, 동시성을 고려해 정규화된 ERD 설계하기 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점)- MockApi를 좀 더 깔끔하게 정리해서 만들지 못한 것? 내가 강화해야 할 강점 중 가장 중요하다고 생각하는 한 가지- 내가 선택한 설계에 이유와 근거를 만들며 장단점을 잘 아는 것 내가 개선해야 할 개선점 중 가장 중요하다고 생각하는 한 가지- 바로 코드부터 짜는 것이 아니라 좋은 설계가 필요하다. 시퀀스 다이어그램, 플로.. 2024. 10. 12. [항해 플러스 백엔드 - 2주차] 수강신청 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 - ERD 설계로 시작해서 STEP에 따라 테이블 구조 개선하기 - JPA 연관관계를 사용해 테이블 매핑 연결하기 - 비관적 락을 이용해 동시성 제어하기 이번 챕터를 마무리하며 가장 기억에 남는 성취- JPA 연관관계 매핑을 정상으로 설정하여 설계대로 동작한 것- 특강 테이블이 아닌 정규화된 특강 옵션 테이블에 비관적 락을 걸어 부하를 줄인 것 이번 챕터에서 반드시 이뤘으면 했는데 이루지 못한 것(아쉬운 점)- 테스트를 위해 testFixture를 분리했는데 그럼에도 파일별로 중복되는 코드가 있어서 좀 더 공통화를 해보자.- 테스트는 setUp()에서는 아예 테스트 인스턴스를 생성하지 않고 각 @Test에서 필요한 것만 생성해보자.- 낙관적 락도 구현해보고 .. 2024. 10. 5. 이전 1 2 3 4 ··· 39 다음 반응형