마이크로서비스 아키텍처 구축 : 1장 마이크로서비스란?

1.1 마이크로서비스 살펴보기

• 마이크로서비스

  • 비즈니스 도메인에 따라 모델링된 독립적으로 릴리스 가능한 서비스

  • 기능을 캡슐화하고 네트워크를 통해 다른 서비스들에 액세스하게 해준다.

  • 외부에서 본 경우

    

    • 하나의 마이크로서비스는 블랙박스로 취급
      • 기술이나 데이터 저장 방식을 외부에서 알 수 없다.
    • 외부 인터페이스를 통해 최소한의 정보만 노출
      • 변경하기 쉬운 것과 변경하기 어려운 것을 명확히 구분
      • 인터페이스를 통해 독립적인 릴리스

1.2 마이크로서비스의 핵심 개념

• 독립적 배포성

  • 다른 마이크로서비스를 배포하지 않고도 변경, 배포, 릴리스 가능
  • 느슨한 결합 필요
    • DB를 공유한다면 문제가 된다.

• 비즈니스 도메인 중심의 모델링

  • 도메인 주도 설계를 이용해 실제 도메인을 잘 표현하도록 코드 구성
  • 마이크로서비스를 다양한 방식으로 재결합해 사용자에게 기능 제공

• 자기 상태 소유

  • 마이크로서비스에 대한 하위 호환성이 없는 변경을 제한해야한다.
    • 업스트림 소비자와의 호환성이 깨진다면 소비자들에게도 변경을 강요하게 된다.

• 크기

  • 크기의 개념은 상황에 따라 좌우된다.
  • 핵심사항
    • 얼마나 많은 마이크로서비스를 처리할 수 있는가?
      • 서비스가 많아질수록 시스템 복장성이 증가
    • 마이크로서비스 경계를 최대한 활용하려면 어떻게 경계를 정의해야 하는가?
      • 모든 것이 결합돼 엉망인 상황을 피하기 위해 경계 정의

• 유연성

  • 마이크로서비스 비용 vs 유연성, 조직성, 기술성, 규모, 견고함
    • 현 상황에 대해 가치를 매겨 비용 비교
  • 필자는 점진적인 마이크로서비스 채택 지지
    • 수행 영향도를 잘 판단하고 필요한 경우 중지 가능

• 아키텍처와 조직의 정렬

  • 콘웨이의 법칙

    • 시스템을 설계하는 조직은 커뮤니케이션 구조를 본떠 설계하도록 제한된다.

  • 과거에는 핵심 역량을 기반으로 사람들을 그룹화

    

    • 기능 변경이 계층을 넘어갈 가능성이 높다.
    • 관련 기술의 응집력은 높으나 비즈니스 기능의 응집력은 낮다.

  • 이제 핸드오프와 사일로를 줄이기 위해 다양한 기술을 갖춘 팀으로 묶는다.

    

    • 빠르게 소프트웨어 출시

1.3 모놀리스

• 단일 프로세스형 모놀리스
  • 모든 코드가 단일 프로세스로 배포되는 시스템
  • 소규모 조직에 적합
• 모듈식 모놀리스
  • 단일 프로세스가 별도의 모듈로 구성된 변형
  • 문제점
    • 데이터베이스가 코드 수준으로 분해되지 않아서 미래에 모놀리스를 분해하려면 어려움에 직면
• 분산형 모놀리스
  • 여러 서비스로 구성된 시스템이지만, 어떤 이유로든 전체 시스템을 함께 배포
  • SOA 정의는 충족하지만 약속을 이해하지 못하는 경우가 많다.
    • SOA : 서비스 지향 아키텍처
      • SOA → 기업용 대형 시스템 통합에 초점 (Integration 중심)
      • MSA → 클라우드, 확장성, 빠른 배포에 초점 (Independence 중심)
  • 분산 시스템과 단일 프로세스형 모놀리스의 단점을 모두 갖고 있지만 두 시스템의 장점은 충분히 갖추지 못했다.
  • 정보 은닉과 비즈니스 기능의 응집력 같은 개념을 중시하지 않는 환경에서 나타난다.
• 모놀리스와 전달 경합
  • 개발자가 늘어나면 동일한 코드를 변경하는 사례가 많아진다.
  • 누가 무엇을 소유하고 결정하는지 혼란을 겪는다.
  • 마이크로서비스 아키텍처는 경계가 구체적이라 이 문제를 줄이는데 더 유연하다.
• 모놀리스의 장점
  • 개발자 워크플로우 간소화
    • 모니터링, 문제해결, E2E 테스트 등
  • 자기 내부에서 코드 쉽게 재사용
    • 코드 재사용 시 코드 복사, 라이브러리 분리, 공유 서비스로 내보낼 지 결정하는 선택지가 단순해진다.

1.4 활성화 기술

• 마이크로서비스를 확장하면서 발생하는 문제를 찾고 도움 될 만한 기술을 찾아야한다.
• 로그 집계와 분산 추적
  • 마이크로서비스를 채택하기 전에 준비해야한다.
  • 시스템이 복잡해짐에 따라 시스템이 수행하는 작업을 더 잘 알아낼 도구를 고려
• 컨테이너와 쿠버네티스
  • 각 마이크로서비스 인스턴스를 격리해 실행
    • 다른 마이크로서비스에 영향을 미치지 않게 한다.
  • 가상화보다 컨테이너가 격리된 실행환경을 프로비저닝하기에 더 가벼운 방법
  • 컨테이너를 관리하는 무언가 → 쿠버네티스
    • 컨테이너가 많아지는 경우 (마이크로서비스가 많아지는 경우) 사용
