"그림으로 공부하는 마이크로서비스 구조" 을 읽고 (1장 - 4장)

그림으로 공부하는 마이크로서비스 구조 | 다루사와 히로유키 - 교보문고

 

서론

---

- 마이크로서비스를 단순히 '아키텍처'로만 보는 것이 아니라 더 포괄적인 '아키텍처 패턴'으로 보는 것
- 이 책은 마이크로서비스를 클라우드 네이티브 컴퓨팅 전체를 포함하는 아키텍처 스타일로 정의하고 있으므로, 마이크로서비스와 관련된 클라우드 네이티브 기술에 대해 설명한다.

- 아키텍처 스타일을 적용해 마이크로서비스를 모델화하면 소프트웨어의 구조 설계에 해당하는 마이크로서비스 아키텍처가 중심에 자리한다. 그리고 그 주변에 있는 인프라 / 실행 환경, 개발 / 운영 환경, 개발 / 운영 기법, 애플리케이션 통합 기술이 마이크로서비스 아키텍처를 지탱하는 형태가 된다.

 

1 장, 디지털 전환 : 마이크로서비스가 중요해진 배경

---

Key Point

- 디지털 전환 (Digital Transformation, DT or DX)

- '최신 IT 기술'을 활용하는 것 보다 더 중요한 것은 '비즈니스를 근본적으로 이해하고, 혁신하는 것'에 있다.

-  (투자적 측면) 최신 기술을 사용해서 인프라 표준화를 도모하고 환경 구축, 운영의 효율화와 속도 향상을 목표로 한다. 구체적으로는 표준 기술로 컨테이너에 의한 가상화를 검토한다. 컨테이너와 쿠버네티스 등의 컨테이너 오케스트레이션을 사용해 인프라를 구축, 운영하므로 특정 클라우드 서비스에 종속되지 않고 공통 인프라를 구축할 수 있다.

- (기술적 측면) 마이크로서비스와 테스트 자동화를 근간으로 한 DevOps를 실현하므로써, 개발 / 변경만 신속하게 하는 것이 아니라 자동화를 통해 오류를 줄여 서비스 품질을 향상시킨다.

- (HR 측면)  

 

2장, 클라우드 네이티브 컴퓨팅과 마이크로서비스

---

Key Point

- REST (REpresentational State Transfer)

- SaaS가 성공하면서 다음으로 주목을 받은 것이 SaaS 회사의 IT 시스템 구현 및 운영이다. SaaS 회사는 그간 축적해둔 방대한 트랜잭션을 바탕으로 확장성과 높은 가용성, 안전한 엔드 유저 시스템을 구축할 수 있다고 본 것이다. 여기서부터 서버나 네트워크 등의 컴퓨팅 플랫폼을 클라우드 서비스로 제공하는 IaaS(Infrastructre-as-a-Service)가 등장한다.

- 2006년에 유통 대기업인 아마존(Amazon)이 아마존 웹 서비스(AWS)를 시작했다. AWS와 마이크로소프트를 시작으로 많은 IT회사가 IaaS 시장에 진출하여 대 성공을 거두었고, 자연스레 이와 관련된 서버나 네트워크 가상화 기술, 서버 구성 및 배포 자동화 기술이 새롭게 개발, 추가 되었으며, 기반 구축의 속도 및 품질 향상을 도모할 수 있었다.

- IT 시스템은 인프라(기반)과 애플리케이션(서비스)으로 구성되어 있다. 인프라를 혁신하는 것은 어플리케이션 혁신에 영향을 주며, 그 반대도 마찬가지이다. 클라우드 컴퓨팅을 사용한 인프라 기술 혁신은 파급적인 영향력을 보여주었는데, 그 중 하나가 바로 PaaS다.

- Paas(Platform-as-a-Service), 소프트웨어나 네트워크를 서비스로 제공하는 IaaS에 비해, PaaS는 미들웨어부터 하위 계층의 컴퓨팅 스택을 서비스로 제공한다. 개발자는 OS나 미들웨어 등의 도입과 구성을 신경 쓰지 않고 개발에 집중할 수 있는 것이 가장 큰 장점이다. 
(Ex : Heroku, Cloud Foundry, Google App Engine, AWS Elastic BeansTalk, Ms Azure App Service...)

