Polpid's Pensieve

Pivotal 에서 개최한 Cloud-Native Day 세미나에 다녀왔다.

https://connect.pivotal.io/CND_Seoul_2019.html

요즘 관심을 갖고 있는 주제가 Cloud, Kubernetes, Microservice 였는데 마침 Pivotal 에서 Microservice  관련 해서 세미나를 해서 아주 기쁜 마음으로 다녀왔다.

클라우드 네이티브 IT를 위한 4가지 요소와 상관관계
- DevOps, CI/CD, Container, MSA

클라우드 네이티브로 가기 위한 4가지 요소로 DevOps, CI/CD, Container, MSA 를 꼽았다. 각각의 요소들은 다음과 같은 의미를 가지고 있다.

DevOps : 작은 단위의 조직. (보통 Two Pizza team 이라고 많이들 한다.)

CI/CD : 자동화, 시각화, 프로세스의 단순화

MSA : 컴포넌트 단위의 모듈화

Container : MSA를 활용할 수 있는 infra적 요소

현재 모놀리스 환경의 어플리케이션들이 클라우드 네이티브로 가기 위해서는 단순히 MSA 적용한다고 해서 되는것은 아니다. 그것을 운영, 개발하는 조직부터 시작해서 모든것이 그것을 잘 활용할 수 있도록 변해가야 가능한 일이다.

그리고 왼쪽 사진의 표에 보면 MSA 라면 한가닥 하는 회사들이 나와있다. 그 회사들의 어플리케이션 배포 주기, 배포 준비 시간을 보면 정말 놀랄만 하다. 대부분 실시간으로 사용자에게 서비스를 하는 회사들인대에도 불구하고 일단위로 배포 횟수가 상상을 초월한다. 우리 회사에서는 부끄럽지만 상상도 할수 없는 수치이다. 그런데 그보다 더 중요한 부분이 아래 빨간색으로 써있다. 배포 횟수가 중요한게 아니라 배포가 필요할때 즉시 배포 할수 있는 환경이 중요한 것이다. 여기서 말하는 배포는 무중단 배포를 의미한다. 배포때문에 사용자가 서비스를 사용하지 못하는 그런 배포를 의미하는게 아니다. (그런거 직접 경험 하면 뿌듯할것 같다... )

마이크로서비스 어떻게 디자인할 것인가.
- Pivotal AppTX

MSA를 할때 항상 고민이 되는게 Bounded Context 이다. 대체 어디까지를 하나의 서비스로 볼것인가. 

Pivotal 에서는 다음과 같은 절차로 진행을 한다고 한다. 

1. 목표설정

2. Event Storm

Event Storming 을 통해서 필요한 Event 들을 도출한다. 이건 개발자만 하는게 아니다. 개발자, 설계자, 운영자(현업?) 등이 모여서 실제 모습을 도출해 낸다. 여기에는 프로그래밍적 요소는 없다. 그리고 이것을 통해 서비스의Bounded Context를 설정한다. 

3. Thin Slice

Event Storming 을 통해 도출된 내용중 하나의 서비스를 선택한다. 

4. Boris

Boris Diagram 을 만든다. 서비스의 흐름에서 발생하는 이벤트 들을 도식화 한것이다. 이걸 함으로써 하나의 서비스에 대한 전체적인 아키택처를 확인할 수 있다. 

(화면에서 보면 포스트잇과 종이를 이용해서 했는데 툴을 사용하지 않는 이유는 툴을 사용하면 툴로 내용을 적는 사람이 말이 많아지며 다른 사람의 참여가 낮아지기 때문이라고 한다. 그리고 종이와 포스트잇을 가지고 하는것 보다 효율적인 툴을 아직까지는 보지 못했다고 한다. Event Storming 때에도 포스트잇과 종이를 이용한다고 한다. )

5. Snap-E

이 단계 에서는 각 단위의 api 를 정의하고 데이터 처리 및 로직을 정의한다.

6. 테스트 완료 및 코드 생성

7. 재사용 가능한 패턴 정리

이렇게 사이클이 마무리 되면 아래와 같은 흐림이 나오게 된다. 

오늘 들은 내용들 중에서 가장 기억에 남는 세션이었다. 요즘 회사에서 개발을 하면 그냥 화면 단위로 하나씩 쪼개서 맡아서 개발한다. 저렇게 서비스에 대한 내용을 다같이 모여서 그려본다든지 해본적은 거의 없었던것 같다. 단지 말로 전달 받고 그때그때 물어가면서 개발을 했다. 그런데 생각해보면 안한거지 못할 정도의 상황은 아닌것 같다. 그리고 이렇게 포스트잇으로 그려보면서 하면 좀더 재미있고 구체적인 설계가 가능하지 않을까 생각이 들었다.

