세미나

if kako(2019) 리뷰

foglove 2019. 12. 3. 10:00

오픈소스 데이터베이스, 흐르는 은행 데이터에 빨대를 꽂아보다.

  • 카카오뱅크는?
    • 금융 탈을 쓴 소셜 서비스
    • 폭발적으로 늘어나는 데이터

데이터를 분산 재배치를 해보자

  • SQL로 데이터 퍼가기
  • CDC 변경분 퍼가기
  • 손 타이핑 노가다해서 퍼가기

SQL로 데이터 퍼가기

  • 장점
    • SQL로 데이터를 자유롭게 제어
    • 로직에 포함되며, 상대적으로 구조가 간결
  • 단점
    • 소스DB에 부하(Select / Index)
    • 지연된 커밋에 따라 데이터 누락 발생 가능

What is Uldra?

  • Source DB -> Target DB 사이에 존재하여 Sharding 지원가능한 소프트웨어
  • JDK 1.8로 작성
  • Uldraman은 어떻게 구성되어 있을까?
    • BinaryLog Parser로 변경분을 파악해서
    • Task Worker를 통해 원하는 DB에 저장하는 방식
  • Goals
    • 쉽고 정확하고 빨라야 한다.

What is BinaryLog in MySQL?

      • Table Map Event
        • 변경을 가한 테이블 정보
        • 데이터베이스 / 테이블 / 테이블 컬럼 타입
      • Row Event (Write, Delete, Update)
        • Write - 추가 데이터
        • Update - 변경 이전 / 이후 데이터
        • Delete - 삭제 이전 데이터
    • Query Event End

Uldraman 이전 모습은?

  • Kakao ADT는 주로 배치 프로세스에 초점
    • 타겟쪽에 구조 변경으로 인해 장애가 발생하더라도
    • 실제로 서비스에는 노출하지 않는다.

하지만 Uldraman은?

  • 실제로 서비스하는 온라인 서비스에 포커싱을 맞춘 프로젝트
  • 특급 서비스

Uldraman을 사용하기 위해서는?

  • Binary Log format은?
    • Row Format으로 기록되는 바이너리 로그여야만 한다.
  • Binary Log Full Image
    • 바이너리 로그에 변경 전 / 후 이미지가 모두 포함되어야 한다.

Kakao ADT & Uldraman의 공통 목표

  • 복제가 시스템이 이상이 생기는 경우?
    • 실패한 지점부터 다시 시작을 해야하는데..
    • 이를 어떻게 해결할까?
    • Overwrite
      • 덮어쓰다보면 언젠간 맞춰진다.
      • 누락된건 없는지..
      • 성공했던 포지션부터 다시 복사하자!
      • Update Row Event인 경우 항상 Delete가 발생하는 것은 아니다.
        • 샤드키 혹은 PK 변경 (샤드키는 국적, PK는 집주소)
        • YES
          • Delete
        • No
          • Replace
    • Sequential
      • 데이터를 그룹핑하고
      • 동일한 그룹에 있는 데이터는 순차적으로 처리하자.
    • 병렬 처리
      • 연관없는 데이터를 병렬로 처리하면 빠르지 않을까?
      • 1차 샤딩 룰
      • 2차 샤딩 룰
        • 몇번째 Thread에서 진행할지 결정

Uldraman의 가진 Feature

  • Recover Mode
    • 데이터 버젼 체크를 해보자.
    • 언젠가는 데이터가 최신은 되지만.. 정합성을 요구하는 상황이라면?
      • 이를 해결하기 위해 데이터 내용에 버젼을 넣고
      • 데이터 버젼이 낮거나 같으면 Overwrite하는 모습
      • 매번 발생하는 상황은 아님
  • Generate Sharding Key
    • 샤딩키를 만들거나 변형해서, 그 기준으로 데이터를 분산하자.
  • Performance는?
    • 스케일 아웃인 경우
      • 1 Node -> Uldraman -> 8 Shard
      • 30,000 rows/sec
    • 스케일인인 경우
      • 4 Shard -> Uldraman -> 1 Node
      • 1 Node의 내장 DB는 tokudb 사용하는 상황

2. 초당 옥수수의 취소를 막아라 !

수만건의 주문을 1초내에 처리내에 처리 하는 기술

 

초당 옥수수 ?

처음에 세미나 제목을 듣고 초당 처리 하는 기술이라서 초당 옥수수라는 별칭으로 불리는 구나 생각 했지만 세미나를 듣고 나서 초당 옥수수라는 일반 옥수수의 비해 3배 이상 당도가 높아서 인기가 있는 초당 옥수수라는게 있다는걸 알게되었다. 초당 옥수수는 일반 판매 하는 방식이 아니고 수확 시기가 오면 미리 예약을 받아서 수확하는 동시에 배송 하는 시스템임

하지만 수확을 예측 해서 배송을 하는 시스템상 수확이 어렵거나 날씨에 영향을 받아 배송 지연처리를 하더라도 배치를 돌려서 보내는 방식이었기 때문에 배치 시간이 될 때 까지 기달려야되는 문제가 있었다.

레거쉬 시스템 문제

1.     배송 지연 안내를 위해 배치를 사용 (5분마다 실행)

2.     너무 복잡한 비즈니스 로직

 

레거쉬 시스템의 문제에 대한 개선점

1.     실시간 TMS 발송

A.     단일 머신을 수행 하기에는 한계가 비동기 워커를 구성 메시지 브로커로 BabbitMQ 를 도입

2.     복잡한 비즈니스 코드 리팩토링

A.     기존에 중복된 소스를 하나로 합치고 배송지연처리,주문조회,배송조회,주문 상태 변화 등 모듈화를 통해 리팩토링

3.     처리 속도 개선

A.     반복되는 태스크 수행시 병목이 발생 그래서 비즈니스 처리를 비동기 워커를 구성하여 여러 개의 컨슈머로 처리 해서 대량의 요청을 분산처리를 통해 해결

액터가 된 비동기 워커

-       분석처리

n  쉽게 분산처리를 할수 있도록 개선 스프링 simpllerabbitlitenercontainerfactory 확장 Listener 별 consumer 커스텀 설정

-       자동 재처리 및 실패 감지

n  Consumer 처리시 예외 발생(약 1%) 한건에 대해서 Retriable 재처리용 큐를 사용해서 재처리

n  재처리용 큐를 통해서 실패가 된 건들은 큐에 쌓고 관리자에게 카톡으로 알림을 해줘서 직접 처리가 가능 하도록 함

배포 없이 빠르게 롤백 하는 전략 : 전체 구조

이전 배포시에는 배포를 하고 문제가 생기면 롤빽을 하는 방식 이었는데 롤뺵 하는 동안 장애가 발생함 하지만 앞단에 스위치를 둬서 배포 하고 문제가 생기면 스위치 on/off 식으로 사용 하면서 1초만에 이전 버전으로 돌릴 수 있도록 바꾸면서 단점을 해결함