- 개발 및 운영의 혁신으로 지속적 통합 (CI, Continuous Integration), 지속적 전달 (CD, Continuous Delivery), DevOps, Agile 개발 프로세스가 주목을 받기 시작하였고, 클라우드 컴퓨팅을 형성하는 기법으로 자리잡았다. (애플리케이션 개발 및 운영 속도의 향상과 유연성을 실현하기 위해서)

- IaaS에 의해 인프라 구축이 비약적으로 빨라졌고, 인프라 위에 서비스 개발과 운영에 속도와 유연성을 주기 위해 CI/CD, DevOps 등의 기법이 클라우드 컴퓨팅을 형성하는 기술로 도입.

- 마이크로서비스란, 인프라 구축의 빠른 속도에 맞추어 서비스 개발과 운영 (변경 작업)을 적시에 진행하기 위한 설계, 개발, 운영 기법을 모은 것이다. 독립적으로 개발 및 실행되는 소프트웨어 컴포넌트를 여러 개 조합해서 하나의 서비스로 만드는 소프트웨어 구조에 있다. 각 서비스는 개별적으로 개발되며, 각각 독립적으로 특정 환경에 배포할 수 있는 구조를 가지고 있다. 개별 서비스를 교체하므로 서비스를 간단히 변경할 수 있는 구조이다.

- SaaS -> IaaS -> PaaS로 서비스 계층 혁신이 이루어지고 있다.

- 클라우드 네이티브 컴퓨팅의 목적은 "확장 가능한 서비스를 구축/운영하는 것과 IT 시스템에 최소한의 인력으로 자주, 그리고 계획한 만큼 임팩트가 있는 변경을 추가하는 것" 이다. 이 외에도 비즈니스적 측면에서의 목표가 있으며, 다양한 클라우드를 활용하여 느슨하게 결합된 서비스를 만들어야 한다. 구체적으로 컨테이너, MSA, 오픈소스 사용 등이 있다.

 

3장, 마이크로서비스 아키텍처의 기본

---

Key Point

- MSA의 서비스 구조는 객체 지향에서 객체와 유사

- 레이어 아키텍처 : 특정 기준에 근거하여 여러 계층(레이어)을 만들고 그 계층 구조를 따라 소프트웨어 컴포넌트나 기능을 분류, 관리하는 접근법

    - 레이어 아키텍처로 도메인 주도 설계 (Domain Driven Design, DD)의 4계층 적용이 가능하다

    - 1. 최상위 사용자 인터페이스 계층

        - 렌더링, 요청 / 응답 전송, 데이터 변환 및 이를 담당하는 서비스 배치

    - 2. 애플리케이션 계층

        - 서비스 조율, 도메인 객체 접근, 트랜잭션 관리

        - MSA 에서는 하나의 사용자 요청을 처리하기 위해 도메인 서비스를 여러 번 호출한다. 매번 클라이언트의 서비스 호출로 서비스 지               연이 일어날 수 있기에,  해당 계층의 서비스가 클라이언트 대신 여러 도메인 서비스를 호출하여 네트워크의 양방향 통신을 1회로 줄             여 성능을 향상시킬 수 있다. (Gang of Four, GoF 디자인 패턴의 파사드(facade)에 해당)

    - 3. 도메인 계층

        - 도메인 상태와 동작(비즈니스 로직)을 구현하는 도메인 서비스 배치

    - 4. 인프라 계층

        - 외부 리소스가 타 계층에 접근 가능하도록 지원. DB나 메시징 등 외부 시스템 연동시 사용

- 레이어 아키텍처는 간단하면서 이해하기 쉬워 기능 분할이나 구조화가 쉽고, 소프트웨어 컴포넌트를 조합해 개발하는 설계 방식에 적합하다. 그러나 확장성이 약하다는 단점이 있다. (추상적인 것이 구체적인 것에 의존하기에)

- 레이어 아키텍처의 단점을 보완하기 위해 제어 반전 (Inversion of Control, IoC)라는 개념이 대두

- 구체적으로 콜백이나 의존성 주입 (Dependency Injection, DI)의 기법이 있으며, 이는 객체지향에서 폭넓게 사용되고 있으며, 스프링도 원래는 DI 컨테이너로 시작했다.

