마이크로서비스 아키텍처 구축 : 8장 배포

8.1 논리적에서 물리적으로

• 다수 인스턴스

  

  • HTTP 기반 통신이라면 로드 밸런서를 이용해 다수 인스턴스에 요청 매핑
  • 다른 여러 데이터 센터에 분산

• 데이터베이스

  • 마이크로서비스의 내부 상태 관리는 감춰져야 한다. → 데이터베이스를 공유하지 말라

  • 마이크로서비스 인스턴스마다 자신만의 데이터베이스는 있을 필요 없다.

  • 동일한 마이크로서비스의 다른 인스턴스들과 DB 공유

  • 읽기 복제본을 사용한 부하 분산

    

    • 확장 시 읽기 전용 트래픽을 읽기 복제본에 옮겨서 쓰기 노드에 더 많은 용량 확보
    • 동일한 데이터베이스 인프라스트럭처가 논리적으로 분리된 여러 데이터베이스를 지원할 수 있다.

  • 동일한 물리 데이터 인프라스트럭처에서 논리적으로 분리된 두 데이터베이스

    

    • 동일 하드웨어, 데이터베이스 엔진
      • 공유 데이터베이스 인프라스트럭처가 고장나면 여러 마이크로서비스에 영향
      • 비용 저렴

  • 각 마이크로서비스는 자신만의 DB 전용 인프라스트럭처 활용

    

    • 비용 증가
    • 공유 서비스에 의존하지 않음

• 환경

  

  • 로컬 개발 → CI → 사전 운영 환경 → 운영 환경
  • 운영 환경과 가까우면 좋지만 비용때문에 타협할 수 있음
    • 예시
      • CI 환경에서는 동일 인스턴스 서비스 복사본 2개
      • 운영환경에서는 서로 다른 2개의 데이터 센터에 서비스 복사본 4개 배포

8.2 마이크로서비스 배포의 원칙

• 격리 실행

  • 마이크로서비스 인스턴스가 자체 컴퓨팅 자원을 가진 격리된 방식으로 실행

  • 단일 머신에 모든 마이크로서비스 인스턴스를 넣는 경우

    • 장점
      • 인프라스트럭처 팀의 작업 부하가 줄어든다.
    • 단점
      • 모니터링이 어려워질 수 있다.
        • 서비스 별 CPU 사용량 관리 어려움
      • 한 서비스에 부하가 걸리면 시스템의 다른 부분에 사용할 수 있는 자원이 줄어든다.
      • 의존성으로 인한 팀의 자율성 저해 가능성 존재

  • 호스트 당 하나의 마이크로서비스 인스턴스
    - 장점
    - 격리된 실행환경
    - 각 서비스 별 전용 자원

    

• 자동화 집중

  • 마이크로서비스 수가 증가하므로 자동화 중요
    • 개발자의 생산성 유지 가능
      • 마이크로서비스가 늘어남에 따라 운영 배포 환경 구축 시간 단축

• 코드형 인프라스트럭처

  • 환경을 재구축할 수 있도록 코드를 소스에 저장
    • 예시 : Terraform, AWS CDK
  • 구성 정보를 버전 관리하고 테스트하며 자유롭게 반복 가능

• 무중단 배포

  • 사용자를 방해하지 않고 릴리스 가능
    • 배포 시 비동기 통신이라면 메세지 유실 가능성 저하
    • 동기식은 통신 중에 배포한다면 통신 내용 유실
  • 롤링 업그레이드
    • 새 버전 배포 전까지 이전 버전 마이크로서비스가 종료되지 않는다.

• 기대 상태 관리

  • 장애 발생, 트래픽 증가 시 새로운 인스턴스 시작
  • 실행중인 시스템이 원하는 기대 상태가 더 이상 유지 되지 않는 방식으로 변경되면 기반 플랫폼은 시스템이 원하는 상태로 되돌리려고 필요한 단계 수행

    • 인스턴스 수, 메모리 용량, CPU 연산량 등

      

  • 예시 : 쿠버네티스, 노마드
  • 장점
    • 플랫폼 스스로 원하는 상태를 유지하는 방법을 관리
    • autoscaling group
  • 전제 조건
    • 마이크로서비스 인스턴스에 대한 완전 자동화된 배포
    • 관리할 항목이 많을 때 유용
  • 깃옵스
    • 기대 상태 관리와 코드형 인프라스트럭처의 개념 통합

8.3 배포 방법

• 격리된 방식으로 실행, 다운타임이 없는 이상적인 방식으로 배포되길 원한다. 또한 자동화 문화 수용, 인프라스트럭처 및 애플리케이션 구성을 코드로 정의, 이상적인 기대 상태 관리

