[MicroService] MSA의 이해(리액티브 선언, MSA 구성요소, MSA 패턴) 1장

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

▶ 리액티브 선언의 4가지 요소

     ● 응답성(Responsive): 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공하는 것을 의미

     ● 탄력성(Resilient): 장애가 발생하거나 부분적으로 고장나더라도 시스템 전체가 고장 나지 않고 빠르게 복구하는 능력을 의미

     ● 유연성(Elastic): 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미하며 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력

     ● 메시지 기반(Message Driven): 비동기 메시지 전달을 통해 위치 투명성, 느슨한 결합, 논블로킹 통신을 지향하는 것을 의미

 

→ 4가지 요소는 모두 리액티브 시스템을 만들기 위한 요소이고 각 요소는 상호 보완적

→ 리액티브 시스템은 첫 번째 요소인 사용자에게 가장 빠르고 적절한 응답을 제공하기 위해 장애로부터 빠르게 회복하고(탄력성), 시스템은 사용량 트래픽에 반응해 시스템 자원 조절을 유연하게 수행하며(유연성), 메시지 기반 통신을 통해 느슨한 결합 과 위치 투명성을 제공해야 한다는 의미

→ reactive의 사전적 의미는 반응을 보이는 인데 이는 다양한 상황에 따라 빠르고 적절하게 반응하는 시스템을 의미하는데 다양한 상황 이란 여러 프런트 엔드 장비나 시스템 이 연계하는 레거시 시스템과 내부 장비들 그리고 빈번히 발생하는 장애나 트래픽 증감을 의미하는 것으로 급변하는 상황에 적응할 수 있는 시스템을 요구하는 것

→ 여기서 리액티브 시스템이 반드시 갖춰야 할 공통적인 특성 하나를 발견할 수 있는데 바로 아키텍처 유연성(flexibility)

→ 리액티브 시스템이 신뢰성 있는 응답을 빠르게 제공하고 부분적 장애가 빨리 복구되고 수요 증가에 탄력적으로 대응하기 위해서는 시스템 자체가 변화와 확장에 언제든지 대응할 수 있는 아키텍처 유연성을 갖추는 것이 필수

→ 아키텍처 유연성은 시스템을 구성하는 구성 요소 간의 관계들이 느슨하게 맺어져 있어 언제든지 대체되거나 추가 확장될 수 있는 특성을 의미하는데 특히 클라우드 인프라 자체가 변화무쌍한 비즈니스 환경에 대응할 수 있는 유연성과 확장성을 갖추고 있기 때문에 그것을 사용하는 애플리케이션 아키텍처도 반드시 이 같은 아키텍처 유연성을 갖춰야 함

→ 메시지 기반 이라는 요소가 이러한 아키텍처 유연성을 만족시키는 요소라 할 수 있는데 Micro Service 아키텍처에서도 Micro Service 간의 의존성을 줄이는 중요한 특성

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

→ 예전에는 아키텍처의 구성 요소들을 각 기업이나 특정 벤더의 제품에 전적으로 의존해서 구축하 거나 수정이 필요한 부분만 별도로 직접 개발하는 경우가 많았기 때문에 특정 벤더 솔루션이나 프레임워크가 변경될 경우 그것에 의존하는 애플리케이션의 많은 부분들을 변경해야 할 정도로 강 결합돼 있었는데 이처럼 특정 벤더 중심의 아키텍처는 검증된 유명 제품군을 사용한다는 점에서 품질이 보장된다고 생각할 수 있는 반면 특정 벤더에 의존한다는 점에서 특정 기술에 락인(lock-in)되어 쉽게 변경하거나 확장하지 못한다는 단점이 있음

→ 최근에 이러한 분위기를 바꿔 하나의 벤더에 의존하거나 직접 구축할 필요가 적어졌는데 왜냐하면 클라우드 환경하에서 사용되는 오픈소스 또는 오픈소스를 기반으로 한 상용 제품들이 이전의 유명 벤더의 제품군 만큼이나 품질이 높아지고 다양한 기능을 지원하면서 서로 다른 오픈소스 제품 간에도 충분한 호환성을 제공하기 때문

→ 이러한 흐름은 아키텍처 설계 활동에도 변화를 가져왔는데 예전에는 검증된 기술이나 솔루션을 기반으로 기술을 직접 구현하는 폐쇄적인 방식이었던 것에 비해 최근의 아키텍처 설계는 필요한 영역에 적절한 솔루션을 선택하고 조합하는 개방적인 방식으로 바뀌고 있음

