SpringOne TOUR Seoul 후기
by Pivotal
이 글은, 지난 목요일 SpringOne TOUR Seoul 세미나 참석 후기이다. 필자가 세미나 중 회사 업무에 신경써서 완전히 집중을 못하였고, 관심사 위주로 정리하였기 때문에 후기 내용이 매우 허접하다. 필자의 후기는 가볍게 보기를 바라며, 반드시 공식 발표 자료를 찾아서 보기를 바란다.
내용 중 잘못 된 내용은 피드백 부탁드립니다.
SpringOne TOUR Seoul
2018년 11월 8일, 지난 목요일에 역삼역 근처 GS빌딩에서 SpringOne TOUR Seoul 세미나가 주최 되었다. 회사 업무가 바빠서 안갈까 고민을 했었지만...정말 다녀오길 잘했다는 생각이 든다.
세미나 발표 순서는 아래와 같다.
1. Reactive Spring with Spring Boot 2.0
2. Cloud-Native Spring
3. Spring Cloud Gateway
4. Cloud Event Driven Architectures with Spring Cloud Stream 2.0
5. Spring, Functions, Serverless and You
6. Spring Boot & Spring Cloud on Pivotal Application Service
7. Using Spinnaker to Create a Development Workflow on Kubernetes
Reactive Spring with Spring Boot 2.0
예상하지 못하였는데, 발표 주제가 살짝 바뀌었다. Java에서 Kotlin 으로 바뀌어서 살짝 당황하였지만, 세미나 내용은 꽤 만족스러웠다.
발표자는 Mark Heckler 라는 Pivotal 개발자인데 자바 챔피언 출신이다. 트위터를 사랑한다는데, 궁금한 점이 있다면 트위터로 물어보면 바로 답변해줄 것 같다.
리액티브 프로그래밍
발표내용
일반적인 Blocking 서버 환경에서는 커넥션이 많아지면 Thread 가 아무것도 못하고 대기 상태가 된다. 반대로, Non-Blocking(논-블록킹) 환경에서는 정해진 Thread 로 많은 작업을 수행할 수 있도록 하기 때문에 많은 Connection(커넥션)에 반응할 수 있다. 즉, 소수의 Thread만 사용하면 되며, 서버의 유연성을 가질 수 있다. 리액티브 프로그래밍은 확장성이 뛰어나고 일관적인 퍼포먼스가 유지되며, 소수의 Thread 에서 모든 커넥션을 처리할 수 있다. 즉, 많은 요청을 더 작은 자원으로 처리하는 것이다. 또한 이전의 Blocking 동기 프로그래밍은 콜백 지옥이 만들어지는 상황이 자주 발생하지만, 리액티브 프로그래밍은 그 부분을 깔끔하게 해결하는 실행 모델이다.
하지만, 리액티브 프로그래밍을 하면 퍼포먼스가 좋아지는가? 라는 질문은 항상 옳지는 않다. 리액티브 프로그래밍은 동기화가 불가능하기 때문에, 커넥션이 소수일 경우에는 오히려 성능이 떨어질 수도 있다.
필자의생각
Reactive 프로그래밍에서 콜백 지옥을 해결할 수 있다라고 이해 하였는데... 필자가 발표 연설 내용을 잘못 이해한 것 같다. 그리고, 추가로 필자가 최근에 스프링웹플럭스에 관해서 정리한 글이 있다. 참고하길 바란다.
https://brunch.co.kr/@springboot/96
Reactive Streams Interface
Reactive Streams 는 4개의 인터페이스로 정의할 수 있다.
필자의생각
참고로, 필자가 세미나 중에 계속 사진을 찍었는데 뒤에 계신 분들에게 방해가 되지 않도록(소심한 마음에) 손을 올려서 찍지 않았다. 일부러 손을 낮춰서 찍었는데 그래서... 앞에 계신 분의 뒷통수가 계속 찍혔다. 저 분 앉은키가 좀 크셔서... 어쩃든 필자 뒤에 계신 분들에게 피해를 줄 수는 없었다.
발표내용
인터페이스를 직접 구현해도 되지만 이미 만들어져있는 라이브러리를 잘 사용하면 되는데, 그게 바로 Project Reactor 이다.
Live Coding, Demo
필자의생각
필자가 Kotlin 을 잘 모르기 때문에, 자세한 코드는 생략하겠다. 발표자의 github 에 모든 코드가 공개되어 있다.
마무리
아래 링크를 참고하길 바란다.
필자의 생각
매우 훌륭한 발표였다! 발표 내용을 자세하게 정리하지 못하였다.
이 글을 보고 있는 개발자 분들에게... 미안하다.
Cloud-Native Spring
두 번째 세션의 주제는 Cloud Native Spring 이다.
발표자는 너무나도 유명한 Josh Long(조쉬 롱) 이다.
Cloud Native Java
발표내용
Cloud Native Java 의 표지를 2년 동안 고민했는데, 인도네시아 자바섬에서 유일하게 서식하는 고유종인 새를 표지에 넣었다. 책 제목이 Cloud Native Java 라서...
Live Coding
필자의 생각
라이브 데모 코딩이 너무 빨라서, 정리를 거의 하지 못하고 그냥 감상만 하다가 끝났다. 기억나는 멘트는 아래와 같다.
- 클라우드 네이티브 자바 책 표지에 나온 새에 대한 썰
- 스프링부트2.1 에서 배너 기능이 더욱 향상되었고, IntelliJ "Hide Banner" 버튼에 대한 썰
- Reactive Spring 이라는 주제로 새로운 책을 쓰고 있다는 썰
- 스프링 5.2 에서는 RSocket 를 정식으로 지원한다는 썰
발표 내용은 머리속에서 지워버렸지만, 너무 유익한 발표였다. 필자가 그동안 개발자로 살면서 참석한 수많은 세미나 중에서는 최고로 재미이는 발표였다. 하지만... Josh Long의 라이브 코딩이 기억이 나지 않는건 왜일까??
어쨋든 나중에 사인 받고, 하이파이브도 했다.
Spring Cloud GateWay
세번째 발표는 Spring Cloud GateWay 에 대한 주제인데, 원래 발표자가 참석하지 못해서 정윤진 님께서 대신 발표하였다. 참고로 정윤진님은 지난 2017년 스프링캠프에서도 발표한 분이다.
공식 발표 자료를 참고하길 바란다.
http://slides.com/spencer/spring-cloud-gateway#/
API Gateway Responsibilities
발표내용
Routing
Canarying
Resiliency
Monolith Strangling
Security
Monitoring
Flexibility
필자의 생각
API Gateway 에 대해서 간단하게 정리한 필자의 글을 참고하자.
https://brunch.co.kr/@springboot/38
API Gateway Types
발표내용
Appliance
SAAS
Web Server
Mesh
Developer-Oriented
Spring Cloud Gateway vs Netflix Zuul
발표내용
넷플릭스에서 만든 Zuul 은, 넷플릭스에서 맞게 구현한 라이브러리를 오픈소스화 한 것이다. 하지만, 스프링에서는 Zuul 을 사용하지 않는 것으로 결정하였고, 새로운 Spring Cloud Gateway 프로젝트를 신규로 시작하게 되었다. 리액티브 기반이고 Netty 서버가 기본으로 적용이 된다. Eureka, Hystrix 와 연동해서 사용할 수 있어서 기본적인 서비스 Discovery 가 가능하다.
참고로 최근에 넷플릭스에서 Zuul 2 를 발표하였는데, 기존 Zuul 이 비동기 프로세스 지원이 어려웠기 때문에 신규로 Zuul 2 를 개발하였다. 아쉽지만 하위 호환성은 없다. 완전히 새로 만들었다.
Inside the Gateway
Configuration
발표내용
기존에 Zuul 에서의 Yaml 컨피그레이션 복잡함을 개선하기 위해서 Spring Cloud Gateway에서 새로운 방식을 도입하였다. 기존 방식도 사용이 가능하다.
Java Congiguration 도 가능하다!!
UseCase
발표내용
API Gateway 는 마이크로서비스로의 전환 과정에서 유용하게 사용할 수 있다. 또한 Gateway 앞단에 Common Gateway를 적용할 수도 있다.
필자의 생각
다양하게 API Gateway 를 적용할 수 있다. 발표 내용 중 Micrometer, Zipkin 등에 대해서도 얘기가 나왔다. 그리고 발표자분들이 테스트를 위해 아래 도구를 사용하였다. Curl 은 인간을 위한 도구가 아니다. 라는 명언을 남겨주셨다.
점심
점심은 테이블로 직접 갖다 줬다. 맛있었다.
Cloud Event Driven Architectures with Spring Cloud Stream 2.0
네번째 세션의 발표자는 Jakub Pilimon 이다.
Event Storming
필자의 생각
발표 초반에 Event Storming 에 대한 많은 설명을 하였다. 필자는 Event Storming 에 대한 이해를 제대로 못하였다. 발표자의 글을 참고하자.
https://spring.io/blog/2018/04/11/event-storming-and-spring-with-a-splash-of-ddd
Event Sourcing
발표내용
장점
Auditing 이 가능하다.
State 를 되돌 릴 수 있기 때문에, 어떤 일 이 발생하였는지 추적할 수 있다.
이벤트 개반으로 다양한 컴포넌트에서 활용할 수 있다.
이력을 보면서 Status에 도달한 것에 대해서 비교를 할 수 있다.
단점
비즈니스 진화에 의한 버저닝이 필요하다.
실수로 이벤트를 잘못 생성한 경우에 문제가 발생할 수 있다.
사고의 전환이 필요하다.
더 많은 코딩을 해야 한다.
1. 비즈니스 추적이 어렵다.
2. 변경을 해야 하는 경우 4개의 컴포넌트 모두 바꿔야 할 수도 있다.
3. 특정 상황에 따라서 버저닝을 해야 한다.
Message Broker
메시지 패턴으로 개선할 수 있다.
1. Input, Output 에 대한 채널만 생각하면 된다.
2. 메시지 브로커를 바꾸는 일은 어렵지 않다.
Spring, Functions, Serverless and You
AS-IS, TO-BE
발표내용
초기 시스템을 구축할 때 우리는 대략적인 계산으로 추측하여 최악의 시나리오를 찾지만, 서버 인스턴스를 만드는 일은 쉽지 않기 때문에 우리는 처음부터 많은 자원을 할당할 수 밖에 없다. 서버들은 제약이 많은 자원이고, 비싸고 관리하기 어렵기 때문에 기업의 임원들은 항상 투자 타당성을 증명해 내기를 바란다. 그래서 가능하면 제한 된 서버에 많은 애플리케이션이 수행되기를 바라며, 한 서버에서 특정 애플리케이션이 문제가 발생하면 주변 다른 애플리케이션에도 치명적인 영향이 미치게 되는 상황이 발생한다. 애플리케이션 간의 의존성으로 인해서 애플리케이션 간의 사이드이펙트가 발생하게 되는 것이다. 해당 문제를 해결하기 위해 우리는 제한된 물리서버에 여러개의 애플리케이션을 분리하기 시작하였는데 역시 분리 과정에서도 문제가 발생을 한다. 새로 분리하는 서버의 환경이 다르기 때문이다. 우리는 클라우드 환경에서 변화를 경험하게 된다. 서버는 범용 상품이 되어가고 있고, 가격도 떨어졌고 이제는 더이상 제약요소가 되지 않는다. Heroku, AWS, Google 등 수많은 클라우드 플랫폼으로 인해서 예전 방식에서 벗어나게 된다. 서버는 일관성이 필요하다. 즉, 똑같아야 한다. 이제 우리는 서버 인스턴스를 올리는데 몇주만에 가능하게 되었고, 지금 당장 개발이 필요하다면 기다리지 않고 바로 AWS를 사용하면 된다. 처음에는 거의 무료에 가깝다.
Serverless
발표내용
Serverless 라는 단어가 완전히 맞는 용어는 아니다. 서버가 아예 없는건 아니다. 우리한테 없지만 어딘가에는 서버는 존재해야 한다.
발표내용
전체 애플리케이션을 Function 으로 이루어질수도 있지만, 예외 상황도 있다. 어디에서 사용할 것인가를 정하는 것이 제일 중요하다. 모든 애플리케이션을 Function 으로 구현한다는 생각은 잘못된 아키텍처이다.
발표내용
Serverless는 좋지만, 우리가 직면한 문제에 대해서 먼저 찾아야 하고 많은 옵션을 고려해야 한다. 새로운 것을 하고 싶어하는 개발자의 저주에 대해서 생각해야 한다. 다람쥐를 쫒아가고 싶은 강아지처럼... 하지만 우리는 반드시 무엇을 해결해야 하는지 알아야 한다. 일부에서는 필요하지도 않은 Serverless를 도입하게 되는데 새로운 것을 무조건 찾지 말고, 우리에게 필요한지를 먼저 심각하게 고민해야 한다.
Serverless 에 도입하기 좋은 예는 아래와 같다.
배치 프로세싱
비동기
CI/CD Automation
이벤트 프로세싱
아주 유용하지만 절대 정답은 아니다. 언제 사용하는게 맞는지, 왜 필요한지를 찾아가는게 훨씬 더 중요하다.
riff
발표내용
메시지 컴포넌트에 대해서 고민할 필요가 없다. 즉, Kafka, RabbitMQ 모두 가능하다.
선택
발표내용
그때그때 마다 다르고, 지금 환경에서 어떤 일이 벌어지는지 알아야 한다. 하나의 솔루션이 정답이 아니다. 개별적으로 보고 판단해서 문제에 대한 해결책을 찾아야 한다. 기술 결정을 하는 과정에서 선택을 하면 그 책임도 함께 따라온다. 기술은 발빠르게 진행하고 있고, 정말 빨리 변하고 있다. Riff 역시 매우 빠르게 변경이 되고 있다.
Spring Boot & Spring Cloud on Pivotal Application Service
세션 내용은 참 좋았습니다. 하지만 필자가 따로 정리를 못했습니다.
혹시, 정리 잘하신 분 피드백 부탁드립니다.
Using Spinnaker to Create a Development Workflow on Kubernetes
세션 내용은 참 좋았습니다. 하지만 필자가 따로 정리를 못했습니다.
혹시, 정리 잘하신 분 피드백 부탁드립니다.
총평
개인적으로 너무 유익한 시간이었다. 통역도 생각보다는 괜찮았다. 물론 초반에 Spring 을 봄 으로 통역하는 등 일부 통역의 한계가 있었지만 전체적으로는 너무 훌륭한 통역이라서 좋았다. 보통, 외국인 연사의 기술 세미나는 통역이 항상 문제였는데 이번 행사는 통역이 신의 한수였던 것 같다. 그리고, 세션 내용도 너무 좋았고, 점심 식사도 괜찮았다.
