마이크로서비스 : 기반 서비스의 종류 : 첫번쨰 이야기

마이크로 서비스의 역사

우선 기반 서비스가 어떠한 과정을 거쳐서 발전되었는지 마이크로서비스 발전 과정을 살펴보도록 하겠습니다. 그때부터 소프트웨어 업계가 거대한 계획이나 프로세스 대신 빠른 실패와 피드백을 기반으로 하는 실용적인 실천 방법을 선호하게 되었습니다.

우선 AWS가 IaaS 개념으로 2006년도에 EC2를 발표했고 넷플릭스가 스트리밍 사업을 시작하고 아마존의 클라우드 서비스인 AWS로 시스템을 이동하기 시작했습니다. 그러다가 데이터베이스 스토리지가 한 번 크게 망가져서 서비스가 큰 장애를 겪게 됩니다.

이걸 계기로 넷플릭스는 큰 덩어리의 모노리식 시스템에서 마이크로서비스 기반의 시스템으로의 전환을 시작했다고 합니다. 그런데 넷플릭스는 그런 마이크로서비스 기반 시스템을 만들고 운영하면서 여러 어려움을 느끼게 됩니다. 그래서 그걸 해결하기 위해 여러 서비스 및 도구들을 개발하게 됩니다. 나중에 그걸 오픈 소스로 공개하게 됩니다. 그것이 넷플릭스 OSS입니다.

마이크로서비스 로드 밸런싱을 위한 리본이나 모니터링을 위한 히스트릭스, 서비스 등록을 위한 유레카 등이 바로 그것입니다. 또 하나의 오픈 소스 공유 흐름이 됩니다. 이런 오픈 소스 공유로 인해 업계가 같이 발전하게 됩니다. 그리고 그 이후에 2013년이 돼서 가장 유명한 컨테이너 기술인 도커가 세상이 등장하게 됩니다.

또한 이쯤에 스프링 진영에서는 마이크로서비스를 쉽게 개발할 수 있는 스프링 부트가 나오고 최근에는 도커 컨테이너 오케스트레이션 기술인 구글의 쿠버네티스가 등장하게 되었습니다. 

AWS의 클라우드 환경, 도커 컨테이너, 넷플릭스가 공유한 오픈 소스들, 스프링이라는 프레임워크, 구글의 쿠버네티스 환경, 이런 것이 마이크로서비스 생태계의 발전을 계속 중단 없이 이끌고 왔다는 것을 살펴볼 수 있었습니다.

 

 

개발 프레임워크

아우터 아키텍처의 애플리케이션 영역을 구성하는 도구 및 기반 서비스에 대해 하나하나 살펴보도록 하겠습니다. 우선 애플리케이션을 만들기 위한 기틀인 개발 프레임워크입니다. 넷플릭스 OSS는 넷플릭스가 자신들이 마이크로서비스를 개발 운영해 보면서 생긴 노하우를 다른 사람들도 쉽게 사용할 수 있도록 공유한 것입니다.

이런 공유가 마이크로서비스 생태계에 많은 도움이 되었습니다. 특히 이러한 요소들은 마이크로서비스 운영 중 생긴 어려움을 해결한 전형적인 마이크로서비스 애플리케이션 패턴들이 됩니다. API 게이트웨이라든지 서비스 디스커버리, 모니터링, 트레이싱 등의 요소들이 있습니다.

넷플릭스 소스 공개로 패턴으로 정착되고 나중에 이런 영역의 문제들을 해결하기 위해 다른 여러 오픈 소스들이 생겨나게 됩니다. 우선 이 공유된 넷플릭스 OSS가 가장 유명하기 때문에 이를 기반으로 살펴보도록 하겠습니다.

 

 

Spring Cloud

넷플릭스 OSS를 더 쉽게 쓸 수 있도록 스프링 진영의 피보탈사가 기존 스프링 부트 프레임워크 상에서 잘 돌아갈 수 있게 래핑한 도구를 발표했습니다. 그것이 스프링 클라우드입니다. 이 스프링 부트와 스프링 클라우드는 마이크로서비스를 개발하기 위한 가장 유명한 기본 프레임워크가 되었습니다. 이 스프링 부트 프레임워크와 스프링 클라우드를 가지고 MSA 애플리케이션을 쉽게 구축할 수 있습니다.

스프링 클라우드는 스프링을 개발하고 있는 피보탈에서 만들고 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈 소스를 스프링 부트 기반으로 사용하기 쉽도록 통합한 것입니다.

 

 

기반 서비스

이런 서비스들이 마이크로서비스를 운영하는 데 기반이 되기 때문에 보통 기반 서비스라고 부릅니다. 전체 도식화된 그림을 보면 다음과 같이 DevOps 환경과 기반 서비스들이 존재하고 그 기반 위에 비즈니스를 구현한 마이크로서비스가 개발되어 서비스를 제공하게 됩니다. 그렇게 해야 클라이언트에서 API 게이트웨이를 통해 필요한 마이크로서비스를 찾을 수 있게 되는 것입니다.

 

마이크로서비스 : 기반 서비스의 종류 : 첫번쨰

 

서버에서 가져오며 인스턴스로 뜨게 됩니다. 동시에 레지스트 서비스에 본인의 물리 주소를 등록하게 됩니다. 물론 이때 API 게이트에는 보안을 위해 인증 인가 처리도 하고 로드 밸런싱도 진행하게 됩니다.

