이번주에 본격적으로 MSA를 하게 되었다.
그러면 MSA 란 무엇이며 왜 나오게 되었는지 부터 알아보면 좋을 것 같다..
사실 프로젝트 주차 들어왔을 때 MSA가 너무 하기 싫어서
(왜? 내용도 광범위하고 이력서에 보여주기 식만 되지 않을까.. 하는 부정적인 마음에) 안해.. 하고 버텨볼까 하는 나쁜 마음이 들었는데, 3,4 주차의 이벤트 처리, 트러블 슈팅 관련해서 모놀로틱 서비스랑 비교해 볼 수 있는 시간일 것 같아 마음을 다잡고 공부를 시작했다
[MSA는 왜 핫할까 ?]
클라우드! 라는 개념을 공부해야 합니다.. 설명이라 여기는 존댓말로 쓸게요.
클라우드는 클라우드 서비스를 제공하는 곳(아마존.. 등등) 업체가 데이터 센터나 서버를 보유하고 관리, 이를 인터넷을 통해 사용자에게 제공하는 서비스를 말합니다.
옛날에는 서버 들고다니면서 환경 설정하고, 기획하는 단계에서 서버를 얼마나 쓸 것인지 고민을 했다면(고정 비용)
, 이제는 필요한 만큼만 사용하게 되고, 서비스가 커지면 늘리고, 적어지면 줄이는 식으로 가변비용이 되었지요!
하지만... 우리가 하고있던 서비스는 하나로 운영되던(모놀로틱) 서비스들이였습니다. 갑자기 가입자 수가 늘어서 서버를 늘리는 상황이 왔는데 상품과 주문까지도 늘려야 하는 상황... 그래서 서비스를 쪼개기 시작합니다.
그러면서 나온 설계 방식 중 하나가 MSA입니다.
클라우드는 필요에 따라 IT 자원을 확장하거나 축소할 수 있는 유연성을 제공하는데, 이는 MSA 측면에서도 너무 잘 맞죠. 사업 규모나 요구 사항에 맞게 자원을 조절할 수 있게 합니다. 또한 기업은 자체 데이터 센터를 구축하거나 유지하는 비용을 줄일 수 있습니다. 이는 가변 비용으로 변환되기 때문에 초기 투자 비용이 줄어들 수 있습니다 이는 .. 큰 기업에서는매우 좋은 선택지겠죠??.
클라우드를 시작으로 설명을 정리하다 보니, 비용적인 것만 설명한 것 같은데, 장애 상황에도 유연하게 대처할 수 있습니다.
일부 서비스에만 트래픽이 확장되는 경우 전체 시스템을 확장할 필요가 없는 경우가 종종 있습니다. MSA에서는 개별적으로 확장할 수 있기 때문에 트래픽이 많은 서비스만 확장하면 됩니다.
또한 마이크로서비스 아키텍처는 서비스 간의 결합도를 낮출 수 있습니다. 이는 서비스 간의 의존성을 최소화하고 부분적으로 서비스를 업데이트하거나 교체할 수 있는 유연성을 제공합니다. 또한, 각 서비스가 독립적으로 배포되기 때문에 장애가 발생해도 전체 시스템이 중단되지 않습니다.
[실제로 개발 하면서 드는 생각과 질문]
1. 이렇게 장점이 명확!! 한데.. 왜 많은 기업들이 바꾸려고 안할까 ?
엄청난 인적 자원과 수정이 들어간다는 점, 기업 입장에서도 큰 결심을 한다는 것, 특히 기존에 있던 데이터베이스를 분리하는 작업은 큰 작업이라고 생각합니다.. 안정성 보안 이슈들.. 기업이 기대되는 비용 절감보다 서비스 바꾸는데 더 큰 비용이 든다면(배보다 배꼽이 더 크다)굳이 바꿔야 할까요?
2. 독립적인 서비스라고 해서 완전 독립일 줄 알았는데, 생각보다 결합도가 높잖아?
api 통신을 위해 feign client(open feign, 넷플릭스), rest template 을 사용할 수 있는데,
요청을 빈번하게 보내는데, 그 서버에 문제가 생긴다면 ? 모놀로틱보다야 덜하겠지만, 그걸 안고 간다? 여전히 고려해야 할 상황이라고 생각합니다.
3. 비용 절감의 효과
엄청나게 큰 서비스가 아닌 이상 서비스를 한 개 이상(분리) 해서 돌리고 있으니... 비용이 더 나가는 것 같다
4. 객체지향 서비스와는 다른 관점
모놀로틱 서비스를 구현 했을 때 RDBMS 로 설계를 하다 보니, JPA의 특성에 맞게 1:many 등 관계를 설정하는 것에 초점을 두고 개발했다. 하지만 MSA 에서는 이런 관계를 다 끊어내고, id를 통해 다른 서비스에 요청을 보낸다.
그럼 RDBMS 사용하는 이유가 뭐지?
그리고 id 는 정말.. 유일성이 보장되는건가? 이런 꼬리 질문들이 생기기 시작했다.
그치.. MSA는 원래 목적이 서비스 간의 의존성을 최소화 하는거라.. 객체랑은 좀 거리가.. 지금가지 객체지향적으로 코딩을 하려고 했던 나 자신에게 현타가 좀 왔는데!
쪼개진 서비스 안에서 또 응집도와 결합도 생각해서 구현하면 되는거니까! 단지 데이터베이스 관점에서?? 설계적 관점에서 ?? 좀 덜 객체적이여졌다고 생각한다..
5. 그럼에도 불구하고 해보면서 느낀점
기술들이 엄청 발전했구나...
앞으로 3, 4 주차에 더 나아갸야 하겠지만 대용량 트래픽 처리하고 이벤트가 있을 때 어떻게 처리할 것인지,
그로 인해 monolothic 한 서비스와 MSA 서비스의 장점, 단점이 무엇인지 조금 더 확신을 가질 수 있을 것 같다
이번주는 분리작업 하면서 어렵기도 하고 이걸 왜... 이런 느낌이 많이 들었는데 앞으로의 과정을 위한 발판이라고 생각하니 매우 의미있는 주였다고 생각한다 호호
다음주도 뿌셔!
[그래서 이번주 뭐했지]
1. 주문 - 배송 로직이 미완성이라 목요일에 끝냈습니다
2. ~ 토요일 오전 : 도커 개념 및 명령어 학습(제공해주신 강의) , 슈도코드 작성해 보았습니다 (그 와중에.. 디비가... 날아가고....)
3. 토요일 오후 부터 개발 시작했고, 각 모듈을 도커로 띄우는 것 까지 성공했습니다
4. ~ 월요일 오후 로컬 환경에서 개발 중이며, 각 모듈을 띄우고 open feign 사용하여 통신에 성공하였습니다.
- 결과물
디비 구조(디비 분리)
포트 설정(서버 분리)
각 프로젝트 모듈화
80 포트로 회원 모듈 접속 api
81 포트로 상품 접속
주문 구현 중..
+) 로그인 처리 : 80 포트에서 user 정보 받음 -> feign client 요청으로 82 포트에 보내기
@SecurityRequirement, @AuthenticationPrincipal 어노테이션 사용, 80포트에서 넘어온 토큰 검증하여 회원 정보 받아올 수 있도록 함
화요일, 수요일 오전 까지 api 게이트웨이 만들고 모듈 분리하는 것이 목적입니다!