모놀리스 아키텍처
중소 규모의 많은 웹 애플리케이션은 모놀리스 아키텍처 형태로 구축된다. 모놀리스 아키텍처에서 애플리케이션은 배포 가능한 하나의 산출물로 생성된다. 모든 UI, 비즈니스 및 데이터베이스 액세스 로직은 함께 고유한 애플리케이션으로 패키징되어 애플리케이션 서버에 배포된다. 아래 그림은 모놀리스 아키텍처이다.
애플리케이션은 단일 작업으로 배포될 수 있지만 한 애플리케이션에서 여러 개발 팀이 작업하는 경우가 많다. 각 개발 팀은 일반적으로 특정 고객을 대상으로 하는 애플리케이션의 개별 부분을 담당한다. 예를 들어 UI/UX, 고객, 데이터 웨어하우스, 금융 관계자 등을 포함한 여러 팀과 조율해야 하는 사내 맞춤형 고객 관계 관리(CRM) 애플리케이션의 시나리오를 생각해 보자.
마이크로서비스 아키텍처 옹호자들은 때때로 모놀리스 애플리케이션을 부정적으로 설명하기도 하지만 모놀로그는 종종 훌륭한 선택지다. 모놀리스는 N-계층 또는 마이크로서비스 같은 복잡한 아키텍처보다 구축 및 배포가 쉽다. 사용 사례가 잘 정의되어 있고 변경 가능성이 낮다면 모놀리스로 시작하는 것이 좋다.
하지만 애플리케이션의 크기와 복잡성이 증가하기 시작하면 모놀리스를 관리하는 것은 어려운 일이 될 수 있다. 모놀리스에 대한 모든 변경이 애플리케이션의 다른 부분까지 차례로 영향을 줄 수 있고, 이 때문에 운영 환경의 시스템에서는 많은 시간과 비용이 소요될 것이다.
마이크로서비스란?
마이크로서비스 개념은 대규모 모놀리스 애플리케이션 기술적 또는 조직적으로 확장하는 데 직면한 많은 난제에 대한 직접적인 대응으로 소프트웨어 개발 커뮤니티에서 태동했다. 마이크로서비스는 작고 느슨하게 결합된 분산 서비스다. 마이크로서비스를 사용하면 대규모 애플리케이션을 책임이 명확하고 관리하기 쉬운 구성 요소로 분해할 수 있다. 또한 잘 정의된 작은 조각으로 분해 해서 대규모 코드베이스에서 발생하는 문제점을 해결하도록 도울 수 있다.
마이크로서비스를 고려할 때 이해해야 할 핵심 개념은 분해, 분리다. 애플리케이션의 기능은 완전히 상호 독립적이어야 한다. 마이크로서비스로 분해하면 아래와 같다.
위 내용은 하나의 팀만 표현했지만 기타 다른 팀도 동일한 상호 독립적인 마이크로서비스를 가진다. 팀의 코드, 소스 제어 레포지토리, 인프라스트럭처(애플리케이션 서버와 데이터베이스)가 이제 애플리케이션의 다른 부분과 완전히 독립적이기 때문에 상호 독립적 빌드, 배포, 테스트를 할 수 있다.
마이크로서비스 아킥텍처 특징
- 애플리케이션 로직은 명확하고 대등한 책임 경계가 있는 작은 컴포넌트로 분해된다.
- 각 구성 요소는 작은 책임 영역을 담당하고 서로 독립적으로 배포된다. 한 마이크로서비스는 비즈니스 도메인의 한 부분에 책임진다.
- 마이크로서비스 애플리케이션은 항상 기술 중립적 포맷(대표적으로 JSON)을 사용해서 통신하기 때문에 서비스 하부의 기술 구현과 무관하다. 이 말은 마이크로서비스 방식으로 구축된 애플리케이션은 다양한 언어와 기술로 구현될 수 있다는 의미이다.
- 작고 독립적이고 분산적인 마이크로서비스 특성 덕분에 조직은 팀을 더 작게 만들고 명학한 책임 영역을 부여할 수 있다. 이들 팀은 애플리케이션 출시처럼 하나의 목표를 향해 일하더라도 각 팀은 그들이 작업하는 서비스에만 책임을 진다.
마이크로서비스는 아래 사항을 항상 기억해야 한다.
작고(small), 단순하고(simple), 분리된(decoupled), 서비스=확장가능하고(scalable), 회복적이며(resilient), 유연한(flexible) 애플리케이션
스프링 마이크로서비스
스프링은 자바 기반 애플리케이션을 구축할 수 있는 가증 대중적인 개발 프레임워크이다. 스프링은 의존성 주입이라는 핵심 개념에 기반을둔다. 의존성 프레임워크를 사용하면 애플리케이션 내 객체 관계를 서로 알기 위해 하드코딩하는 대신 관례와 애너테이션으로 외부화할 수 있어 대규모 자바 프로젝트를 더 효율적으로 관리할 수 있다. 애플리케이션의 다양한 자바 클래스 사이에서 중개자 역할을 하며 의존성을 관리한다. 스프링을 사용하면 끼워 맞추어서 조립하는 레고 블록 세트처럼 코드를 조립할 수 있다.
마이크로서비스가 클라우드 기반 애플리케이션을 구축하기 위한 좀 더 일반적인 아키텍처 패턴 중 하나가 되었기 때문에 스프링 개발 커뮤니티에서 스프링 클라우드를 개발했다. 스프링 클라우드를 사용하면 사설(private), 공용(public) 클라이드에 마이크로서비스를 간단하게 운영하고 배포할 수 있다. 스프링 클라우드는 여러 가지 인기 있는 클라우드 관리형 마이크로서비스 프레임워크를 공통 프레임워크에 포함했다. 따라서 코드에 애너테이션을 추가하는 것만큼 쉽게 이러한 기술을 사용하고 배포할 수 있다
스프링 부트로 만든 Hello World (매우) 단순한 스프링 마이크로서비스
@SpringBootApplication
@RestController
@RequestMapping(value="hello")
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
@GetMapping(value="/{firstName}")
public String helloGET(
@PathVariable("firstName") String firstName,
@RequestParam("lastName") String lastName) {
return String.format("{\"message\":\"Hello %s %s\"}",firstName, lastName);
}
@PostMapping
public String helloPOST( @RequestBody HelloRequest request) {
return String.format("{\"message\":\"Hello %s %s\"}",request.getFirstName(), request.getLastName());
}
}
class HelloRequest{
private String firstName;
private String lastName;
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
클라우드 컴퓨팅이란?
클라우드 컴퓨팅은 유연하고 안전하며 사용하기 쉬운 환경을 제공하고자 인터넷을 통해 컴퓨팅과 가상화된 IT 서비스(데이터베이스, 네트워킹, 소프트웨어, 서버, 분석 등)를 제공하는 것이다.
아래 목록은 가장 일반적인 클라우드 컴퓨팅 모델을 보여준다.
| 모델 명 | 비고 |
| IaaS(Infrastructure as a Service) | 공급업체는 서버, 스토리지, 네트워크 같은 컴퓨팅 자원에 접근할 수 있는 인프라스트럭처를 제공한다. 이 모델에서 사용자는 인프라스트럭처 유지와 애플리케이션 확장성에 대한 모든 것을 책임진다. |
| CaaS(Container as a Service) | IaaS와 PaaS의 중간 모델로, 컨테이너 기반 가상화의 한 형테다. |
| PaaS(Platform as a Service) | 이 모델은 사용자가 애플리케이션 개발, 실행, 유지 관리에 집중할 수 있는 플랫폼 환경을 제공한다. |
| FaaS(Function as a Service) | 서버리스 아키텍처라고도 하는데, 이름에 "서버리스"가 있음에도 이 아키텍처는 서버 없이 특정 코드를 실행하는 것을 의미하지 않는다. |
| SaaS(Software as a Service) | 주문형 소프트웨어라고도 하는 이 모델을 사용하면 사용자는 특정 애플리케이션을 배포하거나 유지 관리할 필요 없이 사용할 수 있다. 대부분은 웹 브라우저를 통해 사용한다. 애플리케이션, 데이터, 운영체제, 가상화, 서버, 저장소, 네트워크 등 모든 것을 서비스 제공자가 관리한다. 사용자는 단지 서비스를 도입하고 소프트웨어를 이용한다. SaaS 플랫폼에는 Salesforce, SAP, Google Business가 있다. |
다양한 클라우드 컴퓨팅 모델은 사용자와 클라우드 공급업체 관리 중 누가 무엇을 담당하는지에 따라 결정된다.
왜 클라우드와 마이크로서비스 인가?
마이크로서비스 아키텍처의 핵심 개념 중 하나는 각 서비스가 분리되어 독립적인 산출물로 패키징되고 배포된다는 것이다. 서비스 인스턴스는 신속히 시작되어야 하고 각각은 서로 구별할 수 없어야 한다. 마이크로서비스를 작성할 때 서비스를 다음중 어떤 형태로 배포할지 곧 결정해야 한다.
- 물리 서버 : 마이크로서비스를 물리 머신에 구축하고 배포할 수 있지만 물리 서버가 제한되어 있어 실제로 이렇게 수행하는 조직은 많지 않다. 물리 서버의 용량을 신속하게 늘릴 수 없으며 여러 물리 서버에 걸쳐 수평적으로 마이크로서비스를 확장하는데 막대한 비용이 소요될 수 있다.
- 가상머신 이미지 : 마이크로서비스의 주요 이점 중 하나는 확정성과 서비스 실패 이벤트에 대한 응답으로 인스턴스를 빠르게 시작하고 종료할 수 있다는 것이다. 가상 머신(VM)은 주요 클라우드 제공업체의 심장이자 영혼과 같다.
- 가상 컨테이너 : 가상 컨테이너는 VM 이미지에 마이크로서비스를 배포하는 데 대한 자연스러운 확장이다. 많은 개발자는 서비스를 전체 VM에 배포하는 대신 도커 컨테이너(또는 이에 상응하는 컨테이너 기술)로 클라우드에 배포한다. 가상 컨테이너는 VM 내 실행되고 가상 컨테이너를 사용하여 하나의 VM을 동일 이미지를 공유하는 일련의 독립형 프로세스로 분리할 수 있다. 마이크로서비스는 패키징되어 서비스의 다수 인스턴스를 IaaS 사설 및 공용 클라우드에 신속히 배포하고 시작할 수 있다.
마이크로서비스 작성 지침
마이크로서비스의 견고한 서비스를 작성하려면 여러가지 주제를 고려해야 한다.
- 적정 규모 : 마이크로서비스가 너무 많은 책임을 지지 않도록 적절한 마이크로서비스 크기를 유지하는 방법이다. 적절한 크기의 서비스를 이용하면 애플리케이션을 신속히 변경할 수 있고 전체 애플리케이션에 대한 전반적인 위험을 줄일 수 있다.
- 위치 투명성 : 서비스 호출에 대한 물리적 상세 정보를 관리하는 방법이다. 마이크로서비스 애플리케이션에서 다수의 서비스 인스턴스가 빠르게 시작하고 종료될 수 있다.
- 반복성 : 서비스의 모든 새 인스턴스가 시작할 때 운영 환경의 다른 서비스와 동일한 구성과 코드베이스를 보장하는 방법이다.
- 확장성 : 서비스 간 직접적인 종속 관계를 최소화하고 마이크로서비스를 적절히 확장할 수 있도록 통신 방식을 구축하는 방법이다.
'마이크로서비스' 카테고리의 다른 글
| 마이크로서비시 아키텍처 설계 (0) | 2024.10.14 |
|---|---|
| 클라우드 네이티브 마이크로서비스 구축을 위한 12 팩터 앱 (0) | 2024.10.10 |
| 스프링 클라우드란? (1) | 2024.10.07 |
| 마이크로서비스 개발 패턴 (3) | 2024.09.10 |
