마이크로 서비스
하나의 큰 애플리케이션을 여러 개의 다른 역할을 수행하는 애플리케이션으로 분리하였을 때 각 애플리케이션을 의미
마이크로 서비스 아키텍처
마이크로 서비스를 분리하여 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처
애플리케이션을 특화된 기능별로 나누게 되면 자연스럽게 애플리케이션의 추상화(abstraction)가 가능해진다.
즉, ‘인증’을 담당하는 서비스(예, auth.example.com)는 그 구체적인 구현 내용을 모르더라도 다른 서비스에서 약속된 인터페이스를 이용해 인증 과정을 수행할 수 있다.
모놀리틱 아키텍처(MONOLITHIC ARCHITECTURE)
비즈니스 로직을 담당하고 있는 애플리케이션이 존재하고,
해당 애플리케이션은 데이터베이스 등 외부 시스템과 특정 프로토콜로 통신을 하게 된다.
또한, 사용자에게 인터페이스를 제공하기 위해서 HTML을 렌더링 하는 부분과 RESTful API를 제공하는 부분을 갖게 된다. 이렇게 구성된 애플리케이션의 소스코드는 하나의 프로젝트로 구성되어 있으며 단일한 패키지로 배포되게 된다.
장점
단순한 구성의 애플리케이션은 로컬 환경에서 개발하기에도 편리하고 통합 시나리오 테스트를 수행하기에도 가장 손쉬운 구성이다.
또한, 모든 코드가 하나의 묶음으로 구성되어 있기 때문에 배포도 매우 간편해진다.
단점
서비스 복잡도가 증가하면서 배포 시간의 증가, 부분적 스케일 아웃의 어려움, 안정성의 감소 등이 있다.
그중 애플리케이션을 구성하는 프로그래밍 언어, 또는 프레임워크의 변경이 거의 불가능에 가까울 정도로 어렵다.
마이크로 서비스 아키텍처(MICROSERVICE ARCHITECTURE)
모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴
독립적인 역할이란 주로, ‘사용자 관리’, ‘주문 관리’, ‘결제 관리’, ‘알림 관리’와 같이 기능적인 요소를 의미한다.
각각의 마이크로 서비스는 크기만 작을 뿐, 각각이 하나의 모놀리틱 아키텍처와 유사한 구조를 갖는다.
다만, 하나의 서비스에서 처리해야 하는 기능과 규모가 작기 때문에 이를 마이크로 서비스라고 부른다.
장점
서비스가 개별적으로 독립적인 단위의 애플리케이션이기 때문에 변경이 용이하고 그 변경이 다른 서비스에 미치는 영향이 적다.
개별 서비스 단위의 배포가 가능하기 때문에 하루에도 필요에 따라 여러 번 배포를 하는 것이 가능하다.
비용적인 측면에서 마이크로 서비스 아키텍처는 부하가 집중되는 특정 서비스를 위해 전체 애플리케이션을 스케일 아웃할 필요가 없기 때문에 불필요한 자원의 낭비를 줄일 수 있다.
서비스의 특성에 맞게 자원을 할당하여 스케일 아웃할 수 있기 때문에 효율적인 자원 사용이 가능하게 된다.
단점
모놀리틱 아키텍처에 비해 서비스 간의 통신에 대한 처리가 추가적으로 필요하다.
단순히 개발해야 하는 코드의 양이 늘어난다는 점뿐만 아니라, 사용자의 요청을 처리하기 위한 응답속도의 증가에도 영향을 미친다.
뿐만 아니라, 분산된 데이터베이스는 트랜잭션 관리가 용이하지 않기 때문에 데이터의 정합성을 맞추기 위한 노력이 추가적으로 필요하다.
도메인이란
사용자가 프로그램을 사용하는 대상 분야로, 실제 세계에서 사용자가 프로그램을 사용하며 발생하는 사건의 집합
개발자 대부분은 비즈니스 프로세스를 개선하거나 자동화하기 위해 일한다. 도메인은 이런 프로세스가 지원하는 활동을 의미
개발자 입장에서 온라인 서점을 구현해야 할 소프트웨어의 대상이 된다.
ex) 온라인 서점의 도메인은 구매 및 조달, 제품 설계, 물류 및 배달 등 다른 분야를 뜻할 수 있다
온라인 서점 = 소프트웨어로 해결하고자 하는 문제의 영역 = 도메인 (Domain)
도메인 모델
유용한 특성을 포함하는 프로세스나 현상의 지도(Map)를 뜻함.
특정 도메인을 개념적으로 정리한 모델
도메인 모델은 사용할 개체를 기억하기 쉬운 이름(식별자)을 부여해 대상을 쉽게 공유할 수 있게 한다.
도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 한다.
도메인 모델은 도메인 자체를 이해하기 위한 개념 모델이다.
개념 모델을 이용해서 바로 코드를 작성할 수 있는 것은 아니기에 구현 기술에 맞는 구현 모델이 따로 필요하다.
그렇기에 개념 모델과 구현 모델은 서로 다른 것이지만 구현 모델이 개념 모델을 최대한 따르도록 할 수는 있다.
도메인 주도 설계
도메인 전문가(실사용자, 현업 전문가)와 개발자가 도메인들을 추상화하여 모델링하고 서로 상호작용하며 설계하는 것.
도메인이 복잡할 경우 도메인 모델과 소프트웨어 구현이 불일치하는 경우가 있으므로, 최대한 단순화시키는 작업이 필요
'coding > IT, CS' 카테고리의 다른 글
Side effect, Decoupling, 디자인 패턴 (0) | 2022.08.10 |
---|---|
테스트 코드 종류와 테스트 피라미드 (0) | 2022.08.09 |
Restful API (0) | 2022.07.31 |
SQL과 NOSQL의 차이 (0) | 2022.07.25 |
JavaScript의 ES, ES5/ES6 (0) | 2022.07.24 |