[데이터넷] 디지털 전환의 모범 사례로 꼽히는 기업들의 IT 전략을 보면 한 가지 공통점이 있다. MSA를 기반으로 비즈니스 민첩성과 유연성을 빠르게 높이고 있다는 것이다. 이번호에서는 콘웨이의 법칙과 마이크로 서비스, 마틴 파울러의 마이크로서비스 프리미엄과 모놀리스 퍼스트, 가트너의 마이크로서비스 아키텍처 컴포넌트, API 게이트웨이 패턴 등 MSA를 위한 산업계의 주장에 대해 살펴보도록 한다. <편집자>

연재 순서 1. 제임스 루이스와 마틴 파울러의 MSA 2. 산업계의 MSA(이번호) 3. 벤더의 MSA 4. MSA와 레거시 현대화

멜 콘웨이(Mel Conway)는 시스템의 규모가 점점 커지고 함께 작업하는 사람들이 많아질수록 해당 시스템을 독립적으로 동작할 수 있는 서비스로 분해하고, 분해한 시스템을 운영할 별도의 유닛 또는 팀 단위로 조직을 나눠 커뮤니케이션 채널을 통해 소통해야 한다고 강조했다.

하나의 시스템에서 작업하는 사람이 한 자릿수일 경우, 시스템을 독립적으로 동작하는 서비스로 분리하는 것은 팀 구성과 커뮤니케이션에 문제가 되지 않는다. 그러나 시스템의 규모가 커지고 함께 작업하는 사람들이 많아질수록, 시스템의 모듈 경계와 겹치는 팀 경계를 갖는 것이 매우 비효율적이며, 관련된 추가 커뮤니케이션 오버헤드의 양이 급격히 증가한다. 비대해진 모놀리식 애플리케이션을 마이크로서비스로 얼마나 잘 분해하는지 그 관건은 다음과 같다.

• 모듈성이 깨진 모놀리식 애플리케이션을 제한된 컨텍스트(Bounded Context)를 갖는 마이크로서비스로 얼마나 잘 분해하는가?
• 제한된 컨텍스트를 갖는 마이크로서비스를 담당할 조직(유닛 또는 팀)을 얼마나 잘 구성하는가?
• 마이크로서비스 담당 팀은 마이크로서비스를 위한 아키텍처, 프레임워크 및 데이터베이스, 빌드 파이프라인 등을 얼마나 잘 구성하는가?
• 마이크로서비스를 담당하는 팀 간 커뮤니케이션을 효율적으로 하면서 하나의 시스템을 얼마나 잘 유지하는가?

.NET을 사용한 코드 품질 및 도메인에 기반한 소프트웨어 설계자이자 강사인 아르달리스(Ardalis)는 자신의 블로그를 통해 콘웨이의 법칙에 의거해 일부 대형 소프트웨어 회사의 알려진 조직과 커뮤니케이션 문제를 한 장의 그림으로 보여줬다.

이와 함께 아르달리스는 “팀 구성에서 발생하는 문제를 인식하려면 콘웨이의 법칙과 대규모 시스템 설계에 미치는 영향을 이해하는 것이 중요하다. 큰 문제를 분해하고 첨부하는 방법은 여러 팀을 구성하는 방법에 달려 있으며, 팀이 구축 및 제공하는 소프트웨어 모듈과 일치하지 않으면 문제가 발생한다. 이러한 문제를 빨리 인식하고 수정할수록 시스템과 조직의 전반적인 성공 가능성이 높아진다”고 말했다.

마이크로서비스 프리미엄과 모놀리스 퍼스트
마틴 파울러(Martin Fowler)는 2015년 그의 홈페이지를 통해 ‘마이크로서비스 프리미엄’과 ‘모놀리스 퍼스트’를 발표했다. 그는 ‘마이크로서비스 프리미엄’에 대해 다음과 같이 정의했다.

“마이크로서비스 아키텍처 스타일은 지난 한 해 동안 뜨거운 주제였다. 오라일리(O’Reilly) 소프트웨어 아키텍처 컨퍼런스에서는 모든 세션이 마이크로서비스에 대해 이야기하는 것처럼 보였다. 팀이 마이크로서비스를 수용하는 데 너무 열심인 반면, 마이크로서비스가 자체 계정에 복잡성을 초래한다는 사실을 깨닫지 못하고 있다. 이것은 종종 프로젝트를 심각한 문제에 빠뜨리는 프로젝트 비용과 위험에 프리미엄을 추가한다.”

또 마틴 파울러는 “시스템이 너무 복잡해 단일체로 관리할 수 없는 경우가 아니면 마이크로서비스를 고려하지 않아야 한다”며 “대부분의 소프트웨어 시스템은 높은 모듈성을 갖는 단일 모놀리식 애플리케이션으로 구축돼야 하며, 별도의 서비스로 분리하지 말라”고 경고했다.

이는 모놀리식 애플리케이션에 여러 문제가 존재할 수 있지만 마이크로서비스를 도입하는 가장 큰 요인은 순전히 모놀리식 애플리케이션의 규모이며, 수정하고 배포하기에 너무 큰 단일체를 갖고 있다고 느끼기 시작할 때 비로소 마이크로서비스로 분해하는 것을 고려해야 한다는 의미다. [그림 2]는 이러한 프로세스를 나타내준다.

