모던 아키텍처 - 리액티브 선언과 마이크로서비스 아키텍처

모던 아키텍처 - 리엑티브 선언과 마이크로서비스 아키텍처

리엑티브 선언 : 현대의 애플리케이션 아키텍처에 요구되는 것들

소프트웨어 아키텍처는 소프트웨어를 구성하는 요소와 그 구성요소 간의 관계를 정의하는 것이다. 또한 아키텍처링은 시스템 구축을 위한 여러 가지 비 기능 요건 예를 들면 문제 영역이 되는 성능, 가용성, 보안, 유지보수성, 확장성 등을 만족하도록 다양한 해결 방법을 찾는 과정이다. 특히 마이크로서비스 아키텍처는 클라우드라는 가상의 인프라를 활용하여 구조화하는 것이기 때문에 클라우드 인프라의 특징을 고려하여 설계 되야 한다. 그렇다면 이런 클라우드 인프라를 고려했을 때 가장 신경 써야 할 요소는 무엇일까?

현대의 어플리케이션은 도처에 존재한다. 가깝게는 모바일 폰, 데스크 탑 컴퓨터, 많은 생활가전에 내장되어 있는 iot기기등이 있다. 사람들은 이러한 기기의 어플리케이션이 즉각 요청에 응답하고 항상 100% 가동되길 기대한다. 이런 현대 어플리케이션의 기대를 잘 표현한 문서가 있다.

2014년 Jonas Bonér등이 선언한 리액티브 선언문이다. 리액티브 선언에서는 아래와 같이 응답성(Responsive), 탄력성(Resilient), 유연성(Elastic), 메시지 기반(Message Driven) 이라는 4가지 특성을 강조하고 이런 요건을 만족한 시스템을 리액티브 시스템이라고 정의하고 있다.

• 응답성(Responsive): 사용자에게 신뢰성 있는 빠른 응답을 제공하는 것을 의미
• 탄력성(Resilient): 회복력이 있다는 것은 장애가 발생하더라도 , 부분적으로 고장이 나더라도 전체가 고장 나지 않고 빠르게 복구하는 능력을 의미한다.
• 유연성(Elastic) : 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미하며, 시스템의 사용량에 비례하여 자원을 늘리거나 줄이는 능력을 말한다.
• 메시지 기반(Message Driven) : 비동기 메시지 전달을 통해 위치 투명성 느슨한 결합 ,논 블로킹 통신을 지향

4가지 요소는 모두 reactive (반응이 빠른) 시스템을 만들기 위한 요소들이고 각 요소들은 상호 보완적이다. 리액티브 시스템은 장애에 빠른 회복과 사용량에 따른 적절한 자원 증감을 사용자에게 신뢰성 있게 제공해야 하고 메시지 기반 통신을 통해 느슨한 결합과 위치 투명성을 제공해야 한다는 의미다.

여기서 우리는 이러한 니즈를 관통하는 리액티브 시스템이 반드시 갖춰야 할 특성 하나를 발견할 수 있다. 그것은 또 다른 의미의 유연성(flexibility)이다. 신뢰성이 있는 빠른 응답성을 제공하고 부분적 장애가 빠르게 복구되고 또한 수요증가에 탄력적으로 대응하기 위해서는 시스템 자체가 변화,확장에 언제든지 대응할 수 있는 아키텍처 적 유연성을 갖추는 것이 필수다.

아키텍처 적 유연성은 시스템을 구성하는 구성요소간의 관계들이 느슨하게 연계되어 있어 언제든지 대체되거나 추가 확장될 수 있는 특성을 말한다. 특히 클라우드 인프라 자체가 변화무쌍한 비즈니스 환경에 대응할 수 있는 유연성과 확장성이 있기 때문에 그것을 사용하는 어플리케이션 아키텍처도 반드시 이러한 언제나 쉽게 변경될 수 있는 아키텍처 적 유연성을 갖춰야한다.

강 결합에서 느슨한 결합의 아키텍처로 변환

