Spring Camp 2017 - 후기

이번 글은 Spring Camp를 다녀온 후기를 남기는 글 입니다.

 

작년에 GDG Seoul 2016 Fair에 이어 컨퍼런스를 참여하게 되었습니다. 개인적으로는 Spring Camp에 더 오고 싶은 마음이 컸고(저는 스프링을 애용하는 자바 개발자입니다.), KSUG이 10주년이 되는 해라고 해서 더욱 큰 규모로 진행된다고 하니 이번 컨퍼런스는 무척이나 기대되었습니다.

 

김경원님의 <Booting Spring Data REST>

이일민님의 <Async & Spring>

이일민님의 <Spring Web Flux>

 

 

김경원님의 <Booting Spring Data REST>

 

- Spring에서 제공하는 Data Rest에 대한 내용이였습니다. Data REST는 Spring + Data JPA 조합에서 보다 빠르게 REST API를 만들 수 있게 도와줍니다.

 

1 . Repository Interface 정의만으로 REST API를 제공 가능합니다 (Controller 없어도 됩니다.)

① @RepositoryRestResource로 Controller, Repository, Service이 통합됩니다.

② PagingAndSortRepository를 상속 받음으로써, 페이징처리와 정렬을 할 수 있습니다.

③ Insert 같은 경우에 전후처리가 필요한 시점이 있는데, @RepositoryEventHandler 추가하거나 AbstractReposoitoryEventHandler 상속받아 처리가 가능합니다.

④ Controller가 필요한 경우에, @RepositoryRestController를 이용하여 가능합니다.(상위 Path를 맞춰줘야 작동합니다.)

 

 

2 . Data JPA에서 Interface에서 메소드를 작성하면 Query를 작성할 수 있는데, 이것을 바로 API 지원합니다.

- 기본적으로는 {domain}s/search/{method name}으로 되나, @RestResource를 이용하여 세부적인 처리가 가능합니다.

 

 

3 . Projection을 이용하여 데이터의 다양한 표현방식을 제공합니다.

- {url}?projection={name}

 

 

4 . HATEOAS를 이용하여 메타데이터를 제공합니다.

- Client에게 url를 제공해줌으로써, url를 조합해야하는 수고를 덜어줍니다.

- ResourceProcessor를 이용하여 Global HATEOAS 설정 가능합니다.

 

 

5 . RepositoryRestConfigureAdapter로 전반적인 세부설정이 가능합니다.

 

 

이일민님의 <Async & Spring>

 

1 . Spring에서는 version 3.2~ 이후에 비동기 개발이 가능합니다.

① 자바 비동기(Future/Executor, Blocking Queue, ForkJoinTask, CompletableFuture, Flow)

② 서블릿 비동기(Async Processing Async Context, Non-Blocking IO, ...)

③ 스프링 비동기(@Async, AsyncRestTemplate)

 

1-1 . 동기와 비동기 차이가 무엇인가?

- 메소드 요청 작업과 리턴 시간이 일치하다면 동기입니다.(↔ 비동기)

 

1-2 . 동기&비동기와 항상 같이 대두되는 Blocking&Non-Blocking

- 동기&비동기를 논할 대상이 아닙니다.

- 내가 직접 제어를 할 수 없는 대상을 상대하는 방법이라고 합니다.

 

 

2 . @Async

- 정해진 리턴타입을 이용해야만 사용 가능 합니다. (String, List<T> 등등 사용 불가능)

① ~ Java 7 : Future, ListenableFuture<T>

② Java 8 ~ : CompletableFuture<T>

 

※ 기본적으로 SimpleAsyncTaskExecutor를 사용합니다.

- 쓰레드풀이 아닙니다.

- 매번 쓰레드를 만들고 사용 후 버려지게 되기 때문에, 자원 낭비가 심합니다.

- Executor, ExecutorService, TaskExecutor를 Bean으로 등록 하게 되면, 해당 쓰레드풀을 이용하여 관리됩니다.

 

+ 쓰레드풀을 설정할 때 corePool/maxPool/Queue를 초기화 하는데, Core Size 만큼 쓰레드를 관리하다가 Queue가 감당하기 힘들 만큼의 쓰레드 수가 늘어나게 되면, Max Size까지 늘리게 됩니다.

 

 

3 . 서블릿 + @MVC

① Callable

② WebAsyncTask : 시간과 쓰레드풀을 지정 가능합니다.

- DeferredResult : 임의의 쓰레드에서 리턴값 설정이 가능합니다.

- DeferredResult + @Async 조합하면 좋다 => ListenableFuture<T>로 대체 가능합니다.

 

But!! 두개의 비동기 방식으로 진행될 경우, DeferredResult를 중첩 사용해야합니다.

But!! 콜백 중첩이 발생합니다.

But!! CompletableFuture<T> 사용할 경우, 콜백 헬을 막을 수 있습니다. (그러니 Java 8를 사용하세요...ㅎ)

 

 

