마이크로서비스 소개

현재 Microservices March 2023에 대한 등록이 시작되었습니다. 일정을 확인하고 여기에서 등록하세요 .

편집자 – 이 7부작 시리즈 기사는 이제 완료되었습니다.

1. 마이크로서비스 소개(이 문서)
2. 마이크로서비스 구축: API 게이트웨이 사용
3. 마이크로서비스 구축: 마이크로서비스 아키텍처에서의 프로세스 간 통신
4. 마이크로서비스 아키텍처에서의 서비스 발견
5. 마이크로서비스를 위한 이벤트 기반 데이터 관리
6. 마이크로서비스 배포 전략 선택
7. 모놀리스를 마이크로서비스로 리팩토링

NGINX Plus를 사용하여 마이크로서비스를 구현하는 것에 대한 정보와 더불어 전체 문서 세트를 전자책으로 다운로드할 수도 있습니다. – 마이크로서비스: 설계부터 배포까지 .

또한 마이크로서비스 솔루션 페이지도 확인해 보세요.

마이크로서비스는 현재 기사, 블로그, 소셜 미디어에서의 토론, 컨퍼런스 프레젠테이션 등에서 많은 주목을 받고 있습니다. 그들은 가트너 하이프 사이클 에 따르면 급속히 과장된 기대의 정점을 향해 나아가고 있습니다. 동시에 소프트웨어 커뮤니티 내에서는 마이크로서비스를 전혀 새로운 것이 아니라고 폄하하는 회의론자들도 있습니다. 반대자들은 이 아이디어가 단지 SOA를 재브랜딩한 것에 불과하다고 주장한다. 하지만 과대광고와 회의론에도 불구하고 마이크로서비스 아키텍처 패턴은 상당한 이점을 가지고 있습니다. 특히 복잡한 엔터프라이즈 애플리케이션의 민첩한 개발과 제공을 가능하게 하는 데 있어서 그렇습니다.

이 블로그 게시물은 마이크로서비스 설계, 구축, 배포에 대한 7부작 시리즈의 첫 번째 글입니다. 이러한 접근 방식과 이것이 보다 전통적인 모놀리식 아키텍처 패턴 과 어떻게 다른지 알아보겠습니다. 이 시리즈에서는 마이크로서비스 아키텍처의 다양한 요소에 대해 설명합니다. 마이크로서비스 아키텍처 패턴의 이점과 단점에 대해 알아보고, 이것이 프로젝트에 적합한지 여부와 적용 방법에 대해 알아봅니다.

먼저 마이크로서비스를 사용해야 하는 이유를 살펴보겠습니다.

모놀리식 애플리케이션 구축

Uber와 Hailo와 경쟁하기 위해 새로운 택시 호출 애플리케이션을 개발한다고 가정해 보겠습니다. 몇 가지 예비 회의와 요구 사항 수집이 끝나면 Rails, Spring Boot, Play 또는 Maven과 함께 제공되는 생성기를 사용하거나 수동으로 새 프로젝트를 만듭니다. 이 새로운 애플리케이션은 다음 다이어그램과 같이 모듈형 육각형 아키텍처를 갖게 됩니다.

애플리케이션의 핵심은 비즈니스 로직이며, 이는 서비스, 도메인 객체, 이벤트를 정의하는 모듈로 구현됩니다. 코어 주변에는 외부 세계와 접속하는 어댑터가 있습니다. 어댑터의 예로는 데이터베이스 액세스 구성 요소, 메시지를 생성하고 사용하는 메시징 구성 요소, API를 노출하거나 UI를 구현하는 웹 구성 요소 등이 있습니다.