- 헥사거널 아키텍처 (hexagonal architecture) : 불특정한 데이터 입출력에 대응할 수 있도록 확장성을 가지는 육각형 형태의 아키텍처

- 도메인(비즈니스 로직)을 중심으로, 주변에 도메인을 호출하는 입력과 실행되는 출력 측이 있다.

- 데이터베이스 간 동기화를 위한 솔루션으로 사가(Saga)가 있다. 사가란 로컬 트랙잭션 이벤트, 보상 트랜잭션 등을 사용해 여러가지 리소스 간 동기화를 취하는 디자인 패턴

- 데이터 결합 : 분산 데이터베이스 환경이 가진 문제 중 하나, 여러 DB에 나누어진 데이터를 하나의 뷰로 구성해서 클라이언트에 제공하려면?

- API 컴포지션 (API Composition) : 도메인 계층의 집약 서비스와 인프라 계층의 레포지토리 서비스를 통해 복수의 DB로부터 얻은 데이터를 APP 계층에서 인메모리로 결합하는 디자인 패턴, 운영 환경 메모리에 부하가 집중되는 단점

- CQRS & 이벤트 소싱 (Event sourcing) : 서로 독립된 디자인 패턴이지만 조합해서 사용되는게 일반적, 데이터 결합 해결책이 될 뿐만 아니라 결과 일관성을 구현하는 새로운 데이터 접근패턴

- CQRS (Command Query Responsibility Segregation, 명령 질의 책임 분리) : 데이터 접근 처리를 갱신형/참조형으로 구분하고 각각의 독립된 서비스 컴포넌트와 저장소를 두는 디자인 패턴. 갱신형 처리에는 영구적 데이터 저장소를 만들어 기능과 신뢰성을 높이고, 참조형 처리에는 고속 검색 기능을 가진 데이터 스토어를 배치

- 이벤트 소싱 : CQRS에서는 갱신형 저장소와 참조형 저장소를 동기화해주는 구조가 없는데, 이를 이벤트 소싱이 해결한다.

- MSA 자체에는 개발 속도를 향상시키는 구조가 없다. 초기 셋업이나 프로젝트 시작시엔 기존 워터폴 형태보다 더 많은 리소스를 요하며, 시간도 많이 걸린다. 이런 MSA를 적용하면서 신속한 개발을 위해 애자일 개발 프로세스를 도입하는 것이다.

- MSA의 모델링을 애자일 개발 프로세스를 사용해서 진행할 때 친화성 좋은 소프트웨어 설계 방식이 DDD, 도메인 주도 개발이다. 도메인 모델을 설계 및 개발 작업의 중심에 두고 반복적으로 변경하고 고도화하며 프로그램을 구현하는 것이다.

- MSA 설계 시 '마이크로'라는 이름 때문에 '반드시 작게 만들어야 하는 것 아닌가' 라는 강박 관념에 사로잡힐 수도 있다. 그러나 MSA에선 의외로 세분화 정도는 문제가 되지 않는다. 유연한 서비스 개발 및 운영이 실현된다면 세분화 정도는 크든 작든 상관 없다. 어차피 세분화 정도나 최적화 정도는 시스템을 운영해봐야 비로소 알 수 있는 것이다. 서비스화는 크게 시작하고 릴리스 후에 주기에 따라 작은 서비스로 분할하는 방법을 추천하는 경우도 많다.

- 모노리스 우선 (Monolith First) : 첫 스프린트에서 핵심 서비스를 모노리스로 설계/개발/릴리 한 뒤 이후 부터 기존 서비스나 신규 기능을 서비스화 하는 방식

 

4장, 마이크로서비스 패턴

---

Key Point

- 데이터 관리 패턴

    - MSA에서는 분산 데이터베이스를 권장 (약하 ㄴ결합)

    - 데이터 동기화 : 분산 데이터베이스 간 데이터 동기화는 어떻게 구현할 것인가

    - 데이터베이스 배치 모델 : 어떤 기준에 근거해서 데이터베이스를 배치할 것인가

    - 데이터 결합 : 분산 데이터베이스에 흩어져 있는 데이터를 어떻게 집약할 것인가

