Skip to content

Instantly share code, notes, and snippets.

@ihoneymon

ihoneymon/20181108_springone_2018_tour.adoc

Created November 9, 2018 08:55
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ihoneymon/da11c195da647a9af1034807e865c872 to your computer and use it in GitHub Desktop.
Save ihoneymon/da11c195da647a9af1034807e865c872 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
20181108_springone_2018_tour.adoc

20181108 SpringOne Tour - Seoul, By Pivotal

Table of Contents

한눈에 보는 정리

  • 코틀린을 이용해도 스프링 프레임워크는 잘 동작한다는 것

    • 코드도 간결하고

    • 맥북은 영어로만 코딩하면 빠르군. 한영 변환 비용은 꽤 비싸다.

  • 피보탈에서 '클라우드 네이티브(Cloud Native)' 에다가 '리액티브(Reactive)' 를 얹었고

  • 리액티브 작동은 개발자가 하나하나 구현하기보다는 플랫폼에 넘기고 스프링 프레임워크 기반의 개발경험을 살려서 리액티브 웹 프로그래밍하면 되고

  • spring cloud gateway 로 라우팅 구현하는 게 편해보였고(YML로 선언하는 것보다는 훨씬)

  • 다들 라이브코딩 앤 스피킹이 자연스러웠고

  • 쿠버네티스까지는 모르겠지만

    • 도커는 능숙하게 쓸 수 있어야 겠다.

  • 조쉬롱은 2년만에 봤는데 발표스타일이 많이 달라져서 유쾌해졌다.

  • 피보탈 클라우드 파운더리 서비스는 언제 이용해볼 수 있을까를 잠시 생각해봄

키노트

  • 노경훈 대표

Note

피보탈은 소프트웨어를 통해 세상을 변화시키려는 기업이다.

  • Pivotal: Transforming how to the world builds software

    • Process: Pivotal Labs

      • Culture(고객의 비즈니스 변화에 중점을 둔 지속적 학습), Process(Practice dispipline, rigor, open to critiquew)

    • Technology: Pivotal Cloud Foundry

      • Tools(Focus on developer productivity), Platform(Any workload, Every Cloud, One secure Platform)

Reactive Spring with Spring Boot(by Kotlin)

Note

자바챔피언이 코틀린으로 스프링 프로그래밍을 한다. 코틀린으로 간결하게 작성하는 모습이 인상깊었다. 코틀린으로 프로그래밍 언어를 전환해도 괜찮겠다는 생각을 하게 되었다. 이건 개인프로젝트로 한번 시도해봄직하다.

리액티브(Reactive)를 통해 성능을 높일 수 있을까?

  • 적은 커넥션으로도 일정한 성능을 유지하며 뛰어난 성능을 확보할 수 있다.

  • 리액티브 프로그래밍을 통해 동일한 스레드를 이용해서 보다 많은 처리를 할 수 있다.

    • 비동기 프로그래밍을 하게 되면,

      1. 콜백을 기반한 처리

      2. 콜백 지옥에 빠지게 된다.

      3. 코드 이해도 하락

      4. 생산성은 떨어진다.

    • 클라우드에 제어 권한을 넘기고 리액티브 프로그래밍을 통해 비즈니스 구현에 집중할 수 있다.

Reactive Stream

  • IT CROWD: 넷플릭스, 지하 전산실 사람들

Heckler가 추천하는 미드

  • Spring Project initializer: Reactive Web, MongoDB 사용

  • ReactiveCrudRepository

  • 코틀린에서는 method가 없고 function 단위 등록되기 때문에 func

  • 리액티브 프로그래밍에서 동작을 위해서는 마지막에 subscribe 를 사용해야 한다.

    • block() 대신 thenMany() 으로 처리

  • 독일사람이 만든 플러그인에서 flapdoodle 이라는 패키지명을 사용한 것이 독특함

