챕터 1을 공부하며 느낀 점

역시 챕터 1은 날먹이다.
대부분 실무에서도 적용하고 있는 기법들이었으나 서킷 브레이커의 경우 사용해본적이 없어서 상당히 기대가 됨.
회사에서 당연하게 하고 있는 것들을 용어로 접하니까 새로운 느낌임. 선대 개발자들이 구축해놓은 시스템들이 다 이런 이유를 갖고 있었구나~ 라고 다시 한 번 느끼게 되는 계기가 되었음.

마이크로서비스 소개

마이크로서비스가 모든 문제를 해결하는 해결책은 아니다.

독립된 소프트웨어 컴포넌트의 장점

MSA에서의 각 컴포넌트는 독립적으로 배포, 업그레이드할 수 있다.
다른 컴포넌트와 상관 없이 여러 인스턴스로 Scale-Out 할 수 있다. (앞단에 보통 LB를 둔다.)

독립된 소프트웨어 컴포넌트의 단점

컴포넌트의 새 인스턴스를 추가하면 수동으로 로드밸런서를 구성하고 새 노드를 수동으로 설정해주어야한다. ( k8s service )
다른 시스템에서 문제가 발생할 경우 오류가 전이된다. 이런 현상을 Chain of Failure라고 부른다. ( Circuit Breaker )
각 컴포넌트들의 최신화를 위한 많은 유지보수 비용이 들어간다. ( 개발자 많이 뽑으셈 )
모니터링이 더 어렵다. ( Grafana )
분산된 여러 컴포넌트에서의 로그 파일을 수집하고 로그 컴포넌트를 상호 연결시키는 것이 어렵다. ( EFK )

마이크로서비스의 정의

빠르게 개발해 지속적으로 배포할 수 있어야 한다.
수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다.
MSA에서 각 컴포넌트는 아무것도 공유하지 않는 아키텍처를 유지해야한다. 즉 MSA의 각 컴포넌트들은 DB를 공유하지 않는다.
명확한 인터페이스를 통해서만 통신한다. 동기식 서비스를 사용하거나, API를 이용한 메시징 방식을 사용할 수 있는데, 버전 관리 전략에 따라 문서화되어야한다.
런타임으로 배포되어야 한다.
MSA 인스턴스는 Stateless 해야한다. 모든 마이크로서비스 인스턴스가 마이크로서비스로 들어오는 요청을 처리할 수 있다.

마이크로서비스의 문제

동기식 통신을 사용하는 다수의 소형 컴포넌트들은 Chain of Failure를 일으킬 수 있다.
다수의 소형 컴포넌트를 최신 상태로 유지하는건 어렵다. (아 개발자 많이 뽑으라고 ㅋㅋ)
로그를 수집하고 분석하기가 어렵다.
하드웨어 자원 사용량 분석도 어렵다.
소형 컴포넌트들을 수동으로 관리하는건 비용이 많이 들고 오류도 발생하기 쉽다.

MSA 디자인 패턴

디자인 패턴은 오래된 개념이다. 특정 상황에 발생하는 문제에 대해 재사용 가능한 해결책을 정리한 것이다.
Service Discovery
Edge Server
Reactive Microservice
Central Configuration
Centralized Log Analysis
Distributed Tracing
Circuit Breaker
Control Loop
Centralized Monitoring And Alarm

Service Discovery

Service Discovery 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

클라이언트가 MSA와 그 인스턴스를 찾을 수 있어야한다.

Service Discovery의 해결책

보통은 서버측에서 Reverse Proxy를 노출시켜서 클라이언트의 요청을 처리할 적절한 인스턴스로 요청을 전달한다.

Edge Server

Edge Server 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

MSA의 컴포넌트는 일부만 외부에 공개하고 그 외의 MSA는 외부에서 접근하지 못하도록 숨기는게 일반적이다.
그 이유는 악의적인 클라이언트의 요청으로부터 보호하기 위함이다.

Edge Server의 해결책

모든 요청이 거치는 새 컴포넌트 (Edge Server)를 추가한다.

Reactive Microservice

Reactive Microservice 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

블로킹 I/O 기반의 API를 사용하면 동시 요청 수가 증가하거나 요청과 관련된 컴포넌트가 증가하면 OS의 가용 쓰레드가 부족해 응답 시간이 늦어지거나 서버가 중단될 수 있다.

Reactive Microservice의 해결책

논블로킹 I/O를 사용해 DB나 다른 MSA가 처리하기를 기다리는 동안 스레드가 할당되지 않게 한다.

Central Configuration

Central Configuration 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

애플리케이션은 일반적으로 환경 변수나 설정 파일에 담긴 구성 정보와 함께 배포되는데 이를 한눈에 보려면 어떻게 해야하나?

Central Configuration의 해결책

모든 MSA의 구성 정보를 저장하는 새 컴포넌트를 추가한다.(?)

Central Configuration에 대한 여담

이 문제는 실제 우리 회사에서도 있는데, 실제 배포된 서비스에서 배포된 application.properties를 확인하고 싶은데 방법이 없음. 어떻게 하면 좋으려나? ( API로 만들어놔야 하나..? )

Centralized Log Analysis

Centralized Log Analysis 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

로컬 머신에 애플리케이션의 로그가 쌓이는데 이를 어떻게 관리해야하나?

Centralized Log Analysis의 해결책

중앙화된 로그 관리 컴포넌트를 개발한다.

Distributed Tracing

Distributed Tracing 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

