[마이크로서비스] 01. 마이크로서비스 구조와 특징

목차
1. 마이크로서비스 구조와 특징
2. 마이크로서비스 아키텍처 구현 단계
3. 서버리스

# 학습 내용

1.  마이크로서비스 구조와 특징

마이크로서비스 아키텍처의 정의

What are microservices?

다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계

• 유지보수에 유리하고, 테스트 가능해야 함
• 느슨하게 결합되어야 함
• 독립적으로 배포 가능함
• 비즈니스 역량을 중심으로 구성해야 함
• 작은 팀에 의해 소유됨

→ 마이크로서비스 아키텍처를 통해 조직은 대규모의 복잡한 애플리케이션을 빠르고, 자주, 안정적이고 지속 가능하게 제공 가능

 

소프트웨어를 빠르고, 자주, 안정적이고 지속 가능하게 제공하는 것이 중요한 이유

- 변덕스럽고 불확실하며 복잡하고 모호한 세상에서 성공하기 위해서는 기업이 민첩하고 민첩하며 더 빠르게 혁신

- 현대 비즈니스는 소프트웨어에 의해 구동되기 때문에 IT는 DORA 측정 기준 으로 측정할 때 해당 소프트웨어를 신속하고 자주 안정적으로 제공할 필요성

 

신속하고 빈번하며 안정적이고 지속 가능한 전달에 필요한 세가지 요소

• 프로세스 - DevOps 핸드북에 정의된 DevOps
• 조직 - 소규모의 느슨하게 결합된 교차 기능 팀의 네트워크
• 아키텍처 - 느슨하게 결합되고 테스트 및 배포 가능한 아키텍처

∴ 팀은 대부분의 시간 동안 독립적으로 작업하여 자동화된 배포 파이프라인에서 테스트하고 프로덕션에 배포하는 작고 빈번한 변경 사항의 스트림을 생성

 

Step 1 : 마이크로 서비스를 사용해야 하는 경우 : 모놀리식 아키텍처를 능가하는 경우

- 예를 들어 DevOps를 채택하고 느슨하게 결합된 소규모 팀으로 재구성하는 등 모놀리식 아키텍처를 최대한 활용하는 것이 중요

- 대부분의 경우 성공 삼각형을 채택하면 모놀리식 아키텍처가 충분히 느슨하게 결합되고 테스트 및 배포가 가능하여 신속한 소프트웨어 제공이 가능

- 그러나 때로는 애플리케이션이 모놀리식 아키텍처보다 커져 빠르고 빈번하며 안정적인 소프트웨어 제공에 장애가 될 수 있음, 일반적으로 응용 프로그램이 크고 복잡해지고 많은 팀에서 개발할 때 발생 (ex. 배포 파이프라인이 병목 현상이 되므로 마이크로서비스로의 마이그레이션을 고려

- 모놀리식을 마이크로서비스로 마이그레이션하는 것을 고려할 때 참고 : A Dark Energy, Dark Matter Perspective

Step 2 : 마이크로서비스 아키텍처 설계

- 기술 선택 - Kubernetes, 메시지 브로커 등 - 중요

- 결정적으로 중요한 것은 훌륭한 서비스 아키텍처를 설계하는 것

- 조립은 마이크로 서비스 아키텍처를 정의하는 데 사용할 수 있는 아키텍처 정의 프로세스

- 요구 사항을 시스템 운영 및 하위 도메인으로 추출 (dark matter와 dark energy를 사용하여 하위 도메인을 서비스로 그룹화)

- 분산 시스템 운영을 설계

- Assemblage는 기술 아키텍처를 설계할 때 가이드가 되는 마이크로서비스 아키텍처 패턴 언어와 함께 작동

- 대상 마이크로서비스 아키텍처를 정의한 후에는 기존 모놀리식을 리팩터링해야 함

Step 3 : 모놀리식에서 마이크로서비스로 마이그레이션

- 모놀리식 애플리케이션을 마이크로서비스로 마이그레이션하기 위한 6개 원칙

- 한 가지 핵심 원칙은 빅뱅 재작성 없이 Stranger Fig 패턴을 사용하여 마이크로서비스로 점진적으로 마이그레이션하는 것으로 이 패턴을 사용하면 디자인 결정을 신속하게 검증하고 새롭고 유용한 기능을 훨씬 더 빨리 제공 가

- Microservices 적용의 반대 패턴을 피하는 것도 중요

 

서비스로서의 컴포넌트화

• 컴포넌트: 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위
• 컴포넌트화: 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것
• 컴포넌트화는 어떻게?: 소프트웨어를 여러 서비스로 분리하는 것

라이브러리 vs. 서비스

출처 : 코드스테이츠 데브옵스 부트캠프 과정

출처 : 코드스테이츠 데브옵스 부트캠프 과정

비즈니스 수행에 따른 구성, 프로젝트가 아니라 제품

before: 기술적 계층에 따른 팀 분류

• 예) UI 팀, 비즈니스 로직 팀, 데이터베이스 팀
• 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가

