[1장] 모놀로식 지옥에서 벗어나라

 

 

 

※ 열심히 작성하고 있습니다.. 기다려 주세욧..!! ※

1장

※ 읽으면서 중요해서 기록하고 공유할 만한 내용 위주로 작성되었습니다. ;)

 

1장 요약:  모놀리식 애플리케이션이 모놀리식 아키텍처라는 옷이 맞지 않을 정도로 커졌을 때 나타나는 모놀리식 지옥의 징후와 이 지옥을 마이크로서비스 아키텍처를 도입해서 탈출하는 방안을 모색합니다. 이 책 지면을 대부분 할애한 마이크로서비스 아키텍처 패턴 언어란 무엇인지 소개합니다.

1) 서서히 모놀리식 지옥에 빠져들다.

육각형 아키텍처

→  갑자기 나오는 아키텍처 패턴 중 하나인 육각형 아키텍처는 2장에서 더 자세하게 설명하고 있습니다.

→  아키텍처 패턴과 디자인 패턴은 다르다..!!

• REST API, 웹 UI 어댑터 등 비즈니스 요청을 호출하는 인바운트 어댑터
• 비즈니스 로직에서 DB에 접속하거나 트윌리오, 스트라이프 등 클라우드 서비스를 호출하게 해주는 아웃바운드 어댑터
• 논리적으로 모듈화한 아키텍처임에도 애플리케이션은 WAR 파일 하나로 패키징 되어있다.

모놀리식 아키텍처의 장점
→ 아래와 같이 장점이 있지만 시간이 흐를수록 개발, 테스트, 배포, 확장하기가 점점 더 어려워진다 왜???

• 개발이 간단하다.
• 애플리케이션을 쉽게 변경할 수 있다.
• 테스트하기 쉽다.
• 배포하기 쉽다.
• 확장하기 쉽다.

모놀리식 아키텍처의 단점

• 너무 복잡해서 개발자가 주눅 들다.
• 개발이 더디다.
  → 애플리케이션이 너무 커져서 IDE 실행 속도가 느려지고, 빌드 시간도 오래 걸린다.
• 커밋부터 배포에 이르는 길고 험난한 여정
• 확장하기 어렵다
• 모놀리스는 확실하게 전달하기 어렵다
  → 덩치가 커서 테스트하기 어렵고, 테스트가 어려우면 프로덕션에 버그가 발생할 가능성이 높다.
• 가술록 한물간 기술 스택에 발목이 붙잡힌다.

2) 마이크로서비스 아키텍처가 답이다.

현실에서 서비스가 점점 방대해지고 있으면 어떻게 처리할 수 있을까?

 

확장 큐브와 마이크로서비스

the Scale Cube

 

※ ChatGPT

Q. the sacle cube 개념이 나오게 된 배경

A. 소프트웨어 시스템의 스케일링(확장성) 전략을 설명하기 위해 만들어진 개념, 특히 마이크로서비스 아키텍처나 클라우드 컴퓨팅에서 중요하다.

 

시스템 확장을 세 가지(X축, Y축, Z축) 주요 차원에서 얘기하고 있다.

• X축 확장: 다중 인스턴스에 고루 요청 분산
  • 단일 인스턴스 → 다중 인스턴스
    (즉, 애플리케이션 서비스를 여러 개로 만드는 것)

x축 확장

• Z축 확장: 요청 속성별 라우팅
  • X축과 같이 다중 인스턴스를 실행하는 것이 같니만, 자신에게 배정된 사용자 하위 집합만 처리한다.
    (예를 들어 유저가 100명이 있으면 A 인스턴스는 사용자 1-50번, B 인스턴스는 51-100번의 사용자를 맡아서 처리한다.)
  • 증가하는 트랜잭션 및 데이터 볼륨을 처리하기 좋은 수단이다.

Z축 확장

• Y축 확장: 기능에 따라 애플리케이션을 서비스로 분해
  • X축/Z축 확장을 하면 애플리케이션 능력과 가용성은 개선되지만, 점점 더 복잡해지는 문제가 있다.
    (나눠진 서비스를 X축 확장하는 방법이다.)

y축 확장

마이크로서비스와 SOA

• SOA
  
  • SOAP 및 WS 표준 등 무거운 기술을 주로 쓰고, 서비스를 통합하는 비즈니스와 메세지 처리 로직이 포함된 ESB 라는 스마트 파이프를 활용한다.
  • 전역 데이터 모델링을 하고 DB도 공유한다.
  • 크고 복잡한 모놀리식 애플리케이션을 통합하는 용도
  • 덩치 큰 서비스 몇개로 구성
• 마이크로서비스
  • 가벼운 오픈 소스 기술을 사용하며, 메세지 브로커나 REST 또는 gRPC처럼 가벼운 프로토콜 위주의 덤 파이프(dumb pipe)를 통해 서비스간 통신을 한다.
    → 단순히 데이터가 드나드는 통로에 그치지 않고 여러 가지 부가 기능을 가미하여 활용성을 높이는 개념이라고 한다.
  • 자체 DB, 자체 도메인 모델을 소유한다.
  • 대체로 SOA보다는 훨씬 규모가 작다.
  • 작은 수십 ~ 수백개의 서비스로 구성

3) 마이크로서비스 아키텍처의 장단점

마이크로서비스 장점

• 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
  • 테스트성
  • 배포성
  • 자율성
• 서비스가 작아 관리하기 용이하다
• 서비스를 독립적으로 배포/확장할 수 있다.
• 결함 격리가 잘된다.
• 신기술을 시험/도입하기 쉽다

마이크로서비스 단점

• 딱 맞는 서비스를 찾기가 쉽지 않다.
• 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵다.
• 여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야 한다.
• 마이크로서비스 아키텍처 도입 시점을 결정하기가 어렵다.

3) 마이크로서비스 아키택처 패턴 언어

• 패턴은 특정한 상황에서 발생한 문제에 대해 재사용 가능한 해법이다.
• 패턴 언어는 특정 영역 내부에서 문제를 해결하는 연관된 패턴의 집합이다.

패턴

 

패턴언어

 

 

 

4) 마이크로서비스 너머: 프로세스와 조직