MSA를 하는 이유

안녕하세요. yeTi입니다.
오늘은 1년간 MSA 적용기 에 이어서 MSA 를 하는 이유에 대한 생각을 공유해보고자 합니다.

MSA의 시작

저는 2018년 AI플랫폼 이라는 것을 만들기 위한 연구소에 입사를 하게 됐고 이 때부터 제안서에 써져있는 MSA 라는 개념을 적용하기 위해 시작했습니다.

MSA 는 어떻게 하는거지?

다짜고짜 MSA 를 하려니 뭐하나 명확한것이 없었습니다.

왜 MSA를 해야되는지부터 단위 서비스의 규모는 어느 정도 여야하는지, 나누는 기준은 무엇인지, 팀의 규모는 어느 정도여야 하는지, 우리 팀의 규모는 3명인데 개발은 어떻게 해야하는지, ...

스스로 정확히 정의를 하지 못하니 대외적으로 명확한 확신에 의한 설명이 불가능 했습니다.

MSA 왜 해요?

개발활동의 목적은 저비용(돈, 시간)으로 고품질의 제품을 만드는 활동입니다.

그러한 관점에서 MSA는 개발 시간, 서버 비용, 인력 비용의 증가와 개발 난이도 증가에 따른 품질 저하를 가지는 구조입니다.

그렇다면 왜 많은 기업들은 비효율적인 MSA를 지향할까요?

저는 현재 업무를 진행하는 서비스에서도 MSA를 기반으로 개발이 되었습니다.

그러면서 이후 합류한 시니어 분들께 가장 많이 들었던 질문은 왜 MSA 를 해요? 였지만, 역시 명확히 대답을 할 수는 없었습니다.

왜냐하면 스스로도 MSA를 왜 해야하는지에 대한 명확한 답을 가지고 있지 않았기 때문입니다.

MSA의 목적

하지만!!
근래에 MSA의 목적에 대해 정의할 수 있는 키워드를 찾았습니다.

Loosely-coupled

저는 조직의 역할과 책임에 대한 Loosely-coupled 를 달성하는 것을 MSA 라고 정의했습니다.

생각을 정리할 수 있었던 컨텐츠들

안영회 대표님의 컨텐츠

• MSA는 조직의 성장과 동반해야 한다
• MSA를 대하는 개발자의 필수 마음자세
• Loosely-coupled 그리고 스프링 프레임워크

장재휴님의 컨텐츠

• Microservice in PangPang
• 일하지 않는 사람은 가라

Loosely-coupled

Loosely-coupled 에 대한 정의를 위키피디아에서 다음과 같이 찾아볼 수 있습니다.

1. in which components are weakly associated (have breakable relationships) with each other, and thus changes in one component least affect existence or performance of another component.
2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services.[1] Loose coupling is the opposite of tight coupling.

여기서 have breakable relationships 을 보고 연관된 생각을 링크드인에 기록 했었습니다.

Loosely-coupled 를 달성하는 방향으로 진화

Loosely-coupled 라는 단어에 대한 생각의 확장을 경험했는데요.

기존에는 OOP 에서 말하는 클래스간 의존성을 줄인다는 틀에서 벗어나, 프로그래밍 진화의 방향성이 역할을 Loosely-coupled 하는 방향으로 진화하고 있다는 생각이 들었습니다.

절차 지향 에서 함수 지향 으로 전환했을 때는 함수 단위로 역할을 부여하여 코드의 응집도를 높이고자 했고

함수 지향 에서 객체 지향 으로 전환했을 때는 클래스 수준으로 역할을 부여하도록 확장했고

객체 지향 에서 DDD(Domain Driven Development) 로는 업무의 경계 수준으로 역할을 부여하도록 확장했습니다.

같은 맥락에서 MSA 는 조직수준에서 업무의 역할과 책임을 부여하도록 확장했다는 생각이 들었습니다.

현업에서 MSA를 적용한 것에 대한 평가

앞서 MSA를 조직간 역할과 책임에 따라 Loosely-coupled 를 달성하기 위한 것이라고 정의했는데요.

그런 측면에서 현업의 상황을 대입해봤을 때 MSA 의 구조가 부적합했다고 평가하고 싶습니다.

왜냐하면 현업에서의 팀의 구조는 단일 팀기반이고 업무의 의사결정 구조도 단일 팀에서 하나의 스프린트에 한번만 배포하는 구조를 가지기 때문에 MSA가 지향하는 조직별 유연한 의사결정 구조를 가져갈 수 없기 때문입니다.

MSA의 기술적 관점

많은 분들이 MSA의 기술적 관점 을 쉽게 접하게 되고 기술을 적용하면 MSA를 달성하는 것으로 생각하게 됩니다.

12 factors, Netflix OSS, Modern Architecture, ...

하지만 조직의 동반과 별게로 MSA를 도입한다면 득보다 실이 많을 것입니다.

MSA의 부수적인 장점

결국 흔히들 얘기하는 MSA의 장점 은 분산된 조직에 의해 얻어지는 부수적인 것 들로 표현하고 싶습니다.

• 트래픽분산의 유연함
• 트래픽분산의 효율증가
• 배포 편의성 증가
• 개발 편의성, 유지보수 편의성
• 원하는 기술스택의 실험
• 장애 전파 최소화

기타 생각들...

도메인별 배포가 가능하기 때문에 서비스 전체의 다운타임을 줄일 수 있다.

아마존은 한 팀이 기지는 책임이 백엔드 개발에만 국한되지 않고 프론트엔드의 컴포넌트까지 가져가기 때문에 특정 도메인의 고도화만 자연스럽게 진행할 수 있다.

비용 측면에서 개발공수는 더 들어가지만 인프라 비용은 배포 비용이나 확장시에는 특정 도메인을 대상으로만 진행할 수 있기 때문에 절약할 수 있다???

결론

MSA를 적용했거나 적용하고 있는 회사들은 조직간 의존성을 약하게하며 진행하고 있는지 궁금합니다.

만일 그렇지 않다면 조직의 경계나 의사결정 구조에 맞는 수준으로 micro service의 경계 를 가져가는 것이 좋지 않을까 생각합니다.

지금까지 MSA 에 대한 개인적인 생각이었습니다.