MSA란 -마틴 파울러 아티클 읽기

Microservice Arcitecture

MSA란

최근에 독립적으로 배포가능한 서비스들을 디자인하는 아키텍쳐로 MSA가 떠오르고 있다.

MSA에 대해 정확한 정의는 내리기 어렵지만

비즈니스 능력(capability),

배포 자동화(automated deployment),

엔드포인트의 지능(intelligence in the endpoints) (dump pipeline),

데이터와 개발 언어의 분산화(decentralized control of language and data)

라는 특정 공통 특징이 있다. 

 

MSA의 근황

MSA라는 새로운 용어가 등장했다. 

우리는 이러한 새로운 것들을 대해 경멸적인 태도로 지나가는게 본래 성향이지만,

MSA는 용어적으로 우리에게 좀 더 찾아보게하고 어필하는 소프트웨어 시스템을 묘사한다. 

우리는 최근 몇몇 프로젝트에서 MSA 구조로 된 프로젝트롤 봐왔고 결과는 매우 긍정적이였으며 

많은 엔터프라이즈 레벨에서 어플리케이션을 만들때 동료들이 지향하는 기본 스타일이 되어가고있다.

하지만 슬프게도 MSA란 무엇인지 말해주는 개요와 어떻게 구축하는지에 대한 정보가 부족하다.

 

간단히 말해서 MSA는 단일 어플리케이션을 작은 서비스들의 모음으로 개발하는 접근 방식으로,

각 서비스들은 자신만의 프로세스에서 실행되며 HTTP와 같이 간단하고 가벼운 메카니즘을 통해서 통신한다.

서비스들은 비즈니스 능력Business Capability(빠르고 유연하게 비즈니스에 대처할 수 있는 능력)의 해 빌드되며 배포 자동화 매커니즘에 의해 독립적으로 배포가 가능하다. 다른 프로그래밍 언어와 다른 데이터 저장 기술을 사용하는 이러한 서비들을 관리하는 최소한의 중앙 관리 시스템이 있다. 

 

모놀로틱과의 비교

마이크로 서비스의 스타일을 설명하기 앞서서 하나의 유닛으로 빌드된 모놀리틱 서비스와 비교하는 것이 유용할 것이다. 엔터프라이즈 어플리케이션은 클라이언트 사이드 유저 인터페이스(HTML 페이지, 브라우저에서 동작하는 자바스크립트), 데이터베이스(데이터를 저장하고 관리), 서버사이드라는  3개의 주요 부분으로 빌드된다. 서버사이드 어플리케이션은 HTTP 요청들을 처리할 것이며 도메인(문제 해결 영역)의 로직을 실행하고, 데이터베이스에 데이터를 검색하거나 업데이트 할것이며, 브라우저로 보낼 정보를 가져오거나 HTML을 채울 것이다. 이러한 서버사이드 어플리케이션은 단일 논리적으로 실행이가능한 것이다. 모놀리틱이라 부른다. 시스템의 어떠한 변화해도 서버사이드 어플리케이션에 새로운 버전을 빌드하고 배포해야한다. 

 

이러한 모놀리틱 서버는 이러한 구축시스템에 자연스럽게 다가갈 수 있는 자연스러운 방법이다. 모든 당신의의 요청을 처리하는 로직은 언어의 기본 기능으로 어플리케이션을 클래스들과 함수들과 이름영역으로 나누늘 것을 허락하는 하나의 프로세스에서 동작한다. 어느정도 주의를 기울여, 당신은 개발자의 노트북에서 실행 및 테스트를 할 수 있고, 코드의 변화에 대해 적절히 테스트 되었고 프로덕션 레벨에 배포할 수 있는지를 확인하기위해 배포 파이프라인을 사용할 수 있다. 당신은 로드밸런서 뒤에 여러개의 인스턴스를 실행시킴으로서 수평적 확장을 할 수 있다. 

 

모놀리틱 어플리케이션들은 성공적일 수는 있었으나 특히 점점 많은 사람들은 그것들을 클라우드에 배포하는 것이 늘어 날수록 불만을 느꼈다. 변화 주기들은 함께 묵였다 즉 어플리케이션의 작은 부분의 변화는 전체의 모놀리틱 어플리케이션에 재빌드와 재배포를 만들었다. 시간이 지남에 따라 좋은 모듈러 구조를 유지하기 어려웠고 하나의 모듈러의 변화를 하나의 모듈러 내부에만 영향을 끼치도록 해야만 하는 것이 어려워졌다.

스케일링은 많은 자원을 요청하는 특정 부분의 스케일링이라기 보다는 전체 어플리케이션의 스케일을 요구 했다. 

 

이러한 짜증들이 서비스들의 모음들로 어플리케이션을 빌드하는 방식인 MSA를 이끌었다. 서비들이 독립적으로 배포가능하고 스케일 가능할 뿐만 아니라 각 서비스들은 또한 모듈 바운더리를 제공하며, 심지어 각 서비스들이 다른 프로그래밍 언어와 데이터베이스를 사용하는 것을 허용한다.  그들은 서로 다른 팀에 의해서 관리가 가능하다. 우리는 MSA가 참신하거나 혁신적으라고 주장하지 않으며 MSA의 뿌리는 적어도 유닉스 설계 방식으로 올라간다. 그러나 우리는 충분한 사람이 마이크로서비스 아키텍쳐를 고려하지 않고 많은 소프트웨어 개발이 MSA를 사용하면 더 나아질 것이라고 생각한다. 

 

