DeveloperSeminar & Conference

우아한 테크의 밤 후기

⏱ 읽기 소요 시간: 16 분

김범준님

배달의 민족

  • 분당 288만 건의 트랜잭션(e-commerce 중 국내 최대 트랜잭션)

  • 한 달에 4천만 건의 트랜잭션

  • 음식 배달 서비스는 고객이 주문하고 싶은 그 시점에 반드시 주문이 가능해야 한다.

  • -> 장애가 나면 다른 커머스보다 더 크리티컬 하다.
    (음식점 사장님은 그 날 하루의 장사를 공치게 되고,
    고객은 먹고 싶은 그 시점에 주문이 불가능하기 때문)

  • 오프라인 모드에서의 주문(기술적인 도전)

  • 앱에 소비자가 최근에 실행했던 가게 정보를 앱 내의 local cache에 저장해서
    오프라인 모드에서도 나오게 구현
    • 최악의 경우(통신 불가능)에 가게 정보에 전화번호를 띄워서
      고객이 직접 전화해서 주문할 수 있도록 만듦

B마트

  • 당일에 한해 예약 배달도 가능
  • 즉시 배달의 편리성(cf) 쿠팡 프레시, 마켓 컬리: 다음날 배송)
  • 편의점보다 저렴한 가격으로 가격 경쟁력 확보

배달 로봇

그 외 서비스: 만화경, 띠잉

우아한 개발 조직

  • 우아한 형제들에서는 기술 관리자(TM), 기술 전문가(TE) 나누어
    원하는 트랙으로 선택해서 커리어 진행 가능

비전

코드 덩어리가 아닌 가치를 만들고 스스로의 가치를 높이며 일한다.

우아한 아키텍처- 김영한님

2015

  • 하루 주문 5만
  • PHP, MS-SQL, ASP
  • 리뷰 서비스 하나가 장애나면, 전체 서비스가 다 장애가 발생하는 문제가 있었음

2016

  • 하루 주문수 10만 돌파
  • PHP -> JAVA로 전환
  • 첫 자바 마이크로 서비스 도전 시작
  • 결제, 주문 중계 독립

2017

  • 하루 주문수 20만 돌파
  • 대 장애의 시대(매주 장애 발생)
  • 메뉴, 정산, 가게 목록 시스템 독립

2018 상반기

  • 탈루비의 시대
  • N광고 폭파 -> 아키텍처 tf 창설
    • 가게 상세 재개발(주요 장애 포인트)
  • 비즈니스 프로젝트보다 탈루비가 더 중요하다고 판단
  • 쿠폰, 포인트 탈루비

2018 하반기

  • 주문 탈루비(MS-SQL) 이전

레거시 3대장

  • 주문
    • 데이터 지분 1위
    • 하루 100만 데이터
  • 가게/업주
    • 시스템 연관도 1위
  • 광고
    • 프로시저 사용 1위

주문

  • 이벤트 기반으로 아키텍처 변경

가게/업주

  • 컬럼이 너무 많았음
    • ex) 가게 리뷰 카운트까지 한 테이블에 몽땅 같이 들어 있었음
  • 배민의 좋은 문화
  • 의견이 달라서 다투더라도 합리적인 의견이라면, 빨리 수긍하고 앞으로 나아간다.

MSA 구조

- 4년간의 MSA 전환기

현재 배민 아키텍처

CQRS

  • 핵심 비즈니스 명령(Command) 시스템과 조회(Query) 중심의 사용자 서비스
  • 둘을 철저하게 분리
  • 성능, 장애 격리, 데이터 동기화
  • 설계 당시에는 AWS 카프카가 없었음

1. 성능

  • 초당 15,000 트래픽을 버틸 수 있도록 설계 변경

2. 장애 격리

  • 가게, 광고 같은 내부 서비스나 DB에 장애가 발생해도 고객 서비스는 유지해야 함