그리고 이러한 모든 마이크로서비스의 운영 관리를 위해 모니터링과 트레이싱도 되어야 합니다. 이러한 서비스 중 몇몇 서비스는 클라우드 제공 업체의 클라우드 플랫폼이 직접 제공하기도 합니다. 즉 AWS, 쿠버네티스 같은 곳에서 아예 Paas 자체 기능으로 제공하는 것입니다.

 

 

API Gateway

다양한 클라이언트가 개별 서비스에 액세스하기 위해서는 단일 진입점을 만들어 놓으면 여러모로 효율적입니다. 예를 들면 각 클라이언트에서 서로 다른 API를 제공할 수도 있고 인증 인가같이 보안 처리를 한 곳에서 처리할 수가 있습니다.

또한 일정 시간 동안 서비스 요청에 대한 반응이 없으면 기존 요청 경로를 차단하고 다른 경로로 요청 경로를 변경하는 기능을 가동하여 서비스가 정상적으로 수행되게 해야 합니다. 또 정상적으로 동작하던 서비스에 문제가 발생하여 서비스 요청에 대한 응답 지원이 발생하면 정상적인 다른 서비스로 요청 경로를 변경하는 기능이 작동되게 해야 합니다.

이렇게 서비스 가용성을 위한 방법을 서비스 라우팅이라고 합니다. 라우팅 기능은 L4 같은 하드웨어 장비로 구현할 수도 있고 이렇게 소프트웨어로 구현할 수도 있습니다. API 게이트웨이가 이 라우팅 기능을 수행합니다. 또한 여러 인스턴스로 부하를 분산하는 로드 밸런싱 처리도 수행합니다.

또 라우팅 처리 시 필터를 두어서 라우팅 전에 선행 처리라든지 후행 처리, 에러 처리 등을 쉽게 구현할 수 있습니다. 이런 API 기능을 스프링 클라우드에서는 스프링 API 게이트웨이 서비스라는 것으로 제공되며 내부 라이브러리는 줄과 리본을 사용하고 있는데 라우팅 처리로는 줄을, 로드 밸런싱 처리로는 리본을 사용하고 있습니다. 피보탈 사이트에서 다운받아서 어노테이션 설정만으로 쉽게 구축할 수 있습니다.

 

 

BFF (Backend For Front-end)

API 게이트웨이를 하나로 두지 않고 프런트엔드의 유형에 따라 각각 두는 패턴이 있습니다. 이것을 Backend For Frontend, BFF라고 부르고 웹을 위한 API 게이트웨이, 모바일을 위한 API 게이트웨이 등 클라이언트 종류에 따라 최적화된 처리를 수행할 수 있게 구성할 수 있습니다.

 

 

서비스 레지스트리

라우터가 서비스 이름을 특정 IP로 라우팅하기 위해서는 서비스가 올라가는 컨테이너의 IP 정보가 고정되어 있지 않기 때문에 이런 서비스 이름과 IP 정보를 매핑하여 보관할 저장소가 필요합니다. 이것이 레지스트리 서비스입니다.

각각의 서비스 인스턴스가 로딩 될 때 자신의 주소를 레지스트리 서비스에 등록해 놓습니다. 여기서 레지스트리 서비스에 등록된 이름과 IP 매핑 정보를 가지고 와서 서비스를 호출하는 것입니다. 스프링 API 게이트웨이에서 줄과 리본이 이 역할을 수행합니다. 

이 레지스트리 서비스는 모든 마이크로서비스의 인스턴스를 알고 있습니다. 즉, 서비스 매핑 데이터베이스가 됩니다. 처음 서비스가 등록될 때 위치 정보가 저장되고 서비스 종료 시 위치 정보가 삭제됩니다.

비즈니스로 로직 수행을 위한 마이크로서비스뿐만 아니라 여기서 설명하고 있는 모든 기반 서비스들의 주소도 같이 보관합니다. 스프링 유레카로 레지스트리 서비스를 구현한 모습입니다. 이름과 IP 포트, 매핑 정보가 이렇게 나와 있습니다.

특히 다수의 인스턴스가 하나의 서비스 이름으로 등록될 때 다수의 IP, 포트 정보가 매핑되어 나타납니다. 이 정보를 로드 밸런싱 서비스가 활용하게 되는 것입니다.

 

 

Externalize Configuration

외부 환경 설정 정보를 저장하기 위한 컨피그 서비스입니다. Twelve-Factor 라고 클라우드 네이티브 애플리케이션을 만들기 위한 체크 리스트가 있습니다. 클라우드에서 돌아갈 애플리케이션은 하드웨어나 컨테이너에 종속된 정보를 가지고 있으면 안 된다는 원칙입니다.

왜냐하면 이러한 정보를 애플리케이션이 가지고 있게 된다면 플랫폼이 변경되었을 때 쉽게 이동하기가 힘들기 때문입니다. 즉 코디에서 사용되는 환경 설정 정보는 코드와 안전이 분리되어 관리되어야 합니다. 이런 서비스가 사용하는 환경 정보로는 데이터베이스 연결 정보, 호스트명, 백엔드 서비스의 연결을 위한 리소스 정보 등이 됩니다.

예를 들면 개발 서버, 테스트 운영 서버는 IP와 포트 정보 등이 환경 변수로 이용될 수 있습니다. 이런 환경 정보들이 서비스 코드에 종속되거나 컨테이너에 종속되어 있으면 유연하지 않게 되고 쉽게 변경할 수 없게 되는 것입니다.