[한이음] MSA 프로젝트 - (1)MSA가 무엇인가

이 프로젝트는 다음 블로그와 사이트를 참고 하여 작성하였습니다 https://wooaoe.tistory.com/57 ,이모티콘 서비스는 왜 MSA를 선택했나? – tech.kakao.com

 

한이음 프로젝트에서 MSA기반 프로젝트를 진행하게 되었다

사실 나는 자바도...개발해본 적 없는데 이번 프로젝트라 자바신이 되어봐야겠음

4월부터 시작된 프로젝트이지만 그래서 스프링 부트 공부하면서..기본부터 갈고 닦다가.. 드디어 MSA를 알아볼 미세한 지식이 쌓여 시험 공부를 하기 싫어 이러쿵 저러쿵 MSA 포스팅 시작한다!!!

일단 MSA가 무엇인지에 대해 배워보는 포스팅으로 하겠다.

 

MSA?

MicroService Architecture 의 준말

독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크이다,마이크로 서비스는 완전히 독립적으로 배포가 가능하고 다른 기술 스택을 사용 가능해진다

그러면 기존의 서비스는?

 

Monolithic Architecture

Monolithic Architecture : 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다.

각각 개발된 모듈을 하나의 결과물로 패키징하여 배포되는 형태

웹의 경우 WAR 파일로 빌드되어 WAS에 배포되는 형태

그런데 이 서비스는 문제가 많다.

• 부분 장애가 전체 서비스의 장애
• 부분적인 scale-out이 어려움 (여러 server로 나누어 일을 처리하는 방식)이어렵다
• 서비스의 변경이 어렵고, 수정 시 장애의 영향도 파악이 힘들다 : 여러 컴포넌트가 하나의 서비스에 결합
• 배포시간이 오래걸린다.
• 한 framework와 언어에 종속적이다

 

MSA의 특징
MSA는 API를 통해서만 상호작용 할 수 있다.
마이크로 서비스는 서비스의 end-point(접근점)을 API형태로 외부에 노출하고, 실질적인 세부사항은 모두 추상화한다.
내부의 구현 로직,아키텍처와 프로그래밍 언어 데이터베이스 등등 다 API에 의해 철저히 가려지게 된다.SOA원칙을 지키게 된다.

 

 

MSA 장점

• 업무 역할 분담이 명확해졌다

물리적으로 서비스가 각자 분리되고 코드 영역이 분리되어 본인이 확인하고 담당해야 할 영역이 명확해짐.

• 배포의 부담이 많이 낮아졌다

배포 시 다른 서비스 로직의 코드가 섞여 들어갈 위험성도 작아지고 장애 시 롤백이나 재배포도 편해짐.

• 신규 서비스 기능 추가가 쉽다

신규 서비스는 물론 기존 코드 수정하는 것 역시 앞서 이야기한 것처럼 단위가 명확하고 작아져 수월하다.

 

 

MSA 단점

• 설계 제약 사항과 고민들이 늘어난다

우선 설계 시 고려해야 할 사항이 늘어난다는 것입니다. 함수 호출이 아닌 IO 연결로 인해 이전에는 고민하지 않았던 서비스 간의 네트워크 에러와 이로 인해 발생하는 트랜잭션 이슈, 서비스 간 상태 동기화 등이 있고, 설계 시 DB 가 분리되는 것을 고려해서 서비스를 만들어야 한다는 점 등입니다.

• 개인이 담당할 서비스가 늘어난다

처음 설계 시 우려했던 것처럼 물리적으로 서비스가 늘어나기 때문에 담당 범위가 늘어납니다.서비스를 365일 24시간 운영도 해야 하지만 우리는 인간인지라 쉬기도 해야 하기 때문에 각 서비스 별로 백업 멤버도 있어야 유연한 근무환경을 유지할 수 있습니다. 너무 많은 분리는 인력 충원 없이는 한계가 올 수 있습니다.

• 서비스가 도메인 지식 공유가 힘들다

백업 멤버 없이 해당 서비스의 도메인 지식이 제대로 공유가 안되거나, 서비스간 기술 스택의 간극이 너무 벌어지면 담당자가 업무 고립이 되어 독박 타임을 맞이할 수 있습니다. 팀 구성원들이 번아웃에 너무 쉽게 빠지지 않게 하기 위해서는 서비스 분할 시 이 부분을 꼭 고민을 해야 할 것입니다.

• 완공을 위해 남은 작업들

완공을 위해 남은 작업들은 아직 다 쪼개지 못한 서비스를 쪼개는 작업, 네트워크로 분리되었기 때문에 잃어버린 성능을 보상할 수 있는 방법, 그리고 보다 더 효율적인 리소스를 활용하기 위해 비동기 방식의 도입 등입니다.