3. 이벤트 전파와 동기화

  • Eventually Consistency(최종적 일관성)
  • 데이터는 언젠가는 다 맞추어진다.
  • 데이터 싱크 1~3초
    (주문 확인은 가게 사장님이 바로 확인하지 않으므로
    1~3초의 데이터 싱크 시간은 용인 가능하다고 판단함)
  • 문제 발생시 해당 시스템 이벤트만 발생

ZERO-PAYLOAD 방식

  • 가게 id만 Queue로 전달한 후, api로 최신 데이터를 가져와서 처리

최소 데이터 보관 원칙

  • 주문에 필요한 데이터만 들고 있다.

데이터 저장소

  • 조회(고성능)

    • 가게 노출: DynamoDB(NoSQL), Redis(Cache)
    • 광고리스팅, 검색: Elasticsearch(검색엔진)
    • 바로결제 라이브: Redis(Cache)

  • 명령

    • Aurora:
    • 가게/업주(정합성이 중요한 도메인): RDB

  • 조회(Query)에 특화된 서비스만 15,000TPS를 고민하면 된다.

  • 명령(Command)와 조회성 서비스 분리

장애 격리

  • 각 시스템이 내부에 필요한 데이터 보관
  • 내부 서비스(광고, 검색)의 모든 변경 내역이
  • 장애 데이터 싱크가 늦어져도 고객 서비스는 가능하도록 한다.

데이터 싱크 장애 대응

  • 이벤트 재발행
  • 전체 IMPORT API 제공
  • 부분 IMPORT API 제공
    • 싱크가 5분 늦어져도 서비스 가능(5분 단위로 전체 데이터 조회하는 api)

기타

  • 적극적인 캐시 사용
  • 서킷 브레이커
  • 비동기 Non-Blocking 시스템 적용
    • 스프링 Webflux, Reactor

정리

  • 배달의 민족 시스템은 거대한 CQRS
  • 성능이 중요한 외부 시스템과 비즈니스 명령이 많은 내부 시스템으로 분리
  • 이벤트 발행을 통한 Eventually Consistency(최종적 일관성)
  • 각 시스템은 API 또는 이벤트 기반
  • 2019.11.1 탈루비(MS-SQL 탈피)!!
  • 현재 16개의 서비스로 분리

패널 토크 1- 조영호님, 김민태님

기존 프로젝트의 레거시를 안고 객체 지향으로 만드는 법- 조영호님

  • 기술적 측면
    • 도메인 영역에 기술적인 영역이 침투하지 않도록 만들어주는 프레임 워크를 선택하자.
      (영호님이 선택했던 방법)
  • 조직적 측면
    • 시스템에서 이 영역은 객체 지향적으로 만들어 인터페이스를 만들어서 끊어내자.
    • 조금, 조금씩 지속적으로 배포하자.
      • 큰 뭉텅이가 아니라 조금씩 배포해야, 바로바로 장애를 인지하고 대처할 수 있다.
      • -> 회사에 문화 전파하기

반복의 중요성- 김민태님

  • 뭔가를 성장시키려면, 큰 덩어리로 가기 어렵다.
  • 문제가 보여야 해결할 수 있다!
  1. 명확하게 내가 어느 부분이 부족한지를 인지(자기 상태를 자가 진단)
  2. 해당하는 부분을 보안할 계획 세우기
  3. 피드백
      1. 나 자신
      1. 다른 사람
      • 누구에게, 어떻게 피드백 받을 수 있을지 고민해 볼 것
  4. 전략 세우기

공부에 대한 방향, 커리어에 대한 조언- 김민태님

  • 개발자로 끝까지 가르침을 받을 수 없다.
  • 자가 발전 방법을 수립할 것
  • 학교에서 배우듯이 차례대로 배우는 건 요즘 시대에 맞지 않다.
    • ex) 알고리즘 -> 자료구조 -> 운영체제 이런식으로 차근차근 단계를 밟아서 배우는 것
  • 지속하려면 전략을 세워야 한다.
  • 짧고 넓은 범위로 학습한다.(야생 학습)
  • 초기에 깊이, 넓이를 고민하지 말자.
    • 금방 깊어지거나 넓어지지 않는다.
    • 배움의 흥미를 유지할 수 있을 정도로 유지
    • 아무 생각 없이 이것 저것 하는게 아니라, 짧은 사이클로 계획 -> 실행 -> 피드백을 반복

