마이크로서비스 아키텍쳐(MicroService Architecture MSA)

장 점

• 소스 문법상 오류의 영향도가 줄어든다.
• 변경된 서비스만 배포하면 되기 때문에 빠른 배포가 가능하다.
• 변경되는 부분만 배포가 가능하기때문에 전체영향도가 적다. 
• 독립적으로 서비스를 운영되기때문에 장애가나더라도 전체에영향을 미치지않는다.
• 특정 서비스의 트래픽이 높을 경우, 전체를 스케일업이나 분산처리 할필요없이 해당 서비스만 스케일업, 분산처리가 가능하여 확정성이높다.

업무별로 서비스 나누어 관리되기 때문에 팀을나누어 관리가능하여 기동성이 높아짐

독립적으로 서비스가 분리되어 영향도가 없어, 개별 서비스 단위의 배포가 가능하기 때문에 하루에도 필요에 따라 여러 번 배포를 하는 것이 가능합니다.

 

단 점

기술이 나뉘면 관리가 어려워짐. 특히 특정기술을 쓰는 개발자가 퇴사하면 해당기술을 알고있는 대상이적어 이슈발생 시 대응이 어려워짐.

서버가 많이 나뉘어 관리가 어려움

서비스 간의 통신에 대한 처리가 추가적으로 필요하다는 점

 사용자의 요청을 처리하기 위한 응답속도의 증가에도 영향을 미칩니다. 

분산된 데이터베이스는 트랜잭션 관리가 용이하지 않기 때문에 데이터의 정합성을 맞추기 위한 노력이 추가적으로 필요합니다. 

대규모 서비스들은 보통 수백개 이상의 마이크로서비스로 이루어지는데 이렇게 많은 서비스들은 각각 서로 분산되어 있기 때문에 관리 포인트가 증가하고 통합해서 모니터링하고 운영하는 것이 모놀리틱 아키텍처에 비해 매우 어려워집니다. 이것은 필연적으로 매우 정교한 배포 자동화를 필요로 하며 많은 PaaS(Platform as a Service) 서비스, 또는 도커(Docker)와 같은 컨테이너 기술을 활용하여 도움을 받을 수 있습니다.

 

MSA 도입 기준

1. 애플리케이션의 배포에 한 시간 이상 소요된다.
2. 단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요하다.
3. 단순한 버그 수정이 더 중대한 버그를 생산하는 일이 많아졌다.
4. 현재의 애플리케이션을 기능별로 나눈다고 가정했을 때 수십개의 마이크로서비스가 가능하다.

예를 들어, 애플리케이션에서 사용자의 인증만을 담당하는 요소가 별도의 서비스로 구현되어 있다면 필요에 따라 성능과 안정성을 증가시킬 수 있는 새로운 프레임워크로 변경하는 것을 고려해볼 수 있습니다. 하지만 만약 전체 애플리케이션이 하나로 묶여 있다면 그 동안 개발된 방대한 양의 코드를 새로운 언어, 또는 프레임워크로 전환해야 하기 때문에 대부분 시도조차 할 수 없을 것 입니다.

 

참고자료

http://guruble.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4microservice-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EA%B7%B8%EA%B2%83%EC%9D%B4-%EB%AD%A3%EC%9D%B4-%EC%A4%91%ED%97%8C%EB%94%94/