외부 호출을 처리하는 동안 MSA 내부에 흐르는 요청 및 메시지를 추적할 수 있어야 한다.

Distributed Tracing의 해결책

요청과 메시지에 대한 Correlation ID를 넣어야하고 모든 로그 이벤트에 이 ID가 있어야한다.

Circuit Breaker

Circuit Breaker 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

동기 방식으로 상호 통신하는 MSA는 연쇄 장애가 발생할 여지가 있다.
하나의 MSA가 응답하지 않으면 MSA의 클라이언트에게 응답하지 않게 된다.

Circuit Breaker의 해결책

서비스에 문제가 감지되면 시간 초과를 무시하고 바로 실패하도록 서킷을 연다.
half-open-circuit 반열림 서킷이라고도 하는 장애 복구형 probe를 사용한다. 즉 서비스가 정상 동작하는지 주기적으로 요청을 보낸다.
프로브가 서비스의 정상 동작을 감지하면 서킷을 닫는다.
이런 기능은 시스템 환경을 탄력적으로 만들어 자가 치유를 가능케 하는 매우 중요한 기능이다.

Control Loop

Control Loop 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

다수의 MSA에서는 중단되거나 지연된 인스턴스를 수동으로 감지하고 대처하는 것이 어렵다.

Control Loop의 해결책

MSA 컴포넌트들의 상태를 관찰하는 새 컴포넌트인 Control Loop를 시스템 환경에 추가하여 관찰하게 한다.

Centralized Monitoring And Alarm

Centralized Monitoring And Alarm 패턴은 다음과 같은 문제점과 솔루션이 존재한다.

선행 문제점

응답 시간이나 하드웨어 자원 사용량이 지나치게 높은 경우 문제의 근본 원인을 찾는 것이 매우 어렵다.
MSA별 하드웨어 자원 사용량을 분석할 수 있어야 한다.

Centralized Monitoring And Alarm의 해결책

인스턴스가 사용하는 자원에 대한 Metric을 수집하는 새로운 컴포넌트를 시스템 환경에 추가한다.

느낀점

정의들에 대한 내용을 요약해놓은 느낌이라 술술 읽혔다.
평소에 많이 들어봤던 내용이라서 친숙했고, 챕터 1 다읽고 나니까 시험 전날에 수업 내용 머리속에 정리한 느낌
독립 소프트웨어 컴포넌트의 문제점으로 지적된 부분에 대한 해결책을 생각해보게 되었다.

독립 소프트웨어 컴포넌트

하나의 플랫폼을 여러 개의 독립적인 기능을 하는 컴포넌트를 분리함
분리된 컴포넌트는 서로 정해진 규격의 API 통신을 통해 상호작용

독립 소프트웨어 컴포넌트의 장점

API 인터페이스만 맞추면 일부분만 기존 시스템과 통합하여 사용 가능
플랫폼의 기능 일부를 기존 시스템으로 취사선택 가능
플랫폼의 일부 기능만 개별 배포 및 버전 업 가능
필요한 부분만 스케일 아웃_Scale-out 가능

독립 소프트웨어 컴포넌트의 문제

새 인스턴스를 추가하려면 수동으로 로드밸런서를 구성해야한다

=> 클라우드 환경에서 지원하는 Auto Scaling을 통해 해결 가능. k8s의 Service
한 컴포넌트에서 오류가 발생했을 때 전체적인 시스템에 장애가 발생할 수 있다.
- 어떠한 이유로 응답 처리가 늦어지게되면, 물고있는 커넥션 수가 너무 많아질 수 있다.
- 더 최악으로 timeout에 대한 failover를 하기 위해 retry를 하다보면 그에 대한 처리도 가중되면서 네트워크 혼잡도가 너무 높아지게 된다. 이는 결국 시스템 전체의 장애로 번진다.
- 처리를 위한 스레드들이 전부 running 상태가 되어 OS 스레드가 고갈되어 컴포넌트가 뻗어버린다 (...)
=> Circuit Breaker로 해결할 수 있다. 스프링 클라우드 넷플릭스 OSS의 Hystrix 등등..

=> 또한, Failover를 위해 사용하는 retry backoff를 최대한 넉넉하게 잡아서 Retry storm을 제거한다. Exponential backoff 참조
코드 재활용이 힘들고, 최신 상태로 유지하는 작업이 많이 힘들다.

=> 코드 재활용은 멀티모듈로 해결 가능

=> 컴포넌트를 유지보수하는 일이 어렵다는 점은 MSA의 가장 치명적인 단점이라고 많이 지적받는 부분.

=> MSA 도입을 꺼리게 되는 이유가 '요구사항이 변경되어서 컴포넌트를 수정해야하는데 개발자가 퇴사해버려서 히스토리 파악이 너무 어려운 상황' 같은 것 때문인데, MSA를 적극적으로 도입한 회사의 사례를 들어보면 '남은 개발자들이 기능을 다시 새로 짜면 되는 것'으로 해결한다고 한다(...) 결국 사람 뽑아서 해결한다는 마인드
로깅 및 모니터링이 힘들다.

=> 초창기에는 몰라도 요즘은 로그를 수집하는 인스턴스를 따로 둬서 ES로 검색할 수도 있고 Grafana와 같이 metric으로 비주얼라이징할 수 있는 툴이 많이 있다.
트랜잭션 추적 및 관리가 힘들다. 즉, 사용자가 요청을 보냈을 때, 내부적으로 어떤 어떤 컴포넌트들을 거쳤는지 추적하기가 많이 어렵다.