논리적으로 모듈화된 아키텍처임에도 불구하고 해당 애플리케이션은 모놀리스로 패키징되고 배포됩니다. 실제 형식은 애플리케이션의 언어와 프레임워크에 따라 달라집니다. 예를 들어, 많은 Java 애플리케이션은 WAR 파일로 패키징되어 Tomcat이나 Jetty와 같은 애플리케이션 서버에 배포됩니다. 다른 Java 애플리케이션은 독립 실행형 JAR 파일로 패키징됩니다. 마찬가지로 Rails와 Node.js 애플리케이션은 디렉토리 계층으로 패키징됩니다.

이 스타일로 작성된 신청서는 매우 흔합니다. IDE와 다른 도구는 단일 애플리케이션을 구축하는 데 중점을 두고 있으므로 개발이 간단합니다. 이런 종류의 애플리케이션은 테스트하기도 쉽습니다. 애플리케이션을 실행하고 Selenium으로 UI를 테스트하는 간단한 방법으로 종단 간 테스트를 구현할 수 있습니다. 모놀리식 애플리케이션은 배포하기도 쉽습니다. 패키지된 애플리케이션을 서버에 복사하기만 하면 됩니다. 로드 밸런서 뒤에서 여러 복사본을 실행하여 애플리케이션을 확장할 수도 있습니다. 프로젝트 초기 단계에서는 잘 작동했습니다.

거대한 지옥을 향해 행진하다

안타깝게도 이 간단한 접근 방식에는 큰 한계가 있습니다. 성공적인 애플리케이션은 시간이 지남에 따라 성장하여 결국 엄청나게 커지는 경향이 있습니다. 각 스프린트 동안 개발팀은 몇 개의 스토리를 더 구현하는데, 당연히 이는 많은 줄의 코드를 추가한다는 것을 의미합니다. 몇 년이 지나면 여러분의 작고 간단한 애플리케이션은 거대한 거대 조직 으로 성장할 것입니다. 극단적인 예를 하나 들자면, 저는 최근 수백만 줄의 코드(LOC)가 들어 있는 애플리케이션에서 수천 개의 JAR 간의 종속성을 분석하는 도구를 작성 중이던 개발자와 이야기를 나누었습니다. 저는 이런 괴물을 만들어내기 위해 수년에 걸쳐 수많은 개발자들의 협력이 있었을 거라고 확신합니다.

애플리케이션이 방대하고 복잡한 단일체로 발전하면 개발 조직은 엄청난 난관에 봉착하게 될 것입니다. 민첩한 개발과 전달을 위한 모든 시도는 실패로 끝날 것입니다. 가장 큰 문제 중 하나는 신청서가 지나치게 복잡하다는 것입니다. 한 명의 개발자가 완전히 이해하기에는 너무 방대합니다. 그 결과, 버그를 수정하고 새로운 기능을 올바르게 구현하는 일이 어렵고 시간이 많이 걸리게 됩니다. 더욱이 이는 하락 추세를 보입니다. 코드베이스를 이해하기 어려운 경우 변경 사항이 올바르게 적용되지 않습니다. 결국 당신은 괴물같고 이해할 수 없는 커다란 진흙덩어리를 얻게 될 것이다.

애플리케이션의 크기가 너무 크면 개발 속도도 느려집니다. 애플리케이션이 클수록 시작 시간이 길어집니다. 예를 들어, 최근 설문 조사에서 일부 개발자는 시작 시간이 무려 12분이나 걸린다고 보고했습니다. 또한, 애플리케이션을 시작하는 데 40분이 걸린다는 일화도 들어봤습니다. 개발자가 애플리케이션 서버를 정기적으로 재시작해야 한다면 하루 중 많은 시간을 기다리는 데 소모하게 되고 생산성이 저하될 것입니다.

대규모 복잡한 모노리식 애플리케이션의 또 다른 문제점은 지속적인 배포를 방해한다는 것입니다. 오늘날 SaaS 애플리케이션의 최첨단 기술은 하루에 여러 번 변경 사항을 프로덕션에 적용하는 것입니다. 복잡한 모놀리스의 경우 이 작업을 수행하기가 매우 어렵습니다. 어느 한 부분을 업데이트하려면 전체 애플리케이션을 다시 배포해야 하기 때문입니다. 앞서 언급한 긴 시작 시간도 도움이 되지 않습니다. 또한, 변경 사항의 영향이 일반적으로 잘 이해되지 않기 때문에 광범위한 수동 테스트를 수행해야 할 가능성이 높습니다. 결과적으로 지속적인 배포는 사실상 불가능합니다.

