728x90
※ 열심히 작성하고 있습니다.. 기다려 주세욧..!! ※
1장
※ 읽으면서 중요해서 기록하고 공유할 만한 내용 위주로 작성되었습니다. ;)
1장 요약: 모놀리식 애플리케이션이 모놀리식 아키텍처라는 옷이 맞지 않을 정도로 커졌을 때 나타나는 모놀리식 지옥의 징후와 이 지옥을 마이크로서비스 아키텍처를 도입해서 탈출하는 방안을 모색합니다. 이 책 지면을 대부분 할애한 마이크로서비스 아키텍처 패턴 언어란 무엇인지 소개합니다.
1) 서서히 모놀리식 지옥에 빠져들다.
육각형 아키텍처
→ 갑자기 나오는 아키텍처 패턴 중 하나인 육각형 아키텍처는 2장에서 더 자세하게 설명하고 있습니다.
→ 아키텍처 패턴과 디자인 패턴은 다르다..!!
- REST API, 웹 UI 어댑터 등 비즈니스 요청을 호출하는 인바운트 어댑터
- 비즈니스 로직에서 DB에 접속하거나 트윌리오, 스트라이프 등 클라우드 서비스를 호출하게 해주는 아웃바운드 어댑터
- 논리적으로 모듈화한 아키텍처임에도 애플리케이션은 WAR 파일 하나로 패키징 되어있다.
모놀리식 아키텍처의 장점
→ 아래와 같이 장점이 있지만 시간이 흐를수록 개발, 테스트, 배포, 확장하기가 점점 더 어려워진다 왜???
- 개발이 간단하다.
- 애플리케이션을 쉽게 변경할 수 있다.
- 테스트하기 쉽다.
- 배포하기 쉽다.
- 확장하기 쉽다.
모놀리식 아키텍처의 단점
- 너무 복잡해서 개발자가 주눅 들다.
- 개발이 더디다.
→ 애플리케이션이 너무 커져서 IDE 실행 속도가 느려지고, 빌드 시간도 오래 걸린다. - 커밋부터 배포에 이르는 길고 험난한 여정
- 확장하기 어렵다
- 모놀리스는 확실하게 전달하기 어렵다
→ 덩치가 커서 테스트하기 어렵고, 테스트가 어려우면 프로덕션에 버그가 발생할 가능성이 높다. - 가술록 한물간 기술 스택에 발목이 붙잡힌다.
2) 마이크로서비스 아키텍처가 답이다.
현실에서 서비스가 점점 방대해지고 있으면 어떻게 처리할 수 있을까?
확장 큐브와 마이크로서비스
※ ChatGPT
Q. the sacle cube 개념이 나오게 된 배경
A. 소프트웨어 시스템의 스케일링(확장성) 전략을 설명하기 위해 만들어진 개념, 특히 마이크로서비스 아키텍처나 클라우드 컴퓨팅에서 중요하다.
시스템 확장을 세 가지(X축, Y축, Z축) 주요 차원에서 얘기하고 있다.
- X축 확장: 다중 인스턴스에 고루 요청 분산
- 단일 인스턴스 → 다중 인스턴스
(즉, 애플리케이션 서비스를 여러 개로 만드는 것)
- 단일 인스턴스 → 다중 인스턴스
- Z축 확장: 요청 속성별 라우팅
- X축과 같이 다중 인스턴스를 실행하는 것이 같니만, 자신에게 배정된 사용자 하위 집합만 처리한다.
(예를 들어 유저가 100명이 있으면 A 인스턴스는 사용자 1-50번, B 인스턴스는 51-100번의 사용자를 맡아서 처리한다.) - 증가하는 트랜잭션 및 데이터 볼륨을 처리하기 좋은 수단이다.
- X축과 같이 다중 인스턴스를 실행하는 것이 같니만, 자신에게 배정된 사용자 하위 집합만 처리한다.
- Y축 확장: 기능에 따라 애플리케이션을 서비스로 분해
- X축/Z축 확장을 하면 애플리케이션 능력과 가용성은 개선되지만, 점점 더 복잡해지는 문제가 있다.
(나눠진 서비스를 X축 확장하는 방법이다.)
- X축/Z축 확장을 하면 애플리케이션 능력과 가용성은 개선되지만, 점점 더 복잡해지는 문제가 있다.
마이크로서비스와 SOA
- SOA
- SOAP 및 WS 표준 등 무거운 기술을 주로 쓰고, 서비스를 통합하는 비즈니스와 메세지 처리 로직이 포함된 ESB 라는 스마트 파이프를 활용한다.
- 전역 데이터 모델링을 하고 DB도 공유한다.
- 크고 복잡한 모놀리식 애플리케이션을 통합하는 용도
- 덩치 큰 서비스 몇개로 구성
- 마이크로서비스
- 가벼운 오픈 소스 기술을 사용하며, 메세지 브로커나 REST 또는 gRPC처럼 가벼운 프로토콜 위주의 덤 파이프(dumb pipe)를 통해 서비스간 통신을 한다.
→ 단순히 데이터가 드나드는 통로에 그치지 않고 여러 가지 부가 기능을 가미하여 활용성을 높이는 개념이라고 한다. - 자체 DB, 자체 도메인 모델을 소유한다.
- 대체로 SOA보다는 훨씬 규모가 작다.
- 작은 수십 ~ 수백개의 서비스로 구성
- 가벼운 오픈 소스 기술을 사용하며, 메세지 브로커나 REST 또는 gRPC처럼 가벼운 프로토콜 위주의 덤 파이프(dumb pipe)를 통해 서비스간 통신을 한다.
3) 마이크로서비스 아키텍처의 장단점
마이크로서비스 장점
- 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
- 테스트성
- 배포성
- 자율성
- 서비스가 작아 관리하기 용이하다
- 서비스를 독립적으로 배포/확장할 수 있다.
- 결함 격리가 잘된다.
- 신기술을 시험/도입하기 쉽다
마이크로서비스 단점
- 딱 맞는 서비스를 찾기가 쉽지 않다.
- 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵다.
- 여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야 한다.
- 마이크로서비스 아키텍처 도입 시점을 결정하기가 어렵다.
3) 마이크로서비스 아키택처 패턴 언어
- 패턴은 특정한 상황에서 발생한 문제에 대해 재사용 가능한 해법이다.
- 패턴 언어는 특정 영역 내부에서 문제를 해결하는 연관된 패턴의 집합이다.
패턴
패턴언어
4) 마이크로서비스 너머: 프로세스와 조직
'읽은 책 > [책] 마이크로 서비스 패턴' 카테고리의 다른 글
[4장] 트랜잭션관리: 사가 (0) | 2024.12.18 |
---|---|
[3장] 프로세스 간 통신 - 2편 (1) | 2024.12.08 |
[3장] 프로세스 간 통신 - 1편 (0) | 2024.12.08 |
[2장] 분해 전략 (0) | 2024.12.01 |
[책] 마이크로 서비스 패턴 책 소개 (1) | 2024.11.30 |