→ 최근 아키텍처 설계 문서들을 보면 각 솔루션의 로고로 채워지는 경향이 있는 데, 이것은 아키텍처링이 유연하고 호환성 있는 적절한 솔루션 및 오픈소스를 선택하는 과정 임을 보여줌

 

▶ 레이어 별로 선택된 애플리케이션

▶ 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 제공하는 클라우드 네이티브 지형도(cloud native landscape)

     ● 클라우드 기반의 애플리케이션을 구축하는 데 필요한 인프라 및 애플리케이션 영역에서 다양한 오픈소스 제품이나 상용 제품이 사용되고 있음

     ● 클라우드 네이티브 지형도는 매년 매분기 마다 업데이트되고 있는데 얼마나 많은 영역에서 다양한 오픈소스 및 제품들이 생겨나고 포진돼 있는지 알 수 있음

     ● 아키텍트는 이처럼 다양한 기술 영역의 변화 흐름을 이해하고 따라가야 하며 최적의 클라우드 환경을 구성할 적절한 제품 및 솔루션을 선택해서 조합할 필요가 있음

     ● 이러한 모습은 강 결합 위주의 모노리스 아키텍처가 유연하고 느슨하게 결합되는 Micro Service 기반 아키텍처로 변화되고 있음을 보여주기도 함

 

▶  Micro Service 아키텍쳐 – 각 구성 요소들은 대체하거나 변경할 수 있도록 구성

     ● 밑에서부터 인프라, 플랫폼, 애플리케이션 영역으로 구분되며 각 관계를 설명하면 맨 아래에 기반이 되는 하드웨어 인프라가 있고, 인프라 영역 위에 애플리케이션을 운영 및 구동하기 위한 플랫폼이 올라가며 플랫폼 위에 애플리케이션인 서비스가 구동됨

     ● 아래의 인프라 영역 과 플랫폼 영역, 애플리케이션 영역에 있는 구성 요소 및 그것들의 관계를 정의하는 것이 MSA 외부 아키텍처(outer architecture)

     ● 외부 아키텍처는 Micro Service가 운영되는 환경을 정의하는데 여기에는 인프라 환경, 플랫폼 환경, Micro Service가 운영되는 애플리케이션 환경이 모두 포함되며 특히 애플리케이션 측면에서는 여러 개의 Micro Service를 관리하고 운영하기 위한 애플리케이션도 모두 포함되는데 이러한 환경을 클라우드 아키텍처가 요구하는 유연성과 확장성을 고려해서 정의해야 하는 것

     ● 실제로 비즈니스가 실행되는 비즈니스 애플리케이션 즉 각 Micro Service의 내부 구조도 정의해야 하는데 이를 MSA 내부 아키텍처(inner architecture) 라고 함

     ● 내부 아키텍처는 Micro Service가 제공하는 API, 비즈니스 로직, 이벤트 발행, 데이터 저장 처리 등을 어떻게 구조화해야 하는가에 관한 내용이며 당연히 이 구조도 변화에 적응 가능하도록 유연하고 확장성 있게 구현해야 함

 

---

◆ MSA 구성 요소 및 MSA 패턴

▶ 저명한 소프트웨어 아키텍트인 크리스 리처드슨(Chris Richardson)은 Micro Service 관련 기술을 설명하는 자신의 온라인 매체인 microservices.io 에서 이러한 Micro Service 아키텍처 패턴을 인프라 패턴, 애플리케이션 인프라 패턴, 애플리케이션 패턴 등으로 분류해서 정의

▶ 인프라가 구축돼야 하고 그 위에 미들웨어가 올라가고 미들웨어 위에서 애플리케이션이 동작

▶ MSA 구성 요소 및 패턴의 유형

     ● 인프라 구성 요소: Micro Service를 지탱하는 하부 구조 인프라를 구축하는 데 필요한 구성요소

     ● 플랫폼 패턴: 인프라 위에서 Micro Service의 운영과 관리를 지원하는 플랫폼 차원의 패턴

     ● 애플리케이션 패턴: Micro Service 애플리케이션을 구성하는 데 필요한 패턴