또한 여러 모듈의 리소스 요구 사항이 상충되는 경우 모놀리식 애플리케이션을 확장하기 어려울 수 있습니다. 예를 들어, 하나의 모듈은 CPU 집약적 이미지 처리 논리를 구현할 수 있으며 이상적으로는 Amazon EC2 Compute Optimized 인스턴스 에 배포될 것입니다. 또 다른 모듈은 메모리 내 데이터베이스일 수 있으며 EC2 메모리 최적화 인스턴스 에 가장 적합할 수 있습니다. 하지만 이러한 모듈이 함께 배포되므로 하드웨어 선택에 있어서 타협해야 합니다.

모노리식 애플리케이션의 또 다른 문제는 안정성입니다. 모든 모듈이 동일한 프로세스 내에서 실행되므로 메모리 누수와 같은 모듈의 버그가 잠재적으로 전체 프로세스를 중단시킬 수 있습니다. 게다가 모든 애플리케이션 인스턴스가 동일하기 때문에 해당 버그는 전체 애플리케이션의 가용성에 영향을 미칩니다.

마지막으로, 모놀리식 애플리케이션은 새로운 프레임워크와 언어를 도입하는 것을 매우 어렵게 만듭니다. 예를 들어, XYZ 프레임워크를 사용하여 작성된 200만 줄의 코드가 있다고 가정해 보겠습니다. 새로운 ABC 프레임워크를 사용해 전체 애플리케이션을 다시 작성하려면 시간과 비용 측면에서 엄청난 비용이 들 것입니다. 해당 프레임워크가 상당히 뛰어나더라도 말입니다. 결과적으로 새로운 기술을 도입하는 데 큰 장벽이 생깁니다. 프로젝트를 시작할 때 선택한 기술에 따라 결정이 내려지게 됩니다.

요약하자면, 성공적인 비즈니스에 중요한 애플리케이션이 거대한 단일체로 성장하여 이를 이해하는 개발자가 거의 없거나 전혀 없다는 뜻입니다. 이 프로그램은 재능 있는 개발자를 채용하기 어렵게 만드는 오래되고 비생산적인 기술을 사용하여 작성되었습니다. 해당 애플리케이션은 확장하기 어렵고 신뢰할 수 없습니다. 결과적으로 애플리케이션을 민첩하게 개발하고 제공하는 것이 불가능합니다.

그러면 이에 대해 무엇을 할 수 있을까요?

마이크로서비스 - 복잡성 해결

Amazon, eBay, Netflix 등 많은 기업은 현재 마이크로서비스 아키텍처 패턴 으로 알려진 패턴을 도입하여 이 문제를 해결했습니다. 하나의 거대하고 일체형 애플리케이션을 만드는 대신, 애플리케이션을 여러 개의 작고 상호 연결된 서비스 세트로 분할하는 것이 아이디어입니다.

서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 일련의 고유한 기능이나 기능을 구현합니다. 각 마이크로서비스는 비즈니스 로직과 다양한 어댑터로 구성된 고유한 육각형 아키텍처를 갖춘 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션 클라이언트가 사용하는 API를 노출합니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임에 각 인스턴스는 종종 클라우드 VM 또는 Docker 컨테이너입니다.

예를 들어, 앞서 설명한 시스템의 가능한 분해는 다음 다이어그램에 표시되어 있습니다.

