Doran

지난주부터 개인프로젝트에 대한 준비를 해왔다. 기획을 하면서는 어떤 비즈니스 문제를 해결할까 하는 고민과 혼자서 설계하고 구현하는 과정에서 어느정도가 적절할까 하는 고민 사이에서 우선은 기본기를 갖추자고 다짐했다.그렇게 결정된 프로젝트는 흔한 쇼핑몰이 되었다. 그래도

지난 8일 이후 개인프로젝트 두번째 기록이다. 마음의 여유가 없어 포스팅을 미뤄왔다. 12일에 회원 서비스 개발을 일단락 짓고서 현재는 19일부터 시작한 인증/인가 서비스를 구현 중에 있다. 회원 서비스 구현에 소요된 기간은 7일이었고, 인증/인가 서비스를 구현하기 위

스프링 시큐리티 관련 내용을 정리하다보니 지난 26일부터 아이템 서비스 구현 시작.순조로울 것으로 예상했으나, 오늘 밤이 되어서야 제대로 된 시작을 할 수 있었다.현재까지 아이템 서비스 개발 소요일만 4일.Item 엔티티와 이를 상속받는 Book, Artwork 엔티티

오늘 저녁에서야 주문 서비스까지 구현 완료하였다. 계획된 기간에서 하루를 넘겼고, 잠깐의 정리하는 시간을 갖다가 바로 다음 작업으로 이어갈 예정이다.아이템 서비스 구현 기간 : 3.26. ~ 4.2. (8일)기존 계획 : 3.22. ~ 3.26. (5일) | 시작 4일

어제는 프로젝트 중간결과에 대해 코드리뷰를 받았다. 우선 현재까지 진행상황은 크게 다음과 같다.H2에서 MySQL로 마이그레이션각 서비스에 스프링 클라우드 적용1번 마이그레이션 작업은 처음이었지만 생각보다 간단하게 해결할 수 있었고, 2번 스프링 클라우드를 적용할 때에

오랜만의 게시물 작성! 그간 알바하고 다른 일들에 신경쓰고 또 쌓였던 기술부채에서 허우적이다가 잠깐이나마 시간내서 기록해보기로 한다. MSA 구조로 설계한만큼 고려해야할 복잡한 요구사항들이 있었고, 그중 하나가

24.05.29. 엔티티 리팩토링이전 포스팅에 이어서 이번에는 매핑 모듈을 ModelMapper에서 MapStruct로 교체하는 과정에 대해 다루도록 한다. 우선 왜 ModelMapper가 아닌 MapStruct인가? 앞선 포스팅에서는 간단히 아래와 같이 언급했다.Mo

이전 포스팅에서 ModelMapper와 MapStruct에 대해 비교하며 MapStruct가 어떠한 지점에서 유리한지를 살펴봤다. 이번에는 실제 프로젝트에 MapStruct를 적용한 코드들을 살펴보기로 한다. 의존성 설정 빌드툴로 Maven을 사용하였기에 xml 방

이번 포스팅에서는 서킷브레이커(Circuitbreaker) 적용에 대해 알아보자.우선 서킷브레이커가 무엇인지는 다른 블로그에도 많이 정리되어 있으니 여기서는 간략히만 짚고 넘어가자면, 사전적 정의로는 회로 차단기라고 해서 문제 있는 회로에 대해 전류가 더 흐르지 않도록

프로젝트의 API 윤곽이 잡혔겠다, 이제는 MSA의 기본 조건이 되는 비동기 처리를 적용해야 했다. 이때 비동기 처리는 트래픽이 쌓인 순간에 로직 처리에 있어 지연이 발생할 수 있는 부분(처리 비용이 높은 부분)에 적용해줌으로써 서비스의 가용성을 높여준다. 그리고 이를

DB 접근에 대한 카프카 적용은 사실 설정에 기본값만 넣는다면 그 자체로 큰 어려움은 없다. 카프카가 뭐지?라는 뜬구름이 좀 있어서 이벤트에 대한 토픽 메세지를 설계할 때에만 잠깐 막히다가, 그 외의 설정에 대한 고민은 없어도 기능 구현은 사실 구글 검색을 통해 해결할

처음부터 비동기 처리가 목적이었기에, 카프카 아키텍처는 물론, 이벤트 기반 아키텍처(이하 EDA)에 대해서도 전혀 생각하지 않았다. 카프카를 하나씩 배워가고 직접 다뤄보면서, 결국 카프카를 사용하기 위한 어떠한 설계 개념이 내게 부재함을 느꼈던 것이다. 그래도 시간만

각 마이크로서비스에 카프카로 비동기 이벤트까지 구현했겠다, 실질적인 성능테스트로 수치화된 결과가 필요했다. 이 관련으로 정리해본다.nGrinder 설치는 스킵.ngrinder-controller-{version}.war 파일과 ngrinder-agent 폴더를 받았다면