본문 바로가기

카테고리 없음

마이크로 서비스 아키텍처(MSA : Micro Service Architectures)

Microservice, 마이크로서비스, Cloud, MSA, Architectures, 아키텍처, Monolithic, 클라우드 :Today keys.

 

이번 포스팅은 마이크로 서비스에 대한 포스팅입니다.

'안' 개발자로서, 이런저런 자료를 찾아보며 정리해 보았습니다.

새로운 내용들을 보다보면, 역시나 IT 분야내에서는 이런 저런 다양하게 알아야 할 것들이 많다는 것을 느끼게 됩니다.

아마도 이번달까지는 관련 내용을 정리해서, 좀 더 포스팅을 하게되지 않을까 싶습니다. (혹은... 정리만.. 포스팅은 다음달?..)

 


 

 

마이크로 서비스 아키텍처(MSA : Micro Service Architectures)

 

 

 

 

 

마이크로 서비스 아키텍처란?

   ▪ 독립적이고 단순한 개별 서비스들로 전체의 서비스를 구성

   ▪ 단일 Application을 나누어서 작은 서비스들의 조합으로 구성

   ▪ 기존의 Monolithic Architecture에 대비되는 개념

   ▪ 2012년 ThoughtWorks의 James Lewis가 Java the Unix way라는 제목의 발표에서 언급.

     2014년 3월 James Lewis와 Martin Flowler가 Microservices 라는 타이틀로 패러다임을 정립한 기사 발표

 

마이크로 서비스 아키텍처의 배경

   ▪ Cloud 서비스 환경에서의 기존의 Monolithic Architectures 적용의 어려움

        - Monolithic Architectures에서는 코드의 크기가 크기 때문에 배포에 대한 부담

        - 서비스 변화의 속도에 따른 배포 주기가 짧아지는 것에 대한 부담

   ▪ 갈수록 복잡해지는 비즈니스에 따른 거대한 서비스 생성

   ▪ OpenSource와 Internet 등으로 인해 짧아지는 기술 수명 주기

   ▪ 서비스 연계성으로 인한 문제

       - 일부 서비스 부분에 변경 시에도 연계 시스템에 대한 Re-Build 필요

 

 

Micro Service Architectures vs Monolithic Architecture

 

 

 

 

마이크로 서비스 아키텍처 구성 방식

   ▪ 마이크로 서비스 간에는 HTTP 기반 API 등을 통해서 통신.

 

 

 

   ▪ 각 서비스는 개별 서비스로 동작하기 때문에 서로 다른 독립적인 언어로 개발 가능. (Polyglot Programming)

 

   ▪ 서비스가 복잡할 경우에는 서비스 간의 연결을 직접 구성하게 될 경우에 복잡도가 증가하므로, 중간에 API를 관리하는 서비스 오케스트레이션 계층으로서의 API Gateway를 구성 가능.

 

 

 

마이크로 서비스 아키텍처의 특징

   ▪ Decoupled : 서비스 간의 종속성 배제

   ▪ Well Defined Interface : 서비스 간의 통신을 위해서 잘 정의된 API 필요

   ▪ Independent : 각 서비스 별로 독립적으로 개발 및 운영할 수 있음

   ▪ Conway's Law 적용 :  "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." / 결국 서비스의 구성 디자인은 그 서비스를 구현하는 조직의 모습에 기반한다.

 

 

 

 

마이크로 서비스 아키텍처의 장점/단점

   ▪  장점

         - 서비스에 대한 확장성이 좋고, 개발 및 배포 사이클 관리 용이

         - 각 서비스 파트에서 제공하는 서비스에 최적하는 방법/언어 사용 가능(Polyglot Programming)

         - 작은 서비스로 구성되기 때문에 서비스에 대한 민첩성 확보.

         - 타 컴포넌트와의 종속성이 배제되어 서비스 변경이 쉬움

        

  ▪  단점

         - 서비스 간의 연계성 및 다양한 기술 사용으로 인한 운영 및 테스트 복잡도 증가

         - 서비스 간의 외부 호출로 인한 성능 비용 증가(Latency)

         - 설계 시의 고려해야 할 사항이 많아짐

         - 서비스의 세분화됨에 따라, 서비스 간의 코디네이션(Chief Architect)이 필요.

         - 배포와 운영에 자동화를 사용하지 않으면, 오히려 기존 방식보다 더 어려움(개별 서비스이기 때문에 수량이 많아짐)

 

 

마이크로서비스 설계시 고려사항들

    ▪ 각 개별 서비스에 대한 기능 적합성 및 성능에 대한 효율성

    ▪ 서비스 간의 호환성

    ▪ 각 서비스에 대한 신뢰성 및 서비스 간의 통신 시의 보안

    ▪ 개별 서비스에 대한 유지보수성 및 이식성