SPRING CAMP 2018

2018년 04월 21일 | Jeremy

Spring Framework을 잘 알지 못하지만, Micro Service Architecture(MSA)에 관심이 많아서 Track A 세션만 들었습니다. 각 세션을 들으면서 개인적으로 정리한 것이라서 오타가 잘못된 정보가 있을 수 있습니다.

희망을 찾기 위한 우리의 여정, Coupang MSA(정재훈님)

5년 전 쿠팡 Monolithic architecture의 Paint point

부분의 장애가 전체 서비스에 영향을 미침
레거시 문제(coupang-common)
부분적인 Scale-out 어려움
배포의 비효율성: 서비스의 성장을 가로막게 됨

Vitamin project for Micro-service

도메인 팀에 helper library 제공
Message Queue를 클러스터링하고, 자동으로 Fail over 되도록 구성

Configuration Management DataBase(CMDB)

Micro-service count 수백개
서버의 인스턴스 10000대
다양한 메타 정보를 가시화하고, 자동화
전체 서비스가 아닌 특정 서비스 기준으로 데이터를 메쉬화

Bolt2(Deployment System of Coupang)

하루에 횟수로는 100번 이상, 2천대 이상 배포 가능하도록 구성
Stage -> Canary -> All

A/B Test

주요한 Feature 변경은 모두 A/B 테스트로 진행
A/B Test는 사용자 모집과 노출 빈도가 중요

API Gateway

API Gateway에서의 콜 수 30억
현재 10,000개 이상의 API를 가지고 있다.
전체 조직에서 특정 API를 누가 사용하고 있는지, 어떤 API가 deprecated되었는지 등을 관리하기 위해
쿠팡 전체 서비스의 API 를 가시화하고, 어떤 Parameter, 어떤 Response, 어떤 팀, 어떤 서비스에서 사용하고 있는지
(초기) API Gateway가 Single Point로 존재해서, Single Point of Failure와 Latency의 증가 문제 발생
(개선) Consumer는 API Gateway에서 Routing 정보를 받아와서 직접 Provider에 요청
(초기) Consumer는 해당 정보를 얻어가기 위해 순차적으로 API를 호출
(개선) Consumer는 API Gateway에 요청만 하면 병렬적으로 수행후 값을 받아감
Traffic throttling: 특정 Consumer가 API를 비정상적으로 많이 호출하더라도 장애가 발생하지 않도록

Site Reliability Engineering(SRE)

서비스에 장애가 난 경우, 어떤 이유 때문에 장애가 났는지?
서비스 장애를 재연하기 위해 어떻게 해야되는가?

Integration test for MSA

문제: 어떤 서비스가 dependency를 가지고 있는 경우, 하나의 서비스를 테스트하기 위해 전체 시스템을 테스트해야 한다.
API Gateway가 있다면 Test를 위한 Dependency를 제거할 수 있다.

Dynamic properties for MSA

Scale-out 할 때 DB connection pool 과 같은 자원은 제한적이기 때문에 이를 동적으로 관리할 방법이 필요함.

이벤트 기반 분산 시스템을 향한 여정(박용권님)

부제: build event-driven distributed system with spring, aws

지난 1년간 공급망 관리(supply chain management, SCM) 시스템을 운영, 개발하며 있었던 일

초기(2016)

사용자 서비스와 백 오피스 모듈로 구성된 Monolithic architecture 시스템
Back office 중심, 주로 수작업으로 이루어짐
주문량 성장에 따른 자동화된 시스템 기반 업무로 전환 필요

Adapter

시스템 통합을 위한 어댑터 서비스 도입
Spring boot(Java 1.8), AWS Elastic Beanstalk
시스템간 이질적인 용어와 모델을 번역하는 역할을 수행(주문과 입/출하 관련)
주문 완료 메시지: 메시지 기반으로 비동기 처리, 시스템간 결합 제거
주문 완료 메시지에서 수신된 메시지는 멱등성(중복 처리)을 보장하도록 기능 개발

컴포넌트의 역할에 따라 패키지를 나눈 것이 아닌, 도메인의 경계에 따라 패키지를 나누었고 그 내부에서 역할에 따라 모듈로 구성

모듈화는 왜?

모듈간 상호작용은 내부 프로세스로 처리
단일 트랜잭션 관리로 인해 강력한 일관성 확보
IDE를 통한 손쉬운 코드 리팩토링
하지만, 모듈화를 구성하다 보니 모듈 간의 강결합이 발생하면서 또 다른 모놀리식 시스템화 현상이 발생하였다.

이벤트 생산과 소비를 통한 느슨한 결합(Loose coupling)

Producer, Consumer
Channel: 생산자와 소비자에 적절한 이벤트가 전달되도록 중간 역할
모듈간의 결합도를 이벤트 기반으로 해소시켰다.

RPC(Remote Procedure Call): 시스템 간 응집도 상승 RESTful API Messaing system

컨텍스트(시스템, 서비스) 간 협업을 위한 두가지 방식

동기: Request<->Response, 실시간 응답이 필요한 경우
비동기: Messaging

스프링 메시징 모듈, 메시징 통합 지원

Spring cloud stream: 다중 바인드 지원. 하지만 아직 aws 지원하지 않습니다.

이벤트 기반 애플리케이션과 메시징 어댑터

11번가 Spring Cloud 기반 MSA 전환 1년간의 이야기(윤용성님)

어떻게 MSA를 도입할까?

잘 사용되지 않는 코드까지 수정할 필요가 있을까?

Hybrid MSA

MSA 플랫폼 Solution 선정

Fallback 발생 조건

Circuit open
Any Exception
Semaphore, ThreadPool exception
Timeout

Hystrix, Ribbon, Eureka

MSA 플랫폼 내부의 API server 간의 호출은 어떻게 할 것인가?

내부의 모든 서버가 Hystrix + Ribbon + Eureka 기반으로 서로 통신

Spring Cloud Feign With Hystrix

MSA 모니터링 문제점

관련된 API 서버가 어느 것인지 쉽게 알기가 어렵다.
분산 Tracing의 필요: 서버와 서버 호출 시 Http Header에 특정 protocol을 추가
특정 Trace ID(UUID)를 부여

MSA를 위한 Spring Cloud와 Kubernetes(홍정석님)

Cloud native 12 요소(https://12factor.net/ko/)

동시성(Concurrency)
폐기 가능(Disposability)
API Gateway - Netflix Zuul
Service Discovery - Consul, Netflix Eureka, Netflix Zookeeper
Service Incovation - Feign
Security - Security
Load balancing - Netflix Ribbon
Resiliency - Health Indicator, Netflix Hystrix
Packaging - Spring Framework(Boot)
Configurations - Config

Container Orchestration

Scheduling

Kubernetes

Automatic binpacking: 가용 서버로 스케쥴링 해주는 기능
Self-healing: 컨테이너의 상태를 모니터링
Horizontal scaling:
Service discovery and Load balancing
Automatic rollouts and rollbacks: 다섯개의 컨테이너 버전업 할 때 버전별로 stop, start를 자동으로 관리
Secret and configuration management
Storage orchestration

Kubelet: 컨테이너가 워커에서 돌아가는데, 마스터가 Kubelet과 통신하고 Kubelet이 컨테이너와 통신