이제 애플리케이션의 각 기능 영역은 자체 마이크로서비스로 구현됩니다. 게다가, 웹 애플리케이션은 여러 개의 더 간단한 웹 애플리케이션(예: 택시 호출의 경우 승객용 애플리케이션과 운전자용 애플리케이션)으로 나뉩니다. 이를 통해 특정 사용자, 장치 또는 전문적인 사용 사례에 맞춰 서로 다른 경험을 쉽게 배포할 수 있습니다.

각 백엔드 서비스는 REST API를 공개하고 대부분의 서비스는 다른 서비스에서 제공하는 API를 사용합니다. 예를 들어, 운전자 관리에서는 알림 서버를 사용하여 이용 가능한 운전자에게 잠재적인 여행에 대해 알립니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기식 메시지 기반 통신을 사용할 수도 있습니다. 이 시리즈의 후반부에서는 서비스 간 커뮤니케이션에 대해 더 자세히 다룰 것입니다.

일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 공개됩니다. 하지만 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신, API 게이트웨이 라고 하는 중개자를 통해 통신이 중재됩니다. API 게이트웨이는 로드 밸런싱, 캐싱, 액세스 제어, API 미터링 및 모니터링과 같은 작업을 담당하며 NGINX를 사용하여 효과적으로 구현할 수 있습니다 . 이 시리즈의 이후 기사에서는 API 게이트웨이를 다룰 것입니다.

마이크로서비스 아키텍처 패턴은 The Art of Scalability라는 훌륭한 책에서 나온 확장성의 3D 모델인 Scale Cube 의 Y축 크기 조정에 해당합니다. 나머지 두 가지 확장 축은 X축 확장으로, 로드 밸런서 뒤에서 애플리케이션의 여러 동일한 사본을 실행하는 것으로 구성되고, Z축 확장(또는 데이터 분할)은 요청의 속성(예: 행의 기본 키 또는 고객의 ID)을 사용하여 요청을 특정 서버로 라우팅하는 데 사용됩니다.

일반적으로 애플리케이션은 세 가지 유형의 확장을 함께 사용합니다. Y축 확장은 이 섹션의 첫 번째 그림에서 위에 표시된 것처럼 애플리케이션을 마이크로서비스로 분해합니다. 런타임 시 X축 스케일링은 처리량과 가용성을 위해 로드 밸런서 뒤에서 각 서비스의 여러 인스턴스를 실행합니다. 일부 애플리케이션은 서비스를 분할하기 위해 Z축 크기 조정을 사용할 수도 있습니다. 다음 다이어그램은 Docker를 Amazon EC2에 실행하여 여행 관리 서비스를 배포하는 방법을 보여줍니다.

런타임 시, 여행 관리 서비스는 여러 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Docker 컨테이너입니다. 고가용성을 위해 컨테이너는 여러 클라우드 VM에서 실행됩니다. 서비스 인스턴스 앞에는 인스턴스 간에 요청을 분산하는 NGINX와 같은 로드 밸런서가 있습니다. 로드 밸런서는 캐싱 , 액세스 제어 , API 측정 , 모니터링 과 같은 다른 문제도 처리할 수 있습니다.

마이크로서비스 아키텍처 패턴은 애플리케이션과 데이터베이스 간의 관계에 상당한 영향을 미칩니다. 다른 서비스와 단일 데이터베이스 스키마를 공유하는 대신, 각 서비스는 자체 데이터베이스 스키마를 갖습니다. 한편, 이러한 접근 방식은 기업 전체의 데이터 모델이라는 개념과 맞지 않습니다. 또한 이로 인해 일부 데이터가 중복되는 경우도 많습니다. 그러나 마이크로서비스의 이점을 얻으려면 서비스별로 데이터베이스 스키마를 갖는 것이 필수적입니다. 이는 느슨한 결합을 보장하기 때문입니다. 다음 다이어그램은 예제 애플리케이션의 데이터베이스 아키텍처를 보여줍니다.