바라는 시니어 개발자의 모습(기준)

조영호님
  • 기본적인 역량인 개발을 잘 해야 한다.
  • 시니어 개발자는 주니어 개발자와 기준이 좀 다르다.
  • 강압적이지 않은 커뮤니케이션
  • 사람을 키우는 것보다 그 팀이 함께 성장하고 있다는 것이 중점
    • ex) 어떤 기술을 도입하기 위해 우리 팀이 스터디를 해보자.

  • “무조건 두 달 안에 할 수 있어요!”가 커뮤니케이션을 잘하는 게 아니다.
    • ex) 한 시니어 개발자가 기한 안에 할 수 있다고 말한 뒤,
      중간 상황을 공유하지 않다가 기한이 되자 아무것도 하지 못한 일이 있었음
      • 이런 경우, 회사 내에서 그 팀 전체의 이미지가 안 좋아질 수 있다.

  • 같이 일했던 동료들이 그 시니어 개발자를 어떻게 평가하는지가 중요하다.

  • 면접에서 5분 안에 강압적인 사람인지를 판단한다.
      1. 자기소개, 배민을 왜 지원 했는지 등의 질문을 했을 때,
        체계적으로 생각하면서 말하는지, 중언부언 하는지
      1. (은연중에) 사용하는 단어, 말투
      • 면접에서 강압적인 분위기를 파악한 후, 레퍼런스 체크

김민태님

  • 긴장해서 대답을 못하는 경우와 싸한 느낌이 들 때를 구분하기 위해 연관된 질문을 계속 한다.
    • ex) “~를 설명해주시는데, ~한 상황이라고 가정하고 얘기해주세요.”식의
      질문에 조건을 넣으면, 강압적인 분들은 이 제한 조건을 잘 듣지 못하고 대답하는 경우가 대부분이었다.

패널 토크 2- 이동욱님, 권용근님

회사 일과 개인 공부 병행하는 법

이동욱 님

  • 개인 공부를 할 때, 회사 공부에 관련 없는 공부는 하지 않는다.
  • 사용하고 있는 오픈 소스의 JDK도 수정할 수 있을 정도의 실력을 위해서는
    곧 이런 기술을 회사에서 사용하겠다 싶은 기술, 회사에서 적용해 볼만한 기술을 공부한다.
    (버그를 고칠 수 있을 만큼의 수준으로 공부)
  • 공부 방법
    • 책을 보고, 깡통 서버를 띄우거나 하는 식으로 직접 만들어 본다.
    • 블로그에 나만의 해석으로 책 내용을 정리한다.
      (그냥 책 내용을 적기만 하면 복붙에 불과하다.)
  • 공부 시간대: 아침 일찍 회사에서 출근해서 공부

권용근님

  • 공식 문서 위주로 공부한다.
  • 라이브러리를 직접 까보면서 공부하는 편
  • 책은 보조적으로 사용한다.
  • 야생 학습법
    • 개발자들에게 효율적이었다.
    • 먼저 코드를 쳐보면서 만들어본다.
  • 실질적인 프로젝트를 만들면서 반복적으로 실패를 경험하고 성장해 나간다.
  • 공부 시간대: 새벽 2,3시까지 공부

토이 프로젝트- 권용근님

  • 챗봇, 코덕: 운영한 지 1년 넘었다.
    • 1년 밖에 안됐지만 레거시 코드가 되어 직접 개선하는 경험을 하고 있다.
  • DDD, Test Code, JPA를 중심으로 레거시를 개선하는 토이 프로젝트를 진행하고 있다.

