몇달쯤 전에 처음 볼 때는 뭐 당연한걸 책으로 써놨네~ 하면서 대충 훑어보고 말았는데
최근 MSA 관련 작업을 하면서 다시 보게 됐다.
다시 보니까 전에 못 보던 부분도 보이고 전체적인 흐름도 잘 정리되서 좋았다.
MSA 관련기술
DevOps 관련 플로우
- 빌드시 유닛테스트
- CI/CD
- pull request 하면서 유닛테스트
- 통과시 container build
– 이미지에 로깅 툴을 넣어서배포 - stg(staging) 배포
- 통합테스트(수동?또는자동)
- prd(production) 배포
예전에 제대로 모르고 넘어간 요소들
API GW(zuul), CircuitBreaker(hystrix), ServiceDiscovery(eureka), ClientLoadbalancer(ribbon)
넷플릭스쪽이 관련 인프라가 잘 돼 있어서 spring쪽 개발자는 그걸 참고하면 편하다.
MSA적용실패사례 – MSA vs Monolith
예전에 O2O 서비스를 만들 때도 SOA를 시도했다가 실패했는데
모놀리스형태로 만들어야 할 규모의 서비스를 무리하게 분할한게 원인이었다.
처음에 사용자별로 서비스를 나눈 것 까지는 좋았다.
- 사용자ROLE별로 구분된 웹서버
- 일반사용자
- 관리자
- 사장님
- 인증서버
- APP api서버
그런데 여기서 일부 기능을 떼서 서비스 지역정보, 메일문자전송, 다국어관리, … 이렇게 넣다보니 일이 너무 많아졌다.
DevOps도 처음 적용해서 여기저기 오류 터지는데 서비스 개발까지 하려니 죽어났다.
MSA 적용 실패요인
인력부족, 기술부족, 자금부족
MSA를 제대로 이해하고 있고 관련기술을 구성할만한 사람이 있어야된다.
연구하면서 진행하려면 서비스 개발 이외에 최소 서너명이 더 있어야 하지 않을까
서비스 변화
MSA는 서비스 목표가 확실해진 이후에 해야되는 것 같다. 전체적인 서비스 구조는 고정 되어 있고 기능을 추가하기 좋다는거지 서비스의 큰 흐름이 변하는 경우에는 절대로 쓰면 안된다.
초기 스타트업은 서비스 하다가 버리고 다시 시작하기도 하고 메인 기능이 막 바뀌고 추가되고 하니까 MSA에 적합하지 않다.
~
개발자라면 한번쯤 보는게 좋을 것 같다.
요즘 대부분 서비스가 MSA화 되어가고 있고 이정도 속도면 10년안에 국가프로젝트도 MSA적용이 일반화될 것 같으니까