=> 모든 컴포넌트 간의 통신에 트랜잭션 ID를 부여해서 각 요청들을 Elastic Search에 넣고 추적하면 가능하긴 하다. 하지만, 컴포넌트 간의 통신 프로토콜을 HTTP로 통일해야하거나 하는 제약조건이 붙게된다.

마이크로서비스 입문

성능은 늘려야겠고.. 하지만, 수직 스케일링의 한계가 있어서 너무 비싸고..
그렇다보니 하나의 프로젝트를 작은 컴포넌트 여러개로 나눠서 수평 스케일링 방식이 주목받게 되었다
많은 선구자들이 MSA의 기반을 만들기 위해 여러가지 시도를 했다.
- Netflix OSS를 래핑해서 Spring Cloud를 만들어서 MSA의 여러 문제점들을 해결하는 기능들을 제공한다.
- 도커는 컨테이너 엔진을 사용해서 환경 분리를 이뤄냈다.
- 쿠버네티스, 아마존 ECS, 도커 스웜 등 컨테이너들을 활용하는 툴들이 많이 출현했다. 고가용성을 제공하기 위해서 컨테이너를 오케스트레이션 하는 툴들이 필요했기 때문이다.
- 서비스 메시(ex. Isito)를 사용해서 k8s의 부족한 편의성을 보완할 수 있다.

마이크로서비스 정의

빠르게 개발해 지속적으로 배포할 수 있어야 한다.
수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다.

MSA는 위 두 가지를 목표로 한다

독립 컴포넌트 정의

아무것도 공유하지 않는 아키텍처를 유지해야한다. DB의 데이터를 공유하지 않는다.
명확한 인터페이스를 통해서만 통신해야 한다. 각 컴포넌트 간에 통신하는 인터페이스는 버전 관리 전략에 따라 문서화되고 유지보수되어야한다.
개별적인 런타임 프로세스로 배포해야한다.
인스턴스는 상태가 없어야 한다. 모든 마이크로서비스 인스턴스가 모든 요청에 대해서 처리할 수 있어야 한다.

독립 컴포넌트들을 활용해서 아키텍처를 구성하면 MSA는 분산 애플리케이션과 같은 형태를 띄게 된다.

분산 컴퓨팅의 여덟가지 오류

피터 도이치^{Peter Deutsch}가 언급한 분산 애플리케이션을 처음 구축할 때 가정하는 8가지. 고통스러운 학습 경험을 통해 8가지가 다 틀렸다는 걸 깨닫게 된다고 한다(...)

네트워크는 안전하다.
네트워크 지연은 0이다.
대역폭은 무한하다.
네트워크는 안전하다.
토폴로지는 변하지 않는다.
관리자는 1명이다.
전송비용은 0이다.
네트워크는 균일하다.

마이크로서비스 디자인 패턴

1977년, 크리스토퍼 알렉산더^{Christopher Alexander}가 MSA의 특정 상황에서 발생하는 문제에 대한 해결책으로 제시한 디자인 패턴

서비스 검색^{Service Discovery}
에지 서버^{Edge Server}
리액티브 마이크로서비스^{Reactive Microservice}
구성 중앙화^{Central Configuration}
로그 분석 중앙화^{Centralized Log Analysis}
분산 추적^{Distributed Tracing}
서킷 브레이커^{Circuit Break}
제어 루프^{Control Loop}
모니터링 및 경고 중앙화^{Centralized Monitoring and Alarm}

참고로 이 외에도 더 많지만, 책에서는 최소한 필요한 패턴들만 나열했다.

서비스 검색

클라이언트가 마이크로서비스와 그 인스턴스를 찾을 수 있어야 한다.

문제점

마이크로서비스 인스턴스가 시작되면서 동적 IP를 할당받는다.
동적 IP는 상황과 시간에 따라 변할 수 있기 때문에 클라이언트는 인스턴스에 접근하기 위해 노출된 포인트가 있어야한다.

해결책

현재 사용가능한 인스턴스를 추적하는 새 컴포넌트(서비스 검색 서비스)를 시스템 환경에 추가한다.

인스턴스를 서비스 검색 서비스에 자동으로 등록하고 해제하도록 한다.
클라이언트가 인스턴스에 접근할 수 있는 엔드포인트를 노출해야한다.
- 엔드포인트로 들어온 클라이언트의 요청을 인스턴스에 라우팅도 되야함.
로드밸런서의 기능도 해야한다. 가용 리소스가 있는 인스턴스에 라우팅.

구현 방식

Client-side Routing : 클라이언트가 서비스 검색 서비스와 통신할 수 있는 라이브러리를 사용해 인스턴스를 찾는 방식
Server-side Routing : 서버 쪽에 리버스 프록시^{Reverse Proxy}를 두어서 요청을 받고 로드밸런싱

에지 서버

공개된 마이크로서비스는 악의적인 클라이언트의 요청으로부터 보호해야 한다.

문제점

모든 인스턴스들이 외부에 노출되면 보안상 취약하게 된다.
외부와 통신하는 일부 엔드포인트만 공개하고 나머지는 내부에 숨겨야 한다.

해결책

클라이언트로부터 들어오는 모든 요청이 거치는 컴포넌트(에지 서버)를 추가한다.

외부에 노출되지 않는 내부 서비스들을 숨긴다.
JWT, OIDC, OAuth 등 인증방식들을 사용해서 인가 받지 않은 악의적인 클라이언트들을 걸러낸다.

리액티브 마이크로서비스

