tracing이 필요한 이유

Monolithic 시스템의 경우 클라이언트의 요청을 받으면 하나의 스레드에서 모든 요청을 실행하므로 로그를 확인하기 쉽다는 장점이 있습니다.
그에 반해 MSA의 경우에는 각 서비스의 복잡도가 낮아지고 역할 분담이 용이하지만 클라이언트의 요청을 받았을 때 여러 개의 마이크로 서비스 간에 통신이 발생해 로그를 확인하기 어려운 문제가 있습니다.
이를 해결하기 위한 어플리케이션 간 분산 추적을 위한 표준이 OpenTracing이며, 대표적은 구현체는 zipkin과 jaeger가 있습니다.

클라이언트가 서버로 호출한 하나의 호출을 Trace라고 했을 때, 서비스 컴포넌트간의 호출을 Span이라고 한다.각 서비스 컴포넌트들은 하나의 클라이언트 호출을 추적하기 위해서 같은 Trace Id를 사용하고,
각 서비스간의 호출은 각각 다른 SpanId를 사용합니다. 이렇게 함으로써 전체 트렌젝션 시간을 Trace로 추적이 가능하고, 각 서비스별 구간 시간은 Span으로 추적할 수 있습니다.

spring boot 예제

spring boot를 이용하여 웹페이즈를 만드는 샘플 프로젝트를 소개하려한다.

작업한 소스코드 예시는 github에 공유하고있습니다.
https://github.com/HyeonGuJ/demo-spring-boot-web

spring boot는 spring에서 작업했던 설정들을 보다 쉽게 할 수 있고, 첫 페이지를 만들기까지 시간이 오래걸리지 않는다. spring initializr를 통해 원하는 기능들을 조합하고 IDE를 통해 페이지를 띄우는것까지 진행해보자.

시간이 없다면 3. 프로젝트 생성하기로 넘어가세요.

spring initializr를 통해 프로젝트 생성

spring initializr는 spring으로 application을 만들기 시작할때 필요한 의존성을 자동으로 셋팅하여 구조를 잡아주기 때문에 application을 처음 만들때 사용하면 매우 좋다.

동기

최근 chrome80 의 cookie 정책변경으로 저자가 서비스하는 모든 서비스들을 https로 운영하기로 했다. 관련 이슈는 여기 (https://hyeonguj.github.io/2020/02/05/chrome80/ ) 에 정리하였다.

기존에는 local환경과 개발서버에서는 http로 통신을 하며 작업을 하였으나 바뀐 정책에서 쿠키를 읽기위해서는 https로 서비스를 해야한다.

개발서버의 경우 apache나 nginx에서 모두 http -> https로 바꾸어주며, 인증서 처리가 되어있기때문에 문제가 되지 않는다. 하지만 local 환경의 경우 tomcat 또는 spring boot application에서 https로 서비스를 할 수 있어야 테스트가 가능하다.

chrome80

크롬 80버전부터 새로운 쿠키 정책(SameSite Cookie)이 시행될 예정이다.
이 정책이 시작되면 어떤 영향도가있는지, 어떻게 대응해야할지 알아보자

바뀐 쿠키정책

목적

CSRF ( cross-site-request-forger ) 공격을 막기 위해 third-party 쿠키를 막으려는것이 기본 컨셉이다. 이를 위해 cookie 정책중 samesite의 기본값을 바꾼다. 하지만 이렇게되면 오류가 매우 많이 발생할수 있으니 top-level navigation일 경우에는 third-party cookie를 허용해주는 Lax를 기본값으로 한다.
chrome79 에서는 samesite 기본값이 None으로 되어있으나 chrome80 부터는 Lax가 된다.

logback

지난포스트 에서 logback의 기본적인 설정에 관하여 다루었다.
이번 포스팅에서는 logback-spring.xml과 profile로 설정을 나누는 방법, 그리고 그 전략에 대해 다룬다.

logback-spring.xml

spring에서 logback은 설정파일을 아래와같은 순서로 찾는다.

1. logback.groovy
2. logback-test.xml
3. logback.xml
4. default

spring-boot의 경우 조금 다르게 logback-spring.xml이라는 이름으로 설정한다.
logback.xml 으로 설정하면 spring-boot 가 설정되기전에 로그백설정을 완료한다. 따라서 spring-boot에서 사용하는 properties 나 profile같은 설정값을 사용할 수 없게된다.

profile에 따라 로그설정

기본적인 logback.xml에 관한 설정은 logback 기본설정 포스팅에서 다루고 profile 설정에 관해 알아보자.

필자는 크게 console에 로깅, file에 로깅, 그리고 logstash로 로그를 전송하는 3가지 설정을 하였다.
그리고 profile별로 아래와같이 나누었다.

phase에 따라서 proflies를 나누는 경우에는 아래와같이 설정 할 수 있다

spring boot logging

스프링부트는 모든 내부 로깅에 Commons Logging를 사용한다, 그러나 근원적인 로그 구현체를 열어볼 수 있다. 기본 설정들은 Java Util Logging, Log4j 그리고 Logback을 제공한다. 각각 콘솔로 출력되고 파일로 출력된다. (10MB 크기가 되면 파일을 새로 생성)

기본적으로, ‘Starter POMs’를 사용한다면, Logback을 로깅에 사용할 것이다. 유연한 Logback은 Java Util Logging, Commons Logging, Log4j 혹은 SLF4J 를 사용하는 의존적 라이브러리들을 의존적인 라이브러리들도 문제없이 동작하는 것을 보장한다.

팁: 자바에서 사용가능한 로깅 프레임워크들은 대부분 지원한다. 목록만 보고서 당혹러워할 이유는 없다. 기본적으로 로깅 의존성을 변경할 필요는 없을 것이며 스프링부트는 기본적으로 잘 되어 있어있다.

스프링 부트에서 일정 시간 주기적으로 작업하는 스케쥴러를 만들어보려고 한다

@EnableScheduling 추가하기

• @EnableScheduling 주석은 응용 프로그램의 스케줄러를 활성화하는 데 사용된다
• 기본 스프링 부트 애플리케이션 클래스 파일에 추가해야 한다

1
2
3
4
5
6
7

@SpringBootApplication
@EnableScheduling
public class DemoApplication {
   public static void main(String[] args) {
      SpringApplication.run(DemoApplication.class, args);
   }
}

프로젝트 구성 개요

• jsp를 쓸수밖에 없는 프로젝트에서 gradle을 이용하여 war로 build 후 java -jar app.war 를 사용하여 프로젝트를 띄울수 있게 하는것이 주 목적이다.

• spring boot 프로젝트러 jar패키징후 내장 톰켓을 사용하는 방식으로는 jsp 를 view template으로 사용할수 없다.

• 이 셋팅이 필요없는 케이스.

  • 굳이 jsp를 쓰지않아도 되는 경우. war셋팅도 필요없으니 기존 jar 배포구조로 구성하면된다.
  • 내장tomcat을 쓰지않는경우. war로 패키징하여 외부 톰켓을 이용하면 되므로 bootRun, bootWar셋팅까지 할 필요는 없다.

실제로는 프로젝트를 마이그레이션 하는 과정에서 발생한 트러블 슈팅 과정을 정리한 산출물입니다.
본 내용에서는 마이그레이션 과정이 아닌 셋팅만 기술하겠습니다.(결과물위주)

spring boot 통합 테스트

스프링 부트로 web 서버를 개발.
client 입장에서 url로 호출시 controller가 잘동작 하는지 테스트하려고 한다.