4 . AsyncRestTemplate

- Spring 4.0부터 사용 가능합니다.

- 비동기방식으로 진행되지만 많은 쓰레드를 만들게 되어 점유율이 높아집니다.

- Non-Blocking IO HttpClientFactory를 사용하면 쓰레드 점유율을 낮출 수 있습니다. (예 :Netty)

- ListenableFuture<T> 로만 반환하게 되므로 CompletableFuture<T> 커스터마이징해서 쓰는 것이 좋습니다.

 

 

5 . 결론

비동기 작업과 잦은 API 호출이라면...

- AsyncRestTemplate는 Non-Blocking IO를 조합해서 쓰자

- @Async와 적절한 TaskExecutor 를 사용하자 

- ListenableFuture<T>, CompletableFuture<T> 를 사용하자

- 항상 기본 셋팅을 사용하지말고, 쓰레드풀을 만들어서 쓰자 ★

 

- But!! 모르면 쓰지말자... ★

① 코드가 복잡해진다.

② 디버깅이 힘들어진다.

③ 아무런 혜택도 못 누리게 된다.

 

 

이일민님의 <Spring Web Flux>

 

1 . 간단한 소개

- Spring 5.0에서 나오는 새로운 방법입니다. (아직 정식 릴리즈 안됨)

- Min JDK : Java 8

- 원래는 Java 9이 테마였으나, WebFlux로 변경되었습니다.

 

 

2 . 왜 써야하는가?

- Async & Non-Blocking Reactive 개발에 사용됩니다.

- 효율적으로 동작하는 고성능 웹 어플리케이션 개발이 가능합니다.

- 서비스 간 호출이 많은 Micro Service Architecture에 적합합니다.

 

 

3 . Web Flux 사용 방법

① 기존 MVC

- @Controller, @RestController

- @RequestMapping

② 새로운 함수형 모델링

- RouteFunction

- HandlerFunction

 

 

4 . 기존 서블릿 요청 탈피ing...

HttpServletRequest

HttpServletRsponse

  ↓

ServerRequest

ServerResponse

 

 

5 . 지원 서버&컨테이너

- Servlet 3.1 +

- Netty

- Undertow

 

 

6 . MVC 요청 방식

① 요청 매핑 - RequestMapping

② 요청 바인딩 - Url Path, Header, Cookie, Body

③ 핸들러 실행 - 로직 수행 & 반환

④ 핸들러 결과 처리

 

6-1 . Web Flux 요청 방식

① 요청 매핑 - RouteFunction

② 요청바인딩, 핸들링 실행 및 결과 처리 - HandlerFunction

- @Bean이나 @Component로 따로 정의하여 route를 관리합니다.

- RouterFunctions.route(Path, ServerRequest)를 이용하여 조금 더 편리하게 관리 가능합니다. 

 

+ and(), andRouth()로 체이닝 가능합니다.

+ nest()로 공통 path 설정이 가능합니다.

 

6-1-1 . 장점

① 요청작업을 명시시적인 코드로 작성이 가능합니다.

 - 어노테이션에 의존하는 것이 아니라 명확합니다.

 - 정확한 타입 체크가 가능합니다.

② 함수 조합을 통한 편리한 구성&추상화 유리합니다.

③ 테스트 작성이 편리합니다.

 

6-1-2 . 단점

① 함수형 스타일로 작성이 어려우면 어렵습니다.(러닝커브가 심합니다.)

 

 

7 . 스프링 Web Flux Annotation 방식

- @RestController, @RequestMapping를 동일하게 사용합니다.

- 반환타입을 Mono, Flux로 하고 실제 반환하고자하는 데이터를 제네릭타입에 넣어줍니다.

Mono<Entity>...

- @RequestBody 또한 Mono<Entity>로 받는 것이 가능합니다.

Mono<String> hello(@RequestBody Mono<User> user) {
  return user.map(u -> "Hello" + user.getName());
}

 

8 . 개선할 수 있는 상황

① JPA : @Async + CompletableFuture 조합으로 개선이 가능합니다.

② Redis, Mongo : ReactiveCrudRepository를 구현하여 개선이 가능합니다.

③ WebClient : AsyncRestTemplate의 Reactive 방식

 

※ JDBC 방식은 JDK 10을 기다려보자....

 

9 . 왜 써야하는가?

① 성능 향상 및 개선된 코드를 볼 수 있습니다.

② 다양한 오퍼레이터 적용이 가능합니다.

③ 추상화된 코드 작성이 용이합니다.

④ 데이터 흐름의 속도를 제어할 수 있는 메커니즘을 제공합니다.

 

 

참고

- 아래 링크는 제가 들은 세션이외에도 추가 링크해놓았습니다.

- http://www.springcamp.io/2017/

- 이경일님의 발표자료

- 신동민님의 발표자료

- 이경원님의 발표자료

- 오명운님의 발표자료

- 정상혁님의 발표자료

- 조인석님의 발표자료