피닉스 프로젝트, 유닉스 프로젝트 읽기
코딩애플 마이크로서비스
kb국민은행은 여태껏 메인프레임 쓰고 있었음 근데 전환하려면 3000억이든다
유닉스 운영체제로 갈아타는 마이크로서비스화할뻔 했는데 10년전에..
그래서 지금도 싸우고 있다
모놀리식 대형 컴퓨터에 엄청큰 프로그램 때려박음
단일 프로그래밍 언어와 단일 데이터베이스. 프로그램 하나이므로.
몇백명 몇천명이 같이 작업
너무나 많은 기능이 프로그램 하나에 들어가있다
결국은 찢게 되었다 잘게 쪼개진 프로그램들로 만들어진다
장애. 서버개발의 문제점은 끝도없이 죽어나가는거
rust같은거 하라는 이유가 안죽는 프로그램 짜기가 쉽지않다
하나가 죽으면 모놀리식은 다 죽는거니까 안죽게 하려고. 쉬다가도 죽으면 뛰어와야함
죽는이유중 가장 큰 이유중 하나 용량이 부족한것!!
용량이 몰리는것이니 scalability 가 중요
큰 프로그램이 작게 쪼겨졌으니 팀들도 작게 쪼개지고 토론하고 설계하며 기능구현하는건 빨라졌다. 빌드되는데 24시간걸리고 이랬었는데 굉장히 빨라짐
프로그램이 분화가 되었기 때문에 성능 중요하면 c++ 안전해야하면 rust
데이터분석만 하면 python db도 자기 원하는거
polyglot. 최적의 언어 개발환경 방법론 쓸 수 있게 되었다
관리하기가 편하다 github에 9명쯤 레포하나 만들어서 브랜치 따고..
언어도 다르고 db도 다르고
프로그램들이 여러개로 쪼개지고 팀이 작아지니까 agile한데 선들이 많아진다
복잡도가 올라간다.
배달의 민족이 5년걸려서 마이크로서비스로 전환함
안죽는게 중요해서!!
배달의민족 마이크로서비스 여행기
2015년에는 mssql php asp사용함. 루비 db장애시 전체 서비스 장애.
스토어드 프로시저 방식 사용. 거대한 모놀리식 시스템
단일 서비스 안에 프론트서버 리뷰 회원인증 포인트 메뉴 광고 주문 등..
루비db죽으면 다 마비
리뷰 관련 데이터베이스 테이블이 밀리면서 전체 시스템이 밀리면서 장애
리뷰가 장애 나더라도 다른건 문제 없어야하는데..
2016년 php에서 자바 언어, 마이크로서비스 도전 시작.
자바개발자가 많았기 때문
결제, 주문을 독립시키고 IDC에서 AWS로 클라우드 이전
넷플릭스는 생존의 문제로 마이크로서비스로 갔다. 이렇게 하지 않으면 운영이 안된다
결제기능 db개별로 해서 뺀다. 전화주문으로 서비스 이용은 할 수 있게 됨
주문중계 기능 gateway서비스. nodejs로 만들었음 지금은 java로 바꿈
선착순 결제 할인 이벤트. 갑자기 트래픽 들어온다.. 프론트 서버 주문 결제 프로세스
몇배는 더 사용자들이 들어옴. 프론트서버가 죽어버림. 주문까지 들어오지도 않음
프론트서버를 하루만에 AWS로 빼버림
AWS에서 100대 증설해서 트래픽 받음. 주문서버도 박살나서 aws로 옮김
결제는 성공. 외부 pg사에서 장애가 남. 결제해주는 pg사가 죽어버림 너무 많아서. 이건 어떻게 할 수 있는게 아님
네번째날 드디어 이벤트 성공
대 장애의 시대. 트래픽은 계속 느는데 scale할수가 없는 구조.
배민은 되게 장애에 민감한 시스템. 마이크로서비스를 해야한다 사장님들도 피해 고객센터도 피해 소비자도 피해
루비 데이터베이스에서 elastic seearch로 떼어냄
시스템 안전성이 가장 중요하다. 레거시 시스템을 새로운 시스템으로 바꾸는건 원래 우선도가 떨어진다.
달리는 마차의 바퀴를 갈아끼는건 쉽지 않다.
하나의 가게가 여러개 광고 진행할수 있도록 만들자! 장애대응이 더 중요해서 폭파시킴
가게상세 화면을 재개발. 쿠폰, 포인트 탈 루비
오프라인 모드 적용 - aws죽었을때 효과적
php가 트래픽 감당 못해서 java로 바꿈 루비 db에 있는것을 길다란 쿼리로 aws다이나모 db에 퍼붓는다
분리해놓고 루비 db에 가는게 줄어든다. 루비는 rdbms. 기능이 많지만
싱크가 약간 늦음
주문시스템 리뷰 시스템 탈루비
주문이 제일 복잡함. 결제 포인트 쿠폰 중계 정산 등이 다 엮임.
레거시 3대장
주문 가게/업주 광고
주문은 데이터 트랜잭션이 다 깔림. 하루 수백만의 데이터 쌓임
가게/업주는 시스템 연관도가 1위
광고는 스토어드 프로시저 사용량이 1위
서비스 자체를 이해하고 싶었다. 백엔드 장애 일어나고 뭔가 하는데 나는 프론트라서 모른다고 하고 싶지 않음
배민 라이더스 개발함
배민 라이더스 주문 시스템 자체를 별도로 만들었음. 주문서버를 나중에 통합함
새로운 주문 테이블을 설계해서 데이터베이스 일부만 바꿔서 aws rds사용
주문시스템 많은 api호출한다. 배민 라이더스 시스템에도 넘어가야하고..
주문하고난다음 리뷰써달라고 앱푸시 해야하는데 주문 완료된거 알아야하고.. 다 api로 만들어져있다
리뷰시스템이 장애가 나면 주문 시스템도 영향을 받는다. 주문은 명확한 이벤트 기반으로 명확한 주문 이벤트 정의 주문 시스템은 이벤트만 발행함. 이벤트를 가져가서 데이터 전달.
이벤트안에 데이터가 있다 리뷰 시스템 레거시 라이더스 등에서 consume한다
리뷰가죽어도 아무 영향이 없음 이벤트기반 시스템에서는 aws sqs에서 남아있어서 안날아가고 consume한다
그럼 데이터 유실이 없어진다 회복력이 좋아짐
aws sns sqs
주문 시스템에 필요한 sqs만들고 필요한 시스템에 꽂으면 된다
연동해달라고 하면 이벤트 던져주면 알아서 꽂아서 시스템 구축한다
남은 레거시 2대장
가게업주 광고
가게랑 광고랑 일대일이었는데 하나의 가게가 하나의 광고만
shop이라는 테이블안에 광고 가들어있었다
떼어내기가 어려웠다
하나의 가게가 여러개의 광고 하려면 매출증대하고 사장님도 좋은데..
가게랑 광고데이터 전부 루비에 묶여있었음
가게상세를 떼어내서 가게노출이라는 시스템으로 만든다
쿼리모델 서비스 조회용
가게목록 검색 → 광고용과 검색용 분리
가게업주 데이터 바꾸면 다른 서비스들은 api찌른다
장애전파되는 문제 가게시스템에 문제 있으면 모든 시스템이 연쇄적으로 죽는다
고성능 조회. 대량의 트래픽이 순간적으로 확 몰려온다 트래픽이 api호출방식 사용하면 모든곳에 다 퍼진다 트래픽 전파.
그럼 대용량 트래픽때문에 장애가 나는데
성능, 장애격리, 데이터 동기화
성능은 대용량 트래픽 대응 api를 초당 15000회 호출하는데.. 모든 시스템이 대용량 트래픽 감당은 어렵다
가게나 광고같은 내부서비스나 db에 장애 발생해도 고객서비스 유지하고 주문가능해야한다
데이터 동기화 = 데이터가 분산되어있음
cqrs 아키텍쳐 배달의민족 시스템 전체를
command query둘을 철처하게 분리
광고랑 가게/업주를 command 사이드 가게 연락처 바꾸면 변경되었다는 이벤트를 쏜다
각 시스템들이 가게업주 데이터 필요하면 consume해서 데이터 갱신
모든것은 서비스가 커지면서 문제가 발생하는거구나..
최종적 일관성 데이터는 언젠가 다 맞추어진다 늦어도 1~3초
문제 발생시 가게 시스템 안에서만 이벤트 재발행
zero-payload 메세징 전파방식
가게에서 이벤트 발행할때 딱 가게 id만 보낸다. 이벤트 수신하는곳에서는 가게 id데이터 꺼내서 가게노출 시스템과 업주시스템 협의한 api호출한다
가게노출과 광고리스팅 데이터가 다르다
polyglot 각 시스템들은 필요한 db사용할수있게 됨
광고는 elastic search 고성능은 mongodb redis
명령은 안정적인 오로라db mysql과 호환된다
가게노출 시스템이 쿼리모델로 되어있다
광고를 보거나 검색하거나 할때 가게 id만 반환해주면 된다 db에 찔러서 key value로 빠르게 조회
트래픽 들어오면 뒷단 호출 안아혹 query와 관련된 시스템만 받고
광고 가게업주 죽어도 고객은 주문할수있다
각 시스템이 내부에 필요한 데이터 보관. 장애시 데이터 싱크 늦어져도 괜찮다
데이터 싱크중에 장애 나면?
전체 import api로 대응함
적극적이 ㄴ캐시 사용 서킷 브레이커 비동기 nonblocking 시스템
정리
배달의민족은 거대한 cqrs시스템
성능이 중요한 외부시스템과 비즈니스 많은 내부 시스템으로 분리
이벤트 발행을 통한 eventually consistency
각 시스템은 api또는 이벤트로 연동
개발은 기획이랑 같이 해야한다
2019년 말에 완전히 마이크로서비스로 전환!
트래픽이 너무 많아야 마이크로서비스 하는거다 데이터 싱크같은거 해야하고 하니까 비용이 10배는 더 든다..
규모의 경제일때 필요할때 해야하는거지 시스템 복잡도가 올라간다
라이브서비스 운영하면서 온프레미스에서 장비를 탄력적으로 집어넣기는 어렵다
왜 네카라쿠배인가..!
플랫폼 운영은 어렵다 노하우가 많이 필요함
서버 하나로 다 해결되면 누가 새기술 넣겠냐. 안죽게 하려고 하다가 이렇게 된거다
php는설치형 서버?
추상적이었던 단어들 구체화된다 서비스간 영향을 최소화 api호출 안하고 이벤트 띄운다
event streaming messaging
DDD domain driven
기획팀과 연결되어야하고.. 마케팅팀도 연결되어야하고 쿠폰이나 이벤트 등등
그래서 팀플하라는거
사용자 웹서버로 접속 static컨턴츠 처리하고 중간에 있는애로 webapp이랑 연결
넷플릭스가 2015년에 마이크로서비스 진화를 마침 그걸 보고 배민이 활용
토스는 2023년에 msa전환
배민 프론트엔드 서버 -우아콘 2020
오늘의집
killercoda는 설명하지 않을 예정!!