출처 : 코드스테이츠 데브옵스 부트캠프 과정

after: 비즈니스 수행 능력(업무 도메인)에 따른 팀 분류

도메인?

- 예) 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인이 됨

- 하나의 온전한 시스템의 단위

팀이 하는 일이 하나의 서비스로 나뉨 → 마이크로서비스

- 장점

• 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적
• 이를 달성하기 위해 각 팀은 서비스에 대한 책임을 가져야 하며 / 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 함

출처 : 코드스테이츠 데브옵스 부트캠프 과정

조직과 아키텍처의 연관성

시스템을 설계하는 조직은, 자신의 조직이 가진 커뮤니케이션 구조를 복제하는 아키텍처 디자인을 만들어 낸다. Mevlyn Conway, 1967

- 콘웨이의 법칙

• 콘웨이의 법칙(Conway's Law)은 소프트웨어 개발에서 조직 구조가 개발되는 소프트웨어 시스템의 구조에 영향을 미친다는 법칙
• 조직 내의 각 부서나 팀은 자신들의 의사소통 구조와 유사한 소프트웨어 아키텍처를 설계하려는 경향이 있음

- 따라서 마이크로서비스로 소프트웨어를 작성할 때에는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 함

- 혹은 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있음 (Dev와 Ops가 함께 만들어가야 함)

 

현명한 엔드포인트와 바보 파이프라인

특징

- "서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다"

- 마이크로서비스에서의 프로세스 간 통신은, "현명한 엔드포인트와 바보 파이프라인" 접근 방식을 따름

- 리눅스 파이프라인의 철학과 흡사

- 서비스와 서비스 사이는 느슨(decoupled)하게, 응집성은 높게

 

대표적인 방법

- REST API (HTTP)

- 메시지 버스를 이용한 메시지 전달 (메시지 큐)

 

분산화 거버넌스, 분산화된 데이터 관리

문제점

- 중앙 집중적인 시스템은 기술을 표준화하는 경향이 있음 (ex) "우리 회사는 Java 9와 Oracle만 사용합니다", "간단한 리포트 만드는 서비스가 필요한데, node.js로 금방 하는 걸 Java를 꼭 써야 해?"

→ 문제 해결에 오히려 방해가 될 수 있음!

 

해결책

분산화된 시스템

- 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적

 > 데이터에 대한 분산 책임이 따름

 > 서비스 데이터베이스 간의 일관성이 중요 → 트랜잭션 협조가 중요

분산화된 응용 프로그램 설계 → 도메인 주도 설계(DDD, Domain-Driven Design)

- 도메인 경계를 분명하게!

 

장애 방지 설계

모놀리틱 설계에 비해 불리한 지점

- 서비스는 언제든지 실패할 가능성이 있음

- 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 함

 > 예) 아키텍처 요소(데이터베이스가 받는 1초당 요청 수)와 비즈니스 관련(1초당 받는 주문 번호와 같은) 부분을 모두 확인

- 대시보드와 모니터링은 필수적임

 

진화하는 설계

컴포넌트 핵심

- 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 함

장점

• 모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요
• 마이크로서비스: 변경한 서비스만 다시 배포 가능
• 간단하고 신속한 출시 프로세스

단점

• 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경 써야 함

 

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

출처 : 코드스테이츠 데브옵스 부트캠프 과정

- 항상 모든 경우에 마이크로서비스 아키텍처가 필요하지는 않음

- 성숙도 모델 중 어떠한 방식을 Level 3단계로 전환한다고 해서 더 나은 서비스가 되는 것도 아님

- 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입할 필요성

