02 디지털 혁신의 엔진-마이크로서비스 유형과 특징

│Senior Program Manager 김영욱

마이크로서비스란

디지털 혁신은 민첩성(agility)을 향한 경쟁이라고 할 수 있다. 조직이 사용자 요구에 앞서 조정하고 혁신하는 속도가 빠를수록 시장 리더가 될 가능성이 높아진다.

마이크로서비스 아키텍처는 기업이 새로운 비즈니스 요구에 신속하게 대응할 수 있는 민첩성과 혁신을 제공하는 기본 디지털 플랫폼이다. 가장 앞선 소프트웨어 설계 기술로 평가되는 마이크로서비스는 이제 산업 전반에 걸쳐 크고 복잡한 인프라를 해체하는 방법으로 널리 채택되었다.

기존의 응용 프로그램은 부피가 큰 독립 일체형이었다면, 마이크로서비스 기반 애플리케이션은 새로운 애플리케이션과 서비스를 더 빠르게 시작하고 실행하기 위해 함께 구성할 수 있는 컴포넌트형의 여러 빌딩 블록으로 구성된다. 이러한 유형의 아키텍처는 수천 개의 개별 구성 요소를 포함할 수 있는 확장성을 가진다.

그림 1 기업 내 마이크로서비스 사용 예 (출처: IBM)

IBM이 발표한 기업 내 마이크로서비스 현황 리포트에 따르면¹⁾ 마이크로서비스는 전 산업 도메인에 걸쳐 사용되고 있으며 많은 이점을 제공한다. 가장 대표적인 사례는 데이터 분석이나 데이터베이스 이용, 고객관계관리 솔루션인 CRM에서 이용 비율이 높다.

이런 많은 이점을 가진 마이크로서비스를 개발하는 아키텍처에는 단일 방법만이 있는 것은 아니다. 어떤 유형도 획일적일 수 없으며 각각 고유한 이점과 전제 조건이 있다. 기업은 필요에 가장 적합한 유형을 선택하거나 생태계의 고유한 서비스 및 구조를 기반으로 그 유형을 혼합할 수 있다. 가장 일반적인 유형 다섯 가지에 대해서 알아보자.

그림 2 마이크로서비스 채택을 통한 주요 이점(출처: IBM)

이런 많은 이점을 가진 마이크로서비스를 개발하는 아키텍처에는 단일 방법만이 있는 것은 아니다. 어떤 유형도 획일적일 수 없으며 각각 고유한 이점과 전제 조건이 있다. 기업은 필요에 가장 적합한 유형을 선택하거나 생태계의 고유한 서비스 및 구조를 기반으로 그 유형을 혼합할 수 있다. 가장 일반적인 유형 다섯 가지에 대해서 알아보자.

유형 1- 세분화된 SOA (Fine-Grained SOA)

Fine-Grained라는 이름대로 작은 덩어리로 상세하게 나뉜 서비스 지향 아키텍처(SOA: Service Oriented Architecture)이고 가장 일반적인 접근 방식이다. 이 유형은 SOA와 동일한 원칙을 적용하지만 인프라를 더 작고 세분화된 조각으로 나눔으로써 한 덩어리 일체형에서 발생하는 일반적인 문제를 줄일 수 있다. 이 방법은 각 서비스가 외부 시스템 연결을 제공하는 서비스 지향 통합의 확장된 형태를 적용한다. 하지만 이 접근법은 외부 데이터 저장소와의 높은 의존성을 만들어 변경 속도가 늦어지고, 애플리케이션의 상태를 반영해야 하는 시스템에 집중도가 증가한다. 

세분화된 SOA는 마이크로서비스를 시작할 때 일반적으로 선택하는 유형이며 기업은 경험이 늘면서 향후에는 더 고급 유형을 선택 적용하게 된다.

특징

• 소규모에서는 잘 동작하지만, 대규모에서는 비효율적임

• 기능 중심이 아닌 외부 시스템과 마이크로서비스의 통합 중심 접근법임

