사실상 크기가 더 크다고 항상 더 나은 것은 아닙니다. 백상아리는 바다에서 가장 위협적인 존재이지만, 물고기 떼가 하나의 그룹으로서 생존 및 번성 능력이 단일 생물보다 더 뛰어난 경우가 많이 있습니다. 실제로 동물의 왕국에서 공동 작업을 통한 성공은 흔한 주제입니다. 개미 군집, 벌떼, 늑대 무리 등 모두 느슨하게 연결된 시스템 내에서 힘을 분산하고 공동의 목표를 달성합니다. 군집, 벌떼 또는 무리 중 구성원 하나가 죽으면 그룹의 나머지 구성원이 계속 일하여 손실을 메웁니다.
마이크로서비스는 이러한 방식을 사용해 소프트웨어 개발과 시스템 아키텍처에 적용합니다. 여러 구성요소 기능이나 서비스를 별도로 만드는 것이 자체 포함되고 완전히 상호 연결된 시스템에 동일한 기능을 설치하는 것보다 더 빠르고 쉽고 안전하며 효율적이라는 아이디어입니다. 여기서는 마이크로서비스와 그 속성, 이점 및 과제를 자세히 살펴봅니다.
마이크로서비스가 무엇인지 이해하는 가장 좋은 방법은 먼저 마이크로서비스가 무엇이 아닌지를 파악하는 것입니다. 마이크로서비스와 다른 구조적 방법 간에는 여러 가지 차이가 있습니다. 여기서는 기존의 모놀리스 아키텍처와 마이크로서비스를 비교하며, 최근의 서비스 지향 아키텍처(SOA)와도 비교합니다.
이름에서 알 수 있듯이 모놀리스는 대규모 통합 애플리케이션으로, 각 구성요소가 대규모로 상호 연결되어 있으며 인접한 구성요소에 종속적입니다. 모놀리스는 모든 기능이 한 곳에서 관리되고 제공되며 모두 단일 코드 베이스에 빌드되는 기본 개발 방식입니다. 개발자들이 모놀리스 구조에서 구현하기를 바란 변경 사항이 자연스럽게 전체 스택을 바꿀 것입니다. 테스트 같은 작업을 전체 스택에 적용하고 처음부터 끝까지 비교적 오래 걸릴 수 있는 대규모 릴리스에서 변경 사항을 그룹화합니다. 마이크로서비스는 더 작고 자체 포함되어 있으며 느슨하게 연결된 구성요소로 구성되어 있다는 점에서 모놀리스와 구별됩니다. 애플리케이션 내 다른 서비스에 영향을 주지 않고 개별 구성요소에 변경 사항을 구현할 수 있습니다.
마이크로서비스와 SOA는 구분하기가 더 어렵습니다. 그러나 둘 다 여러 애플리케이션에 모듈식으로 적용될 수 있는 재사용 가능한 구성요소를 사용하는 반면, SOA는 훨씬 덜 세분화됩니다. 마이크로서비스는 모든 서비스가 단일 기능만 수행하는 지점으로 컨테이너화된 반면, 각 SOA 구성요소는 다양한 비즈니스 기능을 담당하는 완전한 하위 시스템입니다. 또한 SOA는 구성요소 공유 및 의존성을 최적화하는 반면, 마이크로서비스는 이러한 측면을 가능한 한 최소화하려고 합니다.
일반적으로 마이크로서비스의 특성은 다음과 같습니다.
마이크로서비스는 독립된 개별 서비스의 컬렉션으로 설계되었기 때문에 독립 실행형 구성요소로 손쉽게 테스트할 수 있습니다. 전체 시스템과 애플리케이션을 테스트할 필요 없이 구성요소 내 문제를 신속하게 격리한 다음, 특정 오류를 격리하기 위해 오랜 시간을 투자할 수 있습니다.
동시에 작동하기 위해 마이크로서비스는 서로 통신을 유지해야 합니다. 즉 한 서비스 내에서 구현된 변경 사항이 다른 서비스에 직접적으로 영향을 주지 않는 느슨한 연결입니다.
서비스에서 데이터 저장소를 공유하는 대신, 각 구성요소가 고유한 데이터 저장소를 유지합니다. 그러면 다른 서비스의 우발적인 연결을 방지하고 변경 사항으로 인해 다른 독립적인 서비스에 의도치 않게 영향을 미치지 않을 수 있습니다.
다른 서비스를 이용할 필요 없이 개별 서비스를 변경하고 프로덕션 환경에 배포합니다. 시스템 내 모든 배포는 이런 식으로 관리되어 마이크로서비스를 빠르게 개선합니다.
마이크로서비스는 단일 비즈니스 목적으로 조직된 부서 간 업무 팀을 사용합니다. 이러한 팀은 일반적으로 개발자, 데이터베이스 엔지니어, 테스터, 인프라 엔지니어 등으로 구성되며, 독립된 여러 서비스를 기반으로 특정 제품을 개발하는 것을 목표로 합니다.
마이크로서비스에서 독립된 각 서비스는 요청을 받고, 처리하고, 응답할 수 있습니다. 이는 여러 기존 시스템에 비해 상당히 단순화된 것으로, 복잡한 라우팅 및 비즈니스 규칙 애플리케이션 계층은 프로세스를 느리게 만들 수 있습니다.
마이크로서비스 시스템에 전체적으로 장애가 발생하는 경우, 기본적으로 해당하는 모든 독립 서비스에도 동시에 장애가 발생해야 합니다. 느슨하게 연결된 서비스를 사용함으로써, 서비스 중 하나에 장애가 발생하는 경우에도 시스템은 거의 최적의 용량으로 계속 작동할 수 있습니다. 분산된 서비스 덕분에 서비스 하나에 장애가 발생해도 인접한 서비스에 거의 영향을 미치지 않거나 아무런 영향을 미치지 않습니다.
마이크로서비스는 사실상 모듈식이므로 필요한 경우 새 서비스를 추가하기가 비교적 쉽습니다. 그래서 조직은 현재 시스템을 새로운 용도에 맞춰 조정할 수 있고 변화하는 요구를 충족하도록 시스템을 확장하거나 축소할 수 있습니다.
조직은 새 서비스를 개발할 때 다양한 기술 스택을 자유롭게 선택할 수 있습니다. 동시에, 기존 서비스를 변경할 때에도 마찬가지로 새 기술 스택을 이용할 수 있습니다.
마이크로서비스가 서로 직접 통신할 수 있음에도 불구하고, 비즈니스는 중간 계층으로 작동하도록 API 게이트웨이를 통합하여 요청을 라우팅하고 추가 인증을 제공하고 보안을 향상하는 것을 선호합니다. API 통신은 마이크로서비스가 먼저 설정된 상태인 경우에 특히 효과적일 수 있습니다.
마이크로서비스는 기존 개발 아키텍처로부터의 전환을 의미하며, 기존의 구조적 방식보다 더 많은 이점을 제공합니다. 이러한 이점은 다음과 같습니다.
마이크로서비스를 통해 소규모의 독립적인 팀은 명확하게 정의된 컨텍스트 내에서 작업할 수 있습니다. 더 적은 시간에 더 많은 것을 성취하고 예상치 못한 변경 사항에 더 민첩하게 대응할 수 있습니다.
마이크로서비스는 복잡한 애플리케이션과 시스템을 더 작고 단순한 구성요소로 세분화합니다. 개발자는 서비스 간의 차이점을 손쉽게 파악하고 필요한 업데이트를 수행하고 개선할 수 있습니다.
개발자는 하나의 언어나 기술 스택에 갇히지 않고 영향을 받는 서비스 간 통신을 걱정하지 않으면서 각 기능에 맞는 최적의 솔루션, 도구 또는 자원을 자유롭게 선택할 수 있습니다.
마이크로서비스 기반 애플리케이션은 매우 모듈식이므로 비교적 쉽게 개발하고 배포할 수 있습니다. 팀은 함께 조직화하여 개별적인 소규모 구성요소에서 동시에 작업할 수 있으며, 각 구성요소를 독립적으로 배포할 수 있습니다.
기존 애플리케이션 아키텍처에서는 변화하는 요구를 충족한다는 것은 일반적으로 전체 애플리케이션을 확장한다는 의미입니다. 마이크로서비스를 통해 개발자는 해당 서비스와 구성요소에만 자원을 리디렉션하여 관련 비용은 절감하면서 빠르게 확장할 수 있습니다.
한 마이크로서비스에 장애가 발생하는 경우 인접한 마이크로서비스는 영향을 받지 않습니다. 즉 마이크로서비스 기반 애플리케이션은 하나 이상의 구성요소에 장애가 발생해도 작동이 중단되지 않는 경향이 있으며, 애플리케이션 자체는 영향을 받은 서비스가 복구될 때까지 기능이 저하된 상태로 계속 작동합니다.
각 서비스는 자체 포함되어 있으며 특정 기능을 독립적으로 수행하도록 설계되었기 때문에 개발자는 여러 애플리케이션에서 서비스를 다시 사용하고 재활용할 수 있습니다. 구성요소는 '빌딩 블록'처럼 작동하여 모든 새 프로젝트에서 새 코드를 처음부터 작성해야 할 필요성을 상당히 줄입니다.
향상된 민첩성, 증가한 재사용성, 간소화된 배포는 모두 개발 주기와 시장 출시 기간을 단축합니다. 그러면 비즈니스 수익을 늘리고 만족도가 높은 사용자 경험을 제공할 가능성이 커집니다.
마이크로서비스가 제시하는 이점에는 어려움도 따릅니다. 여기서는 조직에서 마이크로서비스 방식을 구현할 때 발생할 수 있는 과제를 자세히 살펴봅니다.
마이크로서비스로 전환한다는 것은 서비스 간 모든 종속성을 식별하고 범주화하는 것입니다. 종속성 때문에 빌드 하나를 완성하기 위해 수많은 다른 빌드를 구현해야 할 수도 있습니다. 이는 불편하고 시간 소모적일 수 있습니다.
마이크로서비스의 주요 요소는 각 구성요소에 자신만의 격리된 데이터베이스가 있다는 점입니다. 그러나 각각의 새 데이터베이스는 관리 복잡성이 늘어납니다. 더 많은 서비스와 더 많은 데이터베이스가 이용될수록 데이터 자체를 관리하기는 불편해집니다.
마이크로서비스를 사용하여 애플리케이션을 새 버전으로 업데이트할 때 이전 버전과의 호환성이 영향을 받을 수 있습니다. 조건부 논리로 빌드하거나 여러 클라이언트에 대한 여러 라이브 버전을 준비하는 솔루션은 유지관리와 관리 면에서 과도하게 복잡해질 수 있습니다.
마이크로서비스는 배포를 간소화하도록 설계됩니다. 그러나 많은 수의 독립된 구성요소로 작업하는 복잡성이 문제가 될 수 있습니다. 자동화가 이 문제를 해결하는 데 도움이 될 수 있습니다.
모든 서비스가 자신만의 데이터베이스를 사용하면 로깅이 어려워질 수 있습니다. 중앙 관리식 로깅 솔루션이 필요합니다. 마찬가지로, 중앙 관리식 뷰와 단일 데이터 소스 없이는 각 서비스를 모니터링하고 관리하기가 불가능할 수 있습니다.
잠재적으로 수백 개의 마이크로서비스가 단일 애플리케이션에 통합될 수 있으므로, 기존 디버깅은 불가능합니다.
마이크로서비스 아키텍처를 통해 팀은 상당한 독립성을 얻을 수 있는 반면, 애플리케이션 내 하나 이상의 서비스에서 발생하는 문제를 해결하기 위해서는 세밀한 팀 간 커뮤니케이션과 조정이 필요할 수 있습니다.
마이크로서비스 애플리케이션은 분산 시스템이기 때문에 팀은 부지불식간에 작업을 중복할 수 있습니다. 그러면 노력을 낭비하고 애플리케이션을 비효율적으로 만들 수 있습니다.
위에서 언급한 과제 외에도, 조직은 마이크로서비스 아키텍처 도입을 고려할 때 다음과 같은 문제점이 있음을 알고 있어야 합니다.
인기 있는 아키텍처 개발 방식임에도 불구하고 마이크로서비스는 일반적으로 과도하게 복잡하고 유지관리가 어려운 기존 애플리케이션을 복구하고 수정하기에 가장 적합합니다. 시작 지점으로 사용할 때는 그다지 효과적이지 않습니다. 기존 방식이 불가능한 수준에 도달하지 않았다면 모놀리스는 재구성이 필요하지 않습니다.
다른 것처럼 서비스는 항상 더 작은 부분으로 나눌 수 있습니다. 그리고 마이크로서비스는 세분화되어 있고 더 큰 전체를 지원하도록 설계된 제한된 기능으로 구성되어 있는데, 이는 너무 지나칠 수 있습니다. 대신, 많은 회사는 더 큰 서비스로 시작한 다음 배포 속도를 늦추거나 관리하기가 너무 복잡해지면 마이크로서비스로 세분화하여 솔루션이 잠재적인 이익을 상쇄하지 않도록 할 수 있습니다.
대규모 분산 시스템은 쉽게 감당할 수 없게 될 수 있습니다. 마이크로서비스를 효율적으로 사용하려면 조직은 관리형 클라우드 서비스와 함께 고급 배포 및 모니터링 자동화를 통합해야 합니다. 그러면 마이크로서비스로의 전환에 따른 부담을 크게 줄일 수 있습니다.
ServiceNow는 CI/CD 및 기타 DevOps 솔루션처럼 빌드 단계에서 사용되는 도구와 방법론에 연결하여 마이크로서비스를 활용한 서비스 빌드의 관리를 지원할 수 있습니다.
잠재적인 다수의 마이크로서비스와 그 일시적인 특성을 고려하여 ServiceNow는 CMDB와 Service Graph를 자동으로 채워서 관계를 추적하고 서비스 정의를 관리하는 옵션을 제공합니다. 이는 IT Operations Management 서비스의 일부로서, 더 광범위한 클라우드 관리 기능도 제공합니다.
DevOps 방식으로 개발된 코드처럼, 마이크로서비스를 관리할 때 속도는 공동의 목표입니다. 즉 개발자와 프로덕션 시스템 간에 가능한 한 가장 빠른 길을 제공하고자 합니다. 그러나 대규모 또는 통제되는 조직은 강력한 변경 제어를 관리해야 합니다. 그러므로 IT Service Management Professional에는 CI/CD 파이프라인에 연결하고 개발 프로세스 중 정보를 수집하고 이전에 정의한 정책과 함께 활용하여 변경 관리 프로세스를 자동화하는 DevOps Change Velocity 기능이 포함되어 있습니다.
마지막으로 ServiceNow는 ServiceNow 워크플로우의 일부로서 외부 마이크로서비스와 통합을 지원하는 것 외에도 내부 및 외부 애플리케이션에서 마이크로서비스와 같은 방식으로 활용할 수 있는 다양한 기능을 제공합니다.
Now Platform에는 워크플로우를 빠르고 효율적으로 디지털화하고 규모에 맞게 실행할 수 있는 핵심 기능이 포함되어 있습니다.