@Service
class CoffeeService(private val repo: CoffeeRepo) {
    fun getAllCffees() = repo.findAll

    fun getCoffeeById(id: String) = repo.findById(id)

    fun getOrdersForCoffee(coffeeId: String) = refo.findByName(coffeeId)

    = Flux.interval(Duration.ofSeconds(1))
    .onBackpressureDrop()
    .map{CoffeeOrder(coffeeId, Instant.no())}
}

  • 웹플러스 테스트 @WebFluxTest(CoffeeService::class)

Mockito.`when`(repo.findAll()).thenReturn(Flux.just(coffee1, coffee2))

@Test
fun `Get all coffees`() {
    StepVerifier.create(service.getAllCoffees()) // 위에서 정의한
        .expectNext(coffee1)
        .expectNext(coffee2)
        .verifiyComplete()
}

  • 리액티브 기능을 테스트하려면 시간을 압축하는 것이 중요하다.

@Test
fun `Get`() {
    StepVerifier.withVirtualTime{service.getOrdersForCoffee(coffee2.id!!).take(10)}
        .thenAwait(Duration.ofHour(10))
        .expectNextCount(10)
        .verifyComplete()
}

  • 10초를 테스트 한번으로 압축하는 방법

  • 리액티브 프로그래밍된 코드를 테스트로 확인하는 과정이 중요하다.

Note

이와 관련해서는 지난 카카오2018에서 토비님이 발표한 내용을 살펴보면 좋겠다.

 
@RestController
@Requestmapping("/coffees")
class CoffeeController(private val service: CoffeeService) {
    @GetMapping
    fund all() = service.getAllCoffees()

    @GetMapping("/{id}")
    fun byId(@PathVariable id: String) = service.getCoffeeById(id)
}

  • httpie 좋아요~

    Note

    httpie는 localhost 생략가능하다.

    ex) http :8080/members

  • 리액티브 프로그래밍을 통해서 블로킹없는 기능을 구현했다.

정리

  • '코틀린을 서버사이드 프로그래밍언어로 사용할 수 있을까?' 라는 의문을 한번에 해소할 수 있었다. 자바를 이용했을 때보다 훨씬 간결한 코드를 보면서 내년에 코틀린을 이용한 프로젝트를 준비해보는 것도 좋을 듯 하다.

Cloud-Native Spring

  • 발표자: Josh Long

  • 클라우드 네이티브 자바 쓰는데 2년 걸렸다.

    • 책 표지에 어떤 동물을 넣을 것인지를 치열하게 논의했다.

    • 자바 섬에 사는 새 → 새는 구름속을 날아다닌다. // 열띤 논의를 했다고 한다.

  • http://www.reactivespring.io/

    • 적은 스레드를 가지고 I/O를 효율적으로 사용할 수 있는 패러다임: 리액티브 프로그래밍

@AllArgsConstructor
@NoArgsConstructor
@Data
class Reservation {} // 조쉬롱도 잘 쓰는 @Data... EqualsAndHashCode

  • 라이브 코딩을 통해 빠른 생산성을 보여주고 있다.

  • 인텔리제이를 바탕으로 빠르게 코드생산성은 높이자.

Note

인텔리제이에 왜!! Spring Boot Banner hide 기능이 생긴 것이냐. 분노하는 조쉬 롱. ** https://twitter.com/yanncebron/status/702216038344220672

Cb7FttiW0AAVBJQ 젯브레인 개발자 Yann이 Hide Banner를 비활성화해주겠다고 했던 게 2016년인데 아직도 반영되지 않고 있다. 이렇게!

chatty banner3

이렇게!

