SPRING CAMP 2018 후기
작성일 | In

SPRING CAMP 2018 Review

Intro

기다리고 기다리던 SPRING CAMP 2018에 다녀왔다.
트랙A에서만 세션을 들었고 트랙B 세션도 정말 좋았다고 한다.
그리고 각 세션들의 요약 및 간단하게 정리한 내용이므로 전체 내용은 각 발표자의 발표 슬라이드를 참고하자.
정리한 내용이 전반적으로 개연성이 부족할 수도 있다. 주니어의 입장에서 이해한 대로 정리하였으니 조금 부족하더라고 이해해주시고 잘못된 부분이 있으면 댓글로 짚어주시면 감사하겠습니다.

springcamp1

개회 및 축사 : 쿠팡의 김범석 대표님.

  • coupang의 기술 -> spring framework + 수백 개의 오픈소스로 구성.
  • 오픈소스를 활용한 성장.
  • 오픈소스의 도움을 많이 받았으므로 그만큼 많이 베풀겠다. (오늘을 기점으로 tech blog 운영 예정)

첫번째 세션 : 희망을 찾기 위한 우리의 여정, Coupang MSA - 쿠팡(Lego - 정재훈님)

  • 쿠팡에 MSA를 도입하면서 겪었던 경험들 공유 쿠팡의 최근 기술 큰 변화
    • php -> java 변환
    • Architecture의 변환 (monolithic Architecture -> MSA)
    • 전반 서비스를 클라우드로 이관
  • monolithic 아키텍처 pain point
    1. 부분의 장애가 전체 서비스에 영향을 미침
    2. 작은 것을 수정해도 전체 QA, 유닛테스트, integration 해야 했음 (빠른 수정 적용이 힘듦), 어떠한 functon이 사용 중이고 사용중이지 않은지 등을 알 수 없었음 - 레거시화가 가속화되었음
    3. scale-out의 힘듦 (전체 서비스의 아키텍처를 뜯어고쳐야 함), 쿠팡 서비스 성장 속도에 못 미침.
    4. 배포시간에 대한 기하급수적인 증가 (좋은 개발자들의 기능들을 만들어도 배포에서 병목 현상이 일어난다, 개발한 것을 적용시키기 위해서는 몇일을 기다려야함) -> monolithic Architecture는 서비스의 성장을 가로막음
  • 따라서, 마이크로서비스 아키텍처로 전환을 시도함. 그 프로젝트를 쿠팡에서는 vitamin framework로 칭함.
  • 전략
    • MSA에서는 모든 모듈 api 통신 (helper 라이브러리를 같이 제공해서 일일이 통신 로직을 구현하지 않도록 함 )
    • 메시지 큐 사용 (강하게 결합된 트랜잭션 분리)
    • 기타.
  • Configuration Management DataBase (CMDB)
    • 서비스, 인프라스트럭쳐 등의 메타 데이터를 manage
    • 해당 서비스의 메타정보 - 어떤 인스턴스, 깃랩은 어디 있고, 빌드는 어떻게 하고 등을 CMDB에 저장 및 제공
    • 쿠팡의 마이크로 서비스 개수 -> 100개 이상, 쿠팡 시스템의 인스턴스 -> 10,000개 이상
  • 마이크로서비스아키텍처에서 왜 배포시스템이 중요할까?
    • 하루에 100번 이상 배포, 수 많은 feature들이 개발되고 있음.
  • 블루/그린 배포 전략 -> Bolt2
    • LOCK을 통하여 master에서 rc 브랜치를 생성
    • rc 브랜치로 부터 stage 서버, canary 서버, All 전체 서버로 배포
    • 그리고 UNLOCK을 통하여 rc 브랜치를 삭제.
    • 헬스체크, 어떤 EC2 인스턴스를 제공하는지 등을 알 필요가 없음, 모든 일련의 과정을 자동화
    • stage : production configuration, But does not bind ELB.
    • canary : 1th Server in Production Servers
    • all : all server for Production
  • AB TEST - 몇 퍼센트의 사용자에게 제공할지 등을 정하고 서비스 후 피드백을 통해 개선
  • 쿠팡의 api 게이트웨이
    • 만개 이상의 api 보유
    • 쿠팡에 어떤 api가 있고 api어떤 스펙 쓰이는지 등을 알 수 없었음,어떤 팀이 어떤 서비스가 쓰는지 알 수 없었음 -> api 게이트웨이 시스템을 통해 개선
    • swagger codegen을 통한 헬퍼라이브러리 자동 생성.
    • api 게이트웨이로 병렬적으로 호출해서 merge 한 뒤 클라이언트에게 제공
    • traffic throttling <- api call의 안정화
  • 장애의 발생 이유
    • 코드 버그
    • 성능에 이슈 있는 코드가 들어가서
    • 하드웨어 실패(이슈)
  • 코드 버그, 성능이슈 있는 코드들이 배포 직후에 발생한다는 것을 알게 됨
    • Confidence 시스템을 만듬 (배포직후 문제가 있으면 자동으로 복구)
    • canary 서버가 배포될때 cpu, memory, tomcat 등 확인.
    • canary 서비스에 장애가 있으면 배포를 막음
  • circuit breaker system - 항상 모니터링 하면서 문제가 있으면 자동으로 복구(상시 운영중인 문제를 회피)
    • 수백개의 자동화된 룰이 정의 되어있음.
  • Coupang Considerations for Micro-service Architecture
    • 현재 내 서비스는 api 게이트웨이하고만 dependency를 가짐
  • 마이크로서비스아키첵처를 도입한다면 SRE 주목.

