Devops Day 42 (5.3) 마이크로서비스_마이크로서비스 구조와 특징

마이크로서비스 아키텍처의 정의
- 유지보수에 유리하고, 테스트 가능해야 함

- 느슨하게 결합되어야 함

- 독립적으로 배포 가능함

- 비즈니스 역량을 중심으로 구성해야 함

- 작은 팀에 의해 소유됨

서비스로서의 컴포넌트화
- 컴포넌트: 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위

- 컴포넌트화: 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것

- 컴포넌트화는 어떻게?: 소프트웨어를 여러 서비스로 분리하는 것

 

라이브러리 vs 서비스

Monolithic vs microservices :
- Monolithic : 모든 기능을 하나의 프로세스로 만들고 여려 개의 서버로 구성됨  

 

- Microservices : 각자의 기능을 각 서비스로 구성하고 다양한 서버로 배포

마이크로서비스 아키텍처 :

마이크로서비스 아키텍처는 애플리케이션을 작은 독립적인 서비스로 나누어 각각의 서비스가 특정 비즈니스 기능을 수행하도록 구성하는 아키텍처 패턴입니다. 이러한 서비스는 작고 자율적으로 실행 가능하며, 각 서비스는 API를 통해 다른 서비스와 통신합니다. 이를 통해 애플리케이션을 더욱 유연하고 확장 가능하게 만들 수 있습니다.

 

마이크로서비스 아키텍처의 주요 특징은 다음과 같습니다.

- 각 서비스는 독립적으로 배포 가능하며, 더 빠른 릴리스 주기를 가능하게 합니다.

- 각 서비스는 자체 데이터 저장소를 가질 수 있습니다. 이는 더욱 높은 확장성을 제공하며, 다양한 데이터베이스 및 스토리지 기술을 사용할 수 있습니다.

- 각 서비스는 자체적인 개발 스택을 가질 수 있습니다. 이는 개발자가 최신 기술을 적용하고 서비스의 성능을 개선하는 데 도움이 됩니다.

- 서비스 간의 통신은 API를 통해 이루어지며, 각 서비스는 자체적인 API를 가집니다. 이는 서비스 간의 결합도를 낮추어 더욱 유연한 애플리케이션을 만들 수 있도록 합니다.

마이크로서비스 아키텍처는 모놀리식 애플리케이션 아키텍처의 한계를 극복하고 더욱 높은 확장성과 유연성을 제공합니다. 그러나 더 많은 서비스와 데이터 저장소를 관리하고 배포해야 하므로, 더욱 복잡한 운영 환경을 가지게 됩니다. 따라서, 마이크로서비스 아키텍처를 구현하려면 적절한 인프라스트럭처와 자동화된 운영 프로세스가 필요합니다.

 

비즈니스 수행에 따른 구성, 프로젝트가 아니라 제품
- BEFORE :기술적 계층에 따른 팀 분류
- 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함

- AFTER : 비즈니스 수행 능력 (업무 도메인)에 따른 팀 분류
- 도메인 : 하나의 온전한 시스템의 단위
- 팀이 하는 일이 하나의 서비스로 나뉨 -> 마이크로서비스
 > 장점 : 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독집적
- 달성하기 위해 :
 > 각 팀은 서비스에 대한 책임을 가져야 함
 > 각 서비스는 메시지 버스 (통신 인터페이스)를 통해 통신해야 함

 

- 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있다

 

현명한 엔드포인트와 바보 파이프라인
특징 : "서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다"
 - 마이크로서비스에서의 프로세스 간 통신은, "현명한 엔드포인트와 바보 파이프라인" 접근 방식을 따름
 - 서비스와 서비스 사이는 느슨(decoupled)하게, 응집성은 높게
대표적인 방법 :
 - REST API (HTTP)
 - 메시지 버스를 이용한 메시지 전달

 

분산화 거버넌스, 분산화된 데이터 관리
문제점 : 중앙 집중적인 시스템은 기술을 표준화하는 경향이 있음
해결책 :
- 분산화된 시스템
 > 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다