- 서비스별 데이터베이스

    - 장점 : 유연하고 빠른 서비스 변경, 요건에 맞는 최적의 데이터베이스 제품 및 기술 선택

    - 고려 : 결과 일관성, 여러 DB간 데이터 동기화 구조, 여러 DB에 걸쳐있는 데이터를 검색 및 집약하는 구조

- 공유 데이터베이스

    - 통합된 하나의 DB 인스턴스를 복수의 서비스 및 App, 시스템이 공유할 수 있는 DB 배치 패턴

    - 지금까지 우리가 사용해 온 친숙한 DB 배치 모델이라 할 수 있다.

    - 모든 데이터가 단일 데이터베이스에 저장되고, 복수의 데이터 갱신 시 로컬 트랜잭션을 사용, ACID를 유지하고 데이터 일관성 확보

    - 단점 : 유연성 떨어짐, 신속한 변경 불가, 단일 DB에 처리가 집중되고 비관적 락에 의한 성능 저하, 확장시 서버를 스케일업 해서 대응

- 코레오그래피 (choreography)

    - DB에 접속하는 서비스가 각각 메시징 제품을 통해 데이터를 동기화

    - 각 서비스가 자립/능동적으로 사가 프로세르를 돌리는 것이 크레오 그래피

    - 구조가 단순하나, 각 서비스와 DB 간 연계를 한 눈에 파악하기 어렵고, 진행 상태를 확인하기 어렵다. 관심사 분리가 저해된다.

- 외부 API 패턴

    - MSA에서 비즈니스 애플리케이션을 설계 및 개발할 때 다양한 클라이언트와 연동하기 위한 패턴

    - MSA에선 하나의 애플리케이션이 여러 개의 서비스로 구성된다, 하나의 작업을 하기 위해 여러 개의 서비스를 호출해야 한다.

    - 이 때, 외부에서 접속할때 발생하는 문제점 (서로 다른 프로토콜 간 통신, 네트워크 지연 등)을 해결해야 한다.

    - 통신 프로토콜 교환 및 교차, 통신 횟수 최소화, 호출 횟수 최소화 등의 해결방안이 필요

    - API 게이트웨이 패턴

         - 도메인 경계에 클라이언트 처리를 담당하는 전용 서비스 API를 설치하는 것

         - 클라이언트 대신에 주문용 API 게이트웨이가 여러 서비스를 대신 호출하는 것

         - 클라이언트와 서비스 간에 API 게이트웨이라는 하나의 완충제를 마련하여 영향을 최소화 할 수 있음

         -  DDD의 GoF 디자인, Facade에 해당된다.

- 통신 패턴

    - REST는 요청/응답 및 동기형 통신 고유의 다양한 문제가 있음. 이를 해결하기 위해 다양한 프로토콜과 통신 상태가 필요하여 멱등성(실행 횟수와 무관하게 언제나 같은 결과를 보장하는 특성)도 고려해야 한다.

    -  원격 프로시저 호출 (Remote Procedure Invocation, RPI)

         - 쉽고 간단하며 범용적이나, 동기형 통신으로 확장성이 약하고 복잡+오래 걸리는 처리에는 부적합.

         - 로직이 복잡하고 지연시 응답 연장, 서버 리소스 고갈로 인한 장애 파생

    - 메시징 (messaging)

         - 발행자와 구독자(컨슈머)가 이벤트(메시지)를 통해 통신하는 모델

         - MOM 또는 메시지 브로커를 통해 이벤트나 메시지를 비동기적으로 전달한다.

         - 메시징 패턴을 활용하므로 일방향&비동기형, 요청/응답&동기형, 요청/응답&비동기형 등 통신 형식을 취할 수 있다.

    - 도메인 특화 프로토콜

         - 특정 상황에 맞는 고유 프로토콜을 적용하는 디자인, 메일 전송 같은 경우 SMTP, POP, IMAP 등

    - 멱등 (Idempotent) 소비자

         - 의도하지 않는 운영이나 작업 시에도 멱등성을 보장하는 통신 패턴

         - DB와 간단한 확인 로직을 조합하여 멱등 소비자를 구현할 수 있다.