마이크로서비스 배포 전략 선택하기

NGINX | 2016년 2월 10일

편집자 – 총 7부로 구성된 이 연재 기사가 이제 완결되었습니다:

전체 기사 모음과 NGINX Plus를 사용한 마이크로서비스 구현 정보를 전자책으로 다운로드할 수도 있습니다. 전자책 제목은 마이크로서비스: 설계부터 배포까지입니다. 또한 마이크로서비스 참조 아키텍처 시리즈와 마이크로서비스 솔루션 페이지도 확인해 보세요.

이 글은 마이크로서비스를 활용한 애플리케이션 구축 시리즈의 여섯 번째 글입니다. 첫 번째 글에서는 마이크로서비스 아키텍처 패턴을 소개하고 마이크로서비스 사용의 장단점을 살펴봅니다. 이어지는 글에서는 마이크로서비스 아키텍처의 다양한 측면인 API 게이트웨이 사용, 프로세스 간 통신, 서비스 검색, 이벤트 기반 데이터 관리를 다룹니다. 이 글에서는 마이크로서비스 배포 전략을 살펴봅니다.

동기

Deploying a 모놀리식 애플리케이션을 배포한다는 것은 일반적으로 규모가 큰 단일 애플리케이션의 동일한 복사본 여러 개를 실행하는 것을 의미합니다. 일반적으로 N개의 서버(물리적 또는 가상)를 프로비저닝하고 각 서버에서 애플리케이션 인스턴스를 M개씩 실행합니다. 모놀리식 애플리케이션의 배포가 언제나 완전히 간단한 것은 아니지만, 마이크로서비스 애플리케이션을 배포하는 것보다는 훨씬 간단합니다.

A 마이크로서비스 애플리케이션은 수십 개에서 많게는 수백 개의 서비스로 구성됩니다. 서비스는 다양한 언어와 프레임워크로 작성됩니다. 각 서비스는 고유한 배포, 리소스, 확장 및 모니터링 요구 사항을 갖춘 소형 애플리케이션입니다. 예를 들어 각 서비스의 수요에 따라 일정한 수의 서비스 인스턴스를 실행해야 합니다. 또한 각 서비스 인스턴스에 적절한 CPU, 메모리 및 I/O 리소스를 제공해야 합니다. 더욱 어려운 점은 이러한 복잡성에도 불구하고 서비스를 빠르고 안정적이며 비용 효율적으로 배포해야 한다는 것입니다.

마이크로서비스 배포 패턴에는 몇 가지 유형이 있습니다. 먼저 호스트당 여러 서비스 인스턴스 패턴을 살펴보겠습니다.

호스트당 여러 서비스 인스턴스 패턴

마이크로서비스를 배포하는 한 가지 방법은 호스트당 여러 서비스 인스턴스 패턴을 사용하는 것입니다. 이 패턴을 사용하면 하나 이상의 물리적 또는 가상 호스트를 프로비저닝하고 각 호스트에서 여러 서비스 인스턴스를 실행합니다. 여러 면에서 이는 전통적인 애플리케이션 배포 방식입니다. 각 서비스 인스턴스는 하나 이상의 호스트에서 잘 알려진 포트를 통해 실행됩니다. 호스트 머신은 일반적으로 반려동물처럼 취급됩니다.

다음 다이어그램은 이 패턴의 구조를 보여 줍니다.

마이크로서비스 아키텍처 기반 애플리케이션을 배포하기 위한 호스트당 여러 서비스 인스턴스 패턴

이 패턴에는 몇 가지 변형이 있습니다. 그중 하나는 각 서비스 인스턴스를 프로세스 또는 프로세스 그룹으로 구성하는 것입니다. 예를 들어 Java 서비스 인스턴스를 Apache Tomcat 서버에 웹 애플리케이션으로 배포할 수 있습니다. Node.js 서비스 인스턴스는 부모 프로세스와 하나 이상의 자식 프로세스로 구성될 수 있습니다.

이 패턴의 또 다른 변형은 동일한 프로세스 또는 프로세스 그룹에서 여러 서비스 인스턴스를 실행하는 것입니다. 예를 들어, 동일한 Apache Tomcat 서버에 여러 Java 웹 애플리케이션을 배포하거나 동일한 OSGI 컨테이너에서 여러 OSGI 번들을 실행할 수 있습니다.

호스트당 여러 서비스 인스턴스 패턴에는 장점과 단점이 모두 있습니다. 주요 장점 중 하나는 리소스를 비교적 효율적으로 사용한다는 것입니다. 여러 서비스 인스턴스가 서버와 운영 체제를 공유합니다. 하나의 프로세스나 프로세스 그룹에서 여러 서비스 인스턴스를 실행하면 훨씬 더 효율적입니다. 예를 들어 여러 웹 애플리케이션이 동일한 Apache Tomcat 서버와 JVM을 공유할 수 있습니다.

이 패턴의 또 다른 장점은 서비스 인스턴스를 비교적 빠르게 배포할 수 있다는 것입니다. 서비스를 호스트에 복사한 후 시작하기만 하면 됩니다. 서비스가 Java로 작성되었다면 JAR 또는 WAR 파일을 복사합니다. Node.js나 Ruby 같은 다른 언어로 작성되었다면 소스 코드를 복사합니다. 어느 경우든 네트워크를 통해 복사되는 데이터의 양은 비교적 적습니다.

또한 오버헤드가 거의 없기 때문에 서비스는 대개 매우 빠르게 시작됩니다. 서비스가 독립된 프로세스로 실행되는 경우에는 해당 프로세스를 시작하기만 하면 됩니다. 그렇지 않고 서비스가 동일한 컨테이너 프로세스나 프로세스 그룹에서 실행되는 여러 인스턴스 중 하나라면, 컨테이너에 동적으로 배포하거나 컨테이너를 다시 시작하면 됩니다.

매력적인 패턴이기는 하지만, 호스트당 여러 서비스 인스턴스 패턴에는 몇 가지 중대한 단점이 있습니다. 주요 단점 중 하나는 각 서비스 인스턴스가 별도의 프로세스로 실행되지 않는 한 서비스 인스턴스 간 격리가 거의 또는 전혀 이루어지지 않는다는 점입니다. 각 서비스 인스턴스의 리소스 사용량을 정확하게 모니터링할 수는 있지만, 각 인스턴스가 사용하는 리소스를 제한할 수는 없습니다. 오작동하는 서비스 인스턴스가 호스트의 메모리나 CPU를 모두 소모할 수도 있습니다.

여러 서비스 인스턴스가 동일한 프로세스에서 실행되는 경우에는 격리가 전혀 이루어지지 않습니다. 예를 들어 모든 인스턴스가 동일한 JVM 힙을 공유할 수 있습니다. 오작동하는 서비스 인스턴스 하나가 동일한 프로세스에서 실행 중인 다른 서비스들을 쉽게 중단시킬 수 있습니다. 게다가 각 서비스 인스턴스가 사용하는 리소스를 모니터링할 방법도 없습니다.

이 접근 방식의 또 다른 중대한 문제는 서비스를 배포하는 운영팀이 구체적인 배포 방법을 알고 있어야 한다는 점입니다. 서비스는 다양한 언어와 프레임워크로 작성될 수 있으므로 개발팀이 운영팀과 공유해야 할 세부 사항이 많습니다. 이러한 복잡성은 배포 중 오류가 발생할 위험을 높입니다.

보시다시피 호스트당 여러 서비스 인스턴스 패턴은 익숙한 방식이지만 몇 가지 중대한 단점이 있습니다. 이제 이러한 문제를 피할 수 있는 다른 마이크로서비스 배포 방식을 살펴보겠습니다.

호스트당 서비스 인스턴스 패턴

마이크로서비스를 배포하는 또 다른 방법은 호스트당 서비스 인스턴스 패턴입니다. 이 패턴을 사용하면 각 서비스 인스턴스가 자체 호스트에서 격리된 상태로 실행됩니다. 이 패턴에는 가상 머신당 서비스 인스턴스와 컨테이너당 서비스 인스턴스라는 두 가지 유형이 있습니다.

가상 머신당 서비스 인스턴스 패턴

When you use 가상 머신당 서비스 인스턴스 패턴을 사용하면 각 서비스를 Amazon EC2 AMI와 같은 가상 머신(VM) 이미지로 패키징합니다. 각 서비스 인스턴스는 해당 VM 이미지를 사용하여 시작되는 VM(예: EC2 인스턴스)입니다. 다음 다이어그램은 이 패턴의 구조를 보여 줍니다.

이는 Netflix가 동영상 스트리밍 서비스를 배포할 때 사용하는 주요 방식입니다. Netflix는 Aminator를 사용하여 각 서비스를 EC2 AMI로 패키징합니다. 실행 중인 각 서비스 인스턴스는 EC2 인스턴스입니다.

자체 VM을 구축하는 데 사용할 수 있는 다양한 도구가 있습니다. 지속적 통합(CI) 서버(예: Jenkins)에서 Aminator를 호출하여 서비스를 EC2 AMI로 패키징하도록 구성할 수 있습니다. Packer.io는 VM 이미지 생성을 자동화할 수 있는 또 다른 도구입니다. Aminator와 달리 EC2, DigitalOcean, VirtualBox, VMware를 비롯한 다양한 가상화 기술을 지원합니다.

The company Boxfuse는 아래에서 설명할 VM의 단점을 극복하는 매력적인 VM 이미지 빌드 방식을 제공합니다. Boxfuse는 Java 애플리케이션을 최소한의 VM 이미지로 패키징합니다. 이러한 이미지는 빌드 속도가 빠르고 신속하게 부팅되며, 공격 표면이 제한적이어서 보안도 더 뛰어납니다.

The company CloudNative는 EC2 AMI를 생성하는 SaaS 서비스인 Bakery를 제공합니다. 마이크로서비스 테스트가 통과하면 Bakery를 호출하도록 CI 서버를 구성할 수 있습니다. 그러면 Bakery가 서비스를 AMI로 패키징합니다. Bakery와 같은 SaaS 서비스를 사용하면 AMI 생성 인프라를 구축하는 데 귀중한 시간을 낭비하지 않아도 됩니다.

가상 머신당 서비스 인스턴스 패턴에는 여러 가지 장점이 있습니다. VM의 주요 장점은 각 서비스 인스턴스가 완전히 격리된 상태로 실행된다는 것입니다. 각 인스턴스에는 일정량의 CPU와 메모리가 할당되며, 다른 서비스의 리소스를 빼앗아 사용할 수 없습니다.

마이크로서비스를 VM으로 배포할 때의 또 다른 이점은 성숙한 클라우드 인프라를 활용할 수 있다는 것입니다. AWS와 같은 클라우드는 부하 분산 및 자동 확장과 같은 유용한 기능을 제공합니다.

서비스를 VM으로 배포할 때 얻을 수 있는 또 다른 큰 이점은 서비스의 구현 기술을 캡슐화할 수 있다는 것입니다. 서비스를 VM으로 패키징하면 블랙박스가 됩니다. VM의 관리 API가 서비스 배포를 위한 API 역할을 하게 됩니다. 따라서 배포가 훨씬 더 간단하고 안정적으로 이루어집니다.

하지만 가상 머신당 서비스 인스턴스 패턴에는 몇 가지 단점이 있습니다. 그중 하나는 리소스 활용 효율이 떨어진다는 점입니다. 각 서비스 인스턴스에는 운영 체제를 포함한 전체 VM의 오버헤드가 발생합니다. 또한 일반적인 퍼블릭 IaaS에서는 VM 크기가 고정되어 있어 VM이 충분히 활용되지 않을 수 있습니다.

게다가 퍼블릭 IaaS는 일반적으로 VM의 사용 여부와 관계없이 요금을 부과합니다. AWS와 같은 IaaS는 자동 확장 기능을 제공하지만, 수요 변화에 신속하게 대응하기는 어렵습니다. 따라서 VM을 필요 이상으로 프로비저닝해야 하는 경우가 많아 배포 비용이 증가합니다.

이 접근 방식의 또 다른 단점은 일반적으로 서비스의 새 버전을 배포하는 데 시간이 오래 걸린다는 것입니다. VM 이미지는 크기가 크기 때문에 빌드하는 데 대체로 오랜 시간이 걸립니다. 또한 VM 역시 크기 때문에 인스턴스를 생성하는 데 시간이 오래 걸리는 편입니다. 운영 체제를 시작하는 데도 일반적으로 어느 정도 시간이 걸립니다. 다만 Boxfuse로 빌드한 것과 같은 경량 VM도 있으므로, 모든 경우에 해당하는 것은 아닙니다.

가상 머신당 서비스 인스턴스 패턴의 또 다른 단점은 대개 여러분(또는 조직 내 다른 누군가)이 차별화되지 않는 수많은 고된 작업을 책임져야 한다는 점입니다. VM 구축 및 관리에 따르는 부수 작업을 처리해 주는 Boxfuse 같은 도구를 사용하지 않는다면, 이러한 작업은 여러분의 몫이 됩니다. 꼭 필요하지만 시간이 많이 드는 이 작업은 핵심 비즈니스에 집중하지 못하게 합니다.

이제 VM의 여러 장점을 그대로 누리면서도 더 가볍게 마이크로서비스를 배포할 수 있는 대안을 살펴보겠습니다.

컨테이너별 서비스 인스턴스 패턴

When you use the 컨테이너별 서비스 인스턴스 패턴을 사용하면 각 서비스 인스턴스가 자체 컨테이너에서 실행됩니다. 컨테이너는 운영 체제 수준의 가상화 메커니즘입니다. 컨테이너는 샌드박스에서 실행되는 하나 이상의 프로세스로 구성됩니다. 프로세스 관점에서 보면 자체 포트 네임스페이스와 루트 파일 시스템을 갖습니다. 컨테이너의 메모리 및 CPU 리소스를 제한할 수 있습니다. 일부 컨테이너 구현은 I/O 속도 제한도 지원합니다. 컨테이너 기술의 예로는 Docker와 Solaris Zones가 있습니다.

다음 다이어그램은 이 패턴의 구조를 보여 줍니다:

마이크로서비스 아키텍처 기반 애플리케이션을 배포하기 위한 컨테이너당 서비스 인스턴스 패턴

이 패턴을 사용하려면 서비스를 컨테이너 이미지로 패키징합니다. 컨테이너 이미지는 서비스를 실행하는 데 필요한 애플리케이션과 라이브러리로 구성된 파일 시스템 이미지입니다. 일부 컨테이너 이미지는 완전한 Linux 루트 파일 시스템으로 구성되지만, 더 경량화된 이미지도 있습니다. 예를 들어 Java 서비스를 배포하려면 Java 런타임과 Apache Tomcat 서버(선택 사항), 그리고 컴파일된 Java 애플리케이션이 포함된 컨테이너 이미지를 빌드합니다.

서비스를 컨테이너 이미지로 패키징한 후에는 하나 이상의 컨테이너를 실행합니다. 일반적으로 각 물리적 또는 가상 호스트에서 여러 컨테이너를 실행합니다. 컨테이너를 관리하기 위해 Kubernetes 또는 Marathon과 같은 클러스터 관리자를 사용할 수 있습니다. 클러스터 관리자는 호스트를 하나의 리소스 풀로 취급합니다. 각 컨테이너에 필요한 리소스와 각 호스트에서 사용 가능한 리소스를 기준으로 컨테이너를 배치할 위치를 결정합니다.

컨테이너당 서비스 인스턴스 패턴에는 장점과 단점이 모두 있습니다. 컨테이너의 장점은 VM의 장점과 유사합니다. 컨테이너는 서비스 인스턴스를 서로 격리합니다. 각 컨테이너가 소비하는 리소스를 쉽게 모니터링할 수 있습니다. 또한 컨테이너는 VM과 마찬가지로 서비스를 구현하는 데 사용되는 기술을 캡슐화합니다. 컨테이너 관리 API는 서비스를 관리하기 위한 API 역할도 합니다.

하지만 VM과 달리 컨테이너는 경량 기술입니다. 일반적으로 컨테이너 이미지는 매우 빠르게 빌드할 수 있습니다. 예를 들어 제 노트북에서는 Spring Boot 애플리케이션을 Docker 컨테이너로 패키징하는 데 불과 5초밖에 걸리지 않습니다. 또한 컨테이너는 긴 OS 부팅 과정이 없기 때문에 매우 빠르게 시작됩니다. 컨테이너가 시작되면 서비스가 실행됩니다.

컨테이너를 사용하는 데에는 몇 가지 단점이 있습니다. 컨테이너 인프라는 빠르게 성숙하고 있지만, VM용 인프라만큼 성숙하지는 않았습니다. 또한 컨테이너는 서로 호스트 OS의 커널을 공유하므로 VM만큼 안전하지 않습니다.

컨테이너의 또 다른 단점은 컨테이너 이미지를 관리하는 데 따르는 번거롭고 부가가치가 낮은 작업을 직접 책임져야 한다는 것입니다. 또한 Google Container Engine 또는 Amazon EC2 Container Service(ECS)와 같은 호스팅형 컨테이너 솔루션을 사용하지 않는다면 컨테이너 인프라뿐만 아니라 해당 인프라가 실행되는 VM 인프라까지 관리해야 할 수 있습니다.

또한 컨테이너는 VM별로 요금이 부과되는 인프라에 배포되는 경우가 많습니다. 따라서 앞서 설명했듯이 부하 급증에 대응하기 위해 VM을 필요 이상으로 프로비저닝하는 데 따른 추가 비용이 발생할 가능성이 높습니다.

흥미롭게도 컨테이너와 VM의 경계는 점차 모호해질 것으로 보입니다. 앞서 언급했듯이 Boxfuse VM은 빌드와 시작이 빠릅니다. Clear Containers 프로젝트는 경량 VM을 만드는 것을 목표로 합니다. [편집자 주 – 2017년 12월에 발표된 바와 같이, Clear Containers 개발은 현재 오픈 소스 Kata Containers 프로젝트에서 계속되고 있습니다.] 또한 유니커널에 대한 관심도 높아지고 있습니다. Docker, Inc.는 최근 Unikernel Systems를 인수했습니다.

또한 최근 등장해 점점 인기를 얻고 있는 서버리스 배포라는 개념도 있습니다. 이는 서비스를 컨테이너에 배포할지 VM에 배포할지 선택해야 하는 문제를 우회하는 접근 방식입니다. 다음으로 이에 대해 살펴보겠습니다.

서버리스 배포

AWS Lambda는 서버리스 배포 기술의 한 예입니다. Java, Node.js 및 Python 서비스를 지원합니다. 마이크로서비스를 배포하려면 ZIP 파일로 패키징하여 AWS Lambda에 업로드합니다. 또한 요청(이벤트라고도 함)을 처리하기 위해 호출되는 함수의 이름 등을 지정하는 메타데이터도 제공합니다. AWS Lambda는 요청을 처리하는 데 필요한 만큼 마이크로서비스 인스턴스를 자동으로 실행합니다. 각 요청에 소요된 시간과 사용된 메모리를 기준으로 요금이 청구됩니다. 물론 세부 사항을 살펴보면 복잡한 부분이 있으며, 곧 AWS Lambda에도 한계가 있다는 것을 알게 될 것입니다. 하지만 개발자인 여러분은 물론 조직 내 누구도 서버, 가상 머신 또는 컨테이너의 어떤 측면도 신경 쓸 필요가 없다는 개념은 매우 매력적입니다.

A Lambda 함수는 상태 비저장 서비스입니다. 일반적으로 AWS 서비스를 호출하여 요청을 처리합니다. 예를 들어 이미지가 S3 버킷에 업로드될 때 호출되는 Lambda 함수는 DynamoDB 이미지 테이블에 항목을 삽입하고 Kinesis 스트림에 메시지를 게시하여 이미지 처리를 트리거할 수 있습니다. Lambda 함수는 타사 웹 서비스도 호출할 수 있습니다.

Lambda 함수를 호출하는 방법에는 네 가지가 있습니다:

웹 서비스 요청을 사용하여 직접 호출
S3, DynamoDB, Kinesis 또는 Simple Email Service와 같은 AWS 서비스에서 생성된 이벤트에 대한 응답으로 자동 실행
AWS API Gateway를 통해 애플리케이션 클라이언트의 HTTP 요청을 자동으로 처리
주기적으로, cron과 유사한 일정에 따라

보시다시피 AWS Lambda는 마이크로서비스를 배포하는 편리한 방법입니다. 요청 기반 요금제이므로 서비스가 실제로 수행한 작업에 대해서만 비용을 지불하면 됩니다. 또한 IT 인프라를 직접 관리할 필요가 없어 애플리케이션 개발에 집중할 수 있습니다.

하지만 몇 가지 중요한 제약 사항이 있습니다. 타사 메시지 브로커의 메시지를 소비하는 서비스와 같이 장시간 실행되는 서비스를 배포하는 용도로는 적합하지 않습니다. 요청은 300초 이내에 완료되어야 합니다. 이론적으로 AWS Lambda가 요청마다 별도의 인스턴스를 실행할 수 있으므로 서비스는 상태 비저장 방식이어야 합니다. 또한 지원되는 언어 중 하나로 작성해야 합니다. 서비스는 빠르게 시작되어야 하며, 그렇지 않으면 시간 초과로 종료될 수 있습니다.

요약

마이크로서비스 애플리케이션을 배포하는 일은 쉽지 않습니다. 다양한 언어와 프레임워크로 작성된 서비스가 수십 개, 심지어 수백 개에 달하기 때문입니다. 각 서비스는 배포, 리소스, 확장, 모니터링에 관한 고유한 요구 사항을 지닌 하나의 미니 애플리케이션입니다. 마이크로서비스 배포 패턴에는 가상 머신당 서비스 인스턴스와 컨테이너당 서비스 인스턴스 등 여러 가지가 있습니다. 서버리스 방식인 AWS Lambda도 마이크로서비스를 배포할 수 있는 또 하나의 흥미로운 선택지입니다. 이 시리즈의 다음이자 마지막 편에서는 모놀리식 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션하는 방법을 살펴보겠습니다.

편집자 – 총 7부로 구성된 이 연재 기사가 이제 완결되었습니다:

전체 기사와 NGINX Plus를 사용한 마이크로서비스 구현 정보를 담은 전자책도 다운로드할 수 있습니다. 전자책 제목은 마이크로서비스: 설계부터 배포까지입니다. 또한 마이크로서비스 참조 아키텍처 시리즈와 마이크로서비스 솔루션 페이지도 확인해 보세요.

게스트 블로거 Chris Richardson은 최초의 CloudFoundry.com을 설립했습니다. CloudFoundry.com은 Amazon EC2용 초기 Java PaaS(서비스형 플랫폼)입니다. 현재 그는 여러 조직을 대상으로 애플리케이션 개발 및 배포 방식을 개선할 수 있도록 컨설팅하고 있습니다. 또한 https://microservices.io에서 마이크로서비스에 관한 글을 정기적으로 게시합니다.