각 서비스에는 자체 데이터베이스가 있습니다. 더욱이 서비스는 해당 요구 사항에 가장 적합한 유형의 데이터베이스, 소위 폴리글롯 지속성 아키텍처를 사용할 수 있습니다. 예를 들어, 잠재적 승객과 가까운 운전자를 찾아주는 운전자 관리 기능은 효율적인 지리 쿼리를 지원하는 데이터베이스를 사용해야 합니다.

표면적으로 보면 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 가지 접근 방식 모두 아키텍처는 일련의 서비스로 구성됩니다. 그러나 마이크로서비스 아키텍처 패턴에 대한 한 가지 생각은 웹 서비스 사양 (WS-*)과 엔터프라이즈 서비스 버스(ESB)의 상업화와 인식된 부담이 없는 SOA라는 것입니다. 마이크로서비스 기반 애플리케이션은 WS-*보다 REST와 같은 더 간단하고 가벼운 프로토콜을 선호합니다. 또한 그들은 ESB 사용을 매우 피하고 대신 마이크로서비스 자체에 ESB와 유사한 기능을 구현합니다. 마이크로서비스 아키텍처 패턴은 또한 정식 스키마 개념 등 SOA의 다른 부분을 거부합니다.

마이크로서비스의 이점

마이크로서비스 아키텍처 패턴은 여러 가지 중요한 이점을 가지고 있습니다. 첫째, 복잡성 문제를 해결합니다. 이는 원래 괴물같이 거대한 단일 애플리케이션을 일련의 서비스로 분해합니다. 기능의 전체 규모는 변함이 없지만, 애플리케이션은 관리하기 쉬운 단위 또는 서비스로 나뉩니다. 각 서비스에는 RPC 또는 메시지 기반 API 형태로 잘 정의된 경계가 있습니다. 마이크로서비스 아키텍처 패턴은 실제로 모놀리식 코드 기반으로는 달성하기 매우 어려운 수준의 모듈성을 적용합니다. 결과적으로 개별 서비스를 훨씬 더 빠르게 개발할 수 있으며, 이해하고 유지 관리하기가 훨씬 더 쉽습니다.

두 번째로, 이 아키텍처를 사용하면 각 서비스에 집중한 팀이 각 서비스를 독립적으로 개발할 수 있습니다. 서비스가 API 계약을 준수하는 한, 개발자는 원하는 기술을 자유롭게 선택할 수 있습니다. 물론, 대부분의 조직에서는 완전한 무정부 상태를 피하고 기술 옵션을 제한하고 싶어할 것입니다. 그러나 이러한 자유는 개발자가 새로운 프로젝트를 시작할 당시에 존재했던 아마도 쓸모없어진 기술을 사용할 의무가 더 이상 없다는 것을 의미합니다. 새로운 서비스를 작성할 때는 최신 기술을 사용할 수 있는 옵션이 있습니다. 게다가 서비스가 비교적 작기 때문에 최신 기술을 사용하여 오래된 서비스를 다시 작성하는 것이 가능해집니다.

셋째, 마이크로서비스 아키텍처 패턴을 사용하면 각 마이크로서비스를 독립적으로 배포할 수 있습니다. 개발자는 자신의 서비스에 대한 로컬 변경 사항의 배포를 조정할 필요가 없습니다. 이런 종류의 변경 사항은 테스트를 거친 후 바로 배포될 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적인 배포를 가능하게 합니다.

마지막으로, 마이크로서비스 아키텍처 패턴을 사용하면 각 서비스를 독립적으로 확장할 수 있습니다. 각 서비스의 인스턴스 수만큼을 용량 및 가용성 제약 조건을 충족하는 방식으로 배포할 수 있습니다. 게다가 서비스의 리소스 요구 사항에 가장 잘 맞는 하드웨어를 사용할 수 있습니다. 예를 들어, EC2 Compute Optimized 인스턴스에 CPU 집약적 이미지 처리 서비스를 배포하고 EC2 Memory-optimized 인스턴스에 메모리 내 데이터베이스 서비스를 배포할 수 있습니다.

마이크로서비스의 단점

프레드 브룩스가 거의 30년 전에 말했듯이, 완벽한 해결책은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에는 단점이 있습니다. 한 가지 단점은 이름 자체입니다. 마이크로서비스 라는 용어는 서비스 크기에 지나치게 중점을 둡니다. 실제로 일부 개발자는 매우 세분화된 10~100개 LOC 서비스를 구축하는 것을 옹호합니다. 소규모 서비스가 바람직하기는 하지만, 그것은 목적을 달성하기 위한 수단일 뿐이지 주된 목표는 아니라는 점을 기억하는 것이 중요합니다. 마이크로서비스의 목표는 민첩한 애플리케이션 개발과 배포를 용이하게 하기 위해 애플리케이션을 충분히 분해하는 것입니다.

마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이기 때문에 발생하는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 게다가 요청의 대상이 느리거나 사용할 수 없을 수 있으므로 부분적 실패를 처리하는 코드도 작성해야 합니다. 이 중 어느 것도 로켓 과학은 아니지만 모듈이 언어 수준의 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션보다 훨씬 더 복잡합니다.

마이크로서비스의 또 다른 과제는 분할된 데이터베이스 아키텍처입니다. 여러 사업체에 업데이트를 제공하는 사업 거래는 매우 흔합니다. 이러한 종류의 거래는 단일 데이터베이스가 있기 때문에 모노리식 애플리케이션에서 구현하기가 쉽습니다. 그러나 마이크로서비스 기반 애플리케이션에서는 다양한 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션을 사용하는 것은 일반적으로 선택 사항이 아니며, 이는 CAP 정리 때문만은 아닙니다. 이러한 방식은 오늘날 확장성이 뛰어난 많은 NoSQL 데이터베이스와 메시징 브로커에서 지원되지 않습니다. 결국 개발자에게는 더 어려운 문제인 최종 일관성 기반 접근 방식을 사용해야 합니다.

마이크로서비스 애플리케이션을 테스트하는 것도 훨씬 더 복잡합니다. 예를 들어, Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 간단합니다. 반면, 서비스에 대한 유사한 테스트 클래스는 해당 서비스와 해당 서비스에 종속된 모든 서비스를 시작해야 합니다(또는 최소한 해당 서비스에 대한 스텁을 구성해야 합니다). 다시 한번 말씀드리지만, 이것은 로켓과학이 아니지만 이를 수행하는 것의 복잡성을 과소평가해서는 안 됩니다.

마이크로서비스 아키텍처 패턴의 또 다른 주요 과제는 여러 서비스에 걸쳐 변경 사항을 구현하는 것입니다. 예를 들어, 서비스 A, B, C에 대한 변경이 필요한 스토리를 구현하고 있다고 가정해 보겠습니다. 여기서 A는 B에 의존하고 B는 C에 의존합니다. 모놀리식 애플리케이션에서는 간단히 해당 모듈을 변경하고 변경 사항을 통합한 다음 한 번에 배포할 수 있습니다. 반면, 마이크로서비스 아키텍처 패턴에서는 각 서비스에 대한 변경 사항의 롤아웃을 신중하게 계획하고 조정해야 합니다. 예를 들어, 서비스 C를 업데이트한 다음 서비스 B를 업데이트하고 마지막으로 서비스 A를 업데이트해야 합니다. 다행히도 대부분의 변경 사항은 일반적으로 하나의 서비스에만 영향을 미치고 조정이 필요한 여러 서비스 변경은 비교적 드뭅니다.

