Chae Seungmin

DevOps & carefree life [TMON] Channel Service Dev. Team

2 minute read

Microservice Architecture (MSA)

Software Application을 구축하는 하나의 Architecture Style
- Application을 작고 독립적인 단위(Microservice)로 나누는 접근 방식.
- 각각의 Microservice는 자체적, 독립적으로 배포 및 실행될 수 있다.

MicroserviceArchitecture_Procdess
Microservice Architecture

MSA의 특징 및 장점 5가지

  1. 느슨한 결합 (Loosely Coupled)
    MLooselyCoupled_Procdess
    Loosely Coupled
    • 각각의 Microservices 들은 독립적으로 작동하므로 다른 서비스와 느슨하게 결합된다.
    • 시스템의 그 어떤 부분도 추가 변경할 필요 없이 특정 서비스를 변경하고 바로 배포 할 수 있는 것.
    • 따라서 한 서비스의 변경이 다른 서비스에 영향을 미치는 일이 적다.
    • 강한 결합은 변경을 더 어렵게 하며 시험 가능성(testability)를 지연시킨다.
      응집력 (High-Cohesion)
      HighCohesion_Procdess
      High-Cohesion
      • 도메인은 다수의 경계가 있는 컨텍스트로 구성됨.
        BoundedContext_Procdess
        Bounded Context
        • Bounded Context(결정 경계)는 명료한 경계에 의해 강제된 구체적인 책임을 구분.
    • 서로 의존하여 같이 변경되어야 할 서비스들을 하나의 서비스 안에 담는 것.
      • SOLID 원칙 중 단일 책임 원칙(Single Responsibility)
        • 하나의 마이크로 서비스 안에는 함께 변경되는 것들을 같은 곳에 모아 놓는다.
      • 설계 시 주의 할 점은 업무 도메인을 정의하고, 해당 업무 도메인 내부에서의 변경을 고려해 각각의 Microservice를 분리 해놓아야 한다.

  2. 독립적 배포
    MicroserviceDevelopmentLifecycle_Procdess
    Microservice Development Lifecycle
    • 각 Microservice 는 독립적으로 배포될 수 있다.
    • 애플리케이션의 일부만 업데이트하거나 확장할 수 있으므로 전체 애플리케이션을 다시 배포할 필요가 없다.
      • 전체 빌드(Build) 가 아닌, 서비스 단위의 빌드 및 배포.
      • 컨테이너 환경에 매우 적합.
      • 구성원 전체가 전부 야근하는 일이 벌어지지 않음 (?)

      • Test Code 또는 TDD 가 필요.

        TDD(Test-Driven Development) - 테스트 주도 개발
        
  - 소프트웨어 개발 방법론 중 하나.
  - 소프트웨어를 개발할 때 테스트를 먼저 작성.
  - 해당 테스트를 통과하는 코드를 구현하는 개발 접근 방식
  3. 서비스 단위 관리
    • 각 Microservice는 별도의 팀에 의해 관리될 수 있으며, 다양한 언어나 기술을 사용하여 개발될 수 있다.
      • 기술 이기종성 (Heterogeneous)
        • 각각의 서비스가 다른 기술을 사용하려 구현 될 수 있다.
        • 서비스에 맞는 기술을 채택할 수 있음. (성능, Data Model, 구현 용이성 등)
        • 너무 과도한 기술 스택은 오히려 부담.
    • Squad 별로 독립적인 서비스를 개발.
      • 타 Squad에 영향을 주지 않기 위함.
  4. 확장성 (Scale Out)
    • 특정 서비스에 대한 수요가 증가한다면, 해당 서비스만 확장할 수 있다.
    • 전체 애플리케이션을 확장하는 것보다 효율적임.
    • 전통적인 ScaleOut 과 다름.
      ScaleOut_Procdess
      [Kubernetes] Circuit Breaker
  5. 복원력 (Resilience)
    • 일부 서비스에 장애가 발생하더라도 다른 서비스는 정상적으로 작동한다. (독립적)
      • 하나의 서비스 장애가 다른 서비스로 전이되지 않는다.
      • Kubernetes : Circuit Breaker 를 통해 구현이 가능함.
        CircuitBreaker_Procdess
        [Kubernetes] Circuit Breaker
    • 전체 애플리케이션의 복원력이 향상된다.
      • 전체 장애를 차단하고 기능은 저하시킨다.
    • 분산 기술에 대한 깊은 이해를 필요로 한다.
  • Database가 분리되어 있어야 한다?
    • 정확히는 Schema의 분리.
    • 논리적인 분리를 말함.



MSA의 단점

  1. 업무 도메인 구분이 어렵다. - 경험의 부족
    • 업무 도메인을 구분하여 잘게 분리하는 것은 생각보다 복잡한 작업.
    • 초기 스타트업에서는 MSA를 권장하지 않는다고 한다. (어떤 업무가 어떻게 나뉘게 될 지 모르기 때문에)
    • 개발 인력의 기본적인 능력이 매우 중요함.
  2. 운영하기 어려움
    • 작은 서비스들이 흩어져 있어 모니터링이 어렵다.
    • 산재된 로그들의 분석이 어렵다.
      • Metric : 액셀 파일의 컬럼과 같은 것 (성과와 효율성을 측정하기 위해 사용되는 수치나 지표)
      • 로그
      • 트레이스 : 쪼개어져 있는 Component 들의 일련 과정을 보아 추적하는 것.
    • 신속한 장애 대처를 위해서 운영자가 Microservice를 구성하는 모든 Component에 대해 잘 알고 있어야 한다.

위와 같은 MSA의 단점 덕분에 Docker 와 같은 컨테이너 기술 및 K8s 등의 컨테이너 오케스트레이션이 대안으로 떠오르게 되었다.



Microservice Architecture OSS 예시

MSAOSS_Procdess
MSA OSS

  • Service Discovery
    • 서비스 시작 시 (톰캣이 뜰 때) Eurreka에 등록
    • Eureka 가 여러 서비스 중 가용 가능한 서비스를 탐지.
      • 장애가 발생한 서비스로 접근 불가하게 설정해줌.



Conway's Law

Application Architecture 는 그것을 개발하는 조직 구조를 그대로 반영한다.



처음으로~

Task Lists

  • Microservice Architecture (MSA)
  • Microservice Architecture OSS 예시

Comments

You May Also Enjoy