동시 요청 수가 증가하거나 연산량이 많아질 때 가용 스레드가 부족해서 응답이 늦어지거나 서버가 중단되는 문제를 해결해야 한다.

문제점

관례적으로 HTTP 기반의 RESTful JSON API와 같은 블로킹 I/O 모델을 사용해 동기식 통신으로 구현되어 왔다.
동시에 요청이 많아지거나 처리량이 많아질 때, 블로킹 I/O로 인해 스레드들을 모두 사용해 고갈될 수 있다.
- 응답이 느려지거나 서버가 중단되어 버리는 상황이 발생할 수 있다.

해결책

논블로킹 I/O를 사용해 데이터베이스나 다른 마이크로서비스가 처리하길 기다리는 동안 스레드가 할당되지 않도록 한다.

비동기를 사용해서 메시지를 보낸 후 수신자가 메시지를 처리하길 기다리지 않도록 한다.
스레드 할당 없이 동기식 요청을 실행하는 리액티브 프레임워크를 사용한다.
- ex. Spring WebFlux
서비스가 중단되더라도 응답할 수 있도록 설계해야한다. 또한, 중단되었던 서비스가 다시 살아나면 다시 사용가능하도록 자가 치유^Self-healing되어야 한다.

구성 중앙화

현재 배포된 모든 인스턴스의 구성 정보를 한눈에 관리할 수 있어야한다. 또한, 구성 변경 시 한번에 자동화가 되어야 한다.

문제점

배포되어있는 인스턴스가 엄청 많은 경우, 각 인스턴스에 적용된 구성 정보를 한번에 파악할 필요가 있다.
구성이 바뀌어서 업데이트가 필요한 경우 한번에 전부 변경할 필요가 있다.

해결책

구성 정보를 저장하고 동기화하는 컴포넌트(구성 서버)를 추가한다.

로그 분석 중앙화

인스턴스들이 기록하는 로그들을 한번에 모아서 분석이 필요하다. 사용자의 요청이 어떤 인스턴스들을 거쳤는지 트랜잭션 추적이 필요하다.

문제점

각 인스턴스 로컬에 로그 파일을 기록하는 상황에서 모든 인스턴스의 로그를 통합해서 관리할 필요가 있다.
문제가 발생한 인스턴스를 추적해서 로그 파일을 확인할 필요가 있다.
사용자의 요청이 어떤 흐름으로 인스턴스들을 타고 들어갔는지 트랜잭션 추적이 필요할 때가 있다.

해결책

로그를 중앙화 해서 관리한다. 로그를 수집하는 컴포넌트를 하나 추가한다.

인스턴스의 로그 이벤트를 수집한다.
수집된 로그를 해석해서 구조적이고 검색 가능한 형식으로 저장한다.
로그를 조회하고 분석하기 위한 비주얼라이징 툴과 API를 제공한다.

분산 추적

시스템 환경에 대한 외부 호출을 처리하는 동안 서비스 사이에서 흐르는 요청 및 메시지를 추적할 수 있어야 한다.

문제점

사용자가 특정 장애에 대한 해결을 요청했을 때, 어떤 서비스가 문제인 것인지 원인 파악을 위해 추적할 필요가 있다.
특정 엔티티에 관련된 문제를 지원하기 위해 모든 관련 로그 메시지를 찾을 필요가 있다.
- 어떤 주문번호에 대한 문제를 해결하기 위해 해당 주문번호와 관련된 모든 서비스의 로그 메시지를 확인해야할 필요가 있다.

해결책

모든 요청 및 메시지에 상관 ID^{Correlation ID}를 넣고 로그에 기록한다.

중앙 로그 서버에서 ID를 가지고 검색하면 모든 로그 이벤트를 찾을 수 있게된다.
모든 수신 요청과 이벤트에 고유 상관 ID를 할당한다.
외부에서 요청이 인입되거나 보내야할 때는 항상 추적을 위한 ID를 넣도록 한다.

서킷 브레이커

인스턴스가 응답하지 않거나 처리가 느려지는 경우, 다른 서비스들에도 장애가 전파될 위험이 있어서 이를 차단해야한다.

문제점

동기 방식으로 통신을 할 때, 응답이 느려지거나 처리가 많아지면 대기하는 스레드가 많아져서 서버가 중단되어 버릴 수 있다.
서버가 중단되면 다른 서비스들에도 영향을 줄 수 있기 때문에 요청을 처리 못하는 경우 부분적으로 바로 응답을 주어 장애가 다른 서비스로 전파되는 것을 중단 시킬 수 있다.

해결책

대상 서비스에 문제가 있다는 것을 감지해서 더이상 요청을 보내지 않도록 차단한다.

단시간 내에 많은 요청이 몰려서 처리 못한 요청이 많아지면 타임아웃을 무시하고 바로 실패로 응답하도록 서킷 브레이커를 추가한다.
반열림 서킷^{Half-open circuit}라고 하는 장애 복구용 프로브를 사용한다. 서비스가 정상 동작하는지 확인하고자 주기적으로 요청을 보내는 프로브를 사용한다.
다시 동작이 가능해지면 서킷을 닫아서 정상동작하도록 한다. 즉, 자가 치유 가능하도록 탄력적인 기능을 제공한다.

제어 루프

여러 서버에 분산되어 있는 시스템에서 중단되거나 지연된 인스턴스를 자동으로 감지하고 자동으로 조치할 필요가 있다.

문제점

분산되어 있는 시스템에서 중단되거나 지연되는 인스턴스를 수동으로 파악하기 매우 어렵다.

해결책