두번째 세션 : 이벤트 기반 분산 시스템을 향한 여정(aws, spring 중심) - 박용권님 (우아한 형제들)

  • 배민찬 (커머스, 물류)
  • 공급망 관리 시스템 (SCM, 고객에게 제품을 배송하기 위한 일련의 업무 프로세스를 지원하고, 처리하기 위한 시스템) 에 대한 이야기를 전달.
  • 지난 1년간의 개발 운영하며 주어졌던 고민, 아이디어, 결과물을 공유
  • 2016년
    • 사용자 서비스와 백 오피스 모듈로 구성된 모놀리식 시스템이었음
    • 오프라인 중심으로 처리 -> 주문량 성장에 따라 자동화된 시스템 기반 업무로 전환 필요
  • 2016년 말, 물류 시스템 도입 (원래의 모놀리식 시스템(스토어 시스템)과 새로운 물류시스템의 가교 역할로 어댑터 서비스를 개발 - sprinboot 기반 개발, AWS Elastic)
  • 어댑터 서비스가 해결하는 두 가지 문제 -> 시스템간 이질적인 용어와 모델을 번역하는 역할 수행, 메시징 기반으로 비동기 처리, 시스템간 결합 제거, 수신된 메시지에 대해 멱등성을 보장하도록 기능 개발
  • 왜 새로운 서비스로 만들어졌나? 복합하게 얽히고 꼬인 레거시 시스템을 깨고, 푸드 커머스 플랫폼으로 진화하기 위한 첫걸음.
  • 불어나는 기능, 커지는 서비스, 쌓이는 도메인 지식
  • 시간이 지나면서 도메인 지식들이 쌓이기 시작함
  • 도메인 경계들을 발견하고 SCM 시스템으로 확장하기 시작함.
  • 응집력 있는 도메인 개념을 묶기, 패키지로 모둘을 구성 - (컴포넌트 역할, 예를 들어 MVC가 아닌 구매는 구매끼리, 배송은 배송끼리)
  • 도메인 주도 개발에서 말하는 바운디드 컨텍스트를 구현해보자 했음.
  • 왜 모둘화 인가? 도메인의 경계를 뚜렷하게 하고자 함. -> 추후 서비스의 독립성을 보장해줄것이라 예상
    1. 모듈 간 상호 작용은 내부 프로세스로 처리
    2. 단일 트랜잭션 관리로 인해 강력한 일관성 확보
    3. IDE를 통한 손쉬운 리랙토링 작업 (가장 와닿는 장점.)
  • 또 다른 문제점 : 모듈간의 강한 결합, 또 다른 모놀리식 시스템화 현상.
  • 이벤트 기반의 아키텍처를 생각하게됨.
    • 이벤트 생산과 소비를 통한 느슨한 결합.
  • 스프링 애플리케이션 이벤트 매커니즘.
    • Event Producer -> ApplicationContext(Event Channel)-> Event Consumer
  • 시스템 또는 서비스 통합을 위한 세가지 방법
    • 원격 프로시저 호출 (RPC, Remote Procedure Call)
    • 레스트풀(RESTful) API
    • 메시징(Messaging)
  • 이 외에 더 많은 얘기들은 이벤트 기반 분산 시스템을 향한 여정 slideshare를 참고 해주세요.