마이크로서비스 기반 애플리케이션을 배포하는 것은 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 기존 로드 밸런서 뒤에 있는 동일한 서버 세트에 배포됩니다. 각 애플리케이션 인스턴스는 데이터베이스 및 메시지 브로커와 같은 인프라 서비스의 위치(호스트 및 포트)로 구성됩니다. 이와 대조적으로, 마이크로서비스 애플리케이션은 일반적으로 다수의 서비스로 구성됩니다. 예를 들어, Adrian Cockcroft [편집자 - Hailo는 MyTaxi에 인수되었습니다.] 에 따르면 Hailo에는 160개의 다양한 서비스가 있고 Netflix에는 600개 이상의 서비스가 있습니다. 각 서비스에는 여러 개의 런타임 인스턴스가 있습니다. 구성, 배포, 확장, 모니터링해야 할 움직이는 부분이 훨씬 더 많아졌습니다. 또한, 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 검색할 수 있도록 하는 서비스 검색 메커니즘(나중 게시물에서 논의)도 구현해야 합니다. 기존의 문제 티켓 기반 및 수동 운영 방식으로는 이 수준의 복잡성을 충족할 수 없습니다. 결과적으로, 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방법을 더 잘 제어하고 높은 수준의 자동화가 필요합니다.

자동화에 대한 한 가지 접근 방식은 Cloud Foundry 와 같은 기성형 PaaS를 사용하는 것입니다. PaaS는 개발자에게 마이크로서비스를 쉽게 배포하고 관리할 수 있는 방법을 제공합니다. 이를 통해 IT 리소스의 조달 및 구성과 같은 문제로부터 보호받을 수 있습니다. 동시에 PaaS를 구성하는 시스템 및 네트워크 전문가는 모범 사례와 회사 정책을 준수하도록 보장할 수 있습니다. 마이크로서비스 배포를 자동화하는 또 다른 방법은 본질적으로 자체 PaaS를 개발하는 것입니다. 일반적인 시작점 중 하나는 Kubernetes 와 같은 클러스터링 솔루션을 Docker와 같은 기술과 함께 사용하는 것입니다. 이 시리즈의 후반부에서는 캐싱, 액세스 제어, API 측정, 마이크로서비스 수준에서 모니터링을 쉽게 처리하는 NGINX Plus와 같은 소프트웨어 기반 애플리케이션 제공 접근 방식이 이 문제를 해결하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다.

요약

복잡한 애플리케이션을 만드는 것은 본질적으로 어렵습니다. 모놀리식 아키텍처는 간단하고 가벼운 애플리케이션에만 적합합니다. 복잡한 용도에 사용하면 엄청난 고통을 겪게 될 것입니다. 마이크로서비스 아키텍처 패턴은 단점과 구현상의 과제에도 불구하고 복잡하고 진화하는 애플리케이션에 더 나은 선택입니다.

이후 블로그 게시물에서는 마이크로서비스 아키텍처 패턴의 다양한 측면에 대한 세부 사항을 살펴보고 서비스 검색, 서비스 배포 옵션, 모놀리식 애플리케이션을 서비스로 리팩토링하는 전략과 같은 주제를 논의하겠습니다.

계속 지켜봐주세요…

편집자 – 이 7부작 시리즈 기사는 이제 완료되었습니다.

1. 마이크로서비스 소개(이 문서)
2. 마이크로서비스 구축: API 게이트웨이 사용
3. 마이크로서비스 구축: 마이크로서비스 아키텍처에서의 프로세스 간 통신
4. 마이크로서비스 아키텍처에서의 서비스 발견
5. 마이크로서비스를 위한 이벤트 기반 데이터 관리
6. 마이크로서비스 배포 전략 선택
7. 모놀리스를 마이크로서비스로 리팩토링

NGINX Plus를 사용하여 마이크로서비스를 구현하는 것에 대한 정보와 더불어 전체 문서 세트를 전자책으로 다운로드할 수도 있습니다. – 마이크로서비스: 설계부터 배포까지 .

게스트 블로거 크리스 리처드슨은 Amazon EC2를 위한 초기 Java PaaS(서비스형 플랫폼)인 CloudFoundry.com 의 창립자입니다. 그는 현재 기업들과 협의해 애플리케이션을 개발하고 배포하는 방식을 개선하기 위해 노력하고 있습니다.