시스템 환경의 상태를 관찰하는 컴포넌트(제어 루프)를 추가한다.

추가된 컴포넌트는 현재 상태가 지정된 상태와 일치하는지 지속적으로 관찰한다.
상태가 다른 서비스가 발견된 경우, 설정된 상태와 동일하게 맞추도록 자동으로 조치를 취한다.

모니터링 및 경고 중앙화

응답시간이 너무 느리거나 하드웨어 사용량이 너무 높은 경우 근본 원인을 찾는 것이 매우 어렵다. 따라서, 자원 사용량을 모니터링할 수 있어야한다.

문제점

하드웨어 사용량이 지나치게 많거나 응답시간이 느릴 때 파악을 위해 모니터링이 필요하다.

해결책

인스턴스의 하드웨어 리소스 사용량에 대한 메트릭 수집을 하는 컴포넌트(모니터 서비스)를 추가한다.

오토 스케일링^Auto-scaling된 서버를 포함해 시스템에서 사용하는 모든 서버의 메트릭을 수집한다.
새로 시작된 서비스의 인스턴스를 감지해 메트릭을 수집한다.
수집한 메트릭을 조회 및 분석하기 위한 비주얼라이징 툴과 API를 제공해야한다.

MSA 디자인 패턴 Cheat Sheet

위에서 소개된 디자인 패턴들에 대한 해결책을 각 플랫폼별로 정리한 시트다.

디자인 패턴	스프링 부트	스프링 클라우드	쿠버네티스	이스티오(Istio)
서비스 검색		Netflix Eureka, Netflix Ribbon	`kube-proxy`, Service
에지 서버		Spring Cloud, Spring Security OAuth	Ingress Controller	Ingress Gateway
리액티브 마이크로서비스	Spring Reactor, Spring WebFlux
구성 중앙화		Spring Config Server	ConfigMap, Secret
로그 분석 중앙화			EFK 스택 (ElasticSearch, Fluentd, Kibana)
분산 추적		Spring Cloud Sleuth, Zipkin		Jaeger
서킷 브레이커		Resilience4j, Hystrix		Outlier detection
제어 루프			Controller Manager
모니터링 및 경고 중앙화			Grafana, Prometheus	Kiali, Grafana, Prometheus

다른 부분 주요 고려사항

데브옵스^DevOps : 개발과 운영조직이 긴밀하게 협업해서 새 버전을 지속적으로 전달할 수 있게 해야한다.
- 다양한 환경에 빌드부터 테스트, 패키징, 배포가 자동화되는 딜리버리 체인 자동화가 필수적이다.
조직 구성과 콘웨이 법칙

소프트웨어 구조는 그 소프트웨어를 개발한 조직의 의사소통 구조를 반영한다. - 멜빈 콘웨이^{Melvyn Conway}, 1967
- 기존 접근 방식에 따라 전문선 기반의 IT팀을 구성하면 3계층 애플리케이션이 나온다. (UI, 비즈니스 로직, DB)
- MSA를 기반으로 전달하려면 관련 서비스 집합을 한 팀에서 맡도록 조직을 정비해야한다.
- 각 팀은 비즈니스 로직을 위한 언어나 프레임워크, 데이터 저장을 위한 DB 기술 등 담당 서비스에 필요한 기술을 보유한다.
일체형 애플리케이션을 마이크로서비스로 분해
- 가장 어렵고 비용이 많이 드는 방식이다.
- 제대로 분해되지 않으면 생기는 문제
- 느린 전달 : 비즈니스 요구사항이 변경되면 서비스에 많은 영향을 미치기 때문에 추가작업이 발생한다.
- 성능 저하 : 여러 서비스 간에 많은 요청이 오가야하므로 느려진다.
- 일관성 없는 데이터 : 데이터가 나뉘기 때문에 시간이 지남에 따라 보유한 데이터와 다른 마이크로서비스가 관리하는 데이터가 어긋나게 된다.
- 적절한 경계를 찾기 위해서는 도메인 주도 설계^{Domain-Driven Design}와 경계가 있는 콘텍스트^{Bounded Context}를 적용하는 게 좋다.
경계가 있는 콘텍스트란? 서브 시스템이나 특정 팀의 담당 업무와 같은, 특정 모델을 정의하고 적용할 수 있는 경계를 명시한 것 - 에릭 에반스^{Eric Evans}
API 설계 : 외부에서 마이크로서비스에 접근하는 공통 API를 공개하는 경우 쉽게 이해할 수 있도록 설계해야한다.
- 여러 API에서 동일한 개념을 사용하는 경우에는 이름과 데이터 유형에 대한 설명이 일치해야한다.
- API를 변경할 때는 통제된 방식을 사용한다.
- 버저닝이 되도록 적절한 버전 관리 스키마를 적용해야 한다.
- 클라이언트가 여유있게 마이그레이션할 수 있도록 여러 버전의 주요 API를 일정 기간 제공해야 한다.
온프레미스에서 클라우드로 마이그레이션
- 대부분의 클라우드 공급자는 관리형 쿠버네티스^{Kubernetes as a Service}를 제공한다.
- 그러므로, 온프레미스에서 쿠버네티스를 구성해서 워크로드를 구성한 뒤에 클라우드 공급자가 제공하는 쿠버네티스로 재배치하는 마이그레이션 전략이 매력적이다.
마이크로서비스를 위한 설계 원칙
- 클라우드 애플리케이션의 열두 가지 요소는 클라우드에 배포가능한 소프트웨어를 구축하기 위한 설계 원칙이다.

