마이크로서비스 외부 아키텍처2 - 마이크로서비스 운영,관리를 위한 플랫폼 패턴
Updated:
마이크로서비스 외부 아키텍처2 - 마이크로서비스 운영,관리를 위한 플랫폼 패턴
마이크로서비스 생태계의 탄생
우선 마이크로서비스 생태계가 어떻게 발전되었는지 그 발전 흐름을 알아보면 마이크로서비스 마이크로서비스 운영관리 패턴에 대해 이해 할 수 있다. 아래 그림을 통해 살펴보자.
이전에 설명했던 CI 개념이 켄트 벡에 의해 XP 방법론의 프랙티스로 1999년도에 소개되고 켄트 벡, 스크럼의 켄 슈와버, 마틴 파울러등 여러 구루들이 모여 2001년에 애자일 선언을 한다. 그때부터 소프트웨어 업계가 장기 계획이나 단계적 프로세스 대신 빠른 실패와 피드백을 기반으로 하는 실용적인 실천 방법을 선호하게 되었다.
한편 다른 쪽에서는 아마존이 IaaS 개념으로 2006년도에 EC2를 발표하며 최초로 클라우드 사업을 시작했다. 그쯤에 기존 동영상 대여업으로 출발했던 넷플릭스가 스트리밍 사업을 시작했는데 얼마 있다 스트리밍 데이터베이스 스토리지가 손실되는 큰 서비스 장애를 겪게 된다. 이를 계기로 넷플릭스는 한 덩어리의 모노리식 시스템에서 마이크로서비스 기반의 시스템으로의 전환을 시작한다. 이때 선택되었던 것이 AWS의 EC2였다.
그러나 클라우드 기반에서의 마이크로소프트 전환은 쉽지 않았다. 우선 어플리케이션이 한 덩어리 였을 때 느끼지 못한 수 많은 문제점이 불거졌다. 여러 개의 서비스로 구성했을 때 장애가 전파된다 던지 여러 개의 서버에 분산된 로그를 관리해야 되는 불편함, 서비스 하나가 동작하지 않아 시스템의 일부 기능이 동작하지 않아도 그것을 알아채지 못하는 그전에 생가지 못한 문제들이 발생했다.
넷플릭스는 이런 문제 해결방법으로 다양한 서비스 및 도구들을 개발하게 된다. 그리고 넷플릭스 기술력에 의구심을 갖는 사람들에게 보란 듯이 오픈 소스로 공개하게 된다. 그것이 넷플릭스 OSS이다. 여러 개의 마이크로서비스간 라우팅과 로드 밸런싱을 위한 줄(Zuul) 과 리본(Ribbon) 모니터링을 위한 히스트릭스(Hystrix), 서비스 등록을 위한 유레카(Eureka) 등이 바로 그것이다. 이런 활동이 마이크로서비스 생태계의 공유 흐름이 됐다. 이런 활동으로 주요 문제 패턴이 공유되고 자연스럽게 개발자 간 협업 및 기여가 이루어졌고 이로 인해 업계가 같이 발전하게 되었다.
그리고 이후 2013년이 돼서 가장 유명한 컨테이너 기술인 도커(Docker)가 세상이 등장하게 된다. 또한 이쯤에 스프링 진영에서는 마이크로서비스를 쉽게 개발할 수 있는 프레임워크인 스프링 부트를 발표하고 최근에는 도커 컨테이너 오케스트레이션 기술인 구글의 쿠버네티스가 등장하였다. 전 장에서 논의한 마이크로서비스 개념을 마틴 파울러가 정의한 시점이 바로 이 시점이다.
이렇게 발전 과정을 살펴보았는데 간단히 정리해 보면 AWS의 클라우드 환경, 도커 컨테이너, 넷플릭스가 공유한 오픈 소스들, 스프링 프레임워크, 구글의 쿠버네티스, 이런 것이 마이크로서비스 생태계의 발전을 계속 중단 없이 이끌었고 이러한 과정을 거쳐 마이크로서비스 아키텍처를 주요 문제들이 논의되고 해결책들이 제시되어 왔다는 것을 알 수 있다.
경험으로 획득한 지혜:마이크로서비스 관리/운영 패턴
마이크로서비스 문제는 여러 개의 서비스로 구성되는 시스템이기 때문에 직면했던 문제들이다. 이에 앞서 언급했다시피 넷플릭스사가 많은 공언을 했는데, 넷플릭스OSS는 넷플릭스가 마이크로서비스를 개발하고 운영하면서 생긴 노하우를 다른 사람들도 쉽게 사용할 수 있도록 공유한 것이다. 이런 공유가 마이크로서비스 생태계에 많은 도움이 되었고, 특히 이러한 요소들은 마이크로서비스 관리와 운영의 지원하는 전형적인 마이크로서비스 애플리케이션 패턴들이 됐다. API 게이트웨이라든지 서비스 디스커버리, 모니터링, 트레이싱 등 주로 다른 마이크로 서비스를 관리/운영하기 위한 플랫폼 패턴들인데 넷플릭스 소스 공개로 패턴으로 정착되고 나중에 이런 패턴을 적용한 다른 여러 도구 , 오픈 소스들이 생겨나게 된다.
또한 넷플릭스 OSS를 더 쉽게 쓸 수 있도록 스프링 진영의 피보탈(Pivotal)사가 기존 스프링 부트 프레임워크 상에서 잘 돌아갈 수 있도록 넥플릭스 OSS 모듈들을 스프링프레임웍으로 감싸서 스프링 클라우드(Spring Cloud)라는 명칭으로 발표했다. 그럼으로써 스프링 부트와 스프링 클라우드는 마이크로서비스를 개발하기 위한 가장 유명한 기본 프레임워크가 되었다. 스프링부트와 스프링 클라우드로 마이크로서비스 애플리케이션 운영환경을 쉽게 구축할 수 있는데 먼저 이를 기반으로 주요 관리/운영 플랫폼 패턴을 간단히 살펴보도록 하겠다.
스프링 클라우드 : 스프링부트 + 넷플릭스 OSS
아래 그림은 스프링 클라우드를 표현한 구성도인데 말한 바와 같이 스프링 클라우드는 스프링프레임웍을 개발하고 있는 피보탈사에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈 소스를 스프링 부트 프레임웍 기반으로 사용하기 쉽도록 통합한 것이다.
이런 서비스들이 마이크로서비스를 운영하는 데 기반이 되기 때문에 보통 기반 서비스라고도 부른다. 전체 도식화된 그림을 보면 DevOps 환경과 기반 서비스들이 존재하고 그 기반 위에 업무처리 마이크로서비스가 운용된다. 그럼 그림을 통해 비즈니스를 구현한 마이크로서비스 서비스와 기반 서비스의 연계 흐름을 대략 살펴보자.
- 모든 마이크로서비스(기반서비스를 포함한)는 인프라의 종속되지 않기 위해DB ,File등 환경 설정 정보를 형상 관리에 연계된Config서비스에서 가져와서 설정 정보를 주입 후, 클라우드 인프라의 개별 인스턴스로 로딩된다.
- 로딩과 동시에 서비스 레지스트 서비스에 자신의 서비스명과 클라우드 인프라부터 할당 받은 물리 주소를 매핑하여 등록한다.
- 클라이언트가 마이크로서비스를 API게이트웨이를 통해 접근하고 이때 API게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸란싱 처리를 한다.
- 이때 서비스레지스트리 검색을 하여 서비스의 위치를 가져온다.
- 또한 API 게이트웨이는 이때 각 서비스접근을 위해 권하서비스와 연계해 인증/인가 처리를 한다.
- 그리고 이러한 모든 마이크로서비스는 모니터링되고 추적된다.
간단하게 마이크로서비스와 기반 서비스의 연계 흐름을 스프링 클라우드를 중심으로 살펴봤다. 이런 처리 흐름은 마이크로서비스의 주요 아키텍처 패턴이 되었기 때문에 스프링 부트 외에 각 클라우드 제공 업체의 플랫폼에 유사한 형태의 각자의 서비스로 존재한다. 즉 AWS, 애저, 쿠버네티스등에서 아예 PaaS 자체 기능이나 과금 되는 별도 서비스로 제공한다. 따라서 개개의 특정 제품중심으로 살펴보는 것 보다 전반적인 패턴을 이해하는 것이 중요하다. 패턴중심으로 하나하나 자세히 이해해 보자.