▶ 인프라 구성 요소

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

     ● 클라우드 환경에서는 이러한 인프라 구성요소가 가상화 되어 제공

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

        → 예전에 오랜 시간에 걸쳐 힘들게 구축했던 인프라를 이제는 AWS, 구글, 마이크로소프트, IBM 등 세계적인 플랫폼 사업자들이 자동화된 IaaS(Infrastructure as a Service), PaaS(Platform as a Service) 서비스를 통해 쉽고 편하게 이용할 수 있게 제공

        → 예를 들면 시스템의 자원 구성, 할당. 관리, 모니터링 등이 클라우드 서비스로 구성돼 있어 일련의 설정 작업을 몇 번의 버튼 클릭만으로 처리할 수 있음

        → 이 같은 환경에서 아키텍트가 해야 할 일을 하나씩 살펴보면 먼저 맨 하부의 시스템의 기반이 되는 인프라를 구축해야 하는데 여기서 고민은 기존의 물리적인 베어 메탈 장비를 구매해서 구축 해야 하느냐 아니면 가상화 환경을 선택해서 이용하느냐 이며 또한 가상화 환경에 구축하기로 결정했더라도 클라우드 사업자가 서비스로 제공하는 퍼블릭 laaS, PaaS를 선택할지 또는 직접 구매 하거나 기존의 보유한 베어 메탈 서버에 프라이빗 PaaS를 구축할지를 고민해야 함

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

        → Micro Service는 어떠한 장비에도 구동될 수 있는데 Micro Service는 어떠한 환경에서도 유연하도록 구성돼야 하므로 특정 인프라를 고집하지 않지만 가상화 장치없이 베어 메탈 장비로 Micro Service 애플리케이션을 구동한다면 Micro Service마다 베어 메탈 장비를 구축해야 하고 인프라의 유연한 확장/축소를 기대하기 힘든 무모한 작업이 될 것이므로 당연히 가상 인프라 환경을 검토할 필요가 있으며 MSA 시스템을 위한 베어 메탈을 고려한다면 그것은 베어 메탈에 별도의 프라이빗 클라우드 환경을 구축하는 것을 의미

        → 예전 같으면 이러한 하위의 인프라 선택이 그 위에 올라가는 다른 소프트웨어 구 성 요소에 영향을 끼쳤겠지만 요즘은 인프라환경으로 퍼블릭 클라우드 환경이나 프라이빗 클라우드 환경이나 어떤 것을 선택하든 다른 아키텍처 요소와 유연하게 결합할 수 있어 크게 신경 쓸 필요가 없는데 이러한 모든 소프트웨어들이 상호 독립적이고 서로 호환되도록 유연한 구조로 만들어졌기 때문

        → 이처럼 유연성이 클라우드 기반 소프트웨어의 필수 요소로 자리 잡고 있는 것이 요즘 추세

 

     ● VM 과 컨테이너

        → 가상 인프라 환경을 활용하기로 선택했다면 그 다음으로 가장 먼저 고민해야 할 사항은 가상 머신(VM; Virtual Machine) 제품과 컨테이너 기반 제품 중 하나를 선택하는 문제

        → 차이점을 살펴보면 가상 머신은 하이퍼바이저(hypervisor)라는 소프트웨어를 이용해 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술인 반면 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성

        → 차이점은 게스트 OS의 유무로 볼 수 있는데 게스트 OS를 사용하는 가상 머신에서는 운영체제 패치 설치나 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생하기 때문에 Micro Service 같은 작은 서비스를 패키지하고 배포하기에는 컨테이너 환경이 더 적합

        → 가장 대표적인 컨테이너 기술로는 필요 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커(Docker)가 유명하고 가장 많이 사용됨

        → 도커 컨테이너는 레이어 단위의 이미지를 포개는 방식으로 구성되며 밑에서 부터 애플리케이션 구동을 위한 기반 이미지, 운영체제, 런타임, 애플리케이션이 이미지로 정의

        →  도커 컨테이너의 이점

            ∵  이식성: 어떠한 호스트 커널이나 플랫폼 버전에 상관없이 도커만 실행할 수 있으면 사용 가능하며 동일하게 동작

            ∵  신속성: 크기가 작고 가볍기 때문에 빠르게 배포 가능하며 문제 발생 시 수정할 필요 없이 새로 기동하면 됨

            ∵  재사용성: 동일한 환경을 재사용해서 쉽게 설정 가능하기 때문에 개발, 테스트, 스테이징, 프로덕트 환경을 동일한 환경으로 구축하기가 쉬움

        →  Micro Service 같이 독립적으로 배포되고 수정되기 위한 환경은 가상 머신보 다는 컨테이너가 더 적절한데 Micro Service의 가변적이고 유연한 속성을 컨테이너가 쉽고 빠르게 지원할 수 있기 때문

        →  가장 많이 사용하는 가상 머신 제품군으로는 AWS EC2, 애저(Azure) VM 등이 있고 컨테이너 기술로는 도커 외에 Unikernels, LXD, OpenVZ, RKt 등이 있으나 도커가 가장 유명하고 실질적 표준으로 자리 잡고 있음

 

---

2장에서 이어서컨테이너 오케스트레이션 내용부터 포스팅하도록 하겠다. 아래 포스팅을 이어보도록하자.

https://joylucky7.tistory.com/51