왜 우리는 지금 MSA구조로 변경해야하는가?

InnomDB·2022년 5월 26일
16

why msa?

제목과 마찬가지로 우리는 왜? MSA를 써야할까?

최근 회사에서 서비스를 MSA 구조로 바꾼다는 말을 듣고 급하게 MSA 공부를 시작을 했다.
구글링해서 기술적인 부분을 알려주는 레퍼런스들은 많고 많다. 그 중에는 기술에 대해서만 기술하는 블로그가 있고, 왜 우리는 MSA로 구조를 변경해야 했는가에 대해서 기술한 블로그들이 있었다. 후자의 블로그들이 나의 흥미를 더 끌리게해 읽는 즐거움이 생겨 나도 왜 우리는 MSA로 구조를 변경해야 하는가를 써보려고 한다.

하지만, 많은 시간 고민해본 결과 이유를 모르겠어서 사수한테 이유를 물어봐서 글을 쓴다. (기억이 가물가물해 기억나는 부분만 적어보겠다...)

사수왈

코드를 보시면 아시겠지만 우리 서비스는 현재 모놀리식 구조라 DB가 1개로 이루어져 있어 각 서비스별로 해당하지 않는 Table까지 가지고 가게 돼서 강한 결합으로 이루어져있기 때문에 서비스별 DB를 분리해 강한 결합을 떼어낼 필요가 있다고 생각하기 때문에 MSA 구조로 변경할 것이다

요약하면, 유비무환이다.

허나, 위에서 적어놓았던 후자의 블로그들에는 꼭 MSA 구조가 필요하지 않다면 적용하지 않아도 된다. MSA는 그냥 하나의 기술 패턴일 뿐이다. 라고 써있다. 우리의 서비스가 지금 당장 MSA를 적용하지 않으면 큰일나는 정도는 아니라고 판단된다. 허나, 내가 잘못 판단한것일 수도 있으니 신입 개발자인 나의 생각이 어떻게 바뀌는지 MSA 구조로 변경하면서 느끼는 점들을 계속해서 기술해보겠다!!

이대로 블로그를 끝내면 아쉬우니까 MSA에 대해서 가볍게 알아보자!!

MSA 넌 대체 뭐니?

MSA(Mola Sipa Angry) 몰라 시파 화남의 약자이다.

는 장난이고 Mirco Service Architecture의 약자이다.

흔히들 MSA하면 겁을 먹는다. 그래서 나도 겁을 먹었다. 그래서 블로그는 여기까지이다.

는 장난이고 MSA에 대해서 우리 저명하신 마틴 파울러 형님은 이렇게 말씀했다.

MSA에 대한 공식적인 정의가 있다고 말할 수는 없습니다. 하지만 레이블에 맞는 아키텍처의 공통 특성으로 보이는 것을 설명하려고 시도할 수는 있습니다

아주아주 저명하신 형님이 말씀하신거니 신뢰할 수 있다.
사실 이 블로그 100번 읽는거보다 파울러 형님 말씀 한번 읽는게 더 도움된다. 구글 번역기를 써서 그런가.. 잘 안읽혀서 진짜 쉽고 도움 하나도 안되게 설명해보려고 한다.

모놀리식하고 어떻게 다른데?

위의 사진에서 모놀리식을 보면 대부분 이제 막 개발을 시작했거나 신입 개발자로 취업을 했거나 하는 사람들은 왼쪽의 모놀리식 아키텍처에 매우 익숙할 것이다. 물론 나도 그렇다. 그럼에도 불구하고 나의 생각을 말하자면 핵심은 DB를 나누는 것이라고 생각한다.
각 서비스별로 DB를 나누었기 때문에 서비스들이 의존성 없이 돌아가고 배포에서도 자유로워 진다고 생각하기 때문이다. 근데 아직 나도 구현 안해봤기 때문에 의존성 제로가 가능할지는 모르겠다.. 아마 불가능하지 않을까 싶다. 그냥 의존성 최소화느낌으로 알아두자.

우리 파울러 형님의 말씀으로 정리하자면 small services, each running in its own process(스스로 돌아 갈 수 있는 작은 서비스) 와, independently deployable(독립적 배포 가능) 이 MicroService라고 생각한다.

마지막으로 장단점 정도는 알아보고 끝내겠다.

MSA 장단점

MSA의 장점

우선 MSA의 장점에 대해 알아보도록 하겠습니다. MSA는 서비스가 커지면서 생겼던 Monolithic Architecture의 문제점들을 어느정도 보완해 줄 수 있습니다.

배포(deployment) 관점

  • 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)

요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
확장(scaling) 관점

  • 특정 서비스에 대한 확장성이 용이함.
    • 클라우드 사용에 적합한 아키텍쳐.

장애(failure) 관점

  • 장애가 전체 서비스로 확장될 가능성이 적음
    • 부분적 장애에 대한 격리가 수월함

이외에도, 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다는 장점이 있습니다.

polygolt아세요? 모르시죠? 그래서 제가 찾아봤습니다.
특정 서비스를 구축하는 데 사용하는 언어나 저장소를 자율적으로 선택할 수 있는 방식'을 폴리글랏(Polyglot)하다라고 쓴다고 하네요.

또, 글만 있으면 이해 안될수도 있잖아요? 그림도 같이 준비했습니다.

Wow~ 놀랍게도 각 서비스마다 사용하는 DB와 언어가 다 다릅니다!! 이럴때 바로 말하세요!!
오~ 폴리글랏하게 잘 짰네 상대방이 오 이녀석 MSA좀 아는 녀석인가? 놀랄껍니다.
마지막으로 그림보고 혹시나 오해하실까봐 말씀드리는데 꼭 폴리글랏하게 짜야 MSA아닙니다. 아셧죠?
이 그림보고 막 써보지도 않은 DB막 쓰면서 난 폴리글랏하게 아주 멋있게 MSA를 해야겠어 하실필요는 없습니다. 저는 아마 Mysql / DaynamoDB / Redis 요렇게만 쓰면서 개발할거 같아요~~ 폴리글랏하쥬?

말이 길었네요 단점 알아보겠습니다..

MSA의 단점

Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다.

  • 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됩니다.
  • 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 합니다.
  • 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵습니다.

다음 파트에서는 그래서 MSA 어떻게 개발해야되는데?의 파트로 본격 MSA의 장점과 단점이 어떻게 해서 이루어 지는지 기술적으로 알아보겠다!!

MSA장단점을 너무 잘 적어놓아 따로 설명할 필요가 없이 퍼왔다. 그래서 출저를 남긴다. 이 블로그도 엄청나게 정리 잘 되어 있으니 꼭 들어가서 보기를 바란다.

profile
이노오오옴

1개의 댓글

comment-user-thumbnail
2022년 5월 26일

ㅋㅋㅋㅋㅋㅋ 글을 너무 웃기게 써주시네요 ㅋㅋㅋㅋㅋ 웃으면서 공부했습니다 유익한 자료 감사합니다 다음 자료도 기대되네요!!

답글 달기