• 물리 머신

  • 가상화 없이 물리 머신에 직접 배포
  • 단점
    • 자산 전체의 활용도 낮아질 수 있다.
  • 따라서 동일한 물리머신에서 여러 가상 머신 공존하는 방법 채택 가능

• 가상 머신

  • 기존 물리 머신을 더 작은 가상 머신으로 분할

  • 예시 : AWS EC2

  • 장점

    • 인프라 사용도를 높이는 동시에 호스트 관리 부담 저하

  • 단점

    • 가상 머신을 담당하는 하부 하드웨어가 고장나면 여러 마이크로서비스 인스턴스가 손실

  • 하부의 CPU, 메모리, I/O, 스토리지를 각 가상 머신에 할당 가능

  • 가상화 비용

    • 가상 머신을 같은 하부 하드웨어에 넣을 수록 VM 자체에서 가용한 컴퓨팅 리소스는 효용이 떨어지는 현상

    • 이유

      • 하이퍼바이저의 오버헤드

    • 하이퍼바이저 기능

      

      • CPU, 메모리 자원을 가상 호스트에 물리 호스트 매핑
      • 가상 머신 자체 조작

  • 가상 머신이 제공하는 엄격한 격리 수준이 필요하거나 애플리케이션을 컨테이너화 할 수 있는 능력이 없다면 VM은 훌륭한 선택

• 컨테이너

  • 가상 또는 물리 머신에서 격리된 컨테이너로 실행
  • 대규모 마이크로서비스 아키텍처를 실행하기 위해 찾는 선택지
  • 장점
    • 하이퍼바이저가 필요 없다.
    • 하부 머신의 커널을 이용하기 때문에 컨테이너에 커널이 없다.
      • 컨테이너는 자체 운영체제를 실행할 수 있지만 운영체제는 공유 커널의 일부를 사용한다.
        • 리눅스에서 프로세스는 특정 사용자의 의해 실행되며 권한 설정 방법에 따라 특정한 기능 존재
        • 프로세스 트리를 관리해 허용된 사용자만 프로세스에 액세스 할 수 있게 만든다.
    • 가상 머신보다 프로비저닝이 훨씬 빠르다.
      • 프로비저닝 : 서비스나 시스템이 동작할 수 있도록 필요한 자원(서버, 네트워크, 스토리지, 소프트웨어 등)을 준비하고 설정하는 과정 전체
  • 단점
    • 완전하지는 않다.
      • 컨테이너를 통해 외부 세계 라우팅 방법 필요 → Docker
      • 가상 머신 격리 수준과 동일하지 않다.
        • OOM 공유 등
  • 윈도우 컨테이너
    • 컨테이너 수준의 격리를 우회하려는 악의적인 당사자가 있다면? → 윈도 컨테이너
    • 장점
      • 자체 Hyper-V VM 내에서 컨테이너를 실행해 더 많은 격리 제공 가능
      • Hyper-V, 프로세스 격리 중 선택 가능
    • 단점
      • 윈도 운영체제 자체의 크기가 너무 크다.
  • 도커
    • 컨테이너 프로비저닝 관리, 일부 네트워킹 문제 처리, 자체 레지스트리 개념 제공
    • 이미지를 빌드하거나, 미리 빌드된 이미지를 가져와 로컬에서 실행 가능
    • 여러 컨테이너를 관리하기 위해 도커 스웜을 출시했지만 쿠버네티스가 최고

• 애플리케이션 컨테이너

  • 여러 인스턴스를 함께 그룹화하는 클러스터링 지원, 모니터링 도구 등과 같은 관리 용이성 측면에서 이점 제공
  • 단점
    • 기술 선택 제한
    • 동일한 프로세스를 여러 애플리케이션이 공유하므로 리소스 사용 및 스레드 분석이 복잡

• PasS

  • 예시 : 히로쿠, AWS Beanstalk
  • 자바의 WAR 파일이나 루비의 gem과 같은 산출물을 가져와서 자동으로 프로비저닝, 실행하는데 의존
  • 단점
    • 제대로 동작하지 않을 때 문제 해결을 위한 내부 접근 권한이 많지 않은 경우가 흔하다.

• FaaS

  • 예시 : AWS 람다
  • 서버리스의 주요 부분
    • 하부 컴퓨터가 중요하지 않고 다양한 기술을 가진 호스트를 포괄
  • 장점
    • 사용한 만큼만 비용 지불
      • 부하가 적거나 예측할 수 없는 상황에서 훌륭한 선택지
        • 부하가 많을 경우 EC2 선택
  • 제한 사항
    • 정확히 실행할 수 있는 것에 대한 제어 부족
    • 함수 호출이 실행할 수 있는 시간을 제한
      • 최대 15분 실행 가능
    • 함수 호출은 무상태
  • 문제점
    • 콜드 스타트
      • 가벼운 언어로 보완 → go, python, ruby 등
    • 함수의 최대 동시 호출 수 제한 → 동적 확장 어려움
  • 마이크로서비스와 매핑
    • 하나의 함수만 배포 가능해서 내부에서 경로에 따라 기능 분기
      • 예시 : url 에 따른 기능 분기 등
    • 애그리거트 당 함수 매핑
      • 각 애그리거트에 대한 함수로 분리
      • 마이크로서비스를 더 작게 쪼갠 구조 가능
      • 문제점
        • 외부에서는 하나의 마이크로서비스처럼 보여야한다.