- 분산화된 응용 프로그램 설계 → 도메인 주도 설계(DDD, Domain-Driven Design)

 

장애 방지 설계
- 서비스는 언제든지 실패할 가능성이 있음

- 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 함
- 대시보드와 모니터링은 필수적임

 

진화하는 설계
- 컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
- 장점 :
  > 모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 합니다.

> 마이크로서비스: 변경한 서비스만 다시 배포하면 됩니다.

> 간단하고 신속한 출시 프로세스
- 단점 :
  > 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경 써야 한다.

 

 

마이크로서비스 아키텍처 구현 단계

[ 표 1] A Microservices Maturity Model, from “Spring 5.0 Microservices,” 2nd Edition”by Rajesh R V (O’Reilly)

- 무작정 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입해야 합니다.

> 각 단계에 있어서 해당 방식이 갖는 장단점

> 기존(Legacy) 시스템의 작동 방식

> 현재 시점의 요구사항

 

서버리스
서버리스의 정의 : 서버가 없는 게 아니라, 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델입니다.

 

서버리스 아키텍처 :
서버리스 아키텍처는 애플리케이션 개발과 배포를 위해 서버를 구축하거나 유지보수하는 데 드는 부담을 줄이는 기술입니다. 서버리스 아키텍처에서는 애플리케이션 코드를 서버리스 플랫폼에 업로드하고, 이를 실행하는 데 필요한 컴퓨팅 리소스(예: CPU, 메모리)를 플랫폼에서 자동으로 할당합니다. 이를 통해 개발자는 서버 구축과 관리, 스케일링 등에 대한 부담을 덜고, 애플리케이션 개발과 배포에 집중할 수 있습니다.

서버리스 아키텍처의 특징은 다음과 같습니다.
- 서버를 직접 관리할 필요가 없으므로 운영 비용이 줄어듭니다.
- 필요한 컴퓨팅 리소스를 자동으로 할당하므로 애플리케이션의 확장성이 좋아집니다.
- 함수 또는 애플리케이션의 상태가 서버리스 플랫폼에 의해 유지되지 않으므로 무상태성이 유지됩니다.
- 각 함수 또는 애플리케이션은 독립적으로 실행되므로 애플리케이션 전체의 안정성이 향상됩니다.
- 서버리스 플랫폼에서 제공하는 다양한 서비스(예: 데이터베이스, 메시징, 인증)를 쉽게 이용할 수 있습니다.

서버리스 아키텍처는 AWS Lambda, Azure Functions, Google Cloud Functions 등 다양한 클라우드 서비스 제공 업체에서 제공되고 있으며, 이를 활용하여 애플리케이션을 빠르게 개발하고 배포할 수 있습니다.

 

컴퓨팅의 진화 과정
그전 애플리케이션을 배포하려면 직접 하드웨어 서버를 구매하고 관리해야 했습니다. 비용도 많이 들고 시스템상 많이 불안했지만 aws 클라우드 컴퓨팅 서비스들 통해 비용과 하드웨어 관리의 불안감을 덜 수 있습니다. 단 서버의 소프트웨어도 보안, 업데이트, 백업과 같은 많은 관리 과정이 필요하다. 이때 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안으로 Serverless가 등장한 것이다.

- 데이터센터에서의 물리 서버 → 데이터센터에서의 가상 서버

> 활용률 증가, 프로비저닝 속도 증가, 높아진 가동 시간, 재해 복구, 하드웨어 독립성

→ 데이터센터에서의 가상 서버 → 클라우드에서의 가상 서버

> 자본 비용 → 운용 비용, 높은 확장성, 탄력적인 리소스, 빠른 속도와 민첩성, 유지보수 비용 감소, 고가용성과 내결함성

> 단점: 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업 시 비쌈

 

서버리스의 이점
- 서버관리 불필요

- 유연한 확장성

- 고가용성

- 유휴 용량 없음

 

