마이크로서비스 소개

Chris Richardson

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 컴퓨팅 최적화 인스턴스에 배포하는 것이 가장 적합할 수 있습니다. 또 다른 모듈은 인메모리 데이터베이스이므로 EC2 메모리 최적화 인스턴스에 가장 적합할 수 있습니다. 하지만 이러한 모듈은 함께 배포되므로 하드웨어를 선택할 때 절충해야 합니다.

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

마지막으로, 모놀리식 애플리케이션에서는 새로운 프레임워크와 언어를 도입하기가 매우 어렵습니다. 예를 들어 XYZ 프레임워크를 사용해 작성한 코드가 200만 줄에 달한다고 가정해 보겠습니다. ABC라는 최신 프레임워크가 훨씬 더 뛰어나더라도, 이를 사용하도록 애플리케이션 전체를 다시 작성하려면 시간과 비용이 막대하게 듭니다. 따라서 새로운 기술을 도입하는 데 큰 장벽이 생깁니다. 결국 프로젝트 초기에 선택한 기술에 계속 얽매이게 됩니다.

요약하자면, 성공적으로 운영되고 있는 비즈니스 핵심 애플리케이션이 극소수의 개발자만 이해할 수 있을 정도로 거대한 모놀리스로 성장한 상황입니다. 이 애플리케이션은 낡고 생산성이 낮은 기술로 작성되어 있어 유능한 개발자를 채용하기도 어렵습니다. 확장하기 어렵고 안정성도 떨어집니다. 그 결과, 애플리케이션을 애자일 방식으로 개발하고 배포하는 것이 불가능합니다.

그렇다면 이 문제를 어떻게 해결할 수 있을까요?

마이크로서비스 – 복잡성 해결하기

Amazon, eBay를 비롯한 많은 조직은 Netflix와 같이 오늘날 마이크로서비스 아키텍처 패턴으로 알려진 방식을 도입하여 이 문제를 해결했습니다. 하나의 거대한 모놀리식 애플리케이션을 구축하는 대신, 애플리케이션을 서로 연결된 여러 개의 소규모 서비스로 분할하는 것이 핵심입니다.

서비스는 일반적으로 주문 관리, 고객 관리 등 서로 구분되는 일련의 기능을 구현합니다. 각 마이크로서비스는 비즈니스 로직과 다양한 어댑터로 구성된 자체 육각형 아키텍처를 갖춘 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션의 클라이언트가 사용하는 API를 제공합니다. 또 다른 마이크로서비스는 웹 UI를 구현하기도 합니다. 런타임에서 각 인스턴스는 대개 클라우드 VM 또는 Docker 컨테이너로 실행됩니다.

예를 들어, 앞서 설명한 시스템을 분해할 수 있는 한 가지 방법은 다음 다이어그램과 같습니다:

이제 애플리케이션의 각 기능 영역은 독립적인 마이크로서비스로 구현됩니다. 또한 웹 애플리케이션은 더 단순한 여러 웹 애플리케이션으로 분리됩니다(예: 택시 호출 애플리케이션의 승객용 애플리케이션과 운전기사용 애플리케이션). 따라서 특정 사용자, 기기 또는 특수한 사용 사례에 맞는 차별화된 경험을 더 쉽게 배포할 수 있습니다.

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

일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 제공됩니다. 하지만 이러한 앱은 백엔드 서비스에 직접 액세스하지 않습니다. 대신 API 게이트웨이라는 중개자를 통해 통신합니다. API 게이트웨이는 부하 분산, 캐싱, 액세스 제어, API 사용량 측정, 모니터링 등의 작업을 담당하며, NGINX를 사용해 효과적으로 구현할 수 있습니다。 이 시리즈의 후속 글에서는 API 게이트웨이에 대해 다룹니다.

마이크로서비스 아키텍처 패턴은 스케일 큐브의 Y축 확장에 해당합니다. 스케일 큐브는 훌륭한 책 확장성의 기술에서 소개된 확장성의 3차원 모델입니다. 나머지 두 확장 축은 로드 밸런서 뒤에서 동일한 애플리케이션 사본 여러 개를 실행하는 X축 확장과, 요청의 속성(예: 행의 기본 키 또는 고객의 ID)을 사용하여 요청을 특정 서버로 라우팅하는 Z축 확장(또는 데이터 파티셔닝)입니다.

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

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

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

각 서비스는 자체 데이터베이스를 보유합니다. 또한 서비스는 자신의 요구 사항에 가장 적합한 유형의 데이터베이스를 사용할 수 있는데, 이를 이른바 다중 언어 지속성 아키텍처라고 합니다. 예를 들어 잠재 승객과 가까운 운전자를 찾는 운전자 관리 서비스는 효율적인 지리 공간 쿼리를 지원하는 데이터베이스를 사용해야 합니다.

표면적으로 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 접근 방식 모두 아키텍처가 일련의 서비스로 구성됩니다. 하지만 마이크로서비스 아키텍처 패턴은 상업화와 불필요한 부담으로 인식되는 웹 서비스 사양(WS‑*) 및 엔터프라이즈 서비스 버스(ESB)를 배제한 SOA라고 볼 수도 있습니다. 마이크로서비스 기반 애플리케이션은 WS‑*보다 REST와 같이 더 단순하고 가벼운 프로토콜을 선호합니다. 또한 ESB 사용을 최대한 피하고, 대신 ESB와 유사한 기능을 마이크로서비스 자체에 구현합니다. 마이크로서비스 아키텍처 패턴은 표준 스키마 개념과 같은 SOA의 다른 요소도 받아들이지 않습니다.

마이크로서비스의 이점

마이크로서비스 아키텍처 패턴에는 여러 가지 중요한 이점이 있습니다. 첫째, 복잡성 문제를 해결합니다. 자칫 거대한 모놀리식 애플리케이션이 될 수 있는 시스템을 여러 서비스로 분해합니다. 전체 기능의 양은 그대로지만, 애플리케이션은 관리 가능한 단위 또는 서비스로 나뉩니다. 각 서비스는 RPC 또는 메시지 기반 API 형태로 명확하게 정의된 경계를 갖습니다. 마이크로서비스 아키텍처 패턴은 모놀리식 코드베이스에서는 실제로 달성하기 매우 어려운 수준의 모듈성을 보장합니다. 따라서 개별 서비스를 훨씬 빠르게 개발할 수 있으며, 이해하고 유지 관리하기도 훨씬 쉽습니다.

둘째, 이 아키텍처에서는 각 서비스를 해당 서비스에 집중하는 팀이 독립적으로 개발할 수 있습니다. 서비스가 API 계약을 준수하는 한, 개발자는 적합하다고 판단되는 기술을 자유롭게 선택할 수 있습니다. 물론 대부분의 조직은 완전한 무질서 상태를 피하고 기술 선택의 범위를 제한하려 할 것입니다. 하지만 이러한 자유 덕분에 개발자는 더 이상 새 프로젝트를 시작할 당시 사용되던, 어쩌면 이미 낡은 기술을 반드시 사용해야 할 필요가 없습니다. 새 서비스를 작성할 때는 최신 기술을 선택할 수 있습니다. 또한 서비스의 규모가 비교적 작기 때문에 기존 서비스를 최신 기술로 다시 작성하는 것도 현실적으로 가능합니다.

셋째, 마이크로서비스 아키텍처 패턴을 사용하면 각 마이크로서비스를 독립적으로 배포할 수 있습니다. 개발자는 자신의 서비스에만 국한된 변경 사항을 배포할 때 다른 팀과 조율할 필요가 없습니다. 이러한 변경 사항은 테스트가 완료되는 즉시 배포할 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복 개선할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적 배포를 가능하게 합니다.

마지막으로, 마이크로서비스 아키텍처 패턴을 사용하면 각 서비스를 독립적으로 확장할 수 있습니다. 각 서비스의 용량 및 가용성 제약 조건을 충족하는 데 필요한 수만큼만 인스턴스를 배포할 수 있습니다. 또한 서비스의 리소스 요구 사항에 가장 적합한 하드웨어를 사용할 수 있습니다. 예를 들어 CPU 사용량이 많은 이미지 처리 서비스는 EC2 컴퓨팅 최적화 인스턴스에 배포하고, 인메모리 데이터베이스 서비스는 EC2 메모리 최적화 인스턴스에 배포할 수 있습니다.

마이크로서비스의 단점

약 30년 전 프레드 브룩스가 썼듯이, 만능 해결책은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에도 단점이 있습니다. 그중 하나는 명칭 자체입니다. 마이크로서비스라는 용어는 서비스의 크기를 지나치게 강조합니다. 실제로 10~100 LOC 규모의 극도로 세분화된 서비스를 구축해야 한다고 주장하는 개발자들도 있습니다. 작은 서비스가 바람직하기는 하지만, 이는 목적을 달성하기 위한 수단이지 그 자체가 주된 목표는 아니라는 점을 기억해야 합니다. 마이크로서비스의 목표는 애자일 방식의 애플리케이션 개발과 배포를 용이하게 할 수 있도록 애플리케이션을 충분히 분해하는 것입니다.

마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 비롯되는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 하는 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 또한 요청 대상의 응답이 느리거나 대상에 접근할 수 없을 수 있으므로 부분 장애를 처리하는 코드도 작성해야 합니다. 이 중 어느 것도 고도의 전문 지식이 필요한 일은 아니지만, 모듈이 언어 수준의 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션에 비하면 훨씬 더 복잡합니다.

마이크로서비스의 또 다른 과제는 분할된 데이터베이스 아키텍처입니다. 여러 비즈니스 엔터티를 업데이트하는 비즈니스 트랜잭션은 상당히 흔합니다. 모놀리식 애플리케이션에는 데이터베이스가 하나뿐이므로 이러한 트랜잭션을 구현하기가 매우 쉽습니다. 하지만 마이크로서비스 기반 애플리케이션에서는 서로 다른 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션은 일반적으로 선택지가 될 수 없는데, 그 이유는 CAP 정리 때문만은 아닙니다. 오늘날 확장성이 뛰어난 많은 NoSQL 데이터베이스와 메시지 브로커가 분산 트랜잭션을 지원하지 않기 때문입니다. 결국 최종 일관성에 기반한 접근 방식을 사용해야 하는데, 이는 개발자에게 더 까다로운 과제입니다.

마이크로서비스 애플리케이션을 테스트하는 것 역시 훨씬 더 복잡합니다. 예를 들어 Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 해당 REST API를 테스트하는 테스트 클래스를 손쉽게 작성할 수 있습니다. 반면 서비스에 대해 이와 유사한 테스트 클래스를 작성하려면 해당 서비스와 그 서비스가 의존하는 모든 서비스를 실행해야 합니다(또는 최소한 해당 서비스들의 스텁을 구성해야 합니다). 다시 말하지만 이것이 엄청나게 어려운 일은 아니지만, 그 복잡성을 과소평가하지 않는 것이 중요합니다.

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

마이크로서비스 기반 애플리케이션을 배포하는 일도 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 기존 로드 밸런서 뒤에 있는 동일한 사양의 서버 집합에 간단히 배포할 수 있습니다. 각 애플리케이션 인스턴스에는 데이터베이스와 메시지 브로커 같은 인프라 서비스의 위치(호스트 및 포트)가 설정됩니다. 반면 마이크로서비스 애플리케이션은 일반적으로 수많은 서비스로 구성됩니다. 예를 들어 Hailo에는 160개의 서로 다른 서비스가 있으며, Adrian Cockcroft에 따르면 Netflix에는 600개가 넘는 서비스가 있습니다. [편집자 주 – Hailo는 MyTaxi에 인수되었습니다.] 각 서비스에는 여러 개의 런타임 인스턴스가 있습니다. 즉, 구성, 배포, 확장 및 모니터링해야 할 요소가 훨씬 더 많습니다. 또한 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 찾을 수 있도록 서비스 검색 메커니즘(후속 게시물에서 설명)을 구현해야 합니다. 기존의 장애 티켓 기반 및 수동 운영 방식으로는 이 정도의 복잡성을 감당할 수 없습니다. 따라서 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방식을 더 강력하게 제어할 수 있어야 하며, 높은 수준의 자동화가 필요합니다.

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

요약

복잡한 애플리케이션을 구축하는 일은 본질적으로 어렵습니다. 모놀리식 아키텍처는 단순하고 가벼운 애플리케이션에만 적합합니다. 이를 복잡한 애플리케이션에 적용하면 큰 어려움을 겪게 됩니다. 단점과 구현상의 어려움에도 불구하고, 마이크로서비스 아키텍처 패턴은 복잡하고 지속적으로 발전하는 애플리케이션에 더 적합한 선택입니다.

이후 블로그 게시물에서는 마이크로서비스 아키텍처 패턴의 다양한 측면을 자세히 살펴보고, 서비스 디스커버리, 서비스 배포 옵션, 모놀리식 애플리케이션을 여러 서비스로 리팩터링하는 전략 등의 주제를 다루겠습니다.

계속 지켜봐 주세요…

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

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

전체 기사 모음과 NGINX Plus를 사용한 마이크로서비스 구현 정보를 전자책으로도 다운로드할 수 있습니다. 전자책 제목은 마이크로서비스: 설계부터 배포까지입니다.

객원 블로거 Chris Richardson은 초기 Amazon EC2용 Java PaaS(서비스형 플랫폼)였던 CloudFoundry.com의 창립자입니다. 현재는 여러 조직을 대상으로 애플리케이션 개발 및 배포 방식을 개선할 수 있도록 컨설팅하고 있습니다.

작성자 소개

Chris Richardson

Chris Richardson의 다른 블로그 게시물