Microservice Architecture와 Monolithic Architecture이란?

Monolithic Architecture

• MicroService Architecture가 각광을 받기 시작하면서 기존의 아키텍처를 지칭하는 의미로 생겨난 단어
• 모든 모듈은 하나의 서비스 내부에 종속되어있으며 서비스 자체에 집중할 수 있는 구조
• 각기 다른 역할을 하는 모듈들이 모여서 하나의 프로젝트
• 개발, 빌드, 배포가 용이할 수 있지만, 프로젝트의 규모가 커질수록 수정, 새로운 기능의 추가가 어려워짐

장점

• 단순한 구조
• 개발환경과 방법의 통일성
• 배포가 간편
• End to End 테스트가 쉬움

단점

• 프로젝트의 규모가 커질수록 복잡도가 심각하게 증가
• 코드 전체를 이해하기 힘듬
• 빌드시간의 증가 (CI/CD 불가능)
• 새로운 기술을 적용하려면 프로젝트를 다 뜯어고쳐야할수있음

 

 

MicroService Architecture

• 기존 아키텍처의 단점을 보완하고자 나온 여러 아키텍처 중 하나
• 작은 서비스 여러개가 모여서 하나의 시스템을 제공하는 아키텍처
• 각 서비스는 작고 독립적이며 느슨하게 결합
• 서비스들을 독립적으로 배포할 수 있으며, 전체 프로그램을 빌드한 뒤에 재배치하지 않고도 기존 서비스들을 업데이트 할 수 있음
• 서비스들이 독립적이라는 특징덕에 클라우드와 컨테이너와 잘 어울리는 아키텍처
• 단일 책임의 원칙을 중시하여 문제들을 더 작은 문제로 분해하여 해결함
• 작게 나뉘어진 서비스가 서로에게 영향을 미치지 않고 독립적으로 역할을 수행하게 만드는 것

 

장점

• 전체프로그램을 다시 배포하지 않고도 업데이트가 가능
• 독립적으로 개발가능
• 서비스 하나가 다운되더라도 전체 서비스에 영향을 끼치지 않음
• 서비스를 독립적으로 확장가능, 리소스의 유연한 운용 가능
• 작게 분해된 서비스들이 같은 언어로 개발될 필요가 없다는 것
• 분산 데이터베이스
  • 각 모듈별로 자신하고만 상호작용을하고 다른 모듈의 DB에는 데이터를 읽거나 수정할 수 없게끔 만드는 것
• CI,CD와 , 자동화된 테스트 필수

 

단점

• 배포가 어렵고, 서비스간 통신방법이 필요하고 복잡함
• 서비스끼리의 테스트가 어려움
• 서비스를 나눠서 데이터 중복이 발생할 수 있고 정합성을 보장하기 어렵움
• 복잡하고 독립된 구조로 인해 통합적인 유지관리가 어려워질 수 있음

 

특징

• 클라우드 환경과 조합이 좋기 때문
• 각각의 모듈들이 합쳐져 큰덩어리로 시스템이 구축
• 사용량이 적은 모듈을 삭제한다고 하더라도 전체 시스템의 스펙은 변하지 않기 때문에 사용량단위로 과금을 해야하는 cloud환경에서는 비효율적
•  서비스단위로 기능을 분리해서 구축할 수 있기 때문에, 사용하지 않는 기능 또는 사용량이 적은 기능을 축소해서 효율화시킬 수 있음
• 비용면에서는 클라우드환경에서 MSA가 매우 높지만 모든것이 완벽하지는 않음
• MSA로 시스템을 구축하게되면 그에 따른 자식서비스들도 늘어나게되고 관리해야할 포인트가 증가하는 단점 존재
• 그럼에도 불구하고 서비스들의 재사용성, 클라우드환경에 친화적이라는 장점때문에 현재 가장 핫한 아키텍처

 

MicroService 와 Monolithic의 차이

• 불가피하게 어플리케이션을 확장하기 위해서 로드밸런서를 두어 서버를 추가해서 트래픽 이슈를 해결
  • Monolithic의 경우 하나의 어플리케이션으로 배포
    • 특정한 서비스(이벤트, 행사 참여 등)에만 트래픽이 발생해도 서버를 추가할 때 모든 기능이 담겨져있는 어플리케이션 사본 을 운영하는 서버를 추가하여 수평확장
    • 수직확장을 위해서 각 호스트 서버의 자원(CPU, RAM)을 늘려 확장
    • 기존 코드의 무결성을 체크하기 위해서 많은 테스트를 거쳐야 함
    • 기술적 부채가 늘어남
      • 운영업무량이 증가(어플리케이션 운영 및 유지보수)
      • 새로운 기능 추가에 따른 코드 라인 수와 복잡도 증가
      • 불가피하게 어플리케이션을 확장(수직, 수평)
  • Microservice의 경우 각 기능마다 서버와 DB가 존재
    • 특정한 서비스에 몰리게 되면 해당 서비스에 대한 수직, 수평확장을 실시
    • 다른 서비스에 대한 무결성을 지킬 수 있음
    • 기술적 부채의 감소, 개발자 생산성 및 속도 향상, 테스트 효율성 증가, 확장성 증가

 

 