멋지지 않은가! 하고 열변을 토함

  • Spring cloud Gateway

    • RouteLocator

      • Spring Boot 2.0.6 사용해야함(2.1.0 버그가 있어서 동작안함)

      • Spring Boot 2.1.0 곧 패치예정

  • Spring Security

    • 하드코딩된 사용자명과 비밀번호를 쓰지 마라. @ROB_WINCH 가 슬퍼한다.

    • 스프링 시큐리티는 스프링 애플리케이션의 WebApplicationContext에 대해 필터링한다.

    • 리액티브웹에서 스프링 시큐리티 필터링을 이용하기 위해서는 ReactiveWebApplicationContext 와 스프링 시큐리티 필터를 연결해줘야 한다.

  • 요청 제어가 가능해짐

  • hedging: 먼저들어오는 것을 사용하겠다.

  • 게이트웨이 구축

  • http 프로토콜을 이용해서 웹 마이크로서비스만 구축하는 것은 아니다. 다양한 프로토콜을 이용할 수 있다.

    • link::https://grpc.io/[gRPC]: 고성능 RPC 프레임워크

    • rSocket: 리액티브 스트리밍을 지원하는 애플리케이션 프로토콜 *현재는 구현해야하는 코드가 많지만 스프링 5.2 에서 지원하면 손쉽게 사용할 수 있을 것이다.

Note

발표자들은 빠른 속도로 한치의 망설임도 없이 구현코드를 작성해갔다. 대다나다!!

Spring Cloud Gateway

  • 발표자: Younjin Jeong

  • Spring Boot를 소개하고 널리 사용되기까지 4년이 걸림

  • 그 다음으로 클라우드기반 개발할 때는 무엇으로 어떻게 할까를 고민할 때 Spring Cloud!

    • 원래는 spencer Gibb가 발표하는 주제다.

Note
스프링 부트 이후의 행보에 대해서는 쉽게 예측하기가 어렵다. @_@)

현재 우리나라에서는 AWS를 이용해서 각 회사에서 필요한 시스템 인프라를 구축하고 관리하는데 익숙해져 있는 탓에 PaaS 에 대한 관심이 그렇게 높지 않다. 인원이 적고 이제 서비스 개발을 막 시작한 스타트업에서는 고려해봄직하다.

한 곳에서 요청을 받아서 사용목적에 따라서 할당(라우팅)해주는 역할을 해준다.

  • What is an API Gateway

    Use API Gateway

  • Reverse Proxy(Nginx)

  • 다양한 분산기법을 사용하고픈 욕구를 충족시켜주는 것이 필요했다.

  • 요구사항

    • Routing

    • Canary-ing(A/B 테스트)

    • Security

    • Monolith Strangling: 모놀리스 분할

    • Monitoring

    • Resiliency(탄력성)

  • SasS

  • Web Server(Proxy)

  • 'Service Mesh'

    • 참고

    • 애플리케이션이 동작하는 모든 서버에 프록시가 존재하며 서비스 디스커버리를 통해서 존재 확인

      • 각각의 컨테이너 안에 로드밸런서가 포함되어 프록시 역할 수행하는지

  • Spring Cloud Gateway(or Netflix Zuul)

  • Project Reactor(Netty 기본내장)

  • 게이트 쪽에서 서버자원을 장시간 점유하게 되는 경우에는 리액티브 프로그래밍이 좋다.

  • Inside the Gateway

  • Ribbon(Ratency 기준 분산가능)

  • Route Configuration 개념 변화: YAML → Java

    • 라우팅할 경로를 지정하는 목적이라면 YAML로 작성하는 것보다 Java 로 구현하는 게 간결해보이기는 한다.

  • wscat: 웹소켓 서버와 클라이언트 사이에서 echo를 날린다

  • Chaos monkey for Spring Boot

    sb chaos monkey architecture

Note

스프링 부트를 위한 카오스 몽키도 있었다(참고: 스프링 부트와 카오스 몽키)

카오스 엔지니어링은 일반적으로 서비스를 테스트 목적으로 일부러 망가트려보고 이에 대한 시스템의 반응을 바탕으로 더 견고한 서비스를 만들기 위한 엔지니어링을 말한다.

