반응형 전체 글711 [항해 플러스 백엔드-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. [항해99-1주차 회고] TDD 시작하기 문제- 이번 주차를 지나며 겪었던 문제가 무엇이었나요? 이번 주차의 가장 큰 문제는 동시성 제어였습니다. 특히 포인트 충전/사용은 "사용자별"로 동시성 제어가 중요했습니다. 철수와 영희가 각각 포인트를 충전한다면 철수와 영희가 굳이 충전의 행위를 동시성으로 제어할 필요가 없습니다. 철수가 동시에 여러 번 충전하는 경우, 영희가 동시에 여러 번 충전하는 경우에 동시성 제어를 해야 합니다. 시도- 문제를 해결하기 위해 어떤 시도를 하셨나요? 동시성 문제를 해결하기 위해 락 메커니즘을 떠올렸습니다. 어플리케이션 수준의 락, DB 수준의 락, 혹은 Redis 등의 기타 락 방법이 있습니다. 이번 과제는 DB를 컬렉션을 이용하였기 때문에 어플리케이션 수준의 락을 사용하는 과제라고 생각했습니다. 해결- 문제를 어.. 2024. 10. 2. [항해 99] 시작하는 마음 1. 지금까지의 회고 항상 단순히 기능이 동작하는 것 이상의 것에 목말라 있었다. 나름 신기술과 좋은 기술들을 많이 공부했으나 실무에서 경험할 기회가 없었다. 두번째로 옮긴 곳은 원하던 스택이 있는 커머스 회사였다. MSA환경에서 트랜잭션 전략을 고민하고, Redis를 활용해 성능을 개선하며 테스트코드 기반으로 안정적인 주문 시스템을 고민했다. 잠시 내려두었던 공부에 다시 의욕이 생겼고 더 잘하고 싶었다. 지금도 혼자서 테스트코드를 작성하며 클린코드와 코드리뷰 문화를 전파하기 위해 고군분투 중이다. 같은 파트원 분들부터 조금씩 전파하려고 한다. 현재의 고민은 테스트코드 기반 다지기, 성능 개선하기, 장애에 빠르게 대응하는 모니터링 방안 마련하기이다. 2. 항해플러스 참여 계기 첫째, 항해 플러스는 .. 2024. 9. 21. 그림으로 보는 도커 개념 + 명령어 정리 * 개요 이번 글의 내용 및 사진은 따라하며 배우는 도커와 CI환경 , 생활코딩 Docker 입구 수업 기반으로 작성하였습니다. 도커를 쓰는 이유 가상화 기술 등장 이전 가상화 기술 등장 이전에 하나 서버에 하나의 응용 프로그램만을 설치해야만 했습니다. 웹서버, Database를 구성하기 위해 '모든 서버마다 OS를 설치'하는 것은 메모리가 매우 비효율적인 일이었습니다. 하이퍼 바이저 기반 VM 등장 하이퍼 바이저의 등장으로 '논리적으로 공간을 분할'하여 VM(Virtual Machine)이라는 '독립적 가상 환경의 서버'를 사용할 수 있게 되었습니다. 하이퍼 바이저는 다수의 게스트 OS를 구동할 수 있도록 소프트웨어, 하드웨어 자원을 가상화하면서 하드웨어와 VM을 모니터링하는 중간 관리자역할입니다... 2024. 9. 13. 이전 1 2 3 4 ··· 79 다음 반응형
