책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 4일차 (~32p)

요약

  • MSA의 기술 영역 아키텍처에 대해 이해함.
    • 리액티브 선언
      • 빠른 응답이 중요
      • 아키텍처의 유연성이 중요
    • 느슨한 결합의 아키텍처로의 변화
      • 특정 벤더에 의존하지 않도록 다양한 벤더를 사용하고 서로 조합함.
    • 마이크로서비스의 외부 아키텍처와 내부 아키텍처가 존재함.
      • 외부 아키텍처는 마이크로서비스가 운영되는 환경임
      • 내부 아키텍처는 마이크로서비스가 제공하는 API, 비즈니스 등을 의미함.
  • MSA 구성 요소와 MSA 패턴을 이해함.
    • 인프라 구성요소
      • 퍼블릭 클라우드, 베어메탈, 프라이빗 클라우드
      • 가상 머신(VM)과 컨테이너

메모

02. MSA의 이해

  • 이번 장에서 본격적으로 기술 영역인 아키텍처에 대해 살펴본다.
    • 리액티브 선언을 통해 현대 아키텍처의 경향성을 알아본다.
    • 한덩어리로 구성된 모노리스 시스템에서 여러 조각으로 구성되는 마이크로 서비스 시스템으로 변화함에 따라 발생하는 문제점들을 해결하기 위해 등장한 MSA 패턴을 살펴본다.

2.1 리액티브 선언: 현대 에플리케이션이 갖춰야 할 바람직한 속성들

  • 소프트웨어 아키텍처란?
    • 소프트웨어를 구성하는 요소와 그 구성요소 간의 관계를 정의한 것임.
  • 아키텍처를 정의하는 과정은 시스템 구축을 위한 여러 가지 비기능 요건을 만족하는 다양한 해결 방법을 찾는 과정임.
  • 마이크로서비스 아키텍처는 클라우드라는 가상화된 인프라를 활용해서 구조화하는 것이기 때문에 가상화된 인프라의 특징을 고려하여 설계해야 함.
  • 사람들은 현대의 애플리케이션들이 요청에 즉각 응답하고 항상 가동되길 기대함.
    • 이와 같은 현대 애플리케이션에 대한 기대를 잘 표현한 문서가 리액티브 선언문임.
      • 응답성
      • 탄력성
      • 유연성
      • 메시지기반
        • 이라는 4가지 특성을 강조하고, 이 요건을 만족하는 시스템을 리액티브 시스템이라고 정의함.
        • 각 요소는 상호 보완적임.
        • 이 시스템을 리액티브 시스템이라고 부르는 이유는?
          • 다양한 상황에 따라 빠르고 적절하게 반응하는 시스템을 의미함.
          • 다양한 상황 = 프런트엔드 장비나 시스템이 연계하는 레거시 시스템과 내부 장비들, 그리고 빈번히 발생하는 장애나 트래픽 증감을 의미함.
            • 즉, 급변하는 상황에 적응할 수 있는 시스템을 요구함.
  • 리액티브 시스템이 반드시 갖춰야할 공통 특성은 바로 아키텍처 유연성임(flexibility)
    • 신뢰성 있는 응답을 빠르게 제공하고 부분적 장애가 빨리 복구되고, 수요 증가에 탄력적으로 대응하려면 시스템 자체가 변화와 확장에 언제든지 대응할 수 있는 아키텍처 유연성을 갖춰야 함.
    • 아키텍처 유연성은 시스템을 구성하는 요소간의 관계들이 느슨하게 맺어져 있어 언제든지 대체되거나 추가될 수 있는 특성을 말함.
      • ex) 클라우드 인프라가 변화무쌍한 비즈니스 환경에 대응할 수 있는 유연성과 확장성을 갖춰야함.
    • “메시지 기반” 요소는 이러한 아키텍처 유연성을 만족시키는 요소임.

2.2 강 결합에서 느슨한 결합의 아키텍처로의 변화

  • 예전에는 아키텍처의 구성요소들을 각 기업이나 특정 벤더의 제품에 전적으로 의존해서 구축하거나 수정이 필요한 부분만 별도로 직접 개발하는 경우가 많았음.
    • 특정 벤더 중심의 아키텍처는 검증된 유명 제품군을 사용한다는 점에서 품질이 보장된다고 생각할 수 있음.
    • 하지만, 특정 벤더에 의존한다는 점에서 특정 기술에 락인(lock-in)되어 쉽게 변경하거나 확장하지 못한다는 단점이 있음.
  • 최근에는 하나의 벤더에 의존하거나 직접 구축할 필요가 적어짐.
    • 클라우드 환경하에서 사용되는 오픈소스 제품 간에도 충분한 호환성을 제공하기 때문임.
  • 최근의 아키텍처 설계는 필요한 영역에서 적절한 솔루션을 선택하고 조합하는 개방적인 방식으로 바뀌고 있음.
    • 클라우드 네이티브 지형도를 보면 (p28) 얼마나 많은 영역에서 다양한 오픈소스 및 제품들이 생겨나고 포진돼 있는지 알 수 있음.
      • 따라서, 아키텍트는 이처럼 다양한 기술 영역의 변화 흐름을 이해하고 따라가야 함.
      • 최적의 클라우드 환경을 구성할 적절한 제품 및 솔루션을 선택해서 조합할 필요가 있음.
      • 이 모습은, 강 결합 위주의 모노리스 아키텍처가 유연하고 느슨하게 결합되는 마이크로서비스 기반 아키텍처로 변화되고 있음을 보여줌.