느낀 점

이번 회사 신규 프로젝트에 Spring Cloud를 도입하며 찾아본 내용이 많긴 했지만, 체계적으로 공부해본 적이 없어 스터디에 합류하였다. 확실히 책으로 공부를 하니 MSA의 장단점, 모놀리틱의 장단점, MSA를 이루기 위해 필요한 구성 요소, 디자인패턴 등을 체계적으로 공부할 수 있어 좋은 것 같다

기타

51p. 분산 컴퓨팅의 여덟가지 오류에서 1. 네트워크는 안전하다와 4.네트워크는 안전하다가 같아서 문서를 찾아보니, 1번은 reliable(신뢰할 만한)이고, 4번은 secure(보안상 안전한)이었음
58p. 구성 중앙화의 한 예시로, 우리 회사에서는 보안상의 이유로 주기적으로 DB 비밀번호를 교체함. 이 때 구성 중앙화를 하지 않으면 서버의 코드마다 DB 비밀번호를 변경하고 재배포해야하는 이슈가 있음. 구성 중앙화를 이룬다면 훨씬 간단하게 변경 가능.

남은 의문점
48p. 동기 서비스를 사용하거나 API를 이용한 메시징 방식?
49p. 왜 일체형 서버는 대형 서버에 배포해야하는가?
- 일체형서버도 작은 서버 여러개 나눠서 배포하고 로드밸런싱하면 되지 않는가?

01. 마이크로서비스 소개

느낀점

기존에 회사에 떠있는 프로젝트, 그리고 내가 편하게 사용하는 것들을 마이크로서비스 디자인 패턴에 대입해보면서 읽으니 조금 더 체계적이고 깊게 이해할 수 있게 됐다.

독립 소프트웨어 컴포넌트의 장점

하위 호환성 유지

독립 소프트웨어 컴포넌트의 문제

Monolithic 방식과 비교하여 Microservice 방식에서 생기는 문제
1. 컴포넌트 새 인스턴스 추가를 위해 새 노드 및 로드 밸런서를 수동으로 구성해야 한다.
2. 오류 발생의 전이. 제 시간에 응답하지 않을 경우 OS 스레드와 같은 주요 자원이 부족해진다. 한 컴포넌트의 중단은 연속적인 오류를 유발한다. 이를 연쇄 장애라고 한다.
3. 모든 컴포넌트 인스턴스의 구성을 일관성 있게 최신 상태로 유지하는 작업의 어려움에 따른 품질 문제
4. 지연 시간 문제 및 하드웨어 사용량 측면에서 모니터링하는 작업은 Monolithic 애플리케이션보다 복잡
5. 분산된 여러 컴포넌트에서 로그 파일을 수집하고 관련된 컴포넌트 로그 이벤트를 상호 연동시키는 작업이 어렵다. ( 컴포넌트의 수를 미리 알고 있다면 실현 가능 )

마이크로서비스 입문

Monolithic의 Scale-up 한계 → 앞단에 로드 밸런서를 배치하고 여러 개의 소형 서버에 작은 컴포넌트 배포하여 Scale-out 가능
마이크로서비스 기반 아키텍처에 대한 문제 해결에 도움을 주는 프레임 워크
- Spring Cloud : 동적 서비스 검색, 구성 관리, 분산 추적, 서킷 브레이커 등의 기능 제공
- Docker : jar 과 같은 배포 가능한 런타임 아티팩트뿐만 아니라 컨테이너로 실행할 수 있는 이미지로 컴포넌트를 패키징하여 실행 가능
- Kubernetes(Container orchestrator) : 컨테이너를 실행하고 여러 대의 서버로 확장하는 고가용성을 지원하고 컴퓨팅 자원을 추가할 수 있는 기능 제공
- Service mesh : Container orchestrator를 보완해 마이크로서비스의 관리 편의성과 탄력성을 높임

마이크로서비스 정의

마이크로서비스 아키텍처의 두 가지 목표
- 빠르게 개발, 지속적 배포
- 수동 혹은 자동으로 쉽게 스케일링
독립 컴포넌트로 동작하기 위한 기준
- 아무것도 공유하지 않는 아키텍처 유지, 즉, 데이터를 공유하지 않는다.
- 명확한 인터페이스를 통해서만 통신, API를 이용한 메시징 방식에서 메시지 형식은 버전 관리 전략에 따라 안정적으로 문서화되고 개선돼야 한다.
- 개별적인 런타임 프로세스로 배포, 각 마이크로서비스 인스턴스는 도커 컨테이너와 같이 독립된 런타임 프로세스로 실행해야 한다.
- 마이크로서비스 인스턴스는 Stateless, 따라서 모든 마이크로서비스 인스턴스는 마이크로서비스로 들어오는 요청을 처리할 수 있다.
마이크로서비스의 규모
- 개발자가 다룰 수 있을 만한 크기 ( 애매하다.. )
- 성능(대기 시간)이나 데이터 일관성을 저해하지 않을 정도의 규모

마이크로서비스의 문제

트래픽이 많은 상황에서 동기식 통신을 사용하는 다수의 소형 컴포넌트의 연쇄 장애 문제
다수의 소형 컴포넌트의 최신 상태 유지 어려움
많은 컴포넌트가 처리에 관여하는 요청에 대한 추적 어려움
컴포넌트 수준의 하드웨어 자원 사용량 분석 어려움
다수의 소형 컴포넌트를 수동으로 관리할 경우의 비용, 오류
분산 컴퓨팅의 여덟 가지 오류
1. 네트워크는 안전하다.
2. 네트워크 지연은 0이다.
3. 대역폭은 무한하다.
4. 네트워크는 안전하다.
5. 토폴로지는 변하지 않는다.
6. 관리자는 1명이다.
7. 전송비용은 0이다.
8. 네트워크는 균일하다.

