architecture cases
Edit모음 : https://gist.github.com/ragingwind/5840075
- Facebook geographic distributed architecture : http://bcho.tistory.com/416
- http://www.infoq.com/presentations/Scale-at-Facebook
Tumblr
- Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter High Scalability
- How Tumblr went from wee to webscale Gigaom
- Tumblr가 가진 기술과 개발 문화
Evernote
- http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html * http://www.mimul.com/pebble/default/2012/03/02/1330664364631.html
Netfix
http://www.mimul.com/pebble/default/2012/09/06/1346890689112.html
Soundcloud
- http://backstage.soundcloud.com/evolution-of-soundclouds-architecture/
- http://www.looah.com/article/view/1652
Stackoverflow
http://yisangwook.tumblr.com/post/73202754212/stackoverflow-com
AOL
Line
- http://helloworld.naver.com/helloworld/809802
- http://helloworld.naver.com/helloworld/551588
- https://engineering.linecorp.com/en/blog/line-storage-storing-billions-of-rows-in-sharded-redis-and-hbase/
광군제 참여 업체
쿠팡
11번가
- https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1
- 스케일 아웃없이 순간 급증하는 주문처리하기(Microservice with Kafka) (DEVIEW 2019, 김태경 님)
우아한 형제들
- Springcamp 2018:이벤트 기반 분산 시스템을 향한 여정
- 점진적인 레거시 웹 애플리케이션 개선 과정
- 배민 API GATEWAY - spring cloud zuul 적용기
- Hystrix! API Gateway를 도와줘!
- 잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화
단일DB로 인한 전체 장애 → 단일DB를 여러 저장소로 분리 (주문/주문중계/가계 등)
읽기 성능 한계 → 읽기 부하를 Document DB로 분산(메시지큐를 이용한 데이터 동기화)
쓰기 성능 한계 → DB 샤딩 (주문키 기반 샤딩)
규칙성 없는 이벤트 발행으로 인한 복잡도 증가, 이벤트 유실 → 이벤트 로직을 단일 어플리케이션에서 처리, transactional outbox 적용
배달의민족 마이크로서비스 여행기
- Netflix가 MSA로 가는데 7년이 걸렸다고 함
- 거대 DB에서 분리한 시스템 순서
- (2016) 결제 서비스를 처음 분리
- 결제가 장애나도 전화 주문을 할 수 있음.
- 당시 돈과 관련된 건은 Cloud에 올릴 수 없었음.
- (2016) 주문 중계
- 여러 주문 접수 경로로부터 포워딩해주는 게이트웨이 서비스
- (2017) 메뉴, 정산
- (2018) 가게 목록 + 검색 시스템
- (2018) 가게 상세
- 기존DB에서 1~5분 배치로 AWS DynamoDB로 데이터 동기화
- (2018) 쿠폰, 포인트
- (2018) 주문
- 제일 복잡. 모든 시스템과 다 엮임.
- 배만과 라이더스를 통합하는 새로운 주문 테이블 설계
- 이벤트 기반으로 변경
- 전사 차원의 이벤트 규약 정리. (생성/접수/배달완료/취소)
- (2018) 리뷰
- (2019) 광고 + 가게
- 신규 사업모델을 반영하면서 시스템 구조 개편(사업과 기술조직을 다 만족시키는 방향)
- CQRS 로 전사 아키첵처를 재구성
- 가게노출시스템(READ 관점), 광고리스팅, 검색 시스템
- 조직구조에서도 Command과 Query를 분리
- (2019) 회원/인증
- 2019년 11.1일 기존 DB 완전 탈출
- (2016) 결제 서비스를 처음 분리
- 2016 치킨 이벤트 대처
- 1일차 Front 서버 장애. 하루만에 AWS 이전
- 2일차 주문서버 장애. 주문도 하루만에 서버 AWS 이전
- 3일차 PG서버 장애. 해당 업체에서 장비를 늘림
- 4일차에는 성공.
- 2017 대장애의 시대
- 하루 주문수 20만 돌파
- 주말에도 장애나고 해서 개발자/CTO 모두다 괴로워함.
- 배민 장애나면 사람들이 요기오 → 배달통으로 순서로 주문시도하는데, 차례대로 죽어버림.
- 2018에 안정성을 최우선의 가치로 선언. 돈버는 과제보다 우선 시.
- CQRS, Event
- Query 시스템은 비동기 nonblocking 기술 많이 사용 (Spring WebFlux)
- Zero payload 방식
- 이벤트에 가게 ID만을 보내고 consumer에서 HTTP API를 호출하여 필요한 데이터를 얻어옴.
- 테이블이 수십개라 모든 데이터를 다 메시지에 넣어서 보내는 방법은 현실적이지 않았음.
- 데이터 저장
- 최소 데이터 보관 원칙 : 각 시스템은 필요한 최소한의 데이터만 보관. 데이터는 논리적인 의존관계를 만듦
- CQRS의 역할에 따라서 저장소 솔류션 선택
- Command 시스템은 안정성이 높은 RDB
- Query 시스템는 성능이 좋은 NoSql류도 도입 (DynamoDB, MongoDB, Redis, ES)
- 데이터동기화
- 장애 대비 : 메시징큐 장애시에 대비해서 전체 데이터를 sync하는 5분 배치가 있음.
- 데이터 validation 등을 위해 API를 호출해야하는 경우의 정책 보완.
- API 실패나 일관성이 맞지 않는 데이터에도 가급적 주문은 이루어지도록 기획과 논의
- 예) 사장님이 음식 메뉴이름을 바꾸었을때 이전 이름으로라도 주문은 되는 것이 낫다.
뉴스기사로도 배민은 서비스 장애를 어떻게 없앴나 에 소개
네이버
뱅크 샐러드
무신사
- “이번 달도 밤샘 정산입니다.” — 정산 시스템은 왜 필요했을까 (설계편)
- “이번 달도 밤샘 정산입니다.” — 정산 시스템은 어떻게 만들었을까
(실전편)
- 이벤트 기반 처리 영역 : 정산의 ‘원천 데이터’를 책임지는 영역. Kafka
- 배치 기반 처리 영역 : 정산의 ‘확정’과 ‘마감’을 책임지는 영역. Spring Batch, Argo Workflow