Coffee Break

  • 정말 맛있었다 ! springcamp2

3번째 세션 : 11번가 Spring Cloud 기반 MSA로의 전환 1년간의 이야기 - 윤용성님.

  • 2016년말 11번가는…
    • 매주 목요일 밤샘 정기 배포 (잦은 장애)
    • IDE에 띄우는 것 조차 버거운 환경..
    • 어느 누구도 소스코드 수정을 두려워 했음.
  • Project vine : 11번가 점진적 MSA 전환 프로젝트
    • 레거시 교살 전략
  • MSA 플랫폼 Solutions 선정
    • MSA를 위한 Best Practice를 빠르게 적용하는 것이 필요 -> 넷플릭스 OSS
    • 개발자들이 가장 친숙해 하는 환경 - Spring boot
    • spring cloud
  • Deep Dive into Hystrix, Ribbon, Eu
    • Hystrix : 넷플릭스가 만든 Fault Tolerance Library
    • Ribbon : 넷플릭스가 만든 소프트웨어 로드 밸런서를 내장한 RPC 라이브러리
    • Spring cloud 에서는 Ribbon 클라이언트를 사용자가 직접 사용하지 않음.
    • Eureka
  • spring cloud zuuls
    • 서버 군별로 하나하나의 세마포어 생성.
  • Spring cloud에 대해 지식이 조금 부족해서 완벽한 이해를 못 하였다.
  • 아래는 이번 세션 발표자료는 아니지만 발표자 윤용성님이 open해놓은 slideshare 자료. 참고해주세요.
  • 11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례
  • 이 자료도 같이 보면 좋을 것 같다. MicroServices at Netflix
  • 그리고 마지막에 팀의 막내인 1년된 신입분이 spring project의 컨트리뷰터라는 사실과 실제로 issue 제보를 했다는 것을 들으면서 많은 자극이 되었다.
  • 자신이 사용하는 기술의 오픈소스를 보기, 많은 관심을 갖자.