MSA의 특징들 

우리는 MSA 스타일의 정형화된 정의가 있다고는 말 못하지만, 여태까지 봐왔던 MSA의 공통적인 특징을 묘사를 시도해 볼 순 있다. 일반적인 특성을 설명하는 정의로서, 모든 MSA 가 모든 성격을 지닌 것은 아니며, 대부분의 MSA가 대부분의 성격을 지닐것이라고 예상한다. 우리는 다소 느슨한 커뮤니티의 활동적인 저자들이 였지만, 우리의 의도는 우리의 작업에서 봐왔던 일과 팀이 알고있는 비슷한 노력들을 설명해보려 하는 것 입니다. 특히 우리는 MSA를 정의하거나 확정지으려고 하지 않습니다. 

 

서비스들을 통한 컴포넌트화

우리는 오랜기간 동안 소프트웨어 산업에 종사해왔고, 우리가 실제세계에서 사물을 보는것처럼 함께 연결되는 컴포넌들로 빌드하는 시스템을 바래왔습니다. 지난 수십년동안 우리는 대규모 플랫폼 언어들의 흔한 라이브러리의 큰 부록으로 상당한 진전을 보았다.

 

컴포넌트에 대해 이야기할때 우리는 무엇이 컴포넌트를 구성하냐라는 어려운 정의에 부딪힌다. 우리의 내린 정의는 컴포넌트란 소프트웨어에서 독립적으로 대체될 수도 있고 업그레이드가 가능한 한 단위이다..  

 

MSA는 라이브러리들을 사용할 것이지만, 그들의 소프트웨어를 컴포넌트화 하는 주요한 방법은 서비스 단위로 잘게 분리하는 것이다. 우리는 라이브러리들을 프로그램을 통해서 연결되며 인메모리 함수로서 불리는 컴포넌트들로 정의한다. 

반면 서비스들은 웹서비스 요청이나 원격 프로서저와 같은 메카니즘과 통신하는 외부 프로세스 구성요소이다 

 

우리가 서비스들을 컴포넌트들로 사용하는 하나의 주요한 원인은 바로 서비스들이 독립적으로 배포가능한 것이다. 만약 너가 어플레케이션을 가지고 있고 여러개의 라이브러리들을 하나의 단일 프로세스로 구성한다면, 하나의 단일 컴포넌트의 변화 결과는 전체 어플리케이션의 재배포해야만 한다.  그러나 다수의 서비스로 컴포넌트화된 어플리케이션이라면 , 단일 서비스의 변화는 오직 단일 서비스의 재배포를 예상할 수 있다. 절대적인 것은 아니며, 일부 변경 사항은 서비스 인터페이스를 변경하여 어느 정도 조정을 초래할 수 있지만, 우수한 마이크로서비스 아키텍처의 목표는 응집력 있는 서비스 경계와 서비스 제약사항의 진화 메커니즘을 통해 이를 최소화하는 것입니다.

 

서비스들은 컴포넌화해서 사용하는 또다른 결과는 보다 명확한 컴포넌트 인터페이스입니다. 대부분의 언어들은 명확한 Published Interface(외부에서 호출가능한 API 느낌?)를 정의하는데 좋은 메카니즘을 갖고 있지 않다.  종종 클라이언트들이 컴포넌들의 캡슐화를 부수는 것을 예방하여 서비스간의 과도한 결합을 초래하는 문서거나 규율이다. 서비스들은 명확한 원격 호출 메커니즘을 사용해서 이러한 문제를 회피하고 더 쉽게만든다.

 

이와 같은 서비스들을 사용하는 것은 단점이 있다. 원격 호출은 프로세스 내부 호출보다 더 비용이 높고, 따라서 원격 API들은 더 잘게 세분화 해야하는데, 이는 종종 사용하기에 어색하다. 만약 당신이 컴포넌트 사이에서 책임의 할당을 변경할 필요가 있다면, 프로세스 경계를 넘을때에서는 이러한 행동들이 더 어려워질 것이다.

 

첫번째 접근에서, 우리는 서비스들이 각 런타임 프로세스에 매핑되는 것을 관찰할 수 있지만 오직 첫번쨰 접근에서만이다.
서비스는 애플리케이션 프로세스와 해당 서비스에서만 사용되는 데이터베이스와 같이 항상 함께 개발되고 배포되는 여러 프로세스로 구성될 수 있습니다.(여기가 좀 무슨말인지 이해가 잘 안된다..)

 

Business Capabilites를 중심으로 조직 구성 

큰 어플리케이션을 여러 부분으로 분할하고자 할때, 주로 관리자는 기술층, UI 팀, 서버사이드 로직팀, 데이터베이스팀에 집중한다. 팀들이 이러한 방식으로 구분되었을때, 아주 간단한 변화조차 팀 간 프로젝트 시간과 예산 소요 시간이 필요하다. 한 똑똑한 팀은 이러한 문제를 최적화 하고, 두가지 단점 중 더 작은 단점을 긍정적으로 판단하여 접근할 수 있는 애플리케이션에 논리를 적용하기만 하면 된다. 다시말해 어디서든 논리가 존재한다, 이것은 콘웨이 법칙을 적용한 하나의 예시이다. 

 

 

//열심히 적는중입니다..

 

 

 

 

 

출처https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities

Microservices