이노베이션 12주차 - 실전프로젝트 회고 5

프로젝트 트러블슈팅

• 분산추적 TraceId 동기화
  • 동일한 요청을 다른 마이크로서비스에서도 식별할 수 있도록 같은 TraceId가 전파되어 로그를 작성해야하는 상황
  • 분산추적에 대한 코드를 작성하고 실제로 확인해본 결과 일반적인 요청에서는 동일한 TraceId로 설정되어 있으나, @FeignClient를 사용하여 다른 서비스를 요청하게 되면 다른 TraceId가 설정되어있는 것을 확인함
  • 문제의 원인이 @FeignClient를 통해 전달되는 요청에서 TraceId가 제대로 동기화되고 있지 않음이라고 판단하였고 OpenFeign에서는 별도의 동기화 작업이 필요하다는 것을 알게 됨
  • 해당 기능을 적용하기 위해 Configuration을 만든 뒤, Micrometer의 핵심 인터페이스인 MeterRegistry를 매개변수로 받는 Capability 클래스를 Bean으로 등록.
• 경매 동시성
  • 동시에 여러 요청이 들어올 경우 트랜잭션이 동시성 문제를 일으켜서 입찰 금액이 비즈니스 규칙에 어긋나게 되는 상황 발생
  • 처음에는 해당 입찰 메서드에 synchronized를 이용해서 해결하려고 했으나 Scale Out을 고려하게 된다면 이러한 방식도 문제가 될 것이라고 예상
  • 따라서 기존 경매 엔티티에 version필드를 만들고 낙관적 락을 적용함으로써 문제를 해결하고자 했음
  • 그러나 낙관적 락을 사용하게 됐을 때, 입찰 금액 수정을 먼저 선점한 트랜잭션이 끝나게 되면 동시에 들어온 더 높은 입찰 요청 금액이 version의 변경으로 트랜잭션을 rollback하게 되는 상황 발생
  • 따라서 읽기와 쓰기 모두 잠금을 걸어서 사용하는 비관적 락을 사용해서 경매 입찰 금액의 정확성과 동시성을 제어. 비관적 락 사용을 통해 모든 트랜잭션이 순차적으로 해당 경매 엔티티의 입찰 금액 수정을 할 수 있게 됨
• 관심사 분리
  • 가장 고민이 많았던 문제
  • 인프라는 기술의 발전 속도 때문에 쉽게 대체될 수 있지만 비즈니스 로직은 특성상 쉽게 변화되지 않음
  • 따라서 해당 비즈니스 로직도 변화에 유연한 방식으로 순수한 자바코드를 이용해 작성하는 것이 향후 서비스가 변화해도 유리할 것이라고 생각하게 됨
  • 하지만 기존의 레이어드 아키텍처에서는 경매 조회, 입찰, 낙찰 관련 메서드에 카프카로 이벤트를 발송하는 메서드도 존재하고, OpenFeign을 이용한 코드도 존재하였음
  • 지금 당장은 아무런 문제가 없지만 기술적인 관심사와 비즈니스 관심사를 분리하여 코드를 작성하는 작업이 필요하다고 생각하게 됨
  • 헥사고날 아키텍처를 고려한 점도 이러한 점에서 고려하게 되었으며 DIP를 통해 비즈니스 로직이 기술들을 바라보는 것이 아닌, 기술들이 비즈니스 로직을 바라볼 수 있게끔 변경하고자 함.
  • 패키지 구조와 추상화를 적용하는데 있어서 생각보다 많은 시간이 소요되었지만 일련의 아키텍처 변경 과정을 통해 순수한 비즈니스 로직을 만들고, 핵심 비즈니스 로직은 도메인 내부로 삽입할 수 있게 됨

---

버전이 맞지 않고, 잘못 작성된 코드와 같은 사소한 트러블슈팅들을 제외하고 이번 프로젝트에서 내가 겪었던 가장 큰 세 가지 문제였다. 예상이 되는 문제들도 여러 개 있었는데,

 

1.재고 감소에 따른 결제 완료 여부를 비동기로 처리하는 것이 합리적인 판단인 것인가

2.스케줄링 서버를 따로 분리하여 역할을 배분하는 것은 생각보다 많은 리소스 낭비가 아닐까

3.커넥션풀과 톰캣쓰레드를 보다 효율적으로 설정하기 위해서는 어떠한 과정이 필요한가

 

등이 있었다. 다만 프로젝트 완성이 현 시점에서는 더 중요한 목표이기 때문에 해당 문제들에 대해서는 프로젝트가 끝나고 추가적으로 다뤄봐야할 것 같다.

 

어느 덧 프로젝트도 막바지를 향해가고 있다. 프론트엔드 작업, 추가적인 코드 리팩토링 등 아직 좀 더 손봐야할 게 많지만 지금껏 해왔던 것들을 되돌아보면 열심히 달려왔던 것 같다. 마지막까지 조금 더 노력해서 최종 프로젝트 발표 때에는 우리가 고민했던 것, 해결한 문제들, 깨닫게 된 것들을 잘 정리해서 마무리하고 싶다.