• 각 단계에 있어서 해당 방식이 갖는 장단점
• 기존(Legacy) 시스템의 작동 방식
• 현재 시점의 요구사항

 

3. 서버리스

서버리스 등장 배경 및 소개

출처 : 코드스테이츠 데브옵스 부트캠프 과정

웹 애플리케이션 구현

• 적은 예산으로
• 빠르고
• 확장 가능하며
• 관리와 운영은 쉽게
• 혼자

→ 당연히 불가능, 이에 대한 해결책은 서버리스

 

서버리스의 정의

- 서버가 없는 게 아닌 '서버에 대한 고민을 안 하는 것'

- 컴퓨터가 없이 애플리케이션이 돌아갈 수 없으므로, 서버리스는 서버에 대한 고민 없이 애플리케이션 구축에만 집중하는 것

 

컴퓨팅의 진화 과정

서버리스 등장 배경

- 애플리케이션 배포를 위해 직접 하드웨어 서버를 구매 후 구성

- 소프트웨어, 하드웨어 모두 관리할 필요성

- 하드웨어 직접 관리는 이점도 있으나 서버 관리에 비용이 많이 소비되고 메모리를 관리하는 등 불편한 점 존재

- 이후 등장한 AWS 클라우드 컴퓨팅 서비스 EC2 등이 하드웨어 관리의 불안감을 어느정도 해소해주었지만, 빌려서 구성한 서버의 소프트웨어의 보안/업데이트/백업과 같은 많은 관리 과정이 필요

→ 서버리스는 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안

출처 : 코드스테이츠 데브옵스 부트캠프 과정

 

---

데이터센터에서의 물리 서버 -> 데이터센터에서의 가상 서버로 전환

- 활용률 증가

- 프로비저닝 속도 증가

- 높아진 가동 시간

- 재해 복구

- 하드웨어 독립성

데이터센터에서의 가상 서버 -> 클라우드에서의 가상 서버로 전환

- 자본 비용 -> 운용 비용

- 높은 확장성

- 탄력적인 리소스

- 빠른 속도와 민첩성

- 유지보수 비용 감소

- 고가용성과 내결함성

- but, 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업 시 고비용 등의 단점도 존재

 

서버리스의 이점

- 서버 관리 불필요

- 유연한 확장성

- 고가용성

- 유휴 용량 없음

 

생각해 볼 거리

서버리스의 의미

- 서버리스 컴퓨팅(serverless computing)은 클라우드 컴퓨팅 실행 모델의 하나로, 클라우드 제공자는 동적으로 머신 자원의 할당을 관리

- 가격은 미리 구매한 용적 단위가 아닌 애플리케이션이 소비한 자원의 실제 양에 기반을 둠

- 서버리스 컴퓨팅은 여전히 서버가 필요하므로 부적절한 명칭이며  "서버리스 컴퓨팅"이라는 이름이 사용된 이유는 서버 관리 및 용적 계획 결정이 완전히 개발자나 운영자로부터 숨겨져 있기 때문

- 서버리스 코드는 마이크로서비스처럼 전통적인 스타일로 배치(deploy)된 코드와 결합하여 사용 가능

- 대안으로, 애플리케이션들은 순수 서버리스 형태로 작성할 수 있으며 프로비전된 서버를 아예 사용하지 않음

 

마이크로서비스와 서버리스와의 관계

- 마이크로서비스≠서버리스

- 서버리스 컴퓨팅은 마이크로서비스 구조의 개발을 구성하기 위해 매우 적합한 형태의 서비스

- 모든 마이크로서비스가 function 단위로 구성되는 것은 아니지만 서버리스는 function 단위로 구성을 하고, 각각의 서비스는 독립적인 API 형태로 구성하여 배포를 진행하면 마이크로서비스 형태의 애플리케이션이 될 수 있기 때문에 연관성이 있고 적합한 형태의 서비스임

- 서버리스는 마이크로 서비스 구조 개발 구성에 유리하나 항상 서버리스 이용할 필요는 없음

- 다만 Stateless한 서비스의 경우 FaaS는 최적의 도구

 

서버리스가 반영하는 마이크로서비스의 특징들 

- 서버리스와 마이크로서비스는 함수와 API가 독립적인 형태로 구성된다는 특징

 

AWS가 제공하는 서버리스 서비스 종류

마이크로서비스는 꼭 서버리스로 구현되어야 할까?

 

