이 섹션에서 템플릿 메서드 패턴, 전략 패턴, 탬플릿 콜백 패턴을 알아볼거다. 전 섹션에서 본 로그추적기를 도입하려고 했는데, 막상 해놓고 보니 부가적으로 반복되는 코드가 너무 장황해졌다. 핵심기능은 단 한줄인데 단지 로그 추적을 위한 부가기능으로 뭔가 앞뒤로 덕지덕지 붙어서 너무 보기 흉하다. 이건 메소드가 2개라서 그나마 괜찮아 보이지 막 클래스와 메소드가 100개씩 넘어가면 더 힘들어진다. 하지만 반복되는 부분을 메서드로 따로 빼려고 해도 핵심 기능이 try catch로 감싸져 있어 이것도 쉽지 않다. 그래서 이 문제를 해결하는 디자인 패턴이 템플릿 메서드 패턴이다. 일단 이게 뭔지 알기 위해 테스트코드를 작성해본다. 주변은 같은데 안에만 다를 때 추상화 클래스 상속을 사용하면 된다. 이게 뭔지는 ..

이제 인터페이스를 만들어가며 본격적으로 해보자. @Slf4j public class FieldLogTrace implements LogTrace { private static final String START_PREFIX = "-->"; private static final String COMPLETE_PREFIX = ""; private static final String COMPLETE_PREFIX = "

프로젝트 기본 세팅 로그 추적기를 만들어볼거다. package hello.advanced.trace; import java.util.UUID; public class TraceId { private String id; private int level; public TraceId() { this.id = createdId(); this.level = 0; } private TraceId(String id, int level) { this.id = id; this.level = level; } private String createdId() { return UUID.randomUUID().toString().substring(0, 8); } public TraceId createNextId() { retur..

전 섹션에 했던건 스프링 서버의 전체적인 환경 관리였고, 나만의 비즈니스를 모니터링 하려면 직접 정의해야 한다. 그래서 해보는거다. 프로젝트 세팅한다. AtomicInteger는 race 방지하려고 이제 이걸 본격적으로 메트릭에 넣어보자. 메트릭에 넣는것도 마이크로미터를 사용한다. 현재 카운터를 넣으니, 마이크로미터의 카운터를 가져와 넣어준다. 그럼 실제 메트릭에서도 저게 등록된다(단, 최소 한번은 실행해야 등록된다). 이 정보 또한 프로메테우스에 가게되고, 다른것들 처럼 그라파나에서도 사용 가능하게된다. 이 등록을 @Counter로 더 편하게 할 수 있다. 태그의 클래스와 메소드 등은 해당 클래스 이름과 함수 이름으로 알아서 적용한다. CountedAspect를 등록한 뒤 @Counted를 하면 된다...

마이크로미터는 여러 모니터링 툴들을 하나로 통합시켜 추상화한거다. actuator에서 기본으로 제공하는 메트릭들을 보자. tag로 범위를 한정해서 볼 수도 있다. 이런 cpu 사용량같은 os뿐 아니라 사용자 요청, 톰캣 쓰레드 갯수, 로그 등도 확인 가능하다. 특히 유용한건 tomcat.threads.busy, tomcat.threads.config.max 그리고 직접 사용자가 만드는 메트릭임. 사용자가 만드는건 실제 서비스로 사용하는 비즈니스 로직을 만들어 넣어 테스트해볼 수 있기 때문. 메트릭의 한계점은 어디에 기록하는게 아니라 순간순간 보는거라 데이터베이스에 넣어서 기록하는게 필요함. 그걸 프로메테우스가 해주고, 보는거는 그라파나로 본다. 설치부터 실습한다. 프로메테우스는 포트 9090가 기본임. ..

여기선 본격적인 강의 들어가기 전에 프로덕션 준비 기능 개념에 대해 먼저 설명해준다. 프로덕션 준비 기능은 코드로 작성한 서버 기술적 외에 배포할 때 고려해야 할 것들을 말함. 지표, 주적, 감사, 모니터링 등. 즉 모니터링 actuator라는걸 설치하면 이미 모니터링 기능으로써 제공된 /actuator url이 있다. 하지만 설치는 설치고 이걸 웹에 노출 시켜야지 나도 볼 수 있다. 어찌보면 당연한건데.. 예를들어 어떤게 bean에 등록되었는지 어쩌구 저쩌구 ~~. 기본은 물론이고 확인 가능하다던지. 좀 스프링에 특화된 모니터링이다. 숨겨져 있을 뿐 기본적으로 shutdown을 제외한 대부분의 기능들은 활성화 되어있다. 자주쓰는 것들 Production-ready Features (spring.io) ..

이번엔 이 외부설정을 주로 어떻게 읽는지 알아볼거다. 새로운 프로젝트로 시작한다. 전에 나온 Environment로 가져와서 읽으면 된다. 근데 일일히 env.getProperty 하기 싫어서 @Value라는게 나옴 @Slf4j @Configuration public class MyDataSourceValueConfig { @Value("${my.datasource.url}") private String url; @Value("${my.datasource.username}") private String username; @Value("${my.datasource.password}") private String password; @Value("${my.datasource.etc.max-connection}..

.jar 파일로 빌드해서 서버에 올리는걸 해봤는데, 같은 코드지만 개발용 서버, 라이브 서버에 따라 안에 들어있는 ip주소 값 등은 바뀌어야 한다. 옛날엔 이런 기능이 없어서 해당 변수만 살짝 바꿔서 빌드하는 방식으로 2번 빌드했다. 하지만 이젠 아니다. 같은 코드에서도 다른 변수를 주입하게 하려면, 코드 내에서 외부 파일을 읽어와 이걸 변수에 할당하는 방법이 있다. 그래서 외부 설정이라고 하는거고, 외부 파일을 읽어들여 사용한다. 위 처럼 크게 4가지 방법이 있다는데 3가지 방법을 알아볼거다. 일단 os 환경변수 위 환경변수를 가져오는걸 자바에서 제공해준다. 하지만 이건 말 그대로 os 속성이라 다른 프로그램에서도 사용할 수 있다. 그래서 자바에서만 사용가능하게 하는 자바 시스템 속성을 보자. 실행할 ..

새 프로젝트로 다시 시작해본다. 데이터베이스랑 연동하는걸 직접 bean으로 등록하며 해보자. 코드 내에서 직접 db관련해서 DataSource, TransactionManager, JDBCTemplate 모두 등록한다. 레퍼지토리에서 이걸 가져와서 쓴다. 사실 DbConfig로 작성한 db등록 내용들은 매 프로젝트 생성시마다 해줘야 하는 반복작업이다. 그래서 자동구성이 있다. 일단 테스트를 만들어 자동구성 안하는것과 하는거 차이를 보자. 내가 만든 @Configure가 실행되서 내가 만든 로그가 뜨는거다. 근데 내가 만든걸 없애도 자동 구성으로 알아서 주입되어있다. 자동 구성은 부트를 쓴다면 왠만하면 있다. 안의 등록 로직은 내가 직접 짠거랑 거의 비슷한 것이 핵심이다. @ConditionalOnClas..

새로 프로젝트를 시작하자 처음부터 하나하나 깔 때 라이브러리들이 버전이 달라 호환이 안된다던가 하는 세팅에서 피곤함을 느낄 수 있다. 그래서 부트가 좀 지원해준다. 일단 버전 관리 자동으로 하는것부터. io.spring.dependency-management가 있다면 라이브러리 버전을 생략해도 이미 검증된 호환 버전을 찾아 알아서 찾아 설치한다. spring-boot/spring-boot-project/spring-boot-dependencies/build.gradle at main · spring-projects/spring-boot · GitHub 위 링크의 bom을 참고함. 스프링 버전에 따라서 이미 검증해놓았다. 또 직접 확인하는 것도 스프링 공식 문서에 있음. Dependency Versions..