발표 :
[C811] 마이크로서비스와 서버리스는 어떤 관계가 있나요?

마이크로서비스와 서버리스는 모두 분산 컴퓨팅 아키텍처에 대한 개념입니다.

클라우드 서버가 보편화 되면서 직접 하드웨어 서버를 구매 및 관리 신경쓰지 않아도 됩니다. 마이크로서비스는 소프트웨어 애플리케이션을 작은 독립적인 서비스 단위로 분할하는 아키텍처입니다. 각 마이크로서비스는 자체적으로 실행 가능하며, 서로 독립적으로 배포, 확장, 수정이 가능합니다. 서버리스 아키텍처는 서버에 대한 개념을 제거하고, 애플리케이션 개발자가 서버 없이도 코드를 실행할 수 있도록 하는 컴퓨팅 아키텍처입니다. 서버리스 서비스는 AWS Fargate, S3, EC2 등이 있습니다.

 

[C812] 서버리스의 특징 중 하나인 무상태성(Stateless)은 무엇을 의미하나요?

서버리스 컴퓨팅에서 무상태성(Statelessness)은 함수 또는 애플리케이션의 상태(state)가 서버리스 플랫폼에 의해 유지되지 않음을 의미합니다. 다시 말해, 이전 함수 호출 또는 이전 애플리케이션 상태가 다음 호출에 영향을 미치지 않는 것을 의미합니다. 서버리스 컴퓨팅에서 함수 또는 애플리케이션은 각각 독립적으로 실행되며, 필요한 경우에만 호출됩니다. 함수나 애플리케이션의 상태를 유지하지 않기 때문에, 이를 관리하거나 저장하기 위한 서버나 데이터베이스가 필요하지 않습니다. 이로 인해 서버리스 컴퓨팅은 더 높은 확장성과 더 낮은 유지보수 비용을 제공할 수 있습니다. 스테이트리스 애플리케이션은 콘텐츠 전달 네트워크 (CDN), 웹, 프린트 서버를 사용해 이러한 단기 요청을 처리합니다. 예시를 들자면, 검색창에 검색어를 입력하고 엔터키를 누르면 원하는 페이지를 보여주는 것입니다.

 

[C813] 마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 하나요? 데이터가 한 곳에 모여있지 않고 중복되어도 괜찮은가요? 모범 사례를 알아보고, 이유를 함께 적어주세요.
마이크로서비스 아키텍처에서 데이터베이스를 분리하는 것은 일반적인 모범 사례입니다. 이는 각 마이크로서비스가 자체 데이터베이스를 가지고 해당 데이터를 독립적으로 관리하면서 서로 간의 결합도를 줄이고, 확장성과 유지보수성을 향상시키기 위한 것입니다. 서비스의 트래픽이 커짐에 따라 한곳에서 관리하다가 문제가 발생시 서비스 전체 장애가 발생 할 수 있어 서비스하고 데이터베이스를 분리해서 사용하는 것이 좋습니다.
모범 사례에로 넷플릭스는 수백개의 마이크로서비스를 AWS 클라우드 기반으로 운영하고 있는 것으로 유명합니다. 인터널 API를 기반으로 가벼운 REST 프로토콜을 활용하여 서비스 통신을 하고 있습니다.

마이크로서비스 아키텍처에서는 서로 다른 서비스 간의 데이터 중복을 허용하는 것이 일반적입니다. 이는 각 서비스가 자체 데이터를 가지고 있기 때문에 각 서비스가 자신의 데이터를 필요로 하는 경우 데이터를 복사하여 사용하는 것이 효율적이기 때문입니다. 각 서비스의 데이터 모델이 다르거나 요구사항이 서로 다른 경우에도 데이터 중복이 효과적일 수 있습니다.

결론적으로 반적으로 마이크로서비스 아키텍처에서는 데이터베이스를 분리하고, 데이터 중복을 허용하며, 이를 위해 일관성 유지와 동기화를 보장하는 방법을 구현하는 것이 모범 사례입니다.