Micro service architecture - (1/3)
이번 포스팅에서 설명할 내용은 요즘에 많이 유행하고 있는 Micro service architecture(MSA)에 관한 내용입니다. It-chain에서 채택한 아키텍처 스타일로 it-chain-Engine이 MSA를 기반으로 개발되어 지고 있습니다. MSA에 대해서 설명하고 MSA와 같이 사용되는 패턴들에 대해 소개 및 it-chain에 어떻게 적용되어있는지를 설명하는 포스팅을 추가 하겠습니다.
MSA란?
마이크로 서비스 아키텍처 스타일은 단일 응용 프로그램을 작은 서비스의 모음으로 개발하는 접근 방식입니다. 각 작은 서비스들은 자체적으로 실행가능하고 경량 메커니즘 (종종 HTTP 리소스 API)으로 서로와 통신합니다. 이러한 서비스들은 비즈니스 역량을 기반으로 구축되며 독립적으로 배포 될 수 있습니다. 서로 다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수있기 때문에 이 서비스들의 중앙 집중식 관리는 거의 필요하지 않습니다. -Martin fowler
왜 MSA가 필요한가?
기존의 단일 응용프로그램 스타일(Monolithic style)로 시스템을 개발하는 것은 아주 자연스러운 방법입니다. 단일 프로그램으로 개발할 경우 로컬환경에서 개발하기도 쉬우며 테스트 및 배포 또한 매우 간편해집니다. 하지만 응용 프로그램의 작은 부분에 대한 변경에도 전체 프로그램을 다시 빌드하여 배포해야기 때문에 배포 시간이 많이 걸립니다. 게다가 시간이 지남에 따라 코드가 점점 복잡해지기 때문에, 모듈 구조를 문제 없이 유지하는 것이 점점 어려워지는 문제가 발생합니다. 어플리케이션을 구성하는 프로그래밍 언어, 또는 프레임워크의 변경이 불가능한 점도 문제입니다.
Mirco service architecture Style을 사용하면 하나의 큰 단일 응용프로그램을 독립적인 기능을 수행하는 작은 단위의 서비스로 분리하기 때문에, 독립적으로 배치 가능하고 확장 가능할 뿐만 아니라 서로 다른 프로그래밍 언어로 개발될 수 있습니다. 각 서비스는 그것을 만든 팀들이 직접 관리합니다.
MSA의 특징
-
서비스를 통한 컴포넌트화
마이크로 서비스 아키텍처에서는 각 컴포넌트를 서비스라는 개념으로 정의합니다. 서비스는 비지니스 로직 뿐만 아니라 데이터베이스까지 독립적으로 개발하고 컴포넌트간의 상호 의존성이 없다. Rest API같은 인터페이스를 제공하여 기능을 외부로 제공합니다.
-
비지니스 수행에 따른 구성
큰 응용 프로그램을 분할하는 경우 일반적으로 기술적 계층을 기반으로 UI팀, 비지니스 로직팀, 데이터베이스팀으로 나누게 됩니다. 이러한 분할 방식은 각 팀을 분리할 때, 단순한 변경이 필요한 경우라도 많은 팀간 협업을 해야할 수 있습니다. 따라서 마이크로 서비스는 비지니스 로직에 따라 서비스로 팀을 나누게 됩니다. 각 팀에서 UI부터 데이터베이스까지 전부 관리합니다.
-
프로젝트가 아닌 제품
대부분의 응용 프로그램은 개발이 완료되면 소프트웨어 운영 조직에 의해 관리되는데 마이크로 서비스 아키텍처의 각 팀은 제품의 전체 라이프 사이클을 책임지게 됩니다. 제품을 인식하는 방식에서 이러한 고려 사항은 수행 능력에 강하게 결합되며 개발자들은 어떻게 소프트웨어가 비지니스를 향상 시킬 수 있는지에 대해 더 고민하게 됩니다.
-
분산화된 데이터 관리
마이크로 서비스 아키텍처는 데이터 저장관점에서 중앙 집중화된 하나의 데이터베이스를 사용하는 것이 아니라 서비스 별로 별도의 데이터 베이스를 사용합니다.. 데이터 베이스의 종류 자체를 다른 데이터베이스를 사용 할 수도 있고 같은 데이터베이스를 사용한다고 하더라도 디비는 분리됩니다.. 또한 각 서비스에서 필요로 하는 데이터들의 중복 문제가 발생하며 이런 중복을 동기화시켜야 한다.
MSA 장점
- 확장성
- 고속 개발의 최적화
- 각 서비스는 다른 프로그래밍 언어 다른 도구를 사용하여 개발가능(요구사항을 구현하기 위해 최적화된 언어와 아키텍처의 선택이 가능)
- 개발팀의 운영와 스케줄링의 높은 자유도
- 각 서비스는 개별 팀에서 독립적으로 개발/배포가 가능
- 각 서비스는 심플하며, 각 비지니스 요구사항에 특화
MSA 단점
- 코드의 중복
- 데이터의 중복
- 통합 테스트의 어려움
- 분산 시스템의 복잡성과 비동기성
- 트랜잭션 처리의 어려움
- 서비스간 통신 비용 증가
이번 포스팅에서는 it-chain에서 MSA를 채택하게 된 이유와 특징을 설명하기 전에 간단히 MSA에 대해 알아보았습니다. 다음 포스팅에는 MSA와 함께 사용되는 여러 패턴들에 대해서 알아보고 it-chain에 어떻게 적용되었는지 적용시 이슈사항들에 대해서 포스팅하겠습니다.