Remember

  • Spring Boot

  • Spring Security

  • Micrometer Support

  • Zipkin Support: Distributed tracing system

Cloud Event Driven Architectures with Spring Cloud Stream 2.0

  • 이벤트소싱을 했을 때 얻게되는 이득은 뭐가 있을까나?

// CreditCard
// DomainEvent implements Event
public void assignLimit(BigDecimal amount) { // command: green note
    if(limitWasAreadyAssigned()) { // invriant - yellow notes
        throw new IllegalArgumentException(); // NACK
    }
    //ACK
    //this.limit = amount;    // 이벤트가 반영되지 않을 수 있다.
    limitAssigned(new LimitAssigned());
}

이벤트가 발생하면 그 결과를 찾아내야 한다. * 신용카드 정보를 저장하기 위해서 필요하다.

  • 신용카드 상태가 변경될 때마다 신용카드 기존 정보가 사라진다.

    • 변경될 때마다 그 정보를 저장한다.

    • 저장정보를 이용해서 필요한 상황이 되었을 때 복구할 수 있다.

    • 도메인 이벤트 이력 저장소(DomainEvent history storage)

    • 상태가 변경되면서 발생하는 모든 값을 파라미터로 전달

  • 이벤트를 스트림에 저장하고 나면 이벤트는 소거(clear)해도 된다.

  • 신용카드 정보가 아닌 이벤트를 저장하는 이유

  • 왜 이벤트소싱을 할까?

    • 도메인에 대한 감사(Auditing) 가능해진다.

    • 문제가 발생했을 때 과거 시점으로 도메인 상태를 복구가능하다.

    • 특정 이벤트에 대한 모니터링을 하는 등 다양한 컴포넌트에서 비교 가능

      • ex) 비슷한 시간에 결제된 항목의 장소를 확인하는 것도 가능하다.

    • 카드결제내역을 비교할 수 있다.

    • 단점

      • 잘못된 이벤트에 대한 처리: Output lug?

      • 작성해야하는 코드가 증가

      • 사고 전환이 필요하다.

  • 절차지향적인 도메인인 경우

    • 누락된 절차를 찾기 힘들다.

  • 메시지소싱(MessageSourcing)

    • Spring Integration

    • input-output 채널에만 집중하면 된다.

  • dependency spring-clout-stream, spring-cloud-stream-bidner-rabbit(MessageQueue)

  • MediaType.APPLICATION_STREAM

  • 예제: http://github.com/pilloPI/credit-cards-producer

Spring, Functions, Serverless and You

  • 발표자: Nate Schutta

  • serverless 는 불가능하다. 어딘가에서는 서버가 있다.

  • 상을 뒤엎을 정도로 화가 났다. Table flap.

  • 기존에 가지고 있던 지식들을 활용할 수 있으니 코드를 삭제하지 마라.

  • 과거 하드웨어 중심시대

    • 인프라를 구축하기 위해 해야할 일들이 많았다.

  • 현재 소프트웨어 중심시대

    • 자신의 고양이를 키우듯

    • 부작용: 공유된 자원(Shared resource): 격리되지 않은 자원때문에 작은 변화가 주변에 영향을 끼친다.

  • (개발)환경을 동일하게 구성하는 것이 어렵다.

    • 과거에는 패치 순서가 다른 경우 다르게 동작할 수 있었다.

      • 복잡하게 이름을 지었다.

  • 서버는 더이상 제약 자원이 아니다.

  • 다양한 클라우드 프로바이더가 생겨났고 서버의 교체가 용이해졌다.

    • ex) 가축에게는 이름을 부여하지 않는다. 숫자를 준다…​. 슬프다.

  • 스크립트를 통해서 실행되는 것을 동일하게 보장할 수 있게 되었다.

  • 서버를 올리는 시간이 단축되었다.

  • IaaS - provision server resources(on premisure)

  • Sometimes on demand self service

  • 큰 힘에는 그에 따른 책임이 따른다.

  • Container != Docker

    • Docker is box!

  • 가상화를 하는 영역이 달라졌다(하드웨어 → 소프트웨어)

    • 도커에게 모든 행위를 알려줘야 한다.

    • docker hub는 커뮤니티 중심이지만 검증된 것은 아니다.