4번째(마지막 세션) : MSA를 위한 Spring Cloud와 Kubernetes - 홍정석님, IBM Korea

  • why MSA?
    • 기존 일체형 아키텍쳐의 문제
  • cloud native 12 요소 (12factors)
    • 클라우드 애플리케이션 개발 방법론
    • https://12factor.net/ko/
  • 마이크로 서비스 아키텍처를 서비스할때 8가지 정도는 만족해야 클라우드 환경에서 동작하는 애플리케이션을 설계 할 수 있다고 생각함.
  • MSA 설계.
    • api gateway
    • service discovry
    • service invocation
    • security
    • load balancing
    • resiliency
    • managemets
      • packaging
      • deployment schehuling
      • metric & logging
      • configurrations
  • 소트웨어로서 본질이 아닌 시스템 환경과 패러다임이 변한 것
  • spring cloud
    • 분산 시스템 개발에 필요한 공통 패턴을 모아 spring 프로젝트로 구성
    • 12 FACTORS 준수
  • spring boot
    • 이름대로 가볍다
    • 불필요한 정보는 배제
    • 미리 정해진 패턴으로 모듈화
    • spring을 위한 기본 코드와 환경 설정보다 비지니스 로직에 집중
    • spring cloud를 이용한 마이크로 서비스를 구성할 런타임의 기초로 사용
  • spring cloud에서 MSA 대응 항목
    • API Gateway - Netflix zuul
    • Service Discovery - Consul, Netflix Eureka, Netflix Zookeeper
    • Service invocation - Feign
    • Security - security
    • Load balancing - Netflix Ribbon
    • Resiliency - Health indicator, Netflix Hystrix
    • Packaging - Spring Framework(Boot)
    • Metric & Loggig - Atlas, Netflix Spectator
    • Configurations - Config
  • Kubernetes란?
    • 컨테이너 오케스트레이터 (실행 및 관리)
    • 다양한 클라우드 및 베어 메탈 환경 지원
    • Google Borg에서 시작되어 오픈소스화 됨
    • 100% GO 언어로 작성
    • 현재 2018년 3월 27일 v1.10 릴리즈다
  • container orchestration 이란?
    • 스케쥴링
    • Cluster 관리
    • 서비스 Discovery
    • 모니터링
    • 설정
  • 컨테이너가 한두개 늘어나면 스크립트의 도움만 받아도 괜찮으나, 점점 늘어만 가는 컨테이너들을 감당 할 수 없다.
  • 다양항 컨테이너 오케스트레이션 : 쿠버네티스, docker swarm , marathon/ mesos, nomad 등
  • 컨테이너 매니지먼트 플랫폼 1등 : 쿠버네티스
  • 쿠버네티스 특징
    • automathc binpacking
    • self-healing
    • horiziontal scaling
    • service discovery and load balancing
    • batch execution
    • automatic rollouts and rollbacks
    • secret and configuration management
    • storage orchestration
  • 예시)
    • 컨테이너도 서버만큼 생각보다 잘 죽는다.
    • 이걸 빠르게 살려주는 것이 필요
    • 운영자가 직접 다 할 수 없다. 따라서 쿠버네티스에서 자동으로 실행시켜줌
  • 쿠버네티스 에서 MSA 대응 항목
    • API Gateway - Kubernetes Service & Ingress Resource
    • Service Discovery - Kubernetes Service & Kube DNS
    • Service invocation - Call with service name
    • Security - Namespace & pod Isolation
    • Load balancing - Kubernetes Service & Ingress Resource
    • Resiliency - Kubernetes Health Check & Resource Isolation
    • Packaging - Container Runtime Interface (Docker, rkt …)
    • Deployment & Scheduling - Deployment & Scheduling strategy
    • Metric & Loggig - stdout, stderr
    • Configurations - ConfigMap
  • spring PetClinic

나의 생각

  • 정말 꼭 와보고 싶었던 스프링캠프 역시 기존에 다녔던 세미나와는 달랐다.
  • 접해 보지 못한 부분들은 생각보다 이해하기 어려웠다. 앞으로 공부해야 할 것이 무궁무진하다는 것을 또 한 번 느꼈다.
  • MSA가 대세임은 확실하다. 그러나 완벽한 기술, 설계는 아니라는 것을 느꼈다.
  • 아키텍쳐의 진화, 그리고 늘어만 가는 트래픽 속에서 어떻게 대응을 할 것인가에 대해 조금 더 생각해볼 수 있는 좋은 기회였다.
  • 주최와 후원해주신 모든 분께 감사하고 정말 많은 것을 얻어가는 자리였던 것 같다.
  • 마지막으로 기념품들! springcamp3
facebook share twitter share
0%