서버리스의 특징 중 하나인 무상태성(Stateless)의 의미

- 일반적으로 마이크로 서비스와 마찬가지로 서버리스 기능은 기본적으로 무상태성

- 무상태성을 통해 서버리스가 일시적이고 확장되며 중앙 장애 지점 없이 복원력을 제공 가능

- 정확히 말하면 무상태성은 FaaS의 특징

- 상태를 가지지 않는 서비스, 예를 들면 로그인

 

서버리스 컴퓨팅의 장단점

장점

- 서버리스 컴퓨팅은 개발자 생산성을 높이고 운영 비용 절감 가능

- 서버 프로비저닝 및 관리와 같은 일상 업무의 부담을 줄여, 개발자가 애플리케이션에 더 많은 시간을 할애 가능

- 서버리스는 개발자가 프로비저닝하기 위한 작업에 필요한 인프라를 명시적으로 설명할 필요를 줄여줌으로써 DevOps 도입을 지원 

- 제3사 BaaS 오퍼링의 모든 구성 요소를 통합해 애플리케이션 개발을 더욱 간소화 가능ㄴ

- 서버리스 모델에서 운영 비용이 낮아지는 이유는 항상 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불하기 때문

단점

- 자체 서버를 실행하지 않거나 자체 서버측 로직을 제어하지 않는 데 따른 단점 존재

- 클라우드 제공업체는 자사 구성 요소가 상호작용하는 방법을 엄격히 제한할 수 있어, 사용자 시스템의 유연성과 커스터마이징 수준에 영향

- BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존할 가능성

- IT 스택의 이러한 측면에 대한 제어 권한을 이전하면 벤더 종속성 문제도 발생 가능

- 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생 가능

 

마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 할까?

- 서비스별로 데이터베이스를 갖도록 설계해야 함

- 각 저장소가 서비스별로 분산되어있어야 하며, 다른 서비스 저장소를 직접 호출할 수 없고 반드시 API를 통해서만 접근해야 함

- 따라서 비즈니스 처리를 위해 데이터 복제, 중복 허용 필요

- 데이터 일관성 문제 발생

 

분산 트랜잭션 이슈

- 분산 트랜잭션 : 네트워크에 존재하는 2개 이상의 시스템 사이에서 발생하는 트랜잭션

- 하나의 트랜잭션이 두개의 시스템에서 연달아 발생할 경우 데이터 일관성 유지가 매우 중요해짐 (ex. 주문, 결제 서비스에서 결제 성공한 경우 주문도 성공되어야 하고 결제 실패한 경우 주문도 취소되어야 함)

 

데이터 일관성 유지 방법 : 결과적 일관성 유지

- 어느 시점에서는 데이터가 서로 다를 수 있으나 결국 모든 시스템이 최신 데이터를 가질 수 있도록 일관성 보장

 

결과적 일관성을 만들기 위한 방법론

1. 메시징 시스템 활용 : 메시지 큐, AWS SQS, Apache Kafka
2. 이기종 데이터베이스 간의 sync 메커니즘(CDC, change data capture) 활용 (Kafka Connect)

 

 

# TIL

FaaS와 Baas

FaaS(Function as a Service) : AWS Lambda

작동원리

- 함수는 런타임이 있어야 실행 가능

- 함수는 클라우드 사업자가 제공하는 (런타임이 담긴) 컨테이너에서 실행

 

지원 언어

• node.js
• Python
• Java
• C#
• Go
• Ruby

 

단점

- 간헐적인 요청: Cold Start(매 요청마다 코드 다운로드, 새로운 컨테이너 실행, 런타임 기동, 코드 실행)

<-> 잦은 요청: Warm Start(코드만을 실행)

 

 

 

# References

챗 GPT

What are microservices?

What are microservices?

https://liveloper-jay.tistory.com/97

마이크로서비스(MicroService)란? _MicroService와 Serverless

https://www.redhat.com/ko/topics/cloud-native-apps/stateful-vs-stateless

스테이트풀과 스테이트리스 비교

https://aws.amazon.com/ko/microservices/

마이크로서비스란 무엇입니까? | AWS

 

https://giljae.medium.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%97%90%EC%84%9C-%EB%8B%A8%EC%9D%BC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%A5%BC-%EB%B6%84%EB%A6%AC%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0-2d3c274bbe39