spring security는 쓰레드로컬 기반으로 동작하기 때문에 reactive 환경에서는 사용하기 힘들다. 그렇다면 reactive 환경에서는 security를 사용하지 않는걸까? 이번에는 reactive 환경에서 security를 어떻게 사용하는지 알아보자.SecurityFilterChainservlet stack에서는 Servlet Filter를 사용하는데, Filter Chain 중간에 DelegatingFilterProxy를 추가하고, DelegatingFilterProxy는 내부적으로 여러 개의 Security Filter를 갖는 SecurityFilterChain을 호출한다.FilterChain내에서는 bean을 사용하기 힘들지만, SecurityFilterChain은 Spring Cont..
RestTemplate기존에 사용하던 RestTemplate은 동기 blocking 기반의 webClient이다. 스프링 5.0부터 더이상의 개발은 하지 않고 유지만 하고 있으며, WebClient를 사용하길 권장하고 있다.WebClientWebClient는 Non-blocking reactive http 클라이언트이며, thread safe하기 때문에 여러 쓰레드에서 동시에 접근해도 문제가 없다. Reactor Netty, Jetty, apache의 HttpComponent를 이용해서 구현되어 있고, http 호출을 위한 여러 설정들을 메서드 체이닝을 통해 유연하게 설정할 수 있다는 특징이 있다.WebClientBuilderWebClientBuilder는 WebClient를 만들면서 필요한 설정들을 제..
Functional Endpoints는 스프링 5.x 버전부터 추가된 기능이다.기존에 Controller를 기반으로 웹서버를 구성하던 것과는 다르게 Functional Endpoints를 사용하면 HandlerFunction과 RouterFunction를 이용해서 좀 더 함수형 기반으로 웹서버를 구성할 수 있다.HandlerFunctionHandlerFunction은 요청을 처리하고, 응답을 반환한다.handle: ServerRequest를 인자로 받고 ServerResponse를 Mono로 반환하는 추상 메서드RouterFunctionRouterFunction은 path, method, predicate등으로 handlerFunction과 연결하여 해당 요청이 들어왔을 때, handlerFunction..
각각의 스레드에서 상태 값을 저장하여 사용할 수 있는 스레드로컬과 유사하게 리액터에서는 컨텍스트를 사용해서 리액터 시퀀스상에 상태 값을 저장하고, 저장된 상태 값을 사용할 수 있다. 먼저 리액터에서의 컨텍스트가 무엇인지 살펴보고, 컨텍스트의 특징과 자주 사용되는 API를 살펴보자 컨텍스트란 Reactor Sequence상에서 상태를 저장할 수 있고, 저장된 상태 값을 Operator 체인에서 공유해서 사용할 수 있는 인터페이스이다. Context에 값을 저장하기 위해서는 contextWrite()를 사용하고, 저장된 상태 값은 key, value 형태로 저장된다. Context에 저장된 값을 읽어오기 위해서는 읽기 전용 뷰인 ContextView를 사용한다. ContextView는 Reactor Sequ..
리액터에서 스케줄러는 쓰레드를 관리하는 쓰레드 관리자 역할을 하는데, 구독시점에 데이터가 emit되는 영역과 emit된 데이터를 operator로 가공 처리하는 영역을 분리해서 손쉽게 멀티스레딩을 가능하게 한다. 또한, 리액터에서의 스케줄러는 크게 operator chain에서 스케줄러를 전환하는 역할을 하는 전용 operator와 스케줄러를 통해 생성되는 쓰레드 실행 모델을 지정하는 부분으로 구성이 되어 있다. 이 두가지 구성요소 중, 스케줄러를 전환해주는 operator에 대해 자세히 살펴보자. 스케줄러를 전환해주는 operator 리엑터에서 지원하는 스케줄러를 위한 전용 operator는 크게 세가지가 있다. publishOn(): operator chain에서 Downstream Operator의..
CPU 사용량, 메모리 사용량, 톰캣 쓰레드, DB 커넥션 풀과 같이 공통으로 사용되는 기술 메트릭은 이미 등록되어 있기 때문에, 등록된 메트릭을 사용해서 대시보드를 구성하고 모니터링 하면 된다. 만약 비즈니스에 특화된 주문수, 취소수, 재고 수량과 같은 부분을 모니터링하고 싶은데, 이 부분은 공통으로 만들 수 있는 부분이 아니라 각각의 비즈니스에 특화된 부분들이다. 결국 비즈니스에 관한 부분은 각 비즈니스 마다 구현이 다르다. 따라서 비즈니스 메트릭은 직접 등록하고 확인해야 한다. 이번에는 우리 비즈니스의 실시간 주문수, 취소수 또 실시간 재고 수량을 메트릭으로 등록하고 확인해보자. 각각의 메트릭은 아래와 같이 정의한다. 주문수, 취소수 상품을 주문하면 주문수가 증가한다. 상품을 취소해도 주문수는 유지..
메트릭 (metric) 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭을 보관하는 DB가 필요하다. 이렇게 하려면 어디선가 메트릭을 지속해서 수집하고 DB에 저장해야 한다. 프로메테우스가 바로 이런 역할을 담당한다. 전체 구조 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다. 1.1 마이크로미터 프로메테우스 구현체는 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 생성한다. 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다. 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다. 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는 프로메테우스를 통해서 조회한다. 프로메..
서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것이다. 세상엔 수 많은 모니터링 툴이 존재하며, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 된다. 하지만 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다. 모니터링 툴에 지표 전달 예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달해야 한다면, 각각의 정보를 JMX ..
개발자가 애플리케이션을 개발할 때 기능 요구사항만 개발하는 것은 아니다. 서비스를 실제 운영 단계에 올리게 되면 개발자들이 해야하는 또 다른 중요한 업무가 있다. 바로 서비스에 문제가 없는지 모니터링하고 지표들을 심어서 감시하는 활동들이다. 운영 환경에서 서비스할 때 필요한 이런 기능들을 프로덕션 준비 기능이라 한다. 쉽게 이야기해서 프로덕션을 운영에 배포할 때 준비해야 하는 비 기능적 요소들을 뜻한다. 지표(metric), 추적(trace), 감사(auditing) 모니터링 좀 더 구체적으로 설명하자면, 애플리케이션이 현재 살아있는지, 로그 정보는 정상 설정 되었는지, 커넥션 풀은 얼마나 사용되고 있는지 등을 확인할 수 있어야 한다. 스프링 부트가 제공하는 액추에이터는 이런 프로덕션 준비 기능을 매우 ..
YAML 스프링은 설정 데이터를 사용할 때 application.properties 뿐만 아니라 application.yml이라는 형식도 지원한다. YAML(YAML Ain't Markup Language)은 사람이 읽기 좋은 데이터 구조를 목표로 한다. 확장자는 yaml, yml이다. 주로 yml을 사용한다. application.properties my.datasource.url=local.db.com my.datasource.username=hyuuny my.datasource.password=password my.datasource.etc.max-connection=1 my.datasource.etc.timeout=3500ms my.datasource.etc.options=CACHE,ADM..
- Total
- Today
- Yesterday
- Spring
- 코테
- 북클럽
- spring boot
- leetcode
- 문자열
- 알고리즘
- 파이썬
- Real MySQL
- 리팩토링
- 노마드
- 구현
- 자료구조
- 데이터베이스
- 릿코드
- kotlin
- Algorithm
- 스프링 부트
- 정렬
- 김영한
- 스프링
- 노마드코더
- webflux
- 그리디
- 인프런
- mysql 8.0
- MySQL
- 백준
- Refactoring
- 코틀린
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |