마이크로서비스 외부 아키텍처1 - 클라우드 인프라 패턴

마이크로서비스 외부 아키텍처1 - 클라우드 인프라 패턴

아키텍처가 문제 영역에 대한 솔루션을 제공하는 것이라 했는데 MSA는 어떠한 문제 영역이 있을까? 또한 어떤 솔루션으로 그 문제를 해결하고 있는가? 어떤 문제 영역에 대한 검증되고 정의된 유용한 해법을 우린 아키텍처 스타일, 아키텍처 패턴이라고 부르는데 마이크로서비스 아키텍처에도 이런 패턴이 존재한다.

저명한 SW 아키텍트인 크리스 리처드슨은 마이크로서비스 관련 기술을 설명하는 자신의 온라인 매체인 microservice.io 에서 이런 마이크로서비스 아키텍처 패턴을 인프라 패턴, 애플리케이션 인프라 패턴, 애플리케이션 패턴 등으로 분류해서 정의했다.

유용한 분류방법이지만 여기서는 실제로 시스템을 구현하는 아키텍트의 입장에서 시스템을 구현하기 위해 먼저 정의 해야할 실행 순서대로 살펴보는 것이 좋을 것 같다. 그래서 마이크로서비스 아키텍처 및 그에 관련된 패턴들을 다음과 같이 구분하여 설명한다.

아키텍처 유형	패턴 유형	설명
마이크로서비스 외부 아키텍처	클라우드 인프라 패턴	마이크로서비스를 지탱하는 하부구조 인프라를 정의하는 패턴들
	플랫폼 패턴	인프라 위에서 마이크로서비스를 운영 관리를 지원하는 플랫폼 차원의 패턴들
마이크로서비스 내부 아키텍처	마이크로서비스 관계 패턴	마이크 서비스 유형 간의 관계를 정의하고 처리하는 패턴들
	마이크로서비스 내부 패턴	마이크로서비스 내부의 구조를 정의하는 패턴들

이번 글 에서는 먼저 마이크로서비스가 운영되는 환경 MSA외부 아키텍처에 대해 자세히 설명하려고 하며, 우선 시스템을 아래에서 지탱하는 인프라 패턴부터 살펴보도록 하자.

클라우드 인프라 패턴

유연하고 확장성 있는 인프라영역을 구성해 보자. 유연하고 확장성 있는 인프라를 구성하려면 일반적으로 쉽게 확장할 수 있는 가상인프라가 고려된다. 그럼 인프라 구성 시 고려할 사항에 대해 살펴보자.

베어 메탈(bare metal) 과 클라우드 제품들

예전에 오랜 시간 힘들게 구축했던 인프라를 AWS, 구글, 마이크로소프트, IBM 등 세계적인 플랫폼 사업자들이 자동화된 IaaS, PaaS 서비스로 쉽고 편하게 제공하고 있다. 예를 들면 시스템의 자원 구성, 할당, 관리, 모니터링 등 일련의 작업들을 몇 번 만의 버튼 클릭만으로 시각화, 자동화해서 제공하고 있다.

이런 환경에서 아키텍트가 해야 할 일을 하나씩 살펴보면 제일 아래의 시스템의 기반이 되는 인프라 영역에서 위에 언급한 클라우드 사업자가 제공하는 IaaS, Paas를 선택할지 기존 물리적인 베어 메탈(bare Metal) 장비를 선택할지 결정하는 일이다. 사실 마이크로서비스는 어떠한 장비에도 구동될 수 있다. 마이크로서비스는 어떠한 환경에서도 유연 하도록 구성되어야 하기 때문에 이런 인프라의 특성을 따지지 않기 때문이다. 그렇지만 가상화 장치없이 베어 메탈 장비로 마이크로서비스 어플리케이션을 구동한다면 무모한 작업이 될 것이다. 따라서 당연히 가상 인프라 환경을 검토하게 된다.

가상화 환경으로 가기로 결정했더라도 클라우드 사업자가 제공하는 IaaS,Paas를 선택할지 또는 직접 오픈 소스로 프라이빗(Private) 한 Paas를 구축할지 고민해야 한다.

클라우드 사업자의 제품이든, 오픈소스 든 어떤 것을 선택할지라도 그 외 아키텍처 요소들과 유연하게 결합할 수 있는데 이건 각 제품들이 상호 독립적이고 호환되도록 모두 유연한 구조로 만들기 때문에 가능한 일이다. 요즘의 추세는 이렇게 유연성이 소프트웨어의 필수 요소가 되고 있다

vm과 컨테이너

가상 인프라 선택에서 제일 먼저 고민되는 사항은 가상 머신(VM) 과 컨테이너를 기반으로 한 제품 사이에서 고민이다. 그 차이점을 살펴보면 가상화는 하이퍼바이저라는 소프트웨어를 이용해서 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술이다. 반면에 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성한다. 즉, 게스트OS가 있느냐 없느냐가 가장 큰 차이이다. 게스트 OS를 사용하는 가상 머신 은 게스트 운영체제 패치 설치와 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생하게 된다.

따라서 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에 컨테이너가 더 적합하다. 가장 대표적인 컨테이너 기술로는 필요한 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커 컨테이너가 가장 유명하고 많이 쓰이고 있다.

컨테이너 오케스트레이션(Orchestration)

만약 컨테이너 기술을 선택했다면 이런 컨테이너를 관리하기 위한 기술 또한 필요하다. 이런 기술을 컨테이너 오케스트레이션(Orchestration)이라고 한다. 도커스윔(Docker Swarm)등이 있는데 최근에서 구글이 자신들의 도커 컨테이너 관리 노하우를 공개한 쿠버네티스(Kubernetes)가 가장 인기이다. 왜냐면 쉽게 쿠버네티스로 사설 컨테이너 플랫폼 환경을 구축할 수 있기 때문이다.

아래 그림은 쿠버네티스를 설치 시 나타나는 메인 화면이다. 쿠버네티스와 AWS 같은 플랫폼 사업자가 제공하는 대부분의 PaaS UI가 대부분 유사한데 컨테이너에 올린 애플리케이션을 다음과 같이 실시간 모니터링할 수 있고 특정한 조건이 되면 예를 들어 CPU 사용량이 어느 수치 이상을 초과 한다 던지 또는 메모리 사용량이 지정 한도에 온 경우 인스턴스 수를 증가시키는 스케일 아웃 설정을 할 수 있다. 또한 쿠버네티스는 이후에 설명할 어플리케이션으로 구현 가능한 일부의 마이크로서비스 관리/운영 패턴들을 자체적으로 내장하고 있기도 한다. 이런 대중성과 인기로 최근에는 AWS, MS 애저, Pivotal, IBM등 컨테이너기반의 자체PaaS 서비스를 가지고 있는 사업자들도 별도의 쿠버네티스 기반의 컨테이너 서비스를 제공하고 있다.

[참고] IaaS, PaaS 와 CaaS 개념

• laaS(Infrastructure as a Service) : VM,스토리지,네트워크와 같은 인프라를 필요한 만큼 적시에 제공하는 서비스로 사용자는 이러한 인프라로 개발환경을 구성한 뒤에 어플리케이션을 배포한다.
  예)AWS EC2, GCP Compute Engine, Azure VM

• PaaS(Platform as a Service) : 복잡함 없이 어플리케이션을 바로 개발,실행,관리 할 수 있는 플랫폼 환경을 서비스 형태로 제공
  예)Google App Engine, Cloud Foundry, Heroku, AWS Elastic beanstalk

• CaaS(Container as a Service) : 컨테이너 기반 가상화를 사용하여 컨테이너를 업로드, 구성,실행, 확장,중지 할 수 있는 서비스.
  예) Microsoft의 Azure Kubernetes Service(AKS), Amazon EKS, Google Kubernetes Engine(GKE), AWS ECS

개발 지원 환경 : 데브옵스 인프라(DevOps Infra) 구성

다음은 마이크로서비스를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 개발지원환경인 DevOps 환경이다. DevOps는 서두에 언급한 것처럼 개발과 운영이 분리되지 않은 개발,운영을 병행 할 수 있는 조직, 그 문화를 말하기도 하는데 여기서는 그런 개발과 운영을 병행 가능하도록 빠르고 높은 품질로 소프트웨어를 개발 지원하는 빌드, 테스트, 배포를 위한 자동화 환경을 말한다.

그런 환경이 왜 필요한지 과거의 수동으로 빌드, 배포하는 과정을 아래 그림을 통해 살펴보겠다.

• 처음에 개발자는 개발환경에서 어플리케이션을 완성하고, 컴파일하고 수동으로 테스트 수행 후 발생된 오류를 수정한 뒤 스테이징 환경으로 배포한다.
• 개발자는 운영 환경에 배포하기 전에 스테이징 환경에서 다시 수동으로 테스트한다. 그러다 오류가 발생하면 첫 환경인 개발환경으로 돌아가 오류를 수정한 뒤 스테이징 환경에서 다시 테스트를 수행한다.
• 이러한 과정이 무사히 끝나면 배포 승인을 받고 승인 완료 후 배포 담당자가 일을 받아 운영 환경에 배포한다.