마이크로서비스 디자인 패턴

서비스 검색
에지 서버
리액티브 마이크로서비스
구성 중앙화
로그 분석 중앙화
분산 추적
서킷 브레이커
제어 루프
모니터링 및 경고 중앙화

서비스 검색

문제점

클라이언트가 마이크로서비스와 그 인스턴스를 찾을 수 있어야 한다.
- 컨테이너 등에서 실행되는 마이크로서비스 인스턴스는 시작하면서 동적 IP 주소를 할당받는 게 일반적

해결책

현재 사용 가능한 마이크로서비스와 그 인스턴스를 추적하는 새 컴포넌트(Service discovery)를 시스템 환경에 추가한다.

해결책의 필요 조건

마이크로서비스와 인스턴스를 자동으로 등록 및 해지
클라이언트는 마이크로서비스의 논리 엔드포인트에 요청을 보낼 수 있어야 하고, 요청은 인스턴드 중 하나로 라우팅된다.
마이크로서비스에 대한 요청은 가용 인스턴스로 로드 밸런싱돼야 한다.
상태가 비정상인 인스턴스를 감지할 수 있어야 한다.
서버 측 라우팅 : 서비스 검색 서비스의 인프라는 모든 요청을 전달하는 리버스 프록시를 노출한다. 리버스 프록시는 클라이언트를 대신해 적절한 마이크로서비스 인스턴스로 요청을 전달한다.

에지 서버

문제점

마이크로서비스 시스템 환경에선 일부 마이크로서비스만 시스ㅔㅁ 환경 외부에 공개하고, 그 외의 마이크로 서비스는 외부에서 접근하지 못하도록 숨기는 게 바람직하다.

해결책

모든 요청을 거치는 시스템 환경에 새 컴포넌트(Edge server)를 추가한다.
일반적으로 에지 서버는 리버스 프록시로 동작하며, 동적 로드 밸런싱 기능을 제공하고자 검색 서비스와 통합될 수 있다.

해결책의 필요 조건

서비스를 외부로 공개하되 악의적인 요청으로부터 보호한다. 즉 표준 프로토콜과 OAuth, OIDC, JWT, API 키 등의 모범 사례를 사용해 신뢰할 수 있는 클라이언트인지 확인한다.

리액티브 마이크로서비스

문제점

자바 개발자는 관례적으로 HTTP 기반 RESTful API와 같은 블로킹 I/O 모델을 사용해 동기식 통신 구현함.
요청을 처리하는 동안 스레드를 점유하게되고, 요청이 증가하면 가용 스레드가 부족해 응답 시간이 늦어지거나 서버가 중단된다.

해결책

논블로킹 I/O 사용

해결책의 필요 조건

가능하다면 async 프로그래밍 모델 사용
동기식 프로그래밍 모델을 선호한다면 논블로킹 I/O를 사용해 응답을 기다리는 동안에도 스레드 할당 없이 동기식 요청을 실행하는 리액티브 프레임워크를 사용한다.

구성 중앙화

문제점

실행 중인 모든 인스턴스의 구성 정보를 한눈에 보려면 어떻게 해야 하는가?
구성을 업데이트하고 관련된 모든 마이크로서비스 인스턴스가 올바르게 업데이트 되게 하려면 어떻게 해야 하는가?

해결책

모든 마이크로서비스의 구성 정보를 저장하는 새 컴포넌트를 추가한다.

해결책의 필요 조건

마이크로서비스 집합에 대한 구성 정보를 한 곳에 저장하고 환경별 설정을 지원한다.

로그 분석 중앙확

문제점

각 마이크로서비스 인스턴스가 로컬에 로그 파일을 기록하는 상황에서 전체 시스템 환경에서 발생하는 사건을 개괄하려면 어떻게 해야 하는가?
문제가 발생한 마이크로서비스 인스턴스를 찾아서 로그 파일에 오류 메시지를 쓰게 하려면?
최종 사용자가 문제를 보고했을 때 이와 관련된 로그 메시지를 찾으려면 어떻게 해야 하는가?

해결책

새 마이크로서비스 인스턴스를 감지해 로그 이벤트 수집
로그 이벤트 검색 가능한 형식으로 저장
로그 이벤트 조회 및 분석을 위한 API와 그래픽 도구 제공

분산 추적

문제점

외부 호출을 처리하는 동안 마이크로서비스 사이에서 흐르는 요청 및 메시지를 추적할 수 있어야 한다.

해결책

관련된 마이크로서비스 사이의 처리 과정을 추적하려면 관련된 모든 요청 및 메시지에 correlation ID를 넣어야 하고, 모든 로그 이벤트에 correlation ID가 있어야 한다.

해결책의 필요 조건

모든 요청과 이벤트에 고유 correlation ID를 할당한다. 헤더와 같이 찾기 쉬운 위치에

서킷 브레이커

문제점

동기식 통신의 연쇄 장애

해결책

서킷 브레이커 추가

해결책의 필요 조건

서비스에 문제가 감지되면 timeout을 무시하고 바로 실패하도록 서킷을 연다.
반열림 서킷이라고도 하는 장애 복구용 프로브를 사용한다. 즉 서비스가 정상 동작하는지 확인하고자 주기적으로 요청을 보낸다.
프로브가 서비스의 정상 동작을 확인하면 서킷을 닫는다.