예전에는 아키텍처의 구성요소들을 각 기업이나 특정 벤더 제품에 전적으로 의존하여 구축하거나 커스터마이징이 필요한 부분만 별도로 직접 개발하는 경우가 많았다. 따라서 특정 벤더 솔루션, 프레임웍이 변경될 경우 의존된 어플리케이션의 많은 부분이 변경되어야 할 정도로 강 결합되어 있었다. 이러한 아키텍처는 때론 검증된 유명한 제품 군을 사용한다는 점에서 품질 측면에서의 장점을 반면에 특정 벤더에 의존한다는 측면에서 기술이 락인(Lock-in) 되어 쉽게 변경,확장되지 못한다는 단점을 가지고 있었다.

그러나 최근에 이러한 분위기 바꿔 한 벤더에 의존하거나 직접 구축할 필요가 적어 졌다. 왜냐하면 클라우드 환경하에서 사용되는 오픈 소스나 오픈 소스를 기반으로 한 상용 제품들이 예전 유명한 벤더의 제품 군 만큼이나 품질이 높아지고 다양한 기능을 지원하며 서로 다른 오픈소스제품간에도 충분한 호환성을 제공하기 때문에이다.

이러한 흐름은 아키텍팅(architecting) 활동에도 변화를 가져왔는데 최근의 아키텍처링은 직접 만드는 것이 아니라 필요한 영역에 적절한 솔루션을 선택하고 조합하는 과정으로 바뀌고 있다. 최근 아키텍처 문서들을 보면 아래 그림과 같이 솔루션의 아이콘을 그리는 경향들이 있는데 이것은 아키텍처링이 유연하고 호환성 있는 적절한 솔루션 및 오픈 소스를 선택하는 과정임을 보여주고 있다. 아래 그림을 보면 하부에서 상부까지 각 시스템 레이어에 어떠한 제품을 선택했는지 알아볼 수 있다.

아래 그림은 클라우드 네이티브 지형도(Cloud Native Landscape) 라는 사이트에서 제공하는 정보이다. 클라우드 기반의 애플리케이션을 구축하기 위해 필요한 인프라 및 애플리케이션 영역에 다양한 오픈 소스 제품이나 상용 제품을 표현하고 있다. 특히 매년 매 분기 업데이트되고 있는데 얼마나 많은 영역에 다양한 오픈 소스 및 제품들이 생겨나고 포진돼 있는지 알 수 있다. 따라서 아키텍트는 이런 다양한 기술 영역의 변화 흐름을 이해하고 따라가야 하며 최적의 클라우드 환경을 구성할 적절한 제품 및 솔루션을 선택하여 조합할 필요가 있다.

또한 이러한 모습은 강 결합 위주의 모노리스 아키텍처가 유연하고 느슨하게 결합되는 마이크로서비스 기반 아키텍처로 변환 되고 있음을 의미한다.

마이크로서비스 외부(Outer) 와 내부(Inner) 아키텍처

다음은 실제 구현했던 마이크로서비스 아키텍처 구조도 사례이다. 각각의 구성요소들은 대체하거나 변경할 수 있도록 구성되었다.

아래부터 인프라, 플랫폼, 애플리케이션 영역으로 구분되는데 각 관계를 설명하면 제일 아래에 하드웨어가 되는 인프라가 있고 인프라 위에 애플리케이션을 구동하기 위한 플랫폼이 올라가고 그 플랫폼 위에 애플리케이션인 서비스가 구동된다.

여기서 아래의 인프라 영역과 플랫폼 영역 그리고 애플리케이션 영역에 있는 구성 요소들을 정의하고 그것들의 관계를 정의하는 것을 MSA 외부 아키텍처(Outer Architecture) 라고 한다. 즉, 외부 아키텍처는 마이크로서비스가 운영되는 환경을 정의하는 과정이다. 여기에는 Infra 환경,플랫폼 환경, 그리고 마이크로서비스가 운영되는 어플리케이션 환경이 모두 포함되는데 특히 어플리케이션 측면에서는 관리를 위한 어플리케이션 운영을 위한 어플리케이션도 모두 포함된다. 이 환경을 클라우드 아키텍처가 요구하는 유연성과 확장성을 고려하여 정의해야 하는 것이다.

그리고 실제로 비즈니스가 실행되는 비즈니스 어플리케이션 즉 각각의 마이크로서비스 내부 구조도 정의해야 하는데 이것을 MSA 내부 아키텍처(Inner Architecture) 라고 부른다. 당연히 이 구조도 유연하고 확장성 있게 구현해야 한다.

다음 포스팅에서 외부 아키텍처의 주요 패턴에 대해서는 자세히 설명하도록 하겠다.