'주문 중계'란 사장이 app, pc 단말기등 다양한 루트로 주문을 접수받을 수 있다.
node.js로 중간에서 코딩해주는 게이트웨이 서비스 비즈니스에 맞는 기술을 사용.(지금은 java로 바꾼 상황)
치킨 디도스 사태
day1: 너무 많은 트래픽 유입으로 프론트서버가 죽어버리며 실패(주문으로 넘어가지도 않음)
day2: AWS로 서버 이전 계획을 급하게 진행(한달치 계획을 하루만에 실행)
장비 100대 이상 증설해 트래픽 대비(어뷰징이 된다?)
문제는 주문 서버가 죽어버렸다.
주문서버도 하루만에 AWS 이전, 장비 증설
day3: 결제를 해주는 외부 pg사, 카드사에서 서비스가 죽어버린다.
외부화사 문제라 그쪽에서 장비 수급해서 해결함
day4: 성공
"이벤트 기반 데이터 전달" 이벤트 기반 시스템
주문을 명확한 이벤트 기반으로 주문의 라이프사이클을 정의한다. 이벤트 기반의 마이크로 서비스 아키텍처를 구성
"주문 시스템은 이벤트만 발행할 것이다. 다른 시스템에서 원하면 이벤트를 가져가서 succession(연속, 잇따름)해서 원하는 비즈니스 로직을 작성해" -> 주문시스템과 api를 완전히 분리.
주문시스템을 sns에 쏘면 이벤트 안에 데이터가 있다.("이벤트가 생성됬습니다. 접수됐습니다. 등") 이 데이터를 다른 api에서 이벤트를 받아서 처리한다.
리뷰시스템이 죽어도 주문 시스템에는 아무 문제가 없다. sns하나만 쏘고 끝난다.
리뷰시스템이 살아나면 이벤트가 날라가지 않고 aws, sqs에 쌓여있는 이벤트를 다시 보낼 수 있다.
새로운 시스템에 주문 라이프 사이클이 필요한 경우 많은 이득을 보았다.
주문 시스템은 할 게 없다. 그냥 그 시스템에 필요한 sqs를 만들고 주문 sns에 연결하고 시스템에 꽂으면 된다.
이때부터 에러가 크게 줄었다.
남은 레거시는 가계/업주, 광고 시스템
가계/업주랑 광고는 1대1 관계, 하나의 가계에 하나(한 장소)의 광고만 가능
가계 테이블 안에 광고 데이터가 들어가있다. 컬럼이 거의 100개가 되어 떼어내기 어려웠다. 전체 시스템에 영향을 주기 때문에 비즈니스를 올스탑해야 할 수 있다.
완전한 마이크로 서비스를 위해 회사 임원들이 "프로젝트 먼데이"를 진행. 3,4개월 동안 시스템 기반을 안정화하고 개발팀이 이 프로젝트에만 집중하도록 지원한다.
가계노출 시스템, "CQRS 모델링", "쿼리모델" 서비스 조회용 가계데이터를 가지고 있는 쿼리모델을 만들었다.
기존의 아키택처 상황과 문제
이벤트 시 대량의 트래픽이 갑자기 몰려온다. 이 트래픽이 모든 api에 퍼진다.
광고나 가계/업주 시스템은 트래픽 해결보다 정확하고 안정적인 운영이 중요하다.
먼데이 아키텍처 고려사항
해결 방안
Command and Query Responsibility Segregation(CQRS)
Eventually Consistency(최종적 일관성)
Zero-Payload 방식 사용
가계아이디만 보내면(실제로는 몇개 더 보낸다.) id를 수신하는 곳에서 데이터가 변경됨을 확인하고 두 시스템에서 협의한 api를 호출한다. api에 있는 데이터로 데이터를 채워넣는다.
변경된데이터만 보내는 경우 이벤트 순서를 고려해야 한다. 가계의 연락처를 a->b로 변경하는 경우 이벤트는 b-a로 올 수도 있다. 해결에 많은 고민이 드니 그냥 이벤트를 항상 최신순으로 보고 최신의 데이터를 조회하고 갱신하자고 결정.
전체데이터만 보내는 경우 테이블만 수십개라 현실적이지 못함
가계 최소정보(가계id)만 보내고 나머지는 api를 만들어서 각 시스템들이 최신에 받은 이벤트면 항상 그 api를 호출해서 각 시스템의 앞단을 갱신한다.
2019년 12월 13일 DH는 딜리버리히어로를 인수한다고 발표, DH는 반독점법 제약으로 요기요를 매각하기로 결정했다. 배민의 탈루비 프로젝트가 성공해 MSA를 완성한 점이 DH의 배민 인수 절차에 큰 영향을 미쳤을 것이라 추측한다. 요기요는 MSA를 어디까지 완성했는지 알아볼 예정
시스템이 커지고 트래픽이 커지고 규모의 경제가 가능해지는 순간에 MSA가 필요하다.
단순하게 테이블 조인하면 될걸 데이터 싱크하고 맞추는 과정에 비용이 10배는 더 든다. 이를 상쇄하고도 남는 경우에 MSA로 넘어가는 것이 맞다고 김영한 개발자는 주장했다.