Monolithic Architecture

• MSA를 클라우드라는 가상의 인프라를 활용하여 구조화하기 때문에 클라우드의 특징을 고려해서 설계해야 함
• 가장 중요한 요소는 비즈니스의 변화에 대응할 수 있는 유연성과 확장성
• Microservice가 운영되는 환경을 정의하는 MSA outer 아키텍처
• 실제로 비즈니스가 실행되는 각각의 Microservice 내의 구조를 정의하는 MSA inner 아키텍처

 

Inner architecture

• 내부 서비스를 어떻게 잘 나누는지에 대한 설계
• 비즈니스/서비스/시스템 마다 특성이 달라 표준이 없음
  1. 마이크로 서비스를 어떻게 정의
  2. DB access 구조를 어떻게 설계
  3. 서비스내 API를 어떻게 설계
  4. 논리적인 컴포넌트 layer를 어떤 방식으로 설계

 

Outer architecture

서비스들간의 구조에 대한 설계

• External Gateway
  • 기능 : 서비스 외부에서 오는 접근을 내부 구조를 드러내지 않고 처리
  • 역할 : 사용자 인증, 권한 정책 관리
  • API Gateway
    : 서버의 앞에서 모든 API 호출을 받아 인증후에 적절한 서비스에 라우팅(메시지 전달) => zuul + Eureka

 

• Service Mesh
  • 기능 : 마이크로 서비스 사이 통신 / 네트워크 제어
  • Service discovery, service routing , 트래픽 관리, 보안 을 수행
  • API Gateway와 유사

 

• Container Management
  • 컨테이너 기반의 어플리케이션이 유연성 및 자율성을 갖고, 개발자가 쉽게 접근/운영할 수 있어 MSA에 적합
  • Kubernetes가 가장 대표적인 컨테이너 관리 환경

 

• Backing Services
  • 실행중인 어플리케이션이 사용할 수 있는 모든 서비스
    • DB, SMTP. 캐시 시스템과 통신하는 리소스들을 포함하는 개념
  • MSA에서는 Message Queue를 이용한 비동기 통신을 지향
    
    • 그렇지 않는 다면 여러 서비스를 걸치는 실시간 트랜잭션 처리시, 하나의 서비스가 죽으면 트랜잭션이 끊김
      • 서비스 요청 보존 불가 & 에러 발생
        
    •  따라서 데이터 변경 or 보상 트랜잭션에 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적
      

 

• Telemetry
  • Tele(먼거리) + Metry(측정) 
  • 분산 환경에서 운영되는 MS의 상태를 일일이 모니터링/대응하기 어려움
    • Telemetry가 서비스 모티너링 + 서비스별 이슈에 대응 하는 환경 구성
  • Logging + Monitoring + Tracing
  • Grafana, Prometheus, EFK, ELK 등의 OSS로 직접 구현
  • datadog  같은 사용 솔루션 사용

 

• CI/CD Automation
  • CI : 지속적인 통합 , CD: 지속적인 전달/배포를 통해 배포가 잦은 MSA의 개발 단계를 자동화
    • jenkins, gitlab

 

 

EDA란?

• MSA에서는 Microservice간 이벤트를 전달하고 요청을 종료하는 비동기식 방식 사용
• 분산 아키텍처 환경에서 상호 간 결합도를 낮추기 위해 비동기 방식으로 메시지를 전달하는 패턴으로 주로 Message Broker(Kafka, RabbitMQ)와 결합하여 구성
• 서비스 요구에 따라 늘어나거나 줄어들 수 있는 탄력성이 높은 클라우드 플랫폼 환경에서 서비스가 다운되었을 때 또는 시스템을 더 확장해야 할 때 사용할 수 있는 매우 효과적인 방법
• 느슨한 결합으로 인해 확장성 및 수정 가능성에 많은 이점을 제공

 

SAGA Pattern이란?

• MSA에서는 하나의 비즈니스 로직을 처리하기 위해서 다수의 Microservice의 데이터를 변경해야하는 경우가 있음
• monolithic의 경우 비즈니스로직 전체를 단일의 로컬 트랜젝션으로 처리가능
• MSA에서는 불가
• SAGA Pattern을 사용하여 트랜젝션을 처리할 비즈니스 로즈니스 로직을 saga라는 논리적인 트렌젝션으로 간주
• 각 MicroService에서는 로컬 트랜젝션으로 처리하고 다른 서비스에 보상을 주는 방식으로 하나의 비즈니스 로직의 트랜젝션을 관리할 수 있음