Microservice Architecture에 대한 이야기 - Integration

Microservices는 요즘 개발자, 엔지니어 사이에서 가장 유행하는 단어 중 하나이다. 나는 설계, 개발을 할 때, agile을 기반한 좀 더 flexible하고 선택지가 많은 아키텍쳐 개념을 찾아 다녔다. 그래서 SOA, ESB를 거쳐 그들의 장점을 모방한 MSA개념을 살펴보게 되었다.

과거에, 복잡해진 업무 프로세스들의 연결을 위해 '스파게티'같은 강하게 연결된 아키텍쳐가 구성되었다. 그 연결하의 업무 로직의 반복을 피하기 위해, 공통 모듈을 만들고 Library를 통합하였다. 그 변화 과정에서 나온 방법이 바로 Service-Oriented Architecture(SOA)이다. 서비스를 모듈화하여 다른 시스템과 공유하고, 통신 방식, 데이터 라우팅을 구성한다. ESB는 그것의 구현 중 하나이다.

이런 종류의 많은 통합 프로젝트 중 SOA로의 변화에 대한 예를 들어보겠다. 하나의 통합 서버에 구축된 Massive Application을 변화시키기 위해 시스템 간의 복잡한 상호 연결 로직을 ESB로 제거하고 팀 간 (Application / Service 리더를 통해) 데이터 모델을 조정하여 웹 서비스에 대한 WSDL를 설정하고 호출간에 필요할 경우 BPEL 프로세스를 추가한다. 이렇게 구성된 ESB 외부에서는 모든 것이 매우 잘 엮여져있는 그물처럼 조직적으로 보인다. 하지만 ESB라는 "상자"를 들어 올리면 많은 것들이 최악의 얽힌 스파게티 코드가 숨겨져 있다는 것을 알게 된다. 그리고 그 커다란 카오스의 집단은 이 모델을 적용한 기업의 이슈를 가져 오는 병목 현상이된다.

그들은 이 속에서 데이터 모델 정의, 프로세스 흐름, 상호 연결 프로토콜 및 데이터 형식 변환 등과 같이 너무 많은 작업을 시도 하는 Smart Pipe라는 개념을 가진 거대한 Monolithic 아키텍쳐 괴물을 파괴해야만 했다. 개발자입장에서 보자면. 서비스 간의 관계는 지저분하고 Monolithic의 특성으로 인해 개발주기가 길고 번거로웠다.
이 문제점을 해결하기 위해 독립적으로 배포 할 수있는 Microservice가 등장했다. Microservice는 Monolithic Arichitecture보다 더 민첩한 '통합'을 가져와서, 개발자에게 이점을 주었다.

MSA환경에서도 '쓸모있는 아키텍쳐'가 되려면 여전히 기존 환경과의 연결 또는 통합이 반드시 필요하다. 하지만 과거의 것과 '통합'을 이룰 때 피해야 할 사항들이 있다.

- 더 이상, Monolithic식의 '통'개발을 통해 개발 주기를 단축시키면 안된다.
- 시스템 통합 코드에서 복잡한 비즈니스 프로세스를 지양해야한다.
- 데이터 모델은 통합(Integration) 레이어에 정의되어선 안된다. 이는 각 팀간의 논쟁 사항이 된다.
- 확장성을 극대화한다는 목적으로 State를 통합(Integration) 계층에 유지하면 안된다.
- 서비스간 복잡한 연결 관계를 제외해야 한다.

하지만 과거의  “integration” 방법에도 착안해야할 좋은 사항들도 있다.

- 조직화, 시각화 된 서비스 상호간의 연결
- Aggregation, Separation 및 Data Normalization과 같은 Pre-defined Pattern
- Event-based 정책 및 Integration 시스템을 위한 느슨한 연결 방식

그래서 Microservice를 위한 계층화 된 아키텍처를 생각해 냈다. 최신 Integration / Application 개발의 새로운 통합 아키텍처에서 달성하고 싶었던 주요 목표는 유연성이다. 확장이 가능한 구조이며, 개발자가 쉽게 아키텍처를 변경할 수 있는 것이 그 목표였다.

이 아키텍처를 구현하기 위해 먼저 새로운 Agile Integration에서 Integration 코드 자체를 비즈니스 업무에 있어 '의미가 있는' 여러 가지 작은 서비스로 분류해야한다. 그 작은 서비스들은 독립적으로 '쓸모가 있는' 구성이 되어야 한다. 그런 다음 CI/CD를 통합 코드에 적용 하여 Monolithic ESB 구조를 피한다.

이 Microservice Architecture에 대해 4개의 독립된 Layer를 정의하여 각 Layer가 개별적으로 쉽게 변할 수 있다.

• Gateway Layer :  버전 관리와 같은 간단한 게이트웨이 라우팅 기능을 제공하여 다른 플랫폼의 장치를 처리한다.

이 계층은 다이어그램에 두 가지 형태의 Gateway가 있다. 파란색 다이어그램 및 초록색이 그것이다.

그것은 관점 분리에 관한 것 이다. 이 계층은 외부 API 사용에 필요한 것을 생성하고 처리하는 데 필요한 모든 것을 포함한다. 두 가지로 구분되는 관점은 다음과 같다. 

APIs
    Traffic throttle 처리에 필요한 모든 정책
    API 보안
    올바른 버전으로의 라우팅

Combine
    데이터 정규화에 대한 유지
    클라이언트 형태에 따른 output type의 변형
    Application Domain간의 연결

• Composite layer: 다수의 Microservice 구성을 처리하는 중요한 중간 Layer이다. 이 계층에서 데이터 처리에 대한 복잡한 라우팅을 수행하고 데이터를 split/aggregate하며 이벤트를 트리거하거나 단순히 전달함으로써 분할 / 집계 된 결과를 다른 마이크로 서비스에 적용한다. 이 계층은 Client로 부터 Microservice의 복잡성을 숨긴다.

이 계층은 아마 대부분의 MSA 통합의 핵심을 구현하는 Layer이다.

MSA 구현

• Microservice에서 사용할 수있는 API를 호출하고 필요에 따라 데이터를 변환하며 해당 내용을 기반으로 담당 Microservice로 데이터를 라우팅한다.

Event Trigger

• 각 서비스간 느슨한 연결을 통해 Event를 유지해야 한다. 비동기 특성으로 인해 최상의 성능을 보장하는 형태를 구현한다. 여기서 이벤트 버스는 Message Broker 일 필요는 없지만 모든 형태의 버스가 될 수 있다. 

Caching

• REST Architecture는 Caching이 필요하다. 복합 Layer는 비즈니스 연관성이 떨어지므로 캐싱 메커니즘을 적용하여 Stateless를 유지해야 한다.

전체 구성 서비스에 Application Domain도 포함되어야한다. Basic Layer에 이것이 포함된다.

• Basic Layer :  시스템의 기본 구성 요소를 포함한다. 데이터 검색 또는 비즈니스 로직 처리를 처리한다. 각각은 모듈은 모두 독립적이어야 한다.

Bounded Context 라는 개념에서 논리적으로 결합된 Microservice 그룹을 Application Domain 이라고한다. 각 도메인이 동일한 데이터 모델을 공유하는 개별 Entity를 나타내는 경우 코드 변환이 쉬워진다.

• Anti-corruption layer - 이 계층은 Legacy Application 또는 Microservice가 규칙에 따라 작동하는 인터페이스를 처리한다.

이 글은 Redhat Architect인 Christina Lin의 포스트를 기반으로 작성되었다.