또 ‘모놀리스 퍼스트’ 글에서는 처음부터 마이크로서비스로 시작하지 않고, 반드시 모놀리스 애플리케이션부터 개발하라면서, 다음을 강조한다.

• 성공적인 마이크로서비스의 거의 모든 사례는 너무 커져 부서진 단일체에서 시작됐다.
• 처음부터 마이크로서비스 시스템으로 구축하는 거의 모든 경우는 심각한 문제로 끝났다.
• 애플리케이션이 가치가 있을 만큼 충분히 커질 것이라고 확신하더라도 마이크로서비스로 새 프로젝트를 시작해서는 안 된다.
• 소프트웨어에 대한 아이디어가 유용한지 알아내는 가장 좋은 방법은 먼저 단순한 버전을 만들고 얼마나 잘 작동하는지 보는 것이다. 아무리 뛰어난 개발자나 아키텍트라 하더라도 처음부터 서비스 간의 경계를 바로 잡는 것은 크게 어렵다.
• 마이크로서비스는 서비스 간에 명확하고 안정적인 경계가 있는 경우에만 제대로 작동한다. 모놀리스 애플리케이션을 먼저 구축한다면 서비스의 올바른 경계가 무엇인지 파악하는 것이 쉽다.
• API 경계와 데이터 저장 방식 모두에서 소프트웨어 내의 모듈성에 주의하면서 모놀리스를 신중하게 설계해야 한다. 즉 모놀리스로 시작해 작고 경계가 명확한 서비스부터 마이크로서비스로 점차 분리하는 것이다.
• 모놀리스 애플리케이션이 비대해져 마이크로서비스로 분해하기 시작하면, 새로운 서비스는 마이크로서비스로 개발하는 것이 좋다.

가트너 MSA 컴포넌트
가트너가 2018년도에 발표한 ‘MSA 컴포넌트’는 MSA의 디팩토(de facto) 표준으로 자리매김하고 있다. 대부분의 MSA 프로젝트 혹은 벤더 제공 솔루션은 가트너 MSA 컴포넌트 구성도를 잘 따르고 있다.

가트너의 MSA 컴포넌트는 내부와 외부를 구분해 크게 두 가지 아키텍처를 정의한다.

• 내부 아키텍처: 내부 아키텍처는 마이크로서비스 시스템 및 데이터베이스 구성을 어떻게 하고, 마이크로서비스를 어떻게 API화할 지 등에 대한 아키텍처이며, 일반적으로 애플리케이션 현대화를 위한 아키텍처라 할 수 있다.
• 외부 아키텍처: 외부 아키텍처는 외부에서 인입되는 API 요청을 어떻게 서비스할 지를 정의하는 아키텍처로, 가트너는 MSA의 외부 아키텍처에 대해 6개 컴포넌트를 정의하고 있다.

- API 게이트웨이: API 게이트웨이는 외부의 클라이언트 앱과 마이크로서비스 API 간의 SSL/TLS 통신, 인증 및 인가, 서비스 디스커버리, 라우팅 및 로드밸런싱, 덤프(Dump)파이프 등 중계 역할을 담당한다.

- 서비스 메시: 서비스 메시는 마이크로서비스에 대한 환경설정 관리, 서비스 검색, 서비스 라우팅 및 로드밸런싱, 트래픽 관리 및 보안 등을 담당한다.

- 컨테이너 관리: 마이크로서비스를 실행하기 위한 컨테이너 스케줄링을 해주는 컨테이너 관리 환경으로, 2017년 말부터 쿠버네티스(Kubernetes)가 디팩토 표준으로 자리매김했다. 아마존, 구글, 애저 등이 컨테이너 관리 환경을 쿠버네티스를 지원하며, IBM이나 시스코와 같은 온프레미스 솔루션 업체들도 쿠버네티스를 지원하고 있다.

- 지원 서비스: 마이크로서비스를 수행하는데 필요한 데이터베이스, 캐시, 메시지 큐(Message Queue), 메일 시스템 등 모든 지원 서비스를 가리킨다.

- 원격측정: 마이크로서비스는 클라우드 네이티브 애플리케이션으로서 기본적으로 분산 환경에서 실행되므로, 분산 환경에서의 마이크로서비스의 실행 상태를 모니터링하고 장애에 대응하기 위해 거래추적 등 원격측정 기능이 반드시 제공돼야 한다.

- CI/CD 자동화: CI/CD 자동화 프로세스는 마이크로서비스 애플리케이션의 개발 및 배포 단계 작업을 자동화하는 것이다. 요즘은 애플리케이션의 개발/배포 주기가 짧아지다 보니, 지속적인 통합, 지속적인 전달, 지속적인 배포 등 프로세스를 자동화하는 것이 무엇보다 중요하다.