8.4 어떤 배포가 적합할까?

• 샘의 정말 기본적인 경험 규칙
  • 고장 나지 않았다면 고치지 말라
  • 당신이 만족한다고 느끼는 만큼 통제권을 포기한 다음 조금씩 더 포기하라. 모든 작업을 히로쿠와 같은 훌륭한 PasS에 맡길 수 있다면 그렇게 하고 만족하라
  • 마이크로서비스를 컨테이너화하는 일이 쉬운 일은 아니지만, 격리 비용에 대한 우수한 절충안임은 분명하다.

8.5 컨테이너 오케스트레이션에 대한 사례

• 컨테이너 오케스트레이션 플랫폼이란?
  • 컨테이너 워크로드가 실행되는 방법과 위치를 다룬다.
  • 기대 상태를 관리해 컨테이너들이 예상된 상태가 유지되도록 한다.

• 노드 : 워크로드가 실행할 머신 집합

• 컨트롤 플레인 : 노드를 관리하는 소프트웨어

• 파드 : 노드 내부 물리 머신 또는 가상 머신

• 서비스 : 안정적인 라우팅 엔드포인트

  • 실행중인 파드로부터 클러스터 내에서 사용할 수 있는 안정적인 네트워크 인터페이스 매핑

• 레플리카셋 : 파드들의 기대 상태 정의

• 디프로이먼트 : 파드와 레플리카셋에 대한 변경 사항 적용

  • 실행 중인 파드에 변경 사항 적용 가능

• 멀티테넌트

  • 부서마다 다양한 자원에 대해 서로 다른 수준의 제어 가능

    • 구축된 플랫폼 채택

      • 레드햇, 오픈시프트 등

    • 페데레이션 모델

      

      • 여러 개로 분리된 클러스터를 가질 수 있다.
      • 리소스 풀링이 어려워진다.
        • 클러스터 B의 유휴 노드를 클러스터 A에 제공하기 어렵다.

• CNCF

  • 클라우드 네이티브 기술의 발전과 생태계 조성을 목표로 하는 리눅스 재단 산하의 개방형 오픈소스 재단
  • 클라우드 네이티브 개발을 촉진하는 프로젝트의 생태계를 큐레이션하는 데 중점

• 쿠버네티스

  • 플랫폼으로 묘사
    • 서비스 메시, 메시지 브로커, 로그 집계 도구 등과 같은 지원 소프트웨어를 설치해 자체 플랫폼 구축
  • 이론적으로 클러스터 간에 이식 가능하지만 실제로 항상 가능하지는 않다.
  • 헬름
    • 쿠버네티스의 누락된 패키지 매니저
  • 오퍼레이터
    • 애플리케이션의 지속적인 관리
  • CRD (Custom Resource Definition)
    • 사용자 지정 리소스 정의
    • 기존 명령줄 인터페이스, 액세스 제어 등과 원활하게 통합

• Knative

  • 내부적으로 쿠버네티스를 사용해 개발자에게 FasS 방식의 워크 플로 제공하는 것이 목표인 오픈소스 프로젝트
  • 개발자에게 쿠버네티스의 복잡성을 숨기고 FasS의 개발자 경험을 쿠버네티스에 가져온다.
  • Istio 안정적

8.6 점진적 제공

• 자주 출시하고 실패율을 낮춘다.
• 배포 : 소프트웨어의 일부 버전을 특정 환경에 설치될 때 발생
• 릴리스 : 시스템이나 그 일부를 사용자가 사용할 수 있도록 만드는 것
• 점진적 제공 : 폭발 반경을 세밀하게 제어하면서 지속적으로 제공하는 것
• 기능 토글을 통해 사용자의 특성에 따라 플래그가 다른 상태를 갖도록 설정
• 카나리아 릴리스
  • 제한된 일부 고객에게만 새로운 기능을 제공
  • 토글을 이용해 마이크로서비스의 이전, 새 버전 라우팅 조절
• 병렬 실행
  • 동일한 기능의 서로 다른 두 구현을 나란히 실행하고 기능에 대한 요청을 두 구현체로 보낸다.
  • 두 구현을 모두 실행할 때 하나의 결과만 원할 가능성이 높다.
    • 신뢰할 수 있는 출처로 간주