프로필사진
DevOps 부트캠프 기록일지
DevOps_04_김재환
2023.05.03(아키텍처의 변화)
2023.05.03(아키텍처의 변화)

2023. 5. 3. 11:53부트캠프/DevOps (TIL)

[ 표 1 ] A Microservices Maturity Model, from “Spring 5.0 Microservices,” 2nd Edition”by Rajesh R V (O’Reilly)

아키텍처의 변화는 위의 표와 같습니다.

 

  • 항상 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아닙니다.

 

마이크로서비스 아키텍처는 서비스 지향 아키텍처(SOA)의 일종으로, 서비스 단위로 애플리케이션을 분해하여 개발, 배포, 확장 및 유지보수를 용이하게 하는 아키텍처입니다. 하지만 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아닙니다.

예를 들어, 단순한 웹 사이트나 애플리케이션의 경우, 마이크로서비스 아키텍처를 도입하기에는 비용과 시간이 부담스러울 수 있습니다. 또한, 서비스 간의 통신과 데이터 일관성을 유지하는 것이 복잡해지는 경우도 있습니다. 따라서 작은 규모의 애플리케이션의 경우에는 모노리틱(monolithic) 아키텍처를 사용하는 것이 더 적합할 수 있습니다.

또한, 기존에 개발된 레거시 시스템의 경우에는 마이크로서비스 아키텍처를 도입하기 어려울 수 있습니다. 레거시 시스템의 경우, 모노리틱 아키텍처와는 달리 강한 의존성이 존재할 수 있으며, 이를 분해하고 서비스 단위로 구성하는 것이 어려울 수 있습니다.

따라서 마이크로서비스 아키텍처를 도입하기 전에는 기존 시스템의 규모, 복잡성, 의존성 등을 고려하여 적절한 아키텍처를 선택하는 것이 중요합니다. 마이크로서비스 아키텍처가 필요한 경우에는 서비스 단위로 애플리케이션을 분해하는 것이 유리하며, 그렇지 않은 경우에는 모노리틱 아키텍처를 유지하는 것이 더 나은 선택일 수 있습니다.

 

  • 성숙도 모델 중 어떠한 방식을 Level 3단계로 전환한다고 해서 더 나은 서비스가 되는 것은 아닙니다.

기술적인 발전이 항상 더 나은 서비스를 제공하는 것은 아닙니다.

서비스의 품질과 성숙도는 기술적인 발전보다 사용자 중심의 디자인, 효과적인 사용자 경험, 그리고 적절한 사용자 지원 등과 같은 다른 요인들에 크게 영향을 받기 때문입니다.

예를 들어, 최신 기술을 도입해도 사용자가 원하는 기능을 충족하지 못한다면 그 기술이 서비스에 추가적인 가치를 제공하지 못할 수 있습니다. 또한, 사용자가 서비스를 사용하는 동안 기술적인 문제로 인해 불편을 겪는다면 이는 기술적인 발전이 사용자의 만족도를 개선하지 못하고 오히려 악영향을 미칠 수 있습니다.

따라서, 성숙도 모델에서는 단순히 기술적인 발전을 따라가는 것이 아니라, 사용자와의 상호작용에서 사용자 중심적인 디자인과 개발을 추구해야 합니다.

 

  • 무작정 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입해야 합니다.

 

  • 각 단계에 있어서 해당 방식이 갖는 장단점

1. 모놀리식 아키텍처

  • 단일 어플리케이션으로 구성되어 있는 전통적인 방식
  • 장점: 간단하고 개발이 쉽고 테스트도 용이하며, 배포 및 관리가 편리
  • 단점: 시스템이 커지면 유지보수와 확장이 어렵고, 다운 타임이 발생할 가능성이 높음

2. 서비스 지향 통합 아키텍처

  • 분산된 서비스들을 통합하기 위해 EAI(Enterprise Application Integration) 기술을 사용한 방식
  • 장점: 서비스들의 독립적인 확장이 용이하며, 각 서비스간 결합도가 낮아지고, 중복을 방지할 수 있음
  • 단점: 서비스의 개수가 증가하면 통합 비용이 높아짐, 서비스간 통신 오버헤드가 발생할 수 있음

3. 서비스 지향 애플리케이션 아키텍처

  • 서비스를 기반으로 분산된 애플리케이션을 구축하는 방식
  • 장점: 모놀리식에서 발생하는 문제점을 해결할 수 있으며, 높은 유연성, 확장성, 가용성을 제공
  • 단점: 복잡한 통신과 분산 환경에서 발생할 수 있는 일관성 문제를 처리해야 함

4. API 중심 아키텍처

  • 다양한 서비스들을 연결하기 위해 API(Application Programming Interface)를 이용하는 방식
  • 장점: 서비스의 독립적인 배포와 유지보수가 가능하며, 다양한 클라이언트 애플리케이션과 통합이 용이함
  • 단점: API의 변경에 따라 클라이언트 애플리케이션의 호환성 문제가 발생할 수 있음

 

  • 기존(Legacy) 시스템의 작동 방식

마이크로서비스 아키텍처를 도입하기 전에 기존 시스템의 작동 방식을 충분히 이해해야 합니다. 기존 시스템의 문제점을 파악하고, 마이크로서비스 아키텍처가 이를 해결할 수 있는지를 검토해야 합니다. 

 

 

  • 현재 시점의 요구사항

마이크로서비스 아키텍처를 도입하기 전에 현재 시점의 요구사항을 충분히 파악해야 합니다. 시스템의 성능, 확장성, 유연성, 보안 등에 대한 요구사항을 분석하고, 마이크로서비스 아키텍처가 이를 충족시킬 수 있는지를 평가해야 합니다.

 

 

 

 

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/why-use-microservices#microservices-architecture-patterns

https://www.ibm.com/cloud/learn/microservices

https://dzone.com/articles/service-oriented-integration-architecture-a-technical-overview

https://tacademy.skplanet.com/live/player/onlineLectureDetail.action?seq=180

https://dzone.com/articles/maturity-models-why-level-3-is-not-the-goal