제어 루프

문제점

다수의 인스턴스가 여러 서버에 분산돼 있는 시스템 환경에선 중단되거나 지연된 마이크로서비스 인스턴스를 수동으로 감지하고 대처하는 것이 어려움.

해결책

시스템 환경 상태를 관찰하는 새 컴포넌트(제어 루프)를 시스템 환경에 추가한다.

해결책의 필요 조건

컨테이너를 기반으로 하는 환경에선 쿠버네티스와 같은 컨테이너 오케스트레이션으로 이패턴을 구현한다.

모니터링 및 경고 중앙화

문제점

응답 시간이나 하드웨어 자원 사용량이 지나치게 높은 경우 문제의 근본 원인을 찾는 게 매우 어렵다.

해결책

인스턴스가 사용하는 하드웨어 자원 사용량에 대한 메트릭을 수집하는 새 컴포넌트(모니터 서비스)를 시스템 환경에 추가한다.

해결책의 필요 조건

모든 서버의 메트릭을 수집해야 한다.
서버에서 새로 시작된 인스턴스를 감지해 메트릭을 수집해야 한다.
수집한 메트릭을 조회 및 분석하기 위한 API와 그래픽 도구를 제공해야 한다.

Resillience4j의 CircuitBreaker

  - 요청 마이크로서비스와 제공 마이크로서비스 사이에 resillience4j 를 통해 통신
  - {최소요청횟수} 이후 {timeout}시간 기준으로 {최근 통계시간}동안 또는 {최근 통계건수}로 평가했을때, {실패율}이상이 되면 Circuit Breaker가 Open되고, {Circuit Breaker지속시간}동안 유지
  - 유지되는 동안 Backend service를 호출하지 않는다.
  - 그 시간이 경과하면 Circuit Breaker는 Half Open상태가 되고, Backend service를 1번 호출한다.
  - 요청이 성공하면 Circuit Breaker는 Close되고, 실패하면 다시 Open된다.
  - CircuitBreaker 환경설정을 하드 코딩하면 옵션을 바꿀 때 마다 재배포해야하므로 config server에서 설정한다. → 구성 중앙화

들으랴 말하랴 서기하는게 쉽지 않네요... 서기하는거 까먹고 있다가 뒤늦게 적어서 내용이 부실한 점 죄송합니다. 😢

동기 서비스를 사용하거나 API를 이용한 메시징 방식?
- 명확한 인터페이스 -> 하위호환성 유지
일체형서버도 작은 서버 여러개 나눠서 배포하고 로드 밸런싱하면 되지 않는가?
- 가능하긴 하나 일반적인 방법은 아니다.
- 여러 종류의 DB를 사용하는 경우, data source connection 문제
- 트래픽이 많은 부분만 Scale-out 할 수 없다. ( 부분 Scale-out )
Spring WebFlux
- 현재 사용하는 사람 없다.
- 러닝 커브가 높다.
- 성능이 많이 차이나지 않는다.
- 코루틴 Async?
네트워크는 안전하다.
- 1번은 reliable, 4번은 secure
Spring Config Server
- 바뀐 Config Runtime에 캐치 가능 ( 서버 안내려도 됨. )
로깅?
- 네이버 : 넬로라는 ELK Wrapping
- 카카오 : EFK
- 토스 : ELK, Hue

DevSprout / Hands-On-Microservices-with-Spring-Boot-and-Spring-Cloud

Chapter 01 마이크로서비스 소개 #1

챕터 1을 공부하며 느낀 점

마이크로서비스 소개

독립된 소프트웨어 컴포넌트의 장점

독립된 소프트웨어 컴포넌트의 단점

마이크로서비스의 정의

마이크로서비스의 문제

MSA 디자인 패턴

Service Discovery

선행 문제점

Service Discovery의 해결책

Edge Server

선행 문제점

Edge Server의 해결책

Reactive Microservice

선행 문제점

Reactive Microservice의 해결책

Central Configuration

선행 문제점

Central Configuration의 해결책

Central Configuration에 대한 여담

Centralized Log Analysis

선행 문제점

Centralized Log Analysis의 해결책

Distributed Tracing

선행 문제점

Distributed Tracing의 해결책

Circuit Breaker

선행 문제점

Circuit Breaker의 해결책

Control Loop

선행 문제점

Control Loop의 해결책

Centralized Monitoring And Alarm

선행 문제점

Centralized Monitoring And Alarm의 해결책

느낀점

독립 소프트웨어 컴포넌트

독립 소프트웨어 컴포넌트의 장점

독립 소프트웨어 컴포넌트의 문제

마이크로서비스 입문

마이크로서비스 정의

독립 컴포넌트 정의

분산 컴퓨팅의 여덟가지 오류

마이크로서비스 디자인 패턴

서비스 검색

문제점

해결책

구현 방식

에지 서버

문제점

해결책

리액티브 마이크로서비스

문제점

해결책

구성 중앙화

문제점

해결책

로그 분석 중앙화

문제점

해결책

분산 추적

문제점

해결책

서킷 브레이커

해결책

제어 루프

해결책

모니터링 및 경고 중앙화

문제점

해결책

MSA 디자인 패턴 Cheat Sheet

다른 부분 주요 고려사항

느낀 점

기타

남은 의문점

01. 마이크로서비스 소개

느낀점

독립 소프트웨어 컴포넌트의 장점