현재 진행 상황

이제까지 구현한 로그추적기는 파라미터를 통해서 넘기는 방법을 없애고 Tracer를 스프링 빈 컨테이너로부터 주입을 받아서 해당 빈의 TraceId값을 이용해서 로그 추적기를 사용했습니다. 싱글톤인 빈으로부터 발생하는 동시성 문제를 ThreadLocal을 사용해서 해결해서 결과적으로 파라미터로 강하게 결합되는 함수의 관계를 독립적으로 분리할 수 있었습니다.

이렇게 해서 로그추적기를 구현하더라도 몇가지의 문제점이 여전히 존재합니다.

문제점

개선한 로그추적기를 서비스 로직에서 사용한 코드입니다.

public String request(String itemId) {
      TraceStatus status = null;
      try {
status = trace.begin("OrderController.request()"); orderService.orderItem(itemId); //핵심 기능
          trace.end(status);
      } catch (Exception e) {
          trace.exception(status, e);
throw e; }
      return "ok";
  }

이 코드로부터 알 수 있는 문제점

1. 서비스 로직에서 로그 추적기를 사용하려면 try, catch문 내부의 로직을 반복적으로 똑같이 구현해야합니다.
   예를 들어 위의 코드에서는 모든 서비스 로직은 trace.begin 메서드 바로 뒤에 넣어야 하고 catch문에서는 무조건 trace.exception메서드를 호출해야합니다. 만약 로그 추적기 코드의 변경점이 발생했다면? 모든 로그추적기를 사용하는 서비스로직을 찾아가서 똑같이 수정해주어야 하는 문제가 발생합니다.
2. 코드의 길이가 길어집니다.
   로그추적기의 코드 내용이 길어질수록 서비스 로직의 가독성이 떨어지고 새로운 서비스로직의 코드에 로그추적기를 적용하려면 작업량이 많아집니다.

이번 이슈에서는 이러한 문제점들을 해결하기 위한 디자인 패턴중 하나인 템플릿 메서드 패턴과 템플릿 콜백 패턴에 대해서 공부해보려고 합니다.

스프링 핵심 원리 고급편

🔥 김영한님 강의 [스프링 핵심 원리 고급편] 를 듣고 배운 점을 기록하면서 직접 코딩해봅니다.

• #6

로그 추적기

개요

애플리케이션이 점점 커지게 되고 서비스 이용자수가 증가하게되면, 점점 서버개발자가 할 일이 늘어난다. 바로 모니터링과 운영이다.
로그는 서비스 서버가 제대로 작동하고 있는지, 어떠한 오류가 있는지, 어떤 사용자가 들어오는지등 현재 작동하고 있는 서버의 상황을 개발자가 감시할 수 있게 만드는 기록이기 때문에 없어서는 안될 존재이다.
이번 이슈에서는 이런 로그의 장점을 살리는 로그 추적기를 요구사항 명세서에 맞게 만들어보고자 한다.

요구사항

• 모든 PUBLIC 메서드의 호출과 응답 정보를 로그로 출력 애플리케이션의 흐름을 변경하면 안됨
• 로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨 메서드 호출에 걸린 시간
• 정상 흐름과 예외 흐름 구분
• 예외 발생시 예외 정보가 남아야 함 메서드 호출의 깊이 표현
• HTTP 요청을 구분
  • HTTP 요청 단위로 특정 ID를 남겨서 어떤 HTTP 요청에서 시작된 것인지 명확하게 구분이 가능해야 함
  • 트랜잭션 ID (DB 트랜잭션X), 여기서는 하나의 HTTP 요청이 시작해서 끝날 때 까지를 하나의 트랜잭션이라 함

과정

• #7
• #8
• #9

요구사항

• 매 서비스 로직에 넣을 수 있는 로그 생성기
• 로그는 하나의 스레드 흐름에서는 같은 트랜잭션 ID를 가져야 함
• 완료시간을 로직마다 측정할 수 있어야 함

• #2
• #3

Member를 Create하고 Member 엔티티의 Name 필드값을 중복 검사합니다.