마이크로서비스 어떻게 구현할 것인가.

구현의 측면에는 다른것도 다 쉽지는 않지만 특히 Database, Transaction 부분이 어렵다고 한다. 그래서 Cache, Event Sourcing 등을 사용해서 어려운 부분들을 해결한다고 한다. 

클라우드 네이티브 플랫폼의 미래
- Kubernetes 기반의 PCF 로드맵

PCF가 지향하려는 방향이 멀티 클라우드에서 벤더에 관계 없이 서비스를 사용할수 있게 해주고 개발자는 서비스 개발에만 집중할수 있도록 만들어주는 것이다. 그걸 위해서 Istio 와 Envoy 를 사용하고 있다고 한다. 이 두개는 전에 Google Cloud 세미나에서도 자주 언급되었던 건데 내용을 좀더 자세하게 살펴봐야겠다.

또 추가적으로 빌드팩에 대해서도 설명을 했다.

보통 도커 이미지를 만들려면 사용자가 필요한 라이브러리들을 Dockerfile에 정의하고 해야 하는데 빌드팩은 그런게 필요 없었다.

개발자가 서비스를 개발해서 PKS에 cf push 를 통해서 올리면 자동으로 필요한 라이브러리들을 찾아서 이미지를 만들어준다. 그리고 도커 이미지의 특정 레이어를 rebase 해서 교체를 할수 있다. (이게 좀 신기했다.)

Pivotal Concourse 를 활용한 CI/CD pipeline automated build-up & Workflow management solution 소개

CI/CD 툴로 Jenkins가 아닌 Concourse를 소개하는 세션이었다. 

Jenkins 가 UI 를 통해서 쉽게 Build pipeline을 만들 수 있는데 오히려 그 부분이 약점이 라고 한다. Concourse  는 특정 파이프라인을 만들고 지우고 또 새로 생성하는 모든 부분들을 yaml을 파일에 정의해서 자동으로 실행을 할수 있다. 그런데 yaml 파일 작성이 쉽지는 않다고 들었던것 같다. ^^;

숨겨진 마이크로서비스

캐시, 메세지 큐에 대한 내용이 많았다. 그리고 MSA를 위한 여러가지 아키텍처에 대한 설명도 있었는데 역시 마지막 시간은 집중력이 떨어졌다. ^^;; 특히 Kafka 를 로그를 위한 장치가 아닌 다른 용도로 응용해서 사용할수도 있는데 꼭 알아두라고 한다. 전에 개인 발표 때문에 Kafka 쓰다가 사리 나올뻔 했는데 이번 기회에 다시 한번 보는것도 좋을것 같다. 

언제나 그랬듯이 세미나를 들으면 공부 뽐뿌가 오게 된다. 일단 적어두고 차근차근 알아보자.!!!

Kafka, EvCache, Istio, Envoy

그리고 올해도 역시 spring one 행사가 열린다. 얼리버드는 할인을 해준다는데...정말 가고싶다. ㅠㅠ 언제쯤 한번 가볼수 있으려나...

지난번 Google Summit 에 이어 이번에는 피보탈에서 주최하는 SpringOne Tour 세미나에 참석을 했다.

https://springonetour.io/2018/seoul

우연히 Facebook 타임라인에 뜬 세미나 일정과 Agenda 를 보고 신청을 했었다. Spring 관련 세미나라서 내용에 대한 기대가 컸다. 세미나의 전체적인 주제는 Reactive 와 Cloud 관련 내용들이 많이 있었다. 회사에서 많이 쓰지는 않는 내용들이었지만 그래도 공부하면서 봤었던 유투브에서 봤던 내용들이어서 어느정도 이해할 수 있었다. 그리고 대부분 라이브 코딩이 포함되어 있어서 오히려 더 도움이 됐다. 

세션 요약

1. Reactive Spring with Spring Boot 2.0 - Mark Heckler

화면에는 Reactive Java 라고 되어있지만 다음 페이지에 바로 Reactive Kotlin 으로 변경했다. 라이브 데모 소스도 Kotlin 으로 작성을 했지만 눈으로 따라가는데에는 어렵지 않았다. 내용은 reactive programing 에 대한 내용이었다. 기존에 application 을 유지하기 위해 많은 양의 Thread 가 필요 했다면 이제는 non-blocking 이다 event-driven 을 이용해서 그 Thread 를 좀더 줄일수 있다, 아니 일정 수준으로 계속 유지 할수 있다는 내용 이었다. 그리고 backpressure 라는 내용이 있었는데 그부분은 좀 생소했다. 처음 듣는 단어라서 좀더 찾아봐야 할것 같다. 

참고사이트

http://www.reactive-streams.org/

https://projectreactor.io/

https://github.com/mkheck/FSR

2. Cloud-Native Spring - Josh Long

두번째 세션에서는 Josh Long 의 발표가 있었다. spring 관련 내용을 찾다 보면 이분 내용의 글들이 많이 있었는데 실제로 보니 정말 유쾌한 분이었다. 유머 감각도 있고. 그리고 놀라운것은 코드 작성 속도가 정말 빠르다. 말도 빨리 하는데 코드 작성하는 속도는 말보다 빠르다. 짧은 시간내에 라이브 코딩으로 gateway도 구현하는 라이브 코딩을 보여주었다. 그리고 역시나 처음본 rsocket?? 을 이용해서 코드를 바꿔서 보여주기도 했다. 

3. Spring Cloud Gateway - Younjin Jeong

API Gateway 에 대한 내용이었다. 그중 Netflix 에서 Zuul 을 사용했는데 asynchronous  non-blocking을 지원하기 위해 Zuul 2 를 새로 만들었다고 한다. 그런데 이게 non-blocking 이다 보니 기존 버전과 하위 호환성은 없다고 한다. 완전 새로은 제품이라고 생각하면 된다. Netflix 에서 자기들이 마이크로서비스를 위해서 사용했던 기술들을 라이브러리로 해서 많이 나왔지만 이게 내부에서 사용했던 것들이라서 소스코드가 깔끔하지 않다는 의견이 있었다. 약간 기억이 정확하지는 않지만 Spring 에서는 Zuul 2 는 아직 지원을 않하고 Zuul 1 을 지원한다고 했던것 같다. (정확하지 않음)

그리고 Zuul 을 설명해주면서 Ribbon 하고 비교설명해준게 내게 도움이 많이 됐다. 전에도 이 2개를 헷갈리고 뭔차이지 라는 생각은 하고 있었는데 오늘 설명을 듣고 좀 명확해 졌다.

Zuul 은 외부 트래픽에 대해서 이 트래픽을 어떤 서비스로 보낼지를 결졍해준다. 

Ribbon 은 Zuul 에서 결정된 서비스중 어느곳으로 보낼지를 결정해준다. 

또 Netfilx 에서 자기들이 직접 개발 운영하면서 Gateway 를 설계할때 Concurrent Connection, Thread Count, Latency 를 잘 판단해서 설계를 해야 한다고 했다. 저건 Youtube 동영상을 캡쳐한 화면인데 시간이 될때 한번 봐야겠다. 

참고사이트

https://github.com/spring-cloud/spring-cloud-gateway

https://github.com/spring-cloud-samples/spring-cloud-gateway-sample

http://slides.com/spencer/spring-cloud-gateway

https://github.com/ryanjbaxter/gateway-s1p-2018

4. Cloud Event Drive Architectures with Spring Cloud Stream 2.0 - Jakub Pilimon

세션 중반까지 잘 듣다가 잠깐 졸았던게 후회되는 세션이었다. 대체 왜 졸았을까.......

먼저 개발을 하기 전에 Event Storming 에 대한 이야기 이다. Event Storming 은 실제 현업과 이야기를 하면서 그들이 사용하고 있는 시스템에 대해서 이야기를 하는것이다. 기술적인 내용 없이 어떤 기능들이 있는지 이야기를 하는 부분이다. Event Storming 을 통해서 우리는 그 대화에서 Event 들을 도출해낸다. 

또 Event Storming 을 통해서 도출된 Event 에 대해서 우리가 해야 할 부분은 이 event 가 동작해야 하는 조건들을 추가하는 것이다. 바로 Event 에 대한 트리거를 확인 하는 작업이다. 

하아.. 이 다음이 문제다. 잠깐 졸고 일어났더니 라이브 코딩이 한창이었다. 그런데 내용을 보니 event 를 저장해서 뭔가를 하는 부분이었는데 그게 바로 Event Sourcing 부분이었던것 같다. 정신을 차리고 코드를 따라가보긴 했는데 결과적으로 주된 내용은 어플리케이션에서 트랜잭션이 일어날 경우 바로 DB 에서 처리하는게 아니라 그걸 발생시킨 Event를 하나씩 저장을 해서 처리를 한다는 것이었다.

