본문 바로가기
세미나 후기

Cloud-Native Day 2019 Seoul 후기

RyuDung 2019. 7. 10. 17:13

  1. Keynote Speech(사친 쉬리다르, 서비스 및 CSO 부사장, Pivotal America & APJ)

    • 현재 시대에서 소프트웨어의 중요성 강조

    • 왜 피보탈인지

      • 여러가지 장점이 많음.

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

    • 서론

      • Adrian Cockcroft

        • 시장 변화 빠른 대응

        • 비지니스에 집중

      • 클라우드 네이티브 사용의 목적

        • 클라우드 컴퓨팅의 장점을 활용

        • 개발 생상성 및 IT 속도를 극대화

    • 클라우드 네이티브 4요소 - 비지니스를 만들기 위한 구성요소

      • DevOps를 통한 서비스 개선 속도의 증가

      • CI/CD를 통한 개발-운영 간 업무 속도의 증가( 자동화)

      • 서비스 컴포넌트 별로 개발

      • 컨테이너를 통한 IT 유연성 개선(컨테이너)

    • 클라우드 네이티브란?

      • 컨테이너를 활용한 경량구조의 app 개발을 위한 조직, 도구, 기술

      • 서비스 컴포넌트 별로 배포가 필요하다가 판된 될 때, 즉시 배포 할 수 있는 환경

    • MSA 장점

      • 모노리스의 한계

        • 강력한 의존성에 의한 변경에 대한 어려움

        • 등..

      • MSA

        • 모듈의 재사용

          • 공통적인 시큐리티, 빌링

        • 개별적 확장성

        • 유지보수 단순화(기존보다 개발자가 더 많이 필요함)

        • 등..

    • MSA 단점

      • 관리 포인트 증가

        • 사람이관리하기 어려움

          • 사람이 하는 업무를 최대한 줄여서 자동화해야함

      • 개발자 역량 강화

        • MSA 친화적인 개발 프레임워크

          • 스프링 부트

    • Pivotal 서비스

      • appTx service

        • 기존 모노리스에서 클라우드로 변경하도록 도와줌

      • Pivotal labs

        • 문화 개발 방법론을 전수

      • PCF

        • 개발자 생산성을 크게 향상 시킬수 있는 플랫폼 서비스

      • 프레임워크제공

        • 스프링 부트가 대표적

    • PAS vs PKS

      • 컨테이너 관리자가 다름

        • 쿠버네이티스

      • PAS는 개발자는 빌드와 환경설정만 함

      • PKS는 PAS와 + 쿠버테이티스를 관리하는것을 더함

        • 모노리스에 더 친화적

    • 1:1 코칭에 대한 서비스를 제공

      • 피보탈 랩스

      • 실리콘 밸리의 문화와 일하는 방식을 적용

  3. MSA 전략 1: 마이크로서비스, 어떻게 디자인 할 것인가?(Domain Drive Design)

    • 최대한 비지니스를 담아내어 개발 할 수 있음.

      • 현업과의 회의를 통해 도메인을 구체하는 과정이 필요.

    • Bounded context를 나눠야 한다 (도메인의 경계)

      • Aggregates

        • Bounded 보다 더 작은 단위, Bounded를 넘어가지 않는다.

        • 트랜잭션영역

          • 같이 처리되어야만 하는 영역

        • 외부연결

          • Root를 통해서만 외부 연결

          • 이벤트 기반 아키텍처(추천)

    • 피보탈과 DDD 진행 플로우

      • 목표 설정 체크

        • ORKs(Objectives  / Key Resuts)

          • 목표설정(O)

          • 목표 성취 갯수를 체크(Key Result)

      • 이벤트 스토밍

        • 현업의 프로세스와 비지니스 이해를 통해 코드에 녹임

        • Simple Tool 활용

          • 마커, 팬, 보드

          • 온라인 x

          • 모든 사람들이(서비스 관련된) 함께 공감대를 이룸

            • 모여서 포스트잇을 붙임

        • 도메인 이벤트를 나열한다

        • 필요한 Aggregate를 표시한다.

        • Bounded Context를 나눈다.

        • 확정되지 않은 사항 필요한 내용을 따로 추가한다.

      • 전체 서비스에서 슬라이스 choice(일부분만 정해서 피보탈 직원들이 함께함)

      • Boris

        • 대략적인 마이크로 서비스의 아키텍쳐 표현

          • 마이크로 서비스

          • 메세지 큐

          • UI

          • 외부 시스템 연계( 백엔드 연계)

          • 등

      • Snap_E

        • 각각의 마이크로 서비스별의 정보를 분류하여 정리

          • store

          • api

          • 등..

        • boris를 통해서 정리

        • Pivotal tracker에서 전산화하여 관리

      • 테스트 완료 및 동작하는 코드 생성(피보탈 직원과 함께)

        • 페어프로그래밍

        • 마이크로서비스 같이 해봄

      • 재사용 가능한 패턴

        • 패턴을 모아서 문서화

          • pivotal의 노하우를 통해 많이 사용된 패턴들

      • MSA 관련 기술

        • 많은 부분에 있어서 고민이 필요

          • MSA 아키텍쳐

          • 플랫폼 아키텍쳐

        • 무작정 MSA를 하기전에 현재 상황을 고려해야 한다.

          • 마이크로 서비스의 장점이 현재 시스템에 필요한가?

          • 많은 배포가 필요한데 괜찮은가?

          • 개발자들의 러닝커브가 필요한데 괜찮은가?

          • 운영에 대한 고민

            • 트러블 슈팅 노하우가 필요

          • 마이크로서비스 경험이 있는 master의 리딩이 필요

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

    • 클라우드 네이티브 어플리케이션 구성

      • DevOps

        • 문화

        • 협업

        • 속도와 안정성

      • Continuous Delivery

        • 어플리케이션 배포 자동화

      • Microservices

        • 도메인주도 개발

        • API

        • 독립적인 배포

        • 간편한 개발 및 유지관리

      • Containers

        • 운영시스템 레벨의 가상화를 통한 개발 마이크로 서비스 배포 수단.

          • 도커등

          • 쿠버네이티스

    • 디자인 원칙

        • SOLID 원칙

        • 높은 응집과 낮은 결합

        • 탄력적이고 확장 가능

        • 높은 가시성과 관측성

    • 12 factor app

      • 헤로쿠 서비스에서 발표

      • beyond 12 factor도 나왔다고함.

    • 마이크로서비스 아키텍쳐에 필요한 구성

      • 설정(Configuration)

      • 서비스 등록 및 감지(Service Registration and discovery)

      • 서비스 게이트웨이(Service Gateway)

      • 서킷 브레이커(Circuit Breakers)

      • 분산 트레이싱(Distributed tracing)

      • https://microservices.io/patterns/microservices.html 패턴 참고

        • 정답보다는 참고자료

        • 점선은 두 가지중에서 선택하라는 의미

      • WAS의 종말

        • 임베디드 WAS로 포함 시켜버림(spring boot)

        • 새로운 것 (경량화)

          • Spring webflux

          • javalin

          • Micronaut

          • ktor

          • spark

      • 논 블록킹

        • node.js

        • Vert.x

        • Spring WebFlux

        • RxJava, RxJs, Rx..

        • Coroutine for Kotlin

        • R2dbc: reactive Relational Database ConnectivY

      • Scale to Zero/ Functional

        • Spring Fu(Kofu/ Jafu)

        • Kotlin/Native

        • GraalVM

      • Inter Service Communication

        • 1:1

        • 1:N

        • GraphQL: 여러 마이크로 서비스 요청을 한번에

      • 페이로드 사이즈를 줄이기 위해

        • JSON -> Protocol Buffer (바이너리) 통신

      • 어려운것

        • 데이터 베이스

          • 기존 DB를 어떻게 잘 나눌것인가?

        • 캐싱

          • 모든 마이크로 서비스는 캐시가 필요하다

          • 방식

            • 캐시에 데이터가 없으면 DB에 요청

            • 모든 DB를 캐시에 올려놓는 방식

      • 이벤트 드리븐으로 데이터를 관리

        • 느슨한 결합

        • 트랜잭션 방식

          • 2PC

          • Saga

          • cdc

            • 데이터 변경 로그를 통해서 데이터를 캡쳐

          • Event Sourcing

          • TCC

      • 카프카 스트림

        • 거의 최신의 데이터를 사용가능

        • 카프카 스트림을 통해서 지역 캐시를 함

      • 트랜젝션의 처리

        • 보상 트랜잭션

          • 이벤트 소싱

          • tcc

          • 데이터베이이스 로깅

        • 데이터 베이스의 정합성 체크가 필요

      • 컨테이너

        • 지속적 통합과 배포

      • 서비스 메시

        • 라우팅

        • 서킷브레이커 등 손쉽게 사용가능

      • 모니터링

        • 로깅

        • 메트릭

        • 트레이싱

      • 시큐리티

        • JWT

        • TLS

        • 등

  5. 클라우드 네이티브 플랫폼의 미래

    • 피보탈 플랫폼

      • PAS(클라우드파운더리 기반)

        • 모던 App(스프링부트)

      • PKS(쿠버네티스 기반)

        • 레거시 프로젝트

      • PFS(아마존의 람다와 같은 이벤트 드리븐)

        • 큐를 이용한 이벤트 드리븐

      • aws

      • gcp

      • openstack

      • vmware

      • azure

    • psm

      • polyglot이란?

        • 각각의 팀이 어떤 테크니컬 서비스를 쓸지 정해진다.

        • 다양한 랭귀지에 맞게 통신을 연결

      • Istio

        • 다양한 프로그래밍 언어의 Ployglot을 제공

        • 트래픽 컨트롤러

      • Envoy

        • Proxy

        • yml  관리 필요(환경설정)

          • 여기서 필요한 부분만 개발자에게 제공

      • Service Mesh Roadmap

    • pbs

      • Pivotal build servcie

        • compile

        • dockerfile

        • Image push

      • Cloud native buildpack

        • 자동으로 도커빌드

  6. 숨겨진 마이크로 서비스: 초고속 응답과 고가용성을 위한 캐시 서비스 디자인

    • 팬아웃 효과

      • 하나의 응답이 여러개의 응답을 합쳐서 보내야 할 수 있음

      • 하나의 요청에 내부에서 요청해야할게 많을 수 있음

    • 넷플릭스의 방법

      • 카오스 콩 테스트를 함

        • 리전 하나를 죽여버림

      • vizceral

      • 캐시를 주요 데이터베이스 처럼 사용하기는 어렵습니다.

      • 데이터 베이스 구간에서의 복제는

        • 복잡하다

      • 데이터를 잃지 않는 캐시 클러스터를 가질수 있다면?

        • = EvCache

    • EvCache

      • 분산 캐시

      • memcached(https://memcached.org/) 를 래핑

        • 실시간에 근접한 글로벌 복제를 구현할 수 있다.

        • 3개의 맴캐시를 인스턴화로 기본으로 같이 띄움

        • ketama 해싱 알고리즘으로 분산

        • 유레카가 캐시 인스턴스들에 대한 정보를 자기고 알아서 동적으로 연결

      • Look Aside 패턴- 일반적

        • 캐시에 갔다가 캐시에 없으면 DB에서 가져온다

      • 카프카를 활용한 확장

        • 캐시 클러스터를 3대에서 8대로 확장하고 싶을때

        • 글로벌 리전간 복제 구성

          • 카프카에 curd 정보를 push

          • 카프카에서 리플리케이션 릴레이션에 넘김

          • 캐시에서 가져와서 메타 데이터와 함께 다른 리전으로 보냄

      • 카프카의 클러스터가 많은 러닝 커브가 필요할 수도 있음

        • 래빗엠큐를 사용하는것을 고려

    • Pivotal GemFire (Cache: https://pivotal.io/kr/pivotal-gemfire)

    • 결론

      • 팬아웃현상은 피할수 없다

      • 분산캐시를 사용하는 것이 중요하다

      • 메시키 큐를 이용해서 통신하는 방법도 있다

  7. 마지막 멘트: 데이터 보다 좋은 개발자를 뽑아서 개발자가 개발에만 몰입할 수 있는 환경을 구성하는 것이 더 중요하다.

  8. 후기

    • MSA를 실제 도입하기 위해서 많은 고민(팀과 회사의 상황, 적절한지 등)을 해봐야한다는 것을 느꼈다.

      실제로 MSA를 하기 위해서는 인프라나 개발등에서 선행 작업이 필요하다는 것을 느꼈다.

    • DDD(도메인 주도 개발)을 어떻게 진행할지에 대한 피보탈의 사례를 통해서 work 프로세스를 볼수 있었다.

    • MSA를 위한 아키텍쳐와 기술과 트랜드를 알게 되어 인사이트를 넓힐 수 있었다.

    • 넷플릭스가 사용하고 있는 고가용성을 위한 캐시 아키텍쳐에 대해서 알 수 있었다.

  9. 발표 자료

 

저작자표시 비영리 변경금지

티스토리툴바