Note

기업마다 애플리케이션 수 만큼 도커 이미지가 존재한다.

도커를 사용하면 그 이미지에 대한 책임을 져야 한다.

  • 패치를 통해 보안업데이트는 수시로 해야한다.

  • meltdown & spectre

  • Kubernetes 개념을 설명

    • 다양한 선택사항이 존재한다.

    • 단순하지 않다.

  • Serverless

    DThZ1jSWsAEgxko

    • IaaS

      • Container

      • Platform

      • Servleress

        • 함수 실행

        • 함수 확장

        • 이벤트 스트리밍 바인드

  • 자신에게 맞는 것을 선택하라.

  • PaaS를 사용하면 인프라 스트럭처를 사용하는 것은 크게 신경쓰지 않아도 된다.

    • 기업의 가치를 어디에 중점을 둘지 고민

  • 다양한 곳에서 사용할 수 있다.

  • 서버리스 환경에서 중요한 건 언어가 아니라 UseCase다!

  • https://projectriff.io/

  • KNATIVE

  • 나에게 어울리는 것은 무엇인가?

Spring Boot & Spring Cloud on Pivotal Application Service(PAS)

  • Younjin Jeong

  • Build once, Run everywhere.

  • 레거피 웹애플리케이션을 컨테이너에 담아서 그대로 배포하는 것은 적절하지 않다.

  • 운영의 영역을 구분지어서 쓰는 일이 있을까? @_@)?

  • 클라우드 게이트웨이, 유레카 등이 소스코드에 반영되어야 하는데 개발자가 그걸 몰라도 될까??

  • full cycle developers - netflix

    1* nN4aj7uohV4v8bnqJCw3g

  • 높은 유연성 → 표준이 복작해진다.

  • 개발자 친화적, 인프라 친화적

  • Spring Cloud Pipeline

  • Container to Container Networking

  • Spring Boot를 이용하면 Factor 12 요소를 쉽게 충족할 수 있다.

Using Spinnaker to Create a Development Workflow on Kubernetes

  • Paul Czarkowski

  • kubectl

  • PKS

    • kubectl 을 통해서 실행

  • kubernetes 101

  • POD

    • 하나 이상의 애플리케이션 컨테이너가 있으며 자원을 공유하며 긴밀하게 연결되어 있다.

  • ReplicaSet

    • 몇 개의 POD을 운영할 지 정의

  • Deployment

    • ReplcaSet 을 정의하고 업데이트 그리고 업그레이드를 정의

  • Statefulset

    • statue fulll application 배포관리

  • Halm

  • spinnaker

    • spinnaker + kubernetes + PCS 를 이용하면 손쉽게 배포 가능

Summary

  • 조쉬롱 캐릭터가 바뀌었다. 예전에는 그렇게 활발한 캐릭터가 아니었는데…​

  • SpringOne Tour 발표트렌드는 라이브코딩이 되었다. 발표장표와 코드를 적절하게 배치하여 개발자들에게 실제로 코드를 보여주고 실제로 동작하는 모습을 보여주면서 흥미와 신뢰를 유발하는 듯 하다.

  • 지난 6월에 있었던 Cloud Native Day in Seoul 보다 훨씬 더 나아졌다.

  • AWSomeday 의 뒤를 이어 SpringOne Tour 도 정기적인 행사로 자리잡게 될까?

  • 나는 아직 스프링 부트를 기반한 애플리케이션 개발 및 운영수준에 머물러 있다. 여기서 이야기하는 API 게이트웨이, 유레카, 서비스 브로커 등의 기능을 이용하기에는 아직 멀고먼 이야기로군.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment