마이크로서비스 배포를 위한 5가지 옵션

마이크로서비스는 가장 확장 가능한 소프트웨어 개발 방법입니다. 그러나 마이크로서비스를 배포하는 올바른 방법(프로세스 또는 컨테이너)을 선택하지 않는 한 이는 아무 의미가 없습니다. 내 서버에서 실행하거나 클라우드를 사용하시겠습니까? Kubernetes가 필요한가요? 마이크로서비스 아키텍처에 관해서는 옵션이 너무 많아서 어떤 것이 가장 좋은지 알기가 어렵습니다.

앞으로 살펴보겠지만 마이크로서비스 애플리케이션을 호스팅하기 위한 완벽한 장소는 주로 크기와 확장 요구 사항에 따라 결정됩니다. 이제 마이크로서비스를 배포할 수 있는 5가지 주요 방법을 살펴보겠습니다.

마이크로서비스 애플리케이션은 각기 다른 장단점과 비용 구조를 가진 다양한 방식으로 실행될 수 있습니다. 몇 가지 서비스에 걸친 소규모 응용 프로그램에 작동하는 것이 대규모 시스템에는 충분하지 않을 수 있습니다.

간단한 것부터 복잡한 것까지 마이크로서비스를 실행하는 5가지 방법은 다음과 같습니다.

단일 머신, 다중 프로세스 : 서버를 구입하거나 임대하고 마이크로서비스를 프로세스로 실행합니다.
다중 시스템, 다중 프로세스 : 분명한 다음 단계는 더 많은 서버를 추가하고 로드를 분산하여 더 많은 확장성과 가용성을 제공하는 것입니다.
컨테이너 : 컨테이너 내부에 마이크로서비스를 패키징하면 다른 서비스와 함께 배포하고 실행하기가 더 쉬워집니다. 쿠버네티스를 향한 첫걸음이기도 하다.
오케스트레이터 : Kubernetes 또는 Nomad와 같은 오케스트레이터는 수천 개의 컨테이너를 동시에 실행하도록 설계된 완전한 플랫폼입니다.
서버리스 : 서버리스를 사용하면 프로세스, 컨테이너 및 서버를 잊고 클라우드에서 직접 코드를 실행할 수 있습니다.

마이크로서비스를 실행하는 다양한 방법.

두 가지 경로가 있습니다. 하나는 프로세스에서 컨테이너로, 궁극적으로 Kubernetes로 이동합니다. 다른 하나는 서버리스 경로로 이동합니다.

각각 자세히 살펴보겠습니다.

옵션 1: 단일 시스템, 다중 프로세스

가장 기본적인 수준에서 마이크로서비스 애플리케이션을 단일 시스템에서 여러 프로세스로 실행할 수 있습니다. 각 서비스는 서로 다른 포트를 수신하고 루프백 인터페이스를 통해 통신합니다.

여러 프로세스가 있는 하나의 시스템. 마이크로서비스를 실행하는 한 가지 방법.

가장 기본적인 형태의 마이크로서비스 배포는 단일 시스템을 사용합니다. 애플리케이션은 로드 밸런싱과 결합된 프로세스 그룹입니다.

이 간단한 접근 방식에는 몇 가지 분명한 이점이 있습니다.

Lightweight : 서버에서 실행되는 프로세스이므로 오버헤드가 없습니다.
편의성 : 다른 도구가 가지고 있는 학습 곡선 없이 마이크로서비스를 경험할 수 있는 좋은 방법입니다.
손쉬운 문제 해결 : 모든 것이 같은 위치에 있으므로 문제를 찾거나 문제가 발생한 경우 작업 구성으로 되돌리는 것은 지속적 전달 이 있는 경우 매우 간단 합니다.
고정 청구 : 매월 지불해야 하는 금액을 알고 있습니다.

DIY 접근 방식은 마이크로 서비스가 몇 개 없는 소규모 애플리케이션에 가장 적합합니다. 그 이상은 다음과 같은 이유로 부족합니다.

확장성 없음 : 일단 서버의 리소스를 최대한 활용하면 됩니다.
단일 실패 지점 : 서버가 다운되면 애플리케이션도 함께 다운됩니다.
취약한 배포 : 서비스가 올바르게 설치되고 실행되도록 하려면 사용자 지정 배포 및 모니터링 스크립트가 필요합니다.
리소스 제한 없음 : 모든 마이크로서비스 프로세스는 CPU 또는 메모리를 얼마든지 소비할 수 있으므로 잠재적으로 다른 서비스가 부족하고 애플리케이션이 저하된 상태로 남을 수 있습니다.

이 옵션에 대한 CI( 지속적인 통합 )는 CI 파이프라인 에서 아티팩트를 빌드 및 테스트 한 다음 지속적인 배포로 배포 하는 동일한 패턴을 따릅니다 .

CI/CD 프로세스는 바이너리를 빌드하고 사용자 지정 스크립트를 사용하여 마이크로서비스를 배포합니다.

CI 파이프라인에 빌드된 실행 파일을 배포하려면 사용자 지정 스크립트가 필요합니다.

이것은 마이크로서비스의 기초를 배우기에 가장 좋은 선택입니다. 소규모 마이크로서비스 애플리케이션을 실행하여 익숙해질 수 있습니다. 확장이 필요할 때까지 단일 서버를 사용하면 다음 옵션으로 업그레이드할 수 있습니다.

옵션 2: 여러 기계 및 프로세스

이 옵션은 본질적으로 옵션 1의 업그레이드입니다. 응용 프로그램이 서버의 용량을 초과하면 확장(서버 업그레이드)하거나 측면 확장(서버 추가)할 수 있습니다. 마이크로서비스의 경우 2개 이상의 머신으로 수평 확장하는 것이 보너스로 향상된 가용성을 얻을 수 있기 때문에 더 합리적입니다. 그리고 분산 설정이 있으면 서버를 업그레이드하여 언제든지 확장할 수 있습니다.

마이크로서비스의 로드를 공유하는 두 대의 머신.

로드 밸런서는 여전히 단일 실패 지점입니다. 이를 방지하기 위해 여러 밸런서를 병렬로 실행할 수 있습니다.

그러나 수평 확장에도 문제가 없는 것은 아닙니다. 하나의 시스템을 지나치면 문제 해결을 훨씬 더 복잡하게 만드는 몇 가지 중요한 사항이 제기되며 마이크로 서비스 아키텍처를 사용할 때 발생하는 일반적인 문제가 나타납니다.

여러 서버에 분산된 로그 파일을 어떻게 연결합니까?
합리적인 메트릭을 어떻게 수집합니까?
업그레이드 및 중단 시간을 어떻게 처리합니까?
트래픽 급증 및 감소를 어떻게 처리합니까?

이것들은 모두 분산 컴퓨팅에 내재된 문제이며, 둘 이상의 시스템이 관련되는 즉시 경험하게 될(그리고 처리해야 하는) 문제입니다.

이 옵션은 여분의 컴퓨터가 몇 개 있고 응용 프로그램의 가용성을 향상시키려는 경우에 적합합니다. 다소 균일한 서비스(동일한 언어, 유사한 프레임워크)를 사용하여 일을 단순하게 유지하는 한 괜찮을 것입니다. 특정 복잡성 임계값을 통과하면 더 많은 유연성을 제공하기 위해 컨테이너가 필요합니다.

옵션 3: 컨테이너로 마이크로서비스 배포

마이크로서비스를 프로세스로 직접 실행하는 것은 매우 효율적이지만 비용이 듭니다.

서버는 필요한 종속성 및 도구를 사용하여 세심하게 유지 관리되어야 합니다.
런어웨이 프로세스는 모든 메모리 또는 CPU를 소모할 수 있습니다.
마이크로서비스 배포 및 모니터링은 불안정한 프로세스입니다.

이러한 모든 단점은 컨테이너로 완화할 수 있습니다. 컨테이너는 프로그램을 실행하는 데 필요한 모든 것을 포함하는 패키지입니다. 컨테이너 이미지는 종속성이나 도구를 먼저 설치하지 않고도(컨테이너 런타임 자체 제외) 모든 서버에서 실행할 수 있는 독립형 단위입니다.

컨테이너는 소프트웨어를 독립적으로 실행하기에 충분한 가상화를 제공합니다. 이를 통해 다음과 같은 이점을 얻을 수 있습니다.

격리 : 포함된 프로세스가 서로 격리되고 OS가 격리됩니다. 각 컨테이너에는 개인 파일 시스템이 있으므로 종속성 충돌은 불가능합니다(볼륨을 남용하지 않는 한).
동시성 : 충돌 없이 동일한 컨테이너 이미지의 여러 인스턴스를 실행할 수 있습니다.
오버헤드 감소: 전체 OS를 부팅할 필요가 없기 때문에 컨테이너는 VM보다 훨씬 가볍습니다.
무설치 배포 : 컨테이너 설치는 이미지를 다운로드하고 실행하기만 하면 됩니다. 설치 단계가 필요하지 않습니다.
리소스 제어 : 서버를 불안정하게 만들지 않도록 컨테이너에 CPU 및 메모리 제한을 둘 수 있습니다.

마이크로서비스를 실행하기 전에 컨테이너 이미지를 빌드하고 레지스트리에 푸시해야 합니다.

컨테이너화된 워크로드에는 CI/CD의 이미지 빌드 단계가 필요합니다.

컨테이너에 대해 자세히 알아보려면 다음 게시물을 확인하세요.

서버에서 직접 또는 관리 서비스를 통해 두 가지 방법으로 컨테이너를 실행할 수 있습니다.

서버의 컨테이너

이 접근 방식은 더 큰 유연성과 제어를 제공하므로 프로세스를 컨테이너로 대체합니다. 옵션 2와 마찬가지로 여러 머신에 부하를 분산할 수 있습니다.

VM에서 컨테이너화된 워크로드를 실행합니다.

마이크로서비스 프로세스를 컨테이너에 래핑하면 더욱 휴대 가능하고 유연해집니다.

서버리스 컨테이너

지금까지 설명한 모든 옵션은 서버를 기반으로 했습니다. 그러나 소프트웨어 회사는 구성, 패치 및 업그레이드가 필요한 서버를 관리하는 사업이 아니라 코드로 문제를 해결하는 사업을 하고 있습니다. 따라서 많은 회사가 가능할 때마다 서버를 피하는 것을 선호하는 것은 놀라운 일이 아닙니다.

AWS Fargate 및 Heroku 와 같은 Containers-as-a-Service 제품을 사용하면 서버를 다루지 않고도 컨테이너화된 애플리케이션을 실행할 수 있습니다. 우리는 컨테이너 이미지를 구축하고 이를 클라우드 공급자에게 지정하기만 하면 됩니다. 가상 머신을 프로비저닝하고 이미지를 다운로드, 시작 및 모니터링하는 나머지 작업은 클라우드 공급자가 처리합니다. 이러한 관리형 서비스에는 일반적으로 걱정할 필요가 없는 기본 제공 로드 밸런서가 포함됩니다.

Fargate와 함께 Elastic Container Service에서 실행되는 컨테이너.

Fargate를 사용한 ECS(Elastic Container Service)를 사용하면 서버를 임대하지 않고도 컨테이너를 실행할 수 있습니다. 클라우드 공급자가 유지 관리합니다.

관리형 컨테이너 서비스의 이점은 다음과 같습니다.

서버 없음 : 서버를 유지 관리하거나 패치할 필요가 없습니다.
손쉬운 배포 : 컨테이너 이미지를 빌드하고 서비스에 사용하도록 지시하기만 하면 됩니다.
자동 크기 조정: 클라우드 공급자는 수요가 급증할 때 더 많은 용량을 제공하거나 트래픽이 없을 때 모든 컨테이너를 중지할 수 있습니다.

그러나 시작하기 전에 다음과 같은 몇 가지 중요한 단점을 알고 있어야 합니다.

공급업체 고정 : 이것이 큰 문제입니다. 클라우드 공급업체가 대부분의 인프라를 제공하고 제어하기 때문에 관리형 서비스에서 벗어나는 것은 항상 어려운 일입니다.
제한된 리소스 : 관리형 서비스는 피할 수 없는 CPU 및 메모리 제한을 부과합니다.
적은 제어 : 다른 옵션과 동일한 수준의 제어가 없습니다. 관리 서비스에서 제공하지 않는 기능이 필요한 경우 운이 없는 것입니다.

컨테이너 옵션은 중소 규모의 마이크로서비스 애플리케이션에 적합합니다. 공급업체에 익숙하다면 관리형 컨테이너 서비스가 더 쉽습니다. 많은 세부 정보를 처리하기 때문입니다.

대규모 배포의 경우 말할 필요도 없이 두 옵션 모두 부족합니다. 특정 규모에 도달하면 컨테이너 관리 방식을 완전히 바꾸는 Kubernetes와 같은 도구에 대한 경험이 있는(또는 배우려는 의지가 있는) 팀원이 있을 가능성이 더 큽니다.

옵션 4: 오케스트레이터

오케스트레이터는 서버 그룹에 컨테이너 워크로드를 분산하는 데 특화된 플랫폼입니다. 가장 잘 알려진 오케스트레이터는 Cloud Native Computing Foundation 에서 유지 관리하는 Google에서 만든 오픈 소스 프로젝트인 Kubernetes 입니다.

오케스트레이터는 컨테이너 관리 외에도 라우팅, 보안, 로드 밸런싱, 중앙 집중식 로그와 같은 광범위한 네트워크 기능, 즉 마이크로서비스 애플리케이션을 실행하는 데 필요할 수 있는 모든 것을 제공합니다.

Kubernetes에서 실행되는 마이크로서비스.

Kubernetes는 Pod를 예약 단위로 사용합니다. 포드는 네트워크 주소를 공유하는 하나 이상의 컨테이너 그룹입니다.

Kubernetes를 사용하면 맞춤형 배포 스크립트에서 벗어날 수 있습니다. 대신 매니페스트를 사용하여 원하는 상태를 코드화하고 클러스터가 나머지를 처리하도록 합니다.

Kubernetes 클러스터에 배포합니다.

지속적 배포 파이프라인은 매니페스트를 클러스터로 보내 클러스터에서 클러스터를 채우는 데 필요한 단계를 수행합니다.

Kubernetes는 모든 클라우드 공급자가 지원하며 마이크로서비스 배포를 위한 사실상 의 플랫폼입니다. 따라서 이것이 마이크로서비스를 실행하는 가장 좋은 방법이라고 생각할 수 있습니다. 많은 회사에서 이것은 사실이지만 명심해야 할 몇 가지 사항도 있습니다.

복잡성 : 오케스트레이터는 가파른 학습 곡선으로 유명합니다. 조심하지 않으면 발에 총을 쏘는 것은 드문 일이 아닙니다. 간단한 애플리케이션의 경우 오케스트레이터는 과잉입니다.
관리 부담 : Kubernetes 설치를 유지 관리하려면 상당한 전문 지식이 필요합니다. 다행스럽게도 모든 괜찮은 클라우드 공급업체는 모든 관리 작업을 제거하는 관리형 클러스터를 제공합니다.
기술: Kubernetes 개발에는 전문 기술이 필요합니다. 움직이는 모든 부분을 이해 하고 실패한 배포 문제를 해결하는 방법을 배우는 데 몇 주가 걸릴 수 있습니다 . 팀이 도구에 익숙해질 때까지 Kubernetes로 전환하는 속도가 느려지고 생산성이 저하될 수 있습니다.

다음 자습서에서 Kubernetes를 사용하여 애플리케이션 배포를 확인하세요.

Kubernetes는 컨테이너를 많이 사용하는 회사 에서 가장 인기 있는 옵션 입니다. 그것이 당신이라면 오케스트레이터를 선택하는 것이 앞으로 나아갈 수 있는 유일한 방법일 수 있습니다. 그러나 이동하기 전에 최근 설문 조사에 따르면 Kubernetes로 마이그레이션할 때 대부분의 회사에서 가장 큰 문제 는 숙련된 엔지니어를 찾는 것 입니다. 따라서 숙련된 개발자를 찾는 것이 걱정된다면 다음 옵션이 최선의 선택일 수 있습니다.

옵션 5: 마이크로서비스를 서버리스 기능으로 배포

서버리스 기능은 지금까지 논의한 다른 모든 것과 다릅니다. 서버, 프로세스 또는 컨테이너 대신 클라우드를 사용하여 주문형 코드를 실행합니다. AWS Lambda 및 Google Cloud Functions 와 같은 서버리스 제품 은 확장 가능하고 가용성이 높은 서비스에 필요한 모든 인프라 세부 정보를 처리하므로 코딩에 집중할 수 있습니다.

서버리스는 클라우드에서 직접 기능을 실행합니다.

서버리스 기능은 자동으로 확장되며 사용량에 따라 요금이 청구됩니다.

장단점이 다른 완전히 다른 패러다임입니다. 장점은 다음과 같습니다.

사용 용이성 : 컨테이너 이미지를 컴파일하거나 구축하지 않고 즉석에서 기능을 배포할 수 있으므로 시도하고 프로토타이핑하는 데 좋습니다.
손쉬운 확장성: (기본적으로) 무한한 확장성을 얻을 수 있습니다. 클라우드는 수요에 맞는 충분한 리소스를 제공합니다.
사용량에 따라 지불 : 사용량에 따라 지불합니다. 수요가 없으면 요금도 없습니다.

그럼에도 불구하고 서버리스가 일부 유형의 마이크로서비스에 부적합하게 만드는 단점이 상당할 수 있습니다.

공급업체 고정 : 관리형 컨테이너와 마찬가지로 공급자의 에코시스템을 구매합니다. 공급업체에서 마이그레이션하는 것은 까다로울 수 있습니다.
콜드 스타트 : 자주 사용하지 않는 기능은 시작하는 데 시간이 오래 걸릴 수 있습니다. 이는 클라우드 공급자가 사용하지 않는 기능에 연결된 리소스를 스핀다운하기 때문에 발생합니다.
제한된 자원 : 각 기능에는 메모리와 시간 제한이 있으며 장기 실행 프로세스가 될 수 없습니다.
제한된 런타임 : 소수의 언어와 프레임워크만 지원됩니다. 익숙하지 않은 언어를 사용해야 할 수도 있습니다.

Imprevisible bills : 비용은 사용량 기반이기 때문에 월말 인보이스 크기를 예측하기 어렵습니다. 사용량 급증은 뜻밖의 결과를 초래할 수 있습니다.

아래에서 서버리스에 대해 자세히 알아보십시오.

서버리스는 확장성을 위한 자동 솔루션을 제공합니다. Kubernetes와 비교할 때 많은 제어 기능을 제공하지는 않지만 서버리스에 대한 전문 기술이 필요하지 않기 때문에 작업하기가 더 쉽습니다. 서버리스는 단점과 한계를 감수할 수 있다면 빠르게 성장하는 소기업에게 훌륭한 옵션입니다.

결론

마이크로서비스 애플리케이션을 실행하는 가장 좋은 방법은 여러 요인에 의해 결정됩니다. 컨테이너(또는 프로세스)를 사용하는 단일 서버는 프로토타입을 실험하거나 테스트하기 위한 환상적인 출발점입니다.

애플리케이션이 성숙하고 많은 서비스에 걸쳐 있는 경우 관리 컨테이너 또는 서버리스와 같은 보다 강력한 것이 필요하며 나중에 애플리케이션이 성장함에 따라 Kubernetes가 필요할 수 있습니다.

다른 옵션을 혼합하고 일치시키는 것을 방해하는 것은 없습니다. 실제로 대부분의 회사 는 베어 메탈 서버, VM 및 Kubernetes를 혼합하여 사용합니다 . Kubernetes에서 핵심 서비스 실행, VM에서 몇 가지 레거시 서비스 실행, 몇 가지 전략적 기능을 위해 서버리스 예약과 같은 솔루션의 조합은 매번 클라우드를 활용하는 가장 좋은 방법이 될 수 있습니다.

출처 : https://semaphoreci.com/blog/deploy-microservices