API 게이트웨이 패턴
마이크로서비스의 가장 큰 목표는 모듈성이 큰 단일체로 결합되고 배포되는 모놀리식 애플리케이션과 달리 느슨하게 결합된 마이크로서비스/모듈로 애플리케이션을 충분히 분해/분리하는 것이다. 이때 클라이언트가 각 마이크로서비스와 직접 통신 한다고 할 때 다음과 같은 문제를 고려해야 한다.

• 마이크로서비스가 세분화된 API를 클라이언트에 노출하는 경우 클라이언트는 각 마이크로서비스를 직접 요청해야 하며, 클라이언트가 하나의 페이지를 구성하기 위해 마이크로서비스에서 제공하는 API를 여러 번 호출해야 할 수도 있다.
• 마이크로서비스마다 서로 다른 통신 프로토콜(예: HTTP/REST, TXP/IP, gRpc, thrift, AMQP, SAP 등)을 사용할 경우, 클라이언트가 이러한 모든 프로토콜을 지원해야 한다.
• 모든 마이크로서비스에서 공통 기능(예: 인증/인가, 로깅, 라우팅/로드밸런싱, 거래추적, 체이닝 거래 등)을 각각 구현할 수 없다.
• 새로운 마이크로서비스가 도입되거나 기존 마이크로서비스가 업데이트되면, 클라이언트를 직접 변경하고 배포하는 것이 쉽지 않다.
• 애플리케이션에 여러 마이크로서비스가 있는 경우 클라이언트 앱에서 많은 엔드포인트를 처리하는 것이 큰 문제일 수 있다. 클라이언트 앱은 해당 내부 엔드포인트에 결합되므로 나중에 마이크로서비스가 개선되면 클라이언트 앱에 큰 영향을 줄 수 있다.

클라이언트와 마이크로서비스가 직접 연결될 경우 발생할 수 있는 여러 문제로 인해 클라이언트와 마이크로서비스 간에 API 게이트웨이 계층을 포함하면, 마이크로서비스 기반 애플리케이션을 작성하는 것이 편리할 수 있다. API 게이트웨이 패턴의 구성도를 살펴보면 [그림 5]와 같다.

‘역방향 프록시 또는 게이트웨이 라우팅(Reverse Proxy or Gateway Routing)’ 게이트웨이 패턴은 외부 클라이언트의 API 요청을 내부 마이크로서비스의 API 엔드포인트로 리디렉션 또는 라우팅하는 역방향 프록시를 제공한다. 게이트웨이는 클라이언트 앱에 대한 단일 엔드포인트 또는 URL을 제공한 후 내부적으로 요청을 내부 마이크로서비스로 매핑한다.

이 라우팅 기능은 마이크로서비스와 클라이언트 앱을 느슨한 커플링이 되도록 분리할 뿐만 아니라 모놀리식 API와 클라이언트 앱 사이에 API 게이트웨이를 배치해 모놀리식 API를 현대화하기도 한다. 그런 다음 여러 마이크로서비스로 분할될 때까지 레거시 모놀리식 API를 계속 사용하면서 새 API를 새 마이크로서비스로 추가할 수 있다.

API 게이트웨이 때문에 클라이언트 앱은 사용 중인 API가 내부 마이크로서비스 또는 모놀리식 API로 구현되는지를 알아야 할 필요가 없게 된다. 더 중요한 것은 모놀리식 API를 마이크로서비스로 개선하고 리팩토링하더라도, 클라이언트 앱은 URI 변경 등을 전혀 하지 않아도 된다.

‘요청 집계(Request Aggregation)’ 게이트웨이 패턴은 여러 내부 마이크로서비스를 대상으로 하는 여러 클라이언트 요청(대개 HTTP 요청)을 단일 클라이언트 요청으로 집계할 수 있다. 이 패턴은 특히 클라이언트 페이지/화면에 여러 마이크로서비스의 정보가 필요할 때 편리하게 사용할 수 있다. 이 방법을 사용하면 클라이언트 앱은 여러 요청을 내부 마이크로서비스에 디스패치한 다음, 결과를 집계하고 모든 것을 다시 클라이언트 앱에 보내는 API 게이트웨이에 단일 요청을 보낸다.

‘교차 편집 문제 또는 게이트웨이 오프로딩(Cross-Edit Issues or Gateway Offloading)’ 게이트웨이 패턴은 개별 마이크로서비스에서 게이트웨이로 기능을 오프로드하면 교차 편집 문제를 한 계층으로 통합해 각 마이크로서비스의 구현을 간소화할 수 있다.

- 인증 및 권한 부여
- 서비스 검색 통합
- 응답 캐싱
- 정책, 회로 차단기 및 QoS 다시 시도
- 속도 제한
- 부하 분산
- 로깅, 추적, 상관관계
- 헤더, 쿼리 문자열 및 청구 변환
- IP 허용 목록에 추가

이처럼 가트너가 발표한 ‘MSA 컴포넌트’는 MSA의 디팩토 표준으로 자리매김하고 있으며, 대부분의 MSA 프로젝트를 수행하거나 벤더에서 제공하는 솔루션에서 기본적으로 차용하고 있다. 이에 다음호에서는 가트너의 ‘MSA 컴포넌트’에 기반한 솔루션들을 중점적으로 살펴보겠다.