2.3 마이크로서비스의 외부 아키텍처와 내부 아키텍처

  • 위 그림은 마이크로서비스 아키텍처의 예임.
  • 각 구성요소는 밑에서 부터 인프라, 플랫폼, 애플리케이션 영역으로 구분됨.
    • 인프라 영역과 플랫폼 영역, 애플리케이션 영역에 있는 구성요소 및 그것들의 관계를 정의하는 것을 MSA 외부 아키텍처라고 함.
    • 즉, 외부 아키텍처는 마이크로서비스가 운영되는 환경을 정의함.
  • 실제로 비즈니스가 실행되는 비즈니스 애플리케이션, 즉 각 마이크로서비스의 내부 구조도 정의해야함.
    • 이를 MSA 내부 아키텍처라고 함.
    • 내부 아키텍처는 마이크로서비스가 제공하는 API, 비즈니스 로직, 이벤트 발행, 데이터 저장 처리 등을 어떻게 구조화해야 하는가에 관한 내용임.
    • 이 구조도 변화에 적응 가능하도록 유연하고 확장성 있게 구현해야 함.

2.4 MSA 구성요소 및 MSA 패턴

  • MSA 의 문제 영역에 대해 여러 사람들에 의해 검증되어 정리된 유용한 해법을 아키텍처 스타일 또는 아키텍처 패턴이라고 부름.
    • 마이크로서비스 아키텍처도 이 같은 패턴이 존재함.
  • 소프트웨어 아키텍트인 크리스 리처드슨은 마이크로 서비스아키텍처 패턴을
    • 인프라 패턴
    • 애플리케이션 인프라 패턴
    • 애플리케이션 패턴
      • 으로 분류해서 정의함.
  • 여기서는 실제로 시스템을 개발하는 개발자 입장에서 마이크로 서비스 시스템을 구현하기 위해 밟아야할 단계들을 순서대로 살펴본다.
    • 우선 인프라가 구축돼야 함.
      • 인프라 구성요소
    • 그 위에 미들웨어가 올라감.
      • 플랫폼 패턴
    • 미들웨어 위에서 애플리케이션이 동작해야함.
      • 애플리케이션 패턴

2.4.1 인프라 구성요소

  • IT 업계에서 ‘인프라’의 의미는 엔터프라이즈 IT 환경을 운영하고 관리하는 데 필요한 근간이 되는 하드웨어, 소프트웨어, 네트워킹 구성요소, 운영체제, 데이터 스토리지 등을 모두 포함함.

퍼블릭 클라우드와 베어 메탈, 프라이빗 클라우드 환경

  • 이제 AWS, 구글, 마이크로소프트 IBM의 세계적 플랫폼 사업자들이 자동화된 Iaas, Paas 서비스를 제공하고, 우리가 이를 편하게 이용할 수 있도록 함.
    • 우리는 여기서 인프라 구축 시, 고민한다.
      • 기존의 물리적인 베어 메탈 장비를 구매해서 구축하는가?
      • 가상화 환경에서 구축한다면?
        • 퍼블릭 Iaas, Paas?
        • 베어 메탈 서버에 프라이빗 Paas?
  • 사실 마이크로 서비스는 어떠한 장비에도 구동될 수 있음.
    • 어떠한 환경에서도 유연하도록 구성돼야 하므로 특정 인프라를 고집하지 않음.
    • 하지만 가상화 장치 없이 베어 메탈 장비로 마이크로서비스 애플리케이션을 구동하려면 인프라의 유연한 확장/축소를 기대하기 힘든 무모한 작업이 될 것임.
      • 따라서, 가상 인프라 환경을 당연히 검토해야 함.
      • MSA 시스템을 위한 베어 메탈을 고려한다면, 베어 메탈에 별도의 프라이빗 클라우드 환경을 구축하는 것을 의미함.
  • 예전에는 인프라 환경으로 퍼블릭, 프라이빗 클라욷 환경에 따라 소프트웨어 구성요소에 영향을 미쳤음.
    • 요즘은 인프라 환경으로 퍼블릭, 프라이빗 어떤 것을 선택하더라도 다른 아키텍처 요소와 유연하게 결합할 수 있어 크게 신경쓰지 않아도 됨.
    • 모든 소프트웨어들이 상호 독립적이고 서로 호환되도록 유연한 구조로 만들어 졌기 때문

VM과 컨테이너

  • 가상 인프라 환경을 활용한다면, 그 다음으로 고민할 것은
    • 가상 머신제품과 컨테이너 기반 제품 중 하나를 선택하는 문제다.

  • 가상 머신은 하이퍼바이저라는 소프트웨어를 이용해 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술임.
  • 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해서 가상의 격리된 공간을 생성함.
    • 차이점은 게스트 OS의 유무로 볼 수 있음.
    • 게스트 OS 를 사용하는 가상 머신에서는 운영체제 패치 설치나 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생함.
      • 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에는 컨테이너 환경이 더 적합함.
  • 가장 대표적인 컨테이너 기술로는 필요 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커가 유명하고 가장 많이 사용됨.

  • 위 그림은 도커 컨테이너의 이미지 레이어임.
    • 밑에서부터 애플리케이션 구동을 위한 기반 이미지, 운영체제, 런타임, 애플리케이션이 이미지로 정의됨.
  • 도커 컨테이너는 다음과 같은 이점이 있음.
    • 이식성
    • 신속성
    • 재사용성

댓글

Designed by JB FACTORY