우선 아래 글은 모두 웹개발을 가정하고 말하는 거임
난 단일 서비스 기업은 msa 구조가 유리하다 생각함. 흔히들 말하는 msa의 장점으로 아래 세가지가 제일 많이 뽑힘
1. 더 세분화된 수평확장으로 비용절감
이건 인프라 비용이 억단위를 넘어가는 대기업이 아닌 다음에야 크게 장점이 아니라 생각함
2. 단일 실패지점 방지
물론 논리적 단일실패지점을 방지할 수는 있음. 그런데 실제 현업에서는 인프라 실패가 더 많이 일어남.
하지만 인프라 단일실패지점은 서비스 수평확장을 통해서도 없앨 수 있음.
3. 서비스별 독립적인 배포 가능
난 이게 msa의 진가라 생각함.
가끔 프갤보면 dau가 몇인데 msa를 쓰냐, 팀도 작은데 왜 msa를 쓰냐고 하지만 다 잘 모르고 하는 말임.
비지니스적 시도가 많고 ttm이 중요한 스타트업이나 대민서비스는 특히 이 장점이 더 두드러짐
si다녀본 사람들은 지옥의 배포열차나, 되던 게 안되는 숙취증후군이 가면 갈 수록 생산성을 잡아먹는단걸 알거임.
신입때는 한번 배포에 3일을 쓰는 곳을 봤음. 엉클밥 아저씨의 클린아키텍쳐에서 나온 시나리오 그대로 흘러갔음.
처음엔 주 1회 배포를 가볍게 하다가 나중엔 격주에 한번 날을 잡고 배포를 함. 새벽까지 계속 되는 오류로 2차 3차 배포가 이어짐.
대기업도 그러는데 평균적인 si는 얼마나 심하겠음?
배포할땐 야근을 해야하고, 배포를 해도 어떤 오류가 발생할지 몰라서 의기소침해지면 점점 새 기능을 빨리 시도하기가 부담이 됨
이런 문제는 팀 간 의존성을 없애고 독립 배포를 가능하게 하는 msa로 해결이 됨.
위 문제를 몸소 체험한 나는 내 회사가 성장하고 신입들을 뽑으면서 혼자 급하게 msa로 전환을 했음.
흔히 msa 구조가 개발하기 어렵다고 생각하는데
이벤트 소싱, graphql 페더레이션, 어느정도의 데이터 중복으로 시스템간 의존성 문제 없이 쉽게 msa 구현을 했음.
msa로 유명한 넷플릭스도 graphql gateway로 단일 엔드포인트를 생성함. 스프링 쪽에서 gql하는 사람들은 넷플이 만든 dgs 라이브러리도 많이 쓴다고 들음.
(어떻게 구현했는지 자세히는 소개 못하겠는데 혹시 작은 회사 개발자나 테크리더로 있는사람은 댓글 달면 내가 운영하는 밋업에 초대할게 들어와서 기술공유하면 좋을거 같음)
mongo 4.0부터 rdb의 개발상 장점은 딱 세가지로 한정이 됨
1. 조인 연산
2. jpa ( lazy loading, 참조형 엔티티 필드 관련 연산)
3. 친숙함
rdb는 rest api 짤때는 1, 2번의 이점이 분명히 있음. 데이터 구조를 완전히 구성해서 리턴해야하기 때문에 유용함.
하지만 graphql처럼 엔티티 필드에 대해 리졸버를 작성하고, n+1 문제를 피하기 위해 데이터로더를 커스텀하여 사용하게 되면 JPA의 lazy 로딩이나 조인 연산의 장점이 크게 느껴지지 않음
오히려 jpa의 blocking api가 webflux 패턴에 영향을 주고, 구조적 스키마가 생산성에 독이 되는 걸 느꼈음
특히 몽고디비가 멀티 컬렉션 트랜잭션을 지원하는 요즘엔 복잡한 통계 쿼리가 필요한 경우가 아니면 rdb 쓸일이 없음
서비스가 수평확장 할때 몽고를 쓰면 더 이상 db가 시스템의 병목이 아니게 되고 일반적인 비즈니스 로직에서 읽기쓰기 연산도 RDB보다 MongoDB가 월등히 빠름.
특히 Postgres랑 비교해서 로드 테스트를 진행했을때는 말도 안되게 차이가 났음.
우리 회사에서도 결제 시스템과 사용자 관리 시스템은 postgres를 쓰지만, 그 외의 서비스는 모두 mongo를 사용함.
10명따리 소규모 기업이라 신입 교육도 내가 하는데, 처음에 gql로 된 msa 시스템이라 소개하고 jpa를 쓰지 않는다고 말하면 다들 겁먹지만
막상 시스템 맡기고 개발시키면 새로운 방식이라 어색하긴 하지만 편하다고 함
각 서비스 담당자가 이벤트에 대한 자기 서비스 책임만 구현하고, 이벤트만 제대로 발행하면 문제가 없으니까
다들 오류에 대한 부담이 덜하고 각자 스케쥴에 맞춰 배포하면 되니까 배포가 수월함
물론 결과적 일관성, 이벤트 버전호환성 등등 조심해야할 부분이 많지만 잘만 설계하면 msa 장점이 많음
좋은 글이네
님 회사 노드 말고 스프링 쓰는 이유가 궁금함 저도 창업 관심있는데 노드말고 스프링 해야하나..
처음엔 옆에 있는 개발자가 쓰던 언어가 국룰인듯
혼자 mvp할땐 노드로 짰는데 인력 구하기도 그렇고 협업할때 개인적 선호가 spring이 더 좋다 생각했음
똥같은 프갤에 간만에 귀한 글이
트래픽이랑 서비스 이름좀 알려주라
몽고 클러스터링 해야될 정도 수준이면 트래픽 꽤 나온다는 소린데
mysql도 비테스로 분산 처리 가능하고, 분산 처리 안해도 일정 규모 이하면 mongodb보다 mysql 성능이 좋던데 어떤 기준으로 mongo 성능이 더 좋다고 한건지 궁금하네 혹시 집계 쿼리 같은거 테스트 해봤음?
팀원이 10명인데 팀이 몇개며 마이크로서비스는 몇개인지도 궁금하넹
메시지 발송 저장이나 서비스 간 트랜잭션은 어떤 방식으로 처리했어?
댓글로 일일히 대답해주기도 좀 애매하고 뭔가 공격성이 느껴져서 대답하기 싫음 ㅋㅋ 혹시 내가 주최하는 밋업 참여할 생각 있으면 거기서 답변해줄게. 오픈톡 남겨
애매한게 아니라 제대로 안챙긴거겠지
일일히->일일이
씹똥글이네 ㅡㅡ - dc App
모든 서비스를 웹플럭스로 작성한 이유가 뭐임?
통합테스트는 어떻게 처리함?
서비스 여러개 거치면 성능 이슈 필연적으로 나오는데, 이거 어떻게 해결함?
서비스 여러개 거치는 게 아님.. 서로 api 동기적 통신을 하는게 아니라 이벤트 소싱 방식으로 결과적 일관성만 보장하는 식으로 하는 거라 오히려 db부하 있는 api인 경우에 응답시간은 더 짧아
딱 특정 케이스만 겪었구만ㅋㅋ 계속 해봐라 api 통신 없이 이벤트만으로 모든게 되는지
결제 서비스 같이 일부는 api 통신하지 데이터 중복을 허용하면 웬만한 동기적 통신은 다 필요가 없어짐. 우리도 첫 한두달 시행착오 겪다가 이미 거의 1년 동안 잘 운영하는 중임.
신기술 힙스터충이메 - dc App
내가 이렇게 물어보는 이유는 규모 작을때 소꿉장난이야 뭐로 하든 큰 문제가 없거든 트래픽 적을땐 지킬걸 안지켜도 실제로 문제로 이어지는 경우는 드무니까 msa는 규모 커지고 도메인 엮이고 지랄나고 사람은 없어서 도메인 존나 여러개 맡고 병목지점 생기고 트러블슈팅은 안되고
보통 그때가 돼서야 후회하거든
웹플럭스도 이제 서비스 복잡해지면 좆되기 시작하지 처음엔 조또아니고 모든게 명확하고 간결함
나중 가면 어차피 혼자서 일하는데 데이터는 사방팔방 분산돼있고 코드도 마찬가지고 배포도 다 개별적으로 해야해서 오버헤드 존나 증가함 투자 많이 못받은 초기 스타트업의 가장 중요한점은 인적 리소스를 어떻게 관리하느냐인데, msa는 관리 오버헤드가 존나 큼
우리는 1인 1서비스 맡고있음
명복을 빈다
ㅋㅋ 극공감 msa는 니일 내일이 되서 인사관리가 제일 문제임
이거 존나 맞말이네 Msa 효능 ㅈ도 없는 서비스에서 암만 난다긴다 최적화해도 진짜 msa필요한 사이즈 되면 문제 다 터지던데
그리고.. 서비스마다 db 분리는 한거지?
논리적으로만 분리함
딱 자기기술챙기다 회사말아먹기좋겠군
신입때 봤다는 1배포 3일소모는 대체 어디서 봤는지 모르겠는데, 그건 그냥 일을 좆같이 한거일 확률이 훨씬 높음 걔들이 msa로 했어봐라 ㅋㅋ 1배포가 아니라 그냥 서비스가 터짐
우린 잘만 운영하고 있는데 저주를 퍼붓고 있네 ㅋㅋ msa하다 데인적있으면 성공사례 보고서 배워야지 배아프다고 욕할게 아니라..
왜 공격적인지 모르겠네 진짜 ㅋㅋ msa하다 망한 적 있음?
그냥 병신 보면 패는편임
ㅋㅋㅋㅋ 나 신상 공개도 했어서 너 잘못하면 고소먹어
okky에서도 너같은애 많이 봄ㅋㅋ 걍 무시할게 진심으로 너가 행복하길 바람
옹냐 ㅋㅋ 많은걸 배우길 바란다
저러다 좆되면 빤스런 갈길듯ㅋㅋ
서비스 동접 1명 예상
그거 열배는 될듯 ㄹㅇㅍㅌ - dc App
댓글 개많네
대부분 내꺼임
dau330~350만 나오고 aws월 1억넘게나오는대 SOA로도잘돌아가는대문제잇나요
저런 애들은 그런게 중요한게 아냐 기술 딸딸이가 중요함
난 네스트충이라 soa도 좋아함. 첨 mvp할때 soa로 했음 그리고 모듈 의존성만 잘 해결하면 내가 말했던 문제도 발생하지 않음. 다만 난 msa가 알려진것만큼 복잡하지 않고 장점이 많다는 걸 말하는가임
오 멋지다
설대는 다르구나
응원한다
기술을 위해 만든 서비스 ㅇㅇ - dc App
MSA를 구성하면 시스템 유지비용이랑 인프라 유지 비용만 더 잡아먹는데 너무 작은 서비스만 하고 딸딸이 치는거 아니냐? 글구 몽고DB랑 RDB랑 같이 써야 좋다는건 동의하고, 그 족같은 스프링을 안썻으면 니가 8시간 일할거 3시간이면 떡쳤다
10인 개발자 msa이지랄하고 자빠졌네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 입코더노
1배포3일은 진짜 ㅋㅋ 헛소리ㅋㅋ 빙신같이 만들었다는걸 증명하는꼴인데 울회사에서 10년서비스되고있는 작지않은 모놀리식 서비스 배포 한시간도 안걸리는데 돌겠노 ㅋㅋㅋㅋ
그 서비스가 graphql을 꼭 요구하는 특수한 상황임? 그게 아니면 다른건 몰라도 graphql은 진짜 개쌉오바인듯
"이런 문제는 팀 간 의존성을 없애고 독립 배포를 가능하게 하는 msa로 해결이 됨." <- 10명 따리 회사인데 무슨 팀을 나눈다는 건지 잘 모르겟음.. 그래도 일단 도전정신은 응원할 만 하다
정신 나간 개발자를 고용하면 이렇게 호미로 막을걸 가래로 막는다 배포3일 걸리는 시스템을 개선하기보단 아키텍쳐를 통째로 들어내는 미친 판단력 그러다 안되면 튀는 미친놈들을 조심해야한다
가장 되지 말아야할 개발자가 바로 이런 것임 si에서 개막장으로 개발해도 이거보다는 가치있는 일임 마이너스는 아니거든
ㅇㄱㄹㅇ