1.1 마이크로 서비스 아키텍처로 진화
-
소프트웨어 아키텍처는 소프트웨어 구성 요소 간 구조, 동작, 상호 작용을 하는 모든 기초 부분과 관련 됨
-
이 책에서는 적은 수의 명확한 작업을 수행하고 네트워크를 통해 메시지로 통신하며 느슨하게 결합된 소프트웨어 서비스로 구성된 마이크로서비스 아키텍처(MSA) 의 구성방법을 설명
1.1.1 N-계층 아키텍쳐
일반적인 아키텍처 유형중 하나는 다계층 또는 N-계층 아키텍처
이 디자인에서 어플리케이션은 UI, 서비스, 데이터, 테스팅 등 고유의 책임과 기능이 있는 여러 계층으로 나뉨
결국 전체 어플리케이션을 만드는 여러 프로젝트가 결합됨
N-계층 어플리케이션의 장점
- 관심사가 잘 분리되어 있어 UI, 데이터, 비즈니스 로직 같은 영역을 따로 고려 가능
- 팀이 N-계층 어플리케이션의 여러 컴포넌트에서 독립적으로 작업하기 쉬움
- 널리 알려진 엔터프라이즈 아키텍처이기 때문에 숙련된 N-계층 프로젝트 개발자를 찾기 수월
N-계층 어플리케이션의 단점
- 변경을 적용하려면 전체 서비스를 재시작해야함
- 메시지가 상하 전체 계층에 걸쳐 있으므로 비효율적일 수 있음
- 대규모 N-계층 어플리케이션이 배포되고 나면 리펙토링이 힘들 수 있음
1.1.2 모놀리스 아키텍처
중소 규모의 많은 웹 어플리케이션은 모놀리스 아키텍처 형태로 구축
모놀리스 아키텍처에서의 어플리케이션은 하나의 산출물 (1개의 프로젝트)
모든 UI, 비즈니스, 및 데이터 베이스 엑세스 로직은 함께 고유한 어플리케이션으로 패키징, 서버에 배포
마이크로 서비스 아키텍처 옹호자들은 모놀리스를 부정적으로 설명하지만 때로는 훌륭한 선택지가 되기도 함
모놀리스는 N-계층 또는 마이크로 서비스 같은 복잡한 아키텍처보다 구축 및 배포가 쉬움
사용사례가 잘 정의되어 있고(사례가 많다는?) 변경 가능성이 낮다면 모놀리스로 시작하는 것이 좋음
- 사내 맞춤형 고객관리(CRM) 어플리케이션의 모놀리스 구성
하지만 어플리케이션의 크기와 복잡성이 증가하기 시작하면 모놀리스를 관리하는 것 즉, 유지보수가 어렵게 될 수 있음
모놀리스에 대한 모든 변경이 사이드 이펙트를 유발할 수도 있고, 이 때문에 운영 환경의 시스템에서는 더 많은 시간과 비용이 소요될 것
마이크로서비스 아키텍처는 유연함과 유지 보수의 이점을 더 많이 제공
1.1.3 마이크로서비스란?
마이크로 서비스는 작고 느슨하게 결합된 분산 서비스
대규모 어플리케이션을 책임이 명확하고 관리하기 쉬운 구성 요소로 분해할 수 있음
잘 정의된 작은 조각으로 분해해서 대규모 코드베이스에서 발생하는 전통적인 복잡성 문제를 해결하도록 도울 수 있음
마이크로 서비스를 고려할 때 이해해야 할 핵심 개념은 분해와 분리
- 사내 맞춤형 고객관리(CRM) 어플리케이션의 마이크로서비스 구성
위 그림은 각 팀이 어떻게 그들의 서비스 로직과 서비스 인프라를 완전히 소유하는지 보여줌
팀의 코드, repository, infra가 모두 독립적으로 존재하기 때문에 상호 독립적으로 빌드, 배포, 테스트가 가능
마이크로서비스 아키텍처의 특징
- 어플리케이션 로직은 명확하고 대등한 책임 경계가 있는 작은 컴포넌트로 분해
- 각 구성요소는 작은 책임 영역을 담당하고 서로 독립적으로 배포
- 한 마이크로 서비스는 소비자와 공급자 간 데이터를 교환하고자 HTTP와 JSON같은 경량 프로토콜 사용
- 마이크로서비스 어플리케이션은 항상 기술 중립적 포맷(대표적으로 JSON과 같은...) 사용해서 통신하기 때문에 서비스 하부 기술 구현과 무관
- 즉, 마이크로서비스 방식으로 구축된 어플리케이션은 다양한 언어와 기술의 조합을 가져갈 수 있음
- 작고 독립적이고 분산적인 마이크로서비스 특징 덕분에 조직은 팀을 더 작게 만들고 명확한 책임영역 부여 가능
- 각각의 팀은 모두가 하나의 목표를 가지지만, 작업하는 서비스에만 책임을 가지게 됨
1.1.4 어플리케이션 구축 방법을 왜 바꾸어야 할까?
- 복잡성 증가
- 고객은 더 빠른 전달을 원함
- 고객 또한 안정적인 성능과 확장성을 요구
- 고객을 어플리케이션을 언제든 사용할 수 있기를 기대
이러한 이유 때문에, 확장성과 중복성이 높은 어플리케이션을 구축하려면 독립적으로 빌드, 배포할 수 있는 작은 서비스로 분해해야 함.
어플리케이션을 더 작은 서비스로 분리하고 단일 모놀리스 형태에서 서비스 산출물을 추출하면 아래와 같은 시스템을 구축할 수 있음
- 유연성
-분리된 서비스는 새로운 기능을 신속하게 제공할 수 있도록 구성 및 재배치 가능
-다른 것과 함께 작동하는 코드가 적을 수록 코드 변경에 따른 복잡성도 낮아지고 코드의 테스트 및 배포 시간도 줄어듦
- 회복성
-분리된 서비스는 어플리케이션이 더이상 한 부분의 저하로 전체가 고장나는 어플리케이션이 아님을 의미
-고장은 어플리케이션 일부분에 국한되어 전체 장애로 확대되기 전에 억제
-회복 불능의 에러인 경우에도 어플리케이션이 원만하게 저하되도록 함
- 확장성
-분리된 서비스는 여러 서버에 쉽게 수평 분산이 가능
-기능과 서비스를 적절히 확장하게 해줌
-모든 기능이 뒤얽혀 있어 어플리케이션 일부분만 문제가 발생해도 전체 어플리케이션을 축소해야하는 모놀리스와 달리 작은 서비스를 사용하기 때문에 확장가능하며 비용 효율도 높음
