마이크로서비스 아키텍처 구축 : 7장 빌드

7.1 지속적 통합에 대한 간략한 소개

• 지속적 통합 → CI
  • 코드 커밋 감지, 체크아웃, 컴파일 및 테스트 통과
  • 산출물을 한번만 빌드하고 해당 버전의 코드를 모든 배포에 사용
• 장점
  • 정적 분석, 테스트를 사용해 코드 품질에 대한 빠른 피드백
• CI가 무엇인지 이해하고 있는지 검증하는 질문
  • 메인라인에 하루에 한 번 체크인하는가?
  • 변경 사항을 검증하는 일련의 테스트가 있는가?
  • 빌드가 깨졌을 때 이를 수정하는 것이 팀의 최우선 일인가?
• 브랜치 모델
  • 트렁크 기반 개발
    • 모든 사람이 동일한 트렁크에서 작업
    • 변경 사항이 다른 사람에게 영향을 미치지 않도록 기능 플래그와 같은 기술 사용 → 미완 작업을 숨긴다.
  • 브랜치는 짧게 유지해라.
• 오픈소스
  • 신뢰할 수 없는 커미터가 임시적으로 많은 기여를 하고 그들의 변경 사항은 신뢰할 수 있는 기여자가 심사한다.

7.2 빌드 파이프라인과 지속적 제공

• 각 단계를 마칠 때 소프트웨어의 진행 상황을 추적하는 방법 제공

• 지속적 제공 → CD

  • 소프트웨어가 수동 및 자동으로 거쳐야 하는 모든 단계를 모델링

• CI 중 빌드가 수행한 단계가 실패하게 되면 실패한 부분에 대한 가시성을 얻게 해야한다.

• 지속적 제공 (continuous delivery)

  • 각 체크인을 릴리스 후보로 취급하고 각 후보의 품질을 평가해 배포할 준비가 됐는지 결정하는 개념

• 지속적 배포 (continuous deployment)

  • 자동화된 메커니즘을 사용해 모든 체크인을 검증, 검사를 통과하는 모든 소프트웨어는 사람의 개입 없이 자동으로 배포

• 도구

  • CD를 완벽하게 지원하는 도구를 사용하면 파이프라인을 정의하고 시각화해 소프트웨어가 운영 단계에 이르는 전체 경로를 모델링할 수 있다.

• 절충점과 환경

  

  • 빠른 피드백과 운영 환경과 더 유사한 환경의 필요성 사이에서 절충점 검토

• 산출물 생성

  1. 산출물은 한 번만 빌드해야 한다.
  2. 검증할 산출물이 배포할 산출물이어야 한다.

  • 배포 가능한 아티팩트를 한 번만 빌드하고, 빌드는 파이프라인 초기에 수행하라

    

  • 동일한 산출물이 여러 환경에서 사용되는 경우 환경마다 다른 구성 정보는 산출물 외부에 보관해야 한다.

    • 느린 테스트 단계 환경에서는 테스트 실패 원인을 진단하기 위해 DEBUG 수준 이상의 로그 기록
    • 성능 테스트와 운영 환경에서는 로그 볼륨을 줄이기 위해 INFO로 변경

7.3 소스 코드와 빌드를 마이크로서비스에 매핑하기

• 거대한 리포지터리 하나와 거대한 빌드

  

  • 모든 마이크로서비스와 관련된 검증 단계를 모두 실행하고 동일한 빌드에 연결된 많은 산출물 생성
  • 장점
    • 락스텝 릴리스를 수용한다면 완벽하게 작동
    • 일반적으로는 피해야 할 패턴이지만, 프로젝트 초기에 단일 팀이 모든 작업을 수행하는 경우 이 모델은 짧은 기간에 적합
  • 단점
    • 한 서비스 코드 한 줄을 변경하려하면 다른 모든 서비스까지 검증 및 빌드 → 불필요한 작업
    • 빌드가 중단되는 경우 이 문제가 수정될 때까지 다른 서비스를 변경하지 못 한다.

• 마이크로서비스당 하나의 리포지터리(멀티레포)

  

  • 리포지터리 단위로 소유권 변경 가능
  • 재사용하려는 코드를 라이브러리로 패키징
    • 라이브러리가 변경되면 사용되고 있는 모든 서비스에서 라이브러리 버전 변경이 필요하다.
    • 또한 서비스의 배포도 필요하다.
  • 여러 리포지터리에서 작업
    • 라이브러리를 통한 코드 재사용 말고 다른 방법 없을까?
      • 재고 및 배송 서비스 코드가 다른 리포지터리에 있다면 한 가지 기능의 변경을 위해 두 리포지터리에 대한 커밋으로 분할해야한다.
        • 한 커밋은 실패하고 다른 커밋은 성공한다면?
          • 롤백 시 번거로움
          • 그 사이 다른 사람이 체크인한다면 문제가 더 복잡해질 수 있다.
    • 필자는 여러 리포지터리에 걸쳐 작업하는 고통이 마이크로서비스의 경계를 강화하는 데 도움이 된다고 주장
    • 마이크로서비스 경계를 넘어 많은 변경을 하고 있다면 적합하지 않을 수 있다.

• 모노레포

  • 여러 마이크로서비스에 대한 코드가 동일한 소스 코드 리포지터리에 저장

  • 장점

    • 여러 프로젝트에서 소스 코드를 원자적 방식으로 변경 가능
    • 한 프로젝트에서 다음 프로젝트로 코드를 보다 세밀하게 재사용

  • 빌드 매핑

    

    • 모노레포 내 폴더를 빌드에 매핑
    • 여러 개의 다른 폴더와 둘 이상의 빌드를 트리거하는 일부 폴더가 만들어질 수 있다. → 복잡성 증가

  • 소유권 정의

    • 소유권에 따라 코드에 대한 권한이 달라진다.
    • 관련 파일에 대한 pull 요청이 발생할 때마다 소스 파일의 코드 소유자에게 검토를 요청하게 된다.

  • 도구

    • 구글의 도구
      • 그래프 기반 빌드 시스템, 빌드 시간을 단축하기 위한 분산 객체 링커, IDE용 플러그인, 의존성 파일을 동적으로 확인하는 텍스트 편집기 등

  • 모노의 범위

    

    • 더 큰 규모에서 발생하는 일부 문제를 피하면서 모노레포의 이점 제공
    • 소유권 경계 안에서 동작

  • 적용 대상

    • 모노레포 패턴에서 최상의 결과를 얻기 위해 상당한 자원을 투입할 수 있는 기술 중심의 대기업