• 소규모 서비스에 중점을 둠

• 비효율적인 프로세스 간 통신으로 인해 변경 속도가 느림

• 상태 관리가 제대로 안 되어 데이터 일관성이 낮음

• 기존 관리 시스템은 증가하는 관리 대상 서비스를 처리할 수 없음

유형 2- 세분화된 SOA상에서 API 계층화

세분화된 SOA 유형의 다음 단계는 아래 그림의 예와 같이 그 위에 API를 계층화하는 것이다. 이 유형은 데이터와 애플리케이션을 API를 통해 연결하자는 API 주도 연결(API-led connectivity)의 개념과 동일하다. 시스템 API는 애플리케이션을 노출하고 프로세스 API는 이를 조정하며 경험 API는 최종 사용자 경험을 제공한다.

마이크로서비스 아키텍처는 각 서비스의 목적을 분류하고 시각화하기 어려울 때 그것을 합리화하기 어렵다. 이 유형은 마이크로서비스를 목적(시스템, 프로세스 및 경험) 별로 그룹화한 계층으로 구성하여 구조를 생성하고 아키텍처를 보다 쉽게 관리할 수 있다. 실제 상황에선 훨씬 더 많은 구성 요소를 이런 유형으로 관리한다는 점을 감안할 때 일반 기업이 모든 것을 스스로 처리하기에는 너무 복잡한 경우가 많다. 이러한 복잡성으로 인해 API 게이트웨이 또는 서비스 메시를 채택하여 각 구성 요소가 제대로 동작하고 더 큰 생태계에 통합되며 보안을 유지하도록 하는 것이 일반적인 사례가 된다.

그림 3 상세화된 SOA 상에서 계층화된 API 방식의 마이크로서비스 구현 예

특징

• 소규모에서는 잘 동작하지만, 대규모에서는 비효율적임

• 아키텍처 구조화 과정 중에, 서비스 간 유연성을 향상할 수 있음

• 각 레이어를 통해 호출 수가 증가함

• 기존 관리 도구는 서비스 시각화를 할 수 없어 더 이상 동작하지 않음

• 최종 애플리케이션 데이터 저장소의 일관성이 개선됨

• 아키텍처 내의 모든 요소를 관리하려면 서비스 메시 또는 API 게이트웨이와 같은 추가 기술이 필요함

• 외부 시스템에 의존하는 각각의 마이크로서비스는 반응 속도가 느림

• 상태 관리 기능이 부족함

• 높은 수준의 재사용이 가능함

• 구조화된 아키텍처 접근 방식을 통한 시스템 통합 로드맵이 가능함

유형 3- 계층화된 API 상에서 메시지 기반 상태 관리

앞의 두 유형에는 상태 관리 기능이 없었다. 즉, 상태 관리가 안 된다는 것은 그 마이크로서비스의 데이터 무결성이 부족하다는 것이다. 계층화된 API 상에서 메시지를 통하여 상태를 관리하는 것은 마이크로서비스 또는 데이터 저장소 간에 주요 비즈니스 데이터의 상태를 복제하여 데이터 무결성을 보장하는 것이다. 

그림 4 계층화된 API 상에서 메시지 기반 상태관리 방식의 마이크로서비스 구현 예

이를 통해 시스템은 이벤트를 모으고, 메시지 대기열을 사용하여 일관성 있게 처리할 수 있으므로 상태를 다른 레이어로 비동기적으로 보내거나 다른 마이크로서비스를 통해 얻을 수 있다. 하지만, 구성 요소를 작게 분리하면 각 마이크로서비스의 구현과 동작이 모호해진다. 마이크로서비스로의 변환을 막 시작하고 상태 저장 애플리케이션 관리에 관심이 있는 조직은 이 유형을 자주 사용하며 사용함에 따라 그 성숙도가 발전한다.

특징

• 상태 관리 기능의 추가로 복잡성이 증가함

• 표준 유형이 없기 때문에 구현이 일관되지 않고 재사용하기 어려울 수 있음

