당근의 회원 시스템을 마이크로서비스로 분리하기

당근의 회원 시스템을 마이크로서비스로 분리하기

1. 프로젝트 시작 배경

2. 레거시 코드 이해하기

3. 시스템 분리

4. 장애없이 안전하게 분리하기

5. 기존 시스템 폐기

6. 성과

프로젝트 시작 배경

1. 불안정한 시스템

2. 누적된 기술부채로 확장/변경이 어려움

확장을 어렵게 하는 기술부채

• 안정적이고 확장 가능한 새로운 시스템 필요성 대두

1. 안정성
1. 99.999% 이상의 가용성을 제공

2. 확정성
1. 기존 회원 시스템의 기술부채들을 해결하고 빠르게 확장/변경이 가능한 회원 시스템

새로운 회원 시스템

• 마이크로 서비스로 분리(DB,인프라도 함께 분리)

• Ruby on rails —> Golang

• 명시적이고 확장 가능한 API

• 확장 가능한 데이터 구조

레거시 코드 이해하기

코드에 대한 데이터 수집

회원 시스템 분리하기

분리의 시작은 API를 가져오는 것

istio 서비스 메시를 두어 트래픽 제어

• Sidecar: Go로 구현된 HTTP 어플리케이션
• 모놀리스 서비스 요청을 신규 회원 서비스로 보내는 프록시
• API 호환성 유지
• 점진적 API 전환
• 모니터링
• ..

이 경우 신규 회원 서비스에 문제가 생길 경우 장애가 발생하게 됨 고로 Sidecar 가 모놀리스 서비스도 호출할 수 있게 해야함

1%의 신규 서비스 요청을 보내다가, 점진적으로 퍼센트를 늘려 100% 전환

장애없이 안전하게 분리하기

1. 데이터가 99.999% 일치한다

2. API 응답 99.999% 일치한다.

데이터가 99.999% 일치해야한다

신규 회원 DB 에는 로그인날짜가 저장되지 않는 이슈가 발생했다면, 데이터가 다를 수 있다.

API 응답 99.999% 일치한다.

Sidecar 는 두 응답값을 가지고 있기에 비교할 수 있었다

기존 회원 시스템 폐기

1. Sidecar 에서 모놀리스 서비스 API 호출을 중단한다

2. 시간이 지나 배포 시 Sidecar 제거 배포가 포함되어 점차 사라지게 한

Sidecar 제거

성과

안정성

확장성

Comment