그럼 왜 이렇게 하느냐에 대한 설명이 나왔다. 이해가 가는 부분도 있고 안되는 부분도 있어서 좀더 공부를 해봐야 할것 같다. 

- 장점

  이벤트를 통해서 모델에 대한 오딧이 가능하다. (이건 좀 이해가 안갔다... )

  이벤트 기반으로 히스토리 확인이 가능하다.

  특정 이벤트 별로 확인 및 분석이 가능하다.

- 단점

  코드가 많고 복잡하다.

  기존에 만들었던 방식과 다르기 때문에 사고의 전환이 필요하다.

참고사이트

https://github.com/ddd-by-examples

https://github.com/pilloPl/credit-cards-producer

https://github.com/pilloPl/credit-cards-consumer

http://pillopl.github.io/

5. Spring, Functions, Serverless and You - Nate Schutta

이번 세션에서는 아키텍처에 대한 내용들이 주제 였다. 세미나 가면 자주 듣던 예인데 전에는 Server를 애완동물처럼 애지중지 하게 다뤘지만 이제는 Server 가 애완동물이 아닌 가축으로 생각되고 있다는 이야기 이다. 다시 말해 Server가 죽으면 교체한다는 의미이다. 

위 사진에서 보여 주듯이 위로 올라갈 수록 Complexity 가 줄어들고 운영하기 좋아지기 때문에 최대한 Serverless 로 올려야 한다는 내용이었다. (4번 세션이후로 점점 집중력이 떨어져서 잘 듣지 못했다..)

6. Spring Boot & Cloud on Pivotal application Service - Younjin Jeong

이번 세션에서는 Pivotal 에서 어떤 서비스들을 제공하고 있고 어떤 플랫폼들이 있는지에 대한 내용이 대부분을 차지 했다. 

내용중에 이부분이 좀 와닿았다. 개발자들이 운영을 하는데 얼마나 시간을 소비하고 있는가. 새로운 기능을 만드는 것보다 대부분의 시간이 기존에 만들었던 거를 수정하고 디버깅하는데에 시간이 사용된다. 이걸 무슨 단어가 있었는데 생각이 안난다. 결과적으로 저렇게 되면 개인에게도 손해고 회사에도 손해이다. 

그래서 필요한게 Full Cycle Developers 다. Netflix 에서 한 말이고 어느정도 와닿는다. 하지만 저렇게 되려면 개인만 해서는 안되고 조직 자체가 그렇게 변해야 하기 때문에 쉬운 일은 아니다. 

Full Cycle Developers at Netflix — Operate What You Build

7. Using Spinnaker to Create a Development Workflow on Kubernetes - Paul czarkowski

마지막 세션에서는 Kubernetes 에 대한 내용이 많이 나왔다. 최근에 자주 보던 내용이어서 많이 집중해서 보지는 않았는데 마지막에 나온 Spinnaker 에 대해서는 좀 찾아 봐야겠다. 

마무리

마지막에 운좋게 당첨되서 "클라우드 네이티브 자바" 책을 받아왔다. 세션 중간에 책 사서 Josh Long 한테 사인 받을까 했었는데 참길 잘했다. ^^ 

앞에서도 말했지만 세션 전체적으로 모르는 내용이 많이 있긴 했지만 중간중간 중복해서 설명되는 내용도 있었고 코드를 따라가다 보면 이해가 되는 내용도 많았다. 역시 개발자는 코드로 대화를 할수 있어야 한다는게 괜한 말이 아니었다. ^^;; 최근 GCP 공부하다 보니 Spring 쪽은 약간 소홀한 면이 있었는데 오늘 세미나를 듣고 보니 잠깐 쉬는동한 공부해야 할게 참 많아졌구나라고 느꼈다. 좀더 분발해야 할것 같고 궁금했던 부분들에 대해서는 빨리 찾아봐야겠다. 

Action Item

Backpressure 란 무엇인지 찾아보자.

rsocket 에 대해서 찾아보자. Facebook 에서 사용한다고 하는데??

Zipkin 사용해보면 좋을것 같다.

Event Sourcing 에 대해서 개념 파악해보고 소스한번 다시 보자.

Spinnaker 에 대해서 알아보자.