• 장애로 인해 데이터 충돌이 발생하거나 상태가 재구축되는 경우 해결 방법이 부족함

• 비동기 프로세스 간 통신으로 효율성이 확보됨

• 데이터 일관성 및 상태관리는 예측할 수 없는 동작과 주어진 메시지의 잠재적인 부작용에 의해 영향을 받음.

• 기본 수준의 대기열이지만 대기열을 통해 전달되는 항목에 대한 표준이 필요함

• 대규모 수준에서는 잘 작동하지만, 운영상 예측할 수 없는 상황이 발생함

유형 4- 계층화된 API 상에서 이벤트 주도형 상태 관리

그림 5 계층화된 API 상에서 이벤트 주도형 상태관리 방식의 마이크로서비스 구현 예

REST API 및 동기 통신이 제공하지 않는 실시간 데이터 업데이트를 위해 이벤트 기반 패턴을 활용하는 접근 방식이다. 이는 사기 탐지, 워크플로 알림, 뉴스 피드 및 주식 업데이트와 같은 사용 사례에 매우 중요하다. 이벤트 기반 시스템은 메시지 지향 시스템과 유사한 대기열을 사용하지만 대기열을 통해 전달되는 것, 특히 이벤트의 디자인 및 동작에 적용되는 표준이 매우 엄격하다.

이벤트라는 것은 상태를 설명하고, 시간과 관련된 작업이다. 이 이벤트를 통해 수신하는 모든 서비스는 이벤트를 순서대로 재생하면 구체화된 상태 보기를 재구성할 수 있다. 마이크로서비스는 종종 비동기식 인터랙션일 때 확장 및 복구에 더 뛰어나지만, RESTful에 비하면 여전히 관리가 어렵다. 두 가지 장점을 모두 활용하려면 마이크로서비스(RESTful 및 이벤트 주도)를 위한 전체 라이프 사이클 관리 기능을 제공하는 솔루션이 필요하다.

특징

• 상태 관리 기능의 추가로 복잡성이 증가함

• 표준 유형이 없으므로 구현이 일관되지 않음

• 장애로 인해 데이터 충돌이 발생하거나 상태가 재구축되는 경우 해결 방법이 부족함

• 비동기 프로세스 간 통신으로 효율성이 확보됨

• 예측할 수 있는 행동을 선호하므로 설계의 유연성이 상실됨

• 데이터 일관성 및 상태관리는 특정 일관성 모델을 통해 개선됨

• 이벤트가 명령과 혼재될 때 문제가 발생할 수 있음

• 합리적인 운영으로 모델의 효과적인 확장이 가능함

• 일관되게 적용할 때 강한 시스템 결합 효과를 볼 수 있지만, 그 효과는 시간이 지남에 따라 떨어지는 경향이 있음.

유형 5- 계층화된 API에 상태를 격리하기

이벤트 기반 마이크로서비스의 또 다른 대안적 접근법은 개별 마이크로서비스에 지속성을 추가하는 것이다. 이 유형은 상호 교환이 아닌, 쿼리 시 일관성을 구현하고 마이크로서비스가 자체 상태를 포함하도록 각 마이크로서비스의 상태를 격리하여 구현한다.

그림 6 계층화된 API에 상태를 격리하는 방식의 마이크로서비스 구현 예

이 유형은 각 마이크로서비스가 내부 데이터 저장소를 가진 단일 정보 소스가 된다. 그 내부 데이터 저장소는 이벤트 로그이든 엔터프라이즈 자산이든 상관없이 외부 저장소와 지속적으로 싱크 업이 된다. 단일 정보 소스 유형은 복잡한 문제를 가질 수 있는 경향이 있지만 외부 저장소를 사용하면 이를 단순화할 수 있다.

이 유형은 마이크로서비스를 세분화하는 것을 선호한다. 예를 들어 고객의 상태를 분리하는 것은 어렵지만 고객의 이메일 주소 상태를 분리하는 것은 어렵지 않다.