살펴 본 봐와 같이 정말 많은 시간을 소요한다. 또한 마지막에 배포를 처리하는 배포 담당자는 보통 시스템이 잘 사용이 안되는 야간에 일을 진행하는 경우가 많다. 당연히 이런 환경에서는 비즈니스 민첩성을 높을 수 없다. 그래서 이런 활동을 자동화할 필요가 있다. 특히 여러 개의 마이크로서비스를 배포해야 하는 환경에서는 배포가 잦을 수 밖에 없기 때문에 자동화가 절실하다.

CI/CD

자동화된 빌드, 배포 작업을 보통 CI/CD라고 하는데 여기서 CI는 지속적 통합(Continuous Integration)를 말한다. 원래 이 활동은 애자일 방법론 중 켄트 벡이 만든 XP의 주요 프랙티스로 시작했다. 오랜 시간 걸리는 빌드를 매일 자동화하여 수행한다면 개발 생산성이나 소스코드 품질이 높아진다는 경험에서 출발했다.

그럼 아래 그림을 통해 진행 과정을 살펴 보자

• 개발자들이 퇴근 시에 매일 자신이 작성한 소스 코드와 그것을 테스트한 테스트 코드를 형상 관리해 체크인(Check-in) 한다.
• 그럼 빌드 도구에서 매일 밤 형상 관리 서버의 코드를 가져와서(Check out) 통합한 다음에 자동으로 빌드하고 테스트 코드를 돌려 테스트를 수행한다.
• 그리고 그 결과를 리포트 문서로 남기고 빌드 된 소스를 실행 환경에 자동으로 배포한다.
• 그렇게 되면 다음날에 테스터가 실행 환경에서 테스트를 바로 수행할 수 있다. 또는 빌드 및 단위 테스트 결과를 개발자가 바로 확인하고 만약 문제가 있다면 즉시 소스 코드를 수정할 수 있다.
• 여기서 자동으로 통합, 테스트하고 그 결과를 리포트로 남기는 활동을 CI라고 하고 실행 환경에 자동으로 배포하는 것을 CD라고 한다.

CD에 대해 좀 더 살펴보면 CD 즉 지속적 배포는 Continuous Delivery와 Continuous Deployment의 앞 두 글자를 의미하는데 두 가지 의미를 모두 포함하고 있다. 그 차이점을 살펴보면 Continuous Delivery 즉 지속적 전달은 빌드 된 소스 코드의 실행 파일을 실행 환경 반영 전 단계까지 배포하는 방식이다. 실행 환경 반영을 위해서는 승인 및 배포 담당자의 허가를 받아야 배포할 수 있으며 배포도 수동으로 처리한다. 조금은 엄격한 배포 절차를 가지는 것이다. 또 Continuous Deployment는 소스 저장소에 빌드 된 소스 코드의 실행 파일을 실행 환경까지 자동으로 배포하는 방식이다. 이러한 방식은 모든 영역을 자동화 하는 것이다.

배포 파이프라인 설계

그럼 이런 CI/CD 과정을 어떻게 설계하는지 살펴보자. 보통 이런 절차를 배포 파이프라인이라고 한다. 배포파이프라인은 통합 및 배포까지 일련의 프로세스를 하나로 연계하여 자동화하고 시각화된 절차를 구축하는 것을 말한다. 이때 어떠한 단계들을 거칠지 어떠한 도구로 그 단계를 구성할지를 결정해야 한다.

아래 그림을 보면 전형적인 파이프라인 흐름도를 볼 수 있는데 빌드, 유닛 테스트, 정적 분석, 배포의 과정을 거치고 있다. 여기에 배포 전에 UI 테스트, 통합 테스트, 배포 승인 프로세스 등을 넣어서 재설계할 수도 있다. 그리고 이것을 구현하기 위해 어떠한 도구들을 활용할지 결정하고 그들과의 연계 정의를 해야 한다. 그런 과정을 배포 파이프라인 설계라고 한다.

클라우드 환경이 활성화 되기 이전에는 이런 과정에서 배포 환경이 베어 메탈 하드웨어인 경우가 있어 일부 과정에서 수동 처리가 존재했으나 최근 클라우드 같은 가상 환경이 대중화 되면서 완전히 자동화가 가능하게 되었다. 즉 인프라 구성을 마치 소프트웨어를 프로그래밍하는 것처럼 처리하고 소수의 인원으로 많은 컨테이너 배포 처리를 할 수 있게 되었는데 이를 Infrastructure as Code라 말하고 배포 파이프라인 절차를 완벽하게 자동화 해준다.

마이크로서비스의 배포파이프라인 설계 시 중요하게 고려해야 할 부분은 마이크로서비스의 경우 배포 파이프 라인도 마이크로서비스 별로 별도로 설계해야 지 독립적인 수정 및 배포가 가능하다는 점이다.