사수의 역할, 사수 없이 일한 경험- 이동욱님

  • 내 옆에 있는 사수는 언제든 떠날 수 있다.
  • 있을 때, 배울 거 하나라도 빼먹자.
  • 사수가 없을 경우의 장점도 있다.
    • ex) 테스트 코드를 당연히 짜야한다고 하면서 좋은 문화를 도입해보는 경험을 할 수 있다.

신입 개발자의 마음가짐- 권용근님

  • 기술을 쫓는 개발자가 되면 안된다.
  • 기본 소양이 굉장히 중요하다.
  • 토이 프로젝트 < 기본 소양
  • 기술은 언제든지 바뀔 수 있다.
  • 기본 소양 없이 기술만 쌓아 올리면, 무너질 수 있다.
    • ex) 테스트 코드 짜기 -> 코드 품질 챙기기
  • 토이 프로젝트를 하려면, TDD로 해보는 것을 추천

코드 품질 VS 비즈니스적인 요구사항 구현- 이동욱님

  • 나만의 학습 방법을 신입 때 갖춰 놓아야, 어느 기술이든 빠르게 배울 수 있게 된다.

테스트 코드

이동욱님

  • 배달의 민족의 정산 서비스만 테스트 코드가 1,400개
  • 테스트 코드가 문서의 역할을 하고 있다.
    • ex) 정산시스템팀에서는 A라는 상황에서 B라는 메서드 실행시 C라는
      결과가 나와야 한다는 식으로 한글로 테스트 코드 메서드명을 짓고 있다.
  • 일정 산정시, 개발자가 직접 기한을 말할 수 있어야 한다.
  • 톰캣 재실행하는 것보다 테스트 코드 돌리는 게 훨씬 더 빠르다.
    • 톰캣 2~3번 띄울 시간에 단위 + 통합 테스트(1,400개) 돌릴 수 있다.(약 7분 소요)
  • 테스트 코드에 대한 리팩토링도 계속 진행 중이다.
    • ex) 1조원에서 1원 차이나면, 찾을 수 있나?
    • 테스트 코드를 짜지 않는 것을 죄악시한다.
    • 우아한 형제들 팀 중에서는 Jenkins에서 코드 커버리지가 떨어지면, push를 못하게 막는 팀도 있다.
    • 정산팀은 보통 코드 커버리지 80% 유지하고, 배치 등의 코어는 특히 관리한다.
  • 설계나 디자인이 잘되어야 테스트 코드 짜기도 용이하다.

권용근님

  • 팀의 현재 테스트 코드는 1,100개
  • 테스트 코드 작성의 장점
    • 테스트를 잘 짜지 못하더라도 개발자의 공포감을 없애주고 자신감을 갖게 해준다.

새로운 기술 도입에 대한 우아한 형제들의 개발 문화

이동욱님

기술 선택의 자유도가 있다.
회사의 기조는 장애가 났을 때, 장애할 수 있으면 된다는 것

느낀점

캐주얼한 분위기의 세미나는 처음이었다.
우아한 형제들에서 베스트 셀러 저자분들과 블로그, 유튜브에서 유명한 개발자분들을
직접 뵙고 얘기를 들을 수 있어서 좋았다.
푸짐한 케이터링과 함께 우아한 형제들의 서비스가 좀 더 좋은 방향으로 가기 위해
어떤 선택들을 하고 노력해왔는지를 알 수 있는 시간이었다.
패널 토크에서는 학습법에 대한 여러 방안들을 알 수 있었고, 다양한 방법들을
시도해보고 나에게 맞는 나만의 학습 방법을 찾아가고자 한다.
또한, 테스트 코드의 중요성을 다시 한 번 느꼈다.
공포감을 없애준다는 권용근님의 말이 와닿았다.
테스트 코드에 대해 좀 더 고민해보고 적용해 나가자.

참고 링크

Share