마이크로서비스 아키텍처(Microservice Architecture)

2021. 2. 3. 10:16Architecture/AA

반응형

마이크로 서비스 아키텍처

  • 큰 문제를 상대적으로 작게 분해해 해결
  • 이렇게 작게 나눈 각 서비스가 독립적으로 역할을 수행
  • 한가지만, 아주 잘 처리하자. 라는 것이 마이크로 서비스 아키텍처의 기본 철학이다.
    • 단일 책임 원칙(SRP)를 중시(Single Responsibility Principle)
  • 비즈니스 태스크를 작은 태스크로 나누며, 각 태스크마다 마이크로 서비스를 정의 한다.
    • 비즈니스 요구사항과 태스크를 얼마나 잘 나눴는지에 따라 시스템에 두개 혹은 100개의 마이크로 서비스가 존재

마이크로 서비스 아키텍처 특징

  • 시스템을 둘 이상의 실행 단위 또는 컴포넌트로 구성한다.

    • 각 컴포넌트는 기능을 서비스 형태로 표출, 결합도가 낮으며 비즈니스 목적에 맞게 동작한다.
    • 각 컴포넌트는 메시징 큐, HTTP 요청/응답 모델 등 미리 정의된 프로토콜 기반으로 서로 통신한다.
  • 시스템은 특정 언어에 구애 받지 않는다.

  • 시스템에는 분산된 데이터베이스가 있어야 한다.

    • 자신하고만 상호작용하는 자체 데이터베이스가 있고 다른 컴포넌트나 서비스에서 해당 데이터베이스를 읽거나 수정 할 수 없다.
  • 시스템 내 각 컴포넌트는 응집력 있고 독립적이며 자체 배포가 가능해야 한다.

  • 자동화된 테스트가 필요하다.

    • 속도는 마이크로서비스 아키텍처에서 가장 중요한 특징이다.
    • 빌드, 테스트, 출시라는 주기에서 자동화된 테스트가 없다면 원하는 목표를 달성할 수 없다.
  • 모든 컴포넌트나 서비스의 장애는 격리돼야 하며, 특정 서비스가 장애가 나도 전체 애플리케이션이 중단되는 일은 없어야 한다.

    • 서비스 장애가 다른 컴포넌트나 서비스에 영향을 미치지 않아야 하며, 장애에 대한 롤백 매커니즘이 있어야 한다.
  • 마이크로서비스 아키텍처의 성공은 얼마나 효율적으로 애플리케이션을 더 작은 컴포넌트로 나누는가에 달렸다.

    • 문제영역을 잘 분류할 수 있다면 아키텍처를 더욱 개선시킬 수 있다.
  • 마이크로서비스 아키텍처의 단점

    • 디버깅이 어렵다. 마이크로서비스가 많다..
    • 마이크로서비스 모니터링
      • 여러개의 서비스에 대해서 모니터링 해야한다.
    • 공통 라이브러리
      • 마이크로서비스 A에서 사용자 객체 JSON을 생성, 다른 마이크로서비스 B에서 사용자 객체 JSON을 사용한다고 가정하자. 하나의 JAR에 사용자 클래스를 정의하고 이 JAR를 두 마이크로서비스에 추가한다.
        • 공통라이브러리를 공유하면 마이크로서비스가 동일한 언어 사용에 고착될 수밖에 없다.
        • 서비스 가의 결합을 증가 시킨다.
        • 해결책으로 사용자 클래스를 두 마이크로 서비스로 각각 작성하는 것이다.(DRY에 위배 될수 있다.)
    • 조직 내 마이크로서비스의 수를 늘리면 데브옵스 작업이 늘어난다.

그래서 서버리스 아키텍처와 PasS 마이크로서비스의 방향으로 가고 있는 추세이다.

  • 마이크로서비스가 Platform as a Service로 제공된다.

    • 도커(docker) 컨테이너를 사용.
  • 비즈니스 중심으로 마이크로서비스 컴포넌트 구성

    • 비즈니스 기능 : 특정 비즈니스 목적에 맞게 독립적으로 운영할 수 있는 서비스.
      • 비즈니스 기능과 마이크로서비스는 의미가 동일한 것처럼 보이지만 그렇지는 않다.
    • 올바른 비즈니스 기능 식별
    • 기능에 마이크로서비스 컴포넌트 정의

마이크로서비스의 정의

  • 소프트웨어애플리케이션으로 봤을 때 독립적인 배포가 가능한 작은 서비스로 비즈니스 목표를 달성하기 위해
    잘 정의되고 가벼운 메커니즘을 통해 통신한다.(단일책임, 느슨한 결합, 비즈니스 목적 제공, 경량 통신, 적은 LOC(line of code) 등)

마이크로서비스 구현을 위한 기능

  • 서비스 디스커버리
    • 마이크로서비스는 서로 통신해야 하며, 이를 위해 각 서비스는 서로의 위치를 알 수 있어야 한다.
      • 아파치 주키퍼, 에어비앤비의 스마트 스택, 넷플릭스의 유레카 등등
      • k8s에서 인그레스 + 서비스 역할?
      • 요청한 서비스에 대해 적절한 인스턴스를 찾는 책임
      • 스프링부트 - 유레카(넷플릭스 유레카)
        • spring-cloud-starter-eureka 스타터 추가

반응형
LIST