본문 바로가기

좀 거창한 주제이긴 하다. MSA 구조로 바꾸기 위한 6가지 원칙?

https://microservices.io/post/refactoring/2020/07/28/six-principles-for-refactoring-to-microservices.html

 

Decompose your monolith - Six principles for refactoring a monolith to microservices

Virtual bootcamp: Distributed data patterns in a microservice architecture My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment! It covers the key distributed data management patterns including Saga, API

microservices.io

쓰고 싶은 글 형태는 아래 글이지만

모놀리스 애플리케이션을 MSA(마이크로서비스)로 마이그레이션 하는 방법 

 

모놀리스 애플리케이션을 MSA(마이크로서비스)로 마이그레이션 하는 방법 - Giljae Joo (주길재)

이쪽 업종에서 일하는 분들이라면 Monolith으로 구현되어 있는 레거시 시스템을 마이크로서비스로 마이그레이션 하고자 하는 Needs가 있을 것이다. 비즈니스를 분석해서 새롭게 만드는 것이 가장

giljae.com

이 글은 그냥 내가 원하는 토픽만 정리해 보자.

일단, 한번에 다 하는 것보다 일단 모듈화 작업을 수행하고 하나씩 MSA로 분리해 낸다. 아래 그림 참고

모듈 to 서비스

관련되서 어디선가 긁어온 말 

한 덩어리의 모노리스 서비스를 부분적으로 서서히 마이크로서비스로 전환하는 것을 스트랭글러 패턴(Strangler pattern)이라고 합니다

쪼개다 보면 이렇게 많이 쓰는데 피하라고 하네

api coupling

커플링을 피해서 설계해라, 주문을 넣었는데 다른 서비스의 유용성과 연계되어 있으면 주문 MSA 입장에서 유용성이 의존적으로 결국 낮아지는 결과를 초래하니깐, 단일 API는 단일 처리를 기본으로 왠만하면 남들하고 엮이지 마라

이런 뜻이네

loose couple 이라는 단어도 많이 나오고 MSA 찾아보면

 

원본 자료는 여기

 

MSA 마이크로 서비스 아키텍처 설계서 참고자료

마이크로 서비스 아키텍처를 사용하면 개발자가 서비스를 독립적으로 개발하고 배포할 수 있어, 유지 관리가 쉽고 확장성이 높아집니다. 또한 각 서비스가 독립적으로 배포되므로, 특정 서비스에 문제가 발생하더라도 전체 시스템에 영향을 미치는 범위를 최소화할 수 있습니다.

 

마이크로 서비스 아키텍처 설계서는 다음과 같은 내용을 포함해야 합니다:
1. 서비스 분해: 각 마이크로 서비스가 어떤 역할을 하는지, 그리고 이들이 어떻게 서로 통신하는지를 명확하게 설명해야 합니다. 이 과정에서 각 서비스의 입력, 출력, 에러 핸들링 메커니즘 등을 포함하는 API 문서가 필요할 수 있습니다.
2. 데이터 관리: 마이크로 서비스는 각각 독립적인 데이터베이스를 가질 수 있으므로, 데이터가 어떻게 관리되고 저장되는지에 대한 정보가 필요합니다.
3. 보안 및 인증: 서비스간 통신에서의 보안이나, 서비스가 외부에서 어떻게 접근 가능한지 등에 대한 정보가 필요합니다.
4. 배포 및 확장: 각 서비스는 독립적으로 배포되고 확장될 수 있으므로, 이에 대한 전략과 절차를 명시해야 합니다.
5. 서비스 간의 통신: 마이크로 서비스가 서로 어떻게 통신하는지에 대한 정의와 규칙이 필요합니다. 이는 일반적으로 HTTP/REST 또는 비동기 메시징을 사용하여 구현됩니다.
6. 오류 처리와 복구: 마이크로 서비스에서 오류가 발생했을 때 어떻게 대처하고 복구할지에 대한 전략이 필요합니다.
각 설계 요소를 정의하고 문서화하는 것은 시스템의 유지 관리와 확장성에 큰 도움이 됩니다. 

 

또한 아래와 같은 추가적인 고려사항들이 설계서에 포함될 수 있습니다:
7. 서비스 디스커버리: 서비스가 동적으로 위치를 찾고 통신할 수 있는 메커니즘을 갖추는 것이 중요합니다. 이는 일반적으로 서비스 디스커버리 플랫폼이나 API 게이트웨이를 통해 해결됩니다.
8. 로깅, 모니터링, 트레이싱: 복잡한 마이크로서비스 환경에서는 각 서비스의 로그를 집중적으로 관리하고, 시스템 전체의 성능을 모니터링하며, 문제가 발생했을 때 그 원인을 추적할 수 있는 메커니즘을 갖추는 것이 중요합니다.
9. 리저버시 패턴과 서킷 브레이커: 분산 네트워크 환경에서는 장애가 발생할 확률이 높으므로, 이를 방지하거나 최소화하기 위한 전략이 필요합니다. 리저버시 패턴(Resiliency pattern)과 서킷 브레이커(Circuit Breaker) 같은 기술들이 이러한 문제를 해결하는 데 도움이 될 수 있습니다.
10. 테스트 전략: 마이크로서비스는 복잡한 시스템을 구성하므로, 각 서비스를 개별적으로 테스트하고, 이들이 함께 작동할 때도 잘 동작하는지 확인하기 위한 테스트 전략이 필요합니다.

 

이러한 내용들을 고려하여 마이크로서비스 아키텍처 설계서를 작성하면, 시스템의 전반적인 이해도를 높이고, 개발, 운영, 유지보수를 효과적으로 수행할 수 있습니다.

 

참고 페이지

https://www.samsungsds.com/kr/insights/msa_and_netflix.html

 

넷플릭스로 알아보는 MSA | 인사이트리포트 | 삼성SDS

 

www.samsungsds.com

MSA에서 중요한 요소 중 하나는 자동 확장(Auto Scale-out)입니다. ... MSA 전환을 위한 기술들을 도입하여 무려 7년에 걸쳐 클라우드 환경으로 이전하였습니다. 이 과정에서 넷플릭스가 경험한 노하우와 문제해결 방법을 공유하기 위해 MSA 전환 기술을 오픈소스로 공개했습니다.

마이크로서비스와 모놀리식 아키텍처 비교

 

마이크로서비스와 모놀리식 아키텍처 비교 | Atlassian

모놀리식 애플리케이션은 하나의 통합된 유닛인 반면, 마이크로서비스 아키텍처는 독립적으로 배포할 수 있는 소규모 서비스의 모음입니다.

www.atlassian.com

모놀리스가 너무 커졌다면 마이크로서비스로 전환해야 할 시기일 수 있습니다

 

일단은 모놀리식 한계 분석 자료

https://www.msaschool.io/operation/analysis/analysis-three/

 

B로그0간

개발 관련 글과 유용한 정보를 공유하는 공간입니다.