• 스트리밍
  • 마이크로서비스간에 데이터를 공유하는 방법
    • 카프카를 이용한 데이터 스트리밍
      • Flink, Debezium을 통해 스트리밍
        • 전체 흐름 예시
          • [MySQL] → [Debezium] → [Kafka] → [Flink] → [Elasticsearch / Dashboard]
        • Debezium
          • 데이터 변경 감지 (CDC)
          • DB의 변경(Insert, Update, Delete)을 실시간으로 감지해서 이벤트로 내보내는 시스템
          • 실시간 데이터 수집
        • Flink
          • Kafka 같은 스트림 데이터 소스를 받아서 실시간으로 분석·가공·집계하는 분산 처리 엔진
          • 실시간 데이터 처리
• 공용 클라우드 및 서버리스
  • 구글 클라우드, 마이크로소프트 애저, AWS
  • 관리형 서비스를 사용하면 해당 작업을 잘 처리할 수 있는 제삼자에게 맡길 수 있다.

1.5 마이크로서비스의 장점

• 기술 이질성

  • 각 서비스에 적합한 도구를 선택할 수 있다.

    

  • 새로운 기술 도입 시 사이드 이펙트가 적다.

• 견고성

  • 벌크헤드
    • 시스템의 구성 요소 중 하나가 고장 날 수 있지만, 그 고장이 연속적으로 발생하지 않는 한 문제를 격리하고 나머지 시스템은 계속 작동할 수 있다.
      • 모놀리식 시스템은 서비스가 실패하면 모든 것이 작동을 멈춘다.
  • 분산 시스템에서 처리해야 할 고장 원인을 이해해서 사용자에게 미칠 영향이 있다면 알아야한다.

• 확장성

  • 모놀리식 서비스에서는 모든 것을 함께 확장해야한다. → 마이크로서비스는 확장이 필요한 서비스만 확장할 수 있다.

• 배포 용이성

  • 하나의 서비스만 변경하여 다른 부분과 독립적인 배포가 가능하다. 문제가 발생해도 신속하게 롤백할 수 있다.

• 조직적 정렬

  • 팀 크기와 생산성의 최적점에 도달하기 위해 하나의 코드베이스에서 일하는 인원을 최소화

• 조합성

  • 컴포넌트 간의 상호 연관성을 다루는 시스템 설계 원칙
  • 데이터를 조합해 재사용 가능

1.6 마이크로서비스의 고충

• 개발자 경험
  • 로컬에서 마이크로서비스 10개이상 실행하기 버겁다.
    • 클라우드에서 개발해야한다.
      • 대신 개발자가 작업해야하는 시스템 영역의 범위를 제한
• 기술 과다
  • 다양한 기술이 가져올 비용과 사용하는 기술의 범위 및 복잡성 고려
• 비용
  • 더 많은 컴퓨터, 스토리지, 프로세스, 네트워크 등을 실행해야 한다는 점을 고려
  • 새로운 개념을 배우고 효과적으로 사용하는 방법을 익히는 시간
  • 더 많은 고객, 트래픽이 있다면 더 큰 수익을 얻는 데 도움이 된다.
• 리포팅
  • 마이크로서비스는 모놀리식 스키마를 분해
    • 논리적으로 분리된 여러 스키마에 분산되어 있어서 리포팅을 실행하기 어렵다.
• 모니터링과 문제 해결
  • msa에서 하나의 프로세스만 cpu 사용량이 100%를 유지한다면 누군가를 깨워야 할까?
    • 예시 > 한 서비스만 폭주한다면 서비스 코드를 짠 개발자 호출
• 보안
  • 마이크로서비스는 더 많은 정보가 서비스 사이의 네트워크를 통해 교류
    • 전송중인 데이터와 마이크로서비스 엔드포인트를 보호해 권한 있는 당사자만 사용할 수 있도록 보장
• 테스팅
  • 단점
    • 테스트 범위가 커져 픽스처 설정 어려워진다.
    • 실행하는데 오래 걸린다.
    • 테스트 실패 지점을 파악하기 어렵다.
  • 대응 방안
    • 계약 주도 테스팅
    • 운영 환경 내 테스팅
• 지연 시간
  • 서비스가 분리되어 많은 네트워크 레이턴시 발생
• 데이터 일관성
  • 단일 DB는 트랜잭션에 의존할 수 있었지만 분산 시스템에서는 사가 패턴, 궁극적 일관성 같은 개념을 사용해야한다.

1.7 마이크로서비스를 사용해야 하는가?

• 문제 영역, 기량, 기술 상황을 평가하고 달성하려는 목표가 무엇인지 이해해야 한다.
• 적합하지 않은 곳
  • 새로운 제품이나 스타트업 기업
    • 서비스 경계 정의를 위해 도메인 모델이 충분히 안정화될 때까지 기다리는 것이 적절
  • 고객이 배포하고 관리할 소프트웨어를 만드는 조직
• 적합한 곳
  • 많은 개발자가 서로 방해하지 않고 동일 시스템에서 작업하는 환경
  • SaaS
    • 변경사항 배포 시 독립적 릴리스 가능
  • 새로운 채널을 통해 고객 서비스를 제공하려는 조직