특징

• 표준화된 특성으로 인해 아키텍처 적용이 쉬움

• 데이터가 복사되지 않거나 다른 액세스 모드가 있는지 확인하기 위해 거버넌스가 필요함

• ERP와 같은 기존 자산 작업은 적용하기 어려울 수 있음

• 재사용은 우선순위가 아님.

• 비동기로 인해 프로세스 간 효율적인 커뮤니케이션이 가능함

• 확장성은 데이터 저장소 확장을 먼저 해결해야 가능함

• 데이터 모델을 독립적인 조각으로 분할하여 확장성을 갖기는 힘듦

마무리

거버넌스, 보안 및 검색 가능성(discoverability)은 마이크로서비스를 사용 중이거나 사용하려는 조직에 있어 중요한 과제다. 그런 면에서 마이크로서비스를 사용하면 다음과 같은 명백한 이점이 있다.

• 민첩성 (Agility)
  마이크로서비스 아키텍처는 모든 변화에 대해 높은 보안과 유연성을 요구하는 복잡한 시스템을 지원하고, 여러 시스템을 쉽게 통합할 수 있다.

• 장애 허용치(Fault Tolerance) 개선
  앱은 컨테이너화된 시스템을 통해 오류로부터 스스로를 더 잘 보호할 수 있다. 이전 단일 아키텍처 기반 애플리케이션에 비해 훨씬 쉽게 수행할 수 있고, 마이크로서비스 환경이 자율적으로 실행되기 때문에 일련의 장애, 속도 저하 및 고장에 직면할 가능성은 적다.

• 빠른 배포
  조금씩 구축하고 배포하기 때문에 더 빨리 개발하고 업그레이드할 수 있다. 이렇게 하면 시스템의 다른 부분에도 부정적인 영향을 미치지 않는다.

• 비용 효율적인 서비스 제공
  마이크로서비스 아키텍처는 필요에 따라 비용이 발생한다. 서비스에 필요한 공간과 성능, 특정 기능이나 요구사항에 맞출 수 있다. 이는 사용자에게 앱에 얼마나 많은 비용을 지출할 것인지에 대한 자율성과 통제력을 제공한다.

• 정기적이고 편리한 업데이트
  개발자가 앱의 한 부분에서 작업할 때 마이크로서비스 앱을 쉽게 업데이트할 수 있다. 개발자는 하나의 마이크로서비스에서 작업하고 관련 업데이트를 한 다음 릴리스하기 때문에 전체 시스템을 다시 만들거나 재설계할 필요가 없다.

• 테스트 용이성
  마이크로서비스의 가장 큰 이점은 테스트의 용이성이다. 개발자는 릴리즈 하기 전에 시스템의 작은 부분을 쉽게 테스트할 수 있다.

전 세계 주요 기업뿐만 아니라 국내 많은 기업이 마이크로서비스 아키텍처를 채택하고 있다. 글로벌 마이크로서비스 트렌드 조사에 의하면²⁾ 91%의 기업이 이미 마이크로서비스를 기업 내 업무 프로세스에서 사용한다고 응답하고 있다. 이 수치는 시간이 지남에 따라 더욱 올라갈 것이고, 마이크로서비스는 기업이나 조직이 소프트웨어 시스템을 구성하는 최우선 요건이 될 것이다. 기업과 사용자에게 제공하는 유연성이 그러한 전환을 하는 이유이다. 하지만, 마이크로서비스를 도입하는 것과 그것의 이점을 충분히 활용하는 성숙한 아키텍처를 갖는 것은 다른 이야기다. 비즈니스 전문가와 기술 전문가가 함께 구성된 퓨전 팀이 현재의 업무 프로세스와 비즈니스 역량을 심도 있게 고민하고 분석한 후에 상황에 맞는 최선의 아키텍처가 구성될 수 있다.

참고문헌

1) IBM. Microservices in the enterprise, 2021

2) Dimensional Research, GLOBAL MICROSERVICES TRENDS, April 2018