마이크로서비스 : 개념, 특성, 배경, 역사

아마존닷컴과 같은 경우는 이미 일반화되었던 쇼핑몰 사업을 가지고 성공을 만들어냈고, 넷플릭스는 비디오 대여 사업으로 시작한 회사입니다. 또한 이들 회사들이 주목할 만한 점은 이들이 끊임없는 비즈니스의 변화를 통해 새로운 가치들을 만들어내고 있다는 것입니다.

11.6초는 몇 년 전에 아마존닷컴이 유명한 IT 컨퍼런스를 통해 발표한 수치입니다. 아마존닷컴이 어플리케이션을 배포하는 주기입니다. 비즈니스상의 문제점이나 개선 사항이 있을 경우에도 이를 수정해서 배포해야 합니다. 즉 그렇기 때문에 이 의미는 아마존 닷컴은 11.6초마다 새로운 서비스와 상품을 배포하고, 또한 서비스의 반응을 보아 개선이 필요할 때나 버그가 발생했을 때 이를 즉시 개선하고 있다는 것입니다.

최근에 비즈니스 흐름은 굉장히 빨리 변하고 기업은 서비스를 고객에게 빨리 보여줘야 하고, 그러한 피드백을 기반으로 서비스를 개선하거나 런칭해야 합니다. 이를 비즈니스 민첩성이라고 말합니다. 배포 주기와 같이 시스템도 이런 비즈니스 변화에 빨리 대응할 수 있는 조건을 갖춰야 합니다. 

전통적인 소프트웨어 개발 모델은 개발 조직과 운영 조직이 분리되어 있고, 개발 조직은 개발이 끝난 후에 운영 조직에게 시스템을 건네 준 이후로 그 시스템을 잊어버립니다. 그렇지만 아마존에서는 그렇게 하지 않습니다. 직접 만들고 직접 운영합니다. 즉 아마존에서는 개발 조직이 운영까지 같이 하고 책임진다는 말입니다.

보통의 시스템을 만드는 회사에서는 크게 개발팀, 운영팀으로 나누어져 있고, 개발팀 내에서도 서비스 기획 파트, 디자이너 파트, 개발 파트, 품질 파트 등으로 나눠져 있습니다. 개발하는 동안에도 이런 다양한 파트들과 협업을 위해 많은 시간이 필요합니다. 그리고 개발팀이 개발을 다 하면 시스템을 운영 매뉴얼과 함께 운영팀에 넘기고 개발팀은 또 다른 시스템을 개발하는 것이 일반적이었습니다.

즉 다양한 기능을 보유한 하나의 팀이 개발도 하고 운영도 한다면, 만드는 속도도 빠르게 되고, 처음부터 운영을 고려해서 책임감 있게 잘 만들고, 운영 시 발생되는 문제도 다른 사람에게 물어보지 않고 쉽게 개선할 수가 있습니다. 이것을 보통 Devops 조직이라고 합니다.

그렇지만 비즈니스 민첩성을 위해 Devops만 필요한 것이 아닙니다. 이 Devops 문화에서, 어떤 개발 환경에서 어떠한 구조의 어플리케이션을 만드는가 하는 것도 매우 중요합니다. 예전에는 어플리케이션을 개발하기 위해 많은 시간들이 필요했습니다. 어플리케이션이 돌아가기 위한 컴퓨터 장비들을 설치하고 어플리케이션 구동에 필요한 프로그램들을 설치했습니다. 서버 장비를 구입하고 데이터 센터에 옮기고 네트워크를 연결하고 운영체제를 설치하고 필요한 소프트웨어를 설치하는 기간이 적어도 수주에서 길게는 몇 달이 걸리기도 했습니다.

 

 

 

클라우드 환경의 등장

요즘은 클라우드 환경이 등장을 했습니다. 필요한 만큼 자원을 쉽게 쓸 수 있습니다. 아마존의 AWS나 구글의 구글 클라우드, 마이크로소프트사의 Azure, IBM의 Bluemix 등 클라우드 인프라는 필요한 시기에 필요한 만큼 쉽고 편한 서비스 형태로 인프라를 사용할 수가 있습니다. 따라서 비용도 사용하는 만큼만 내면 됩니다. 새로운 서비스를 출시해야 하는데 예전처럼 며칠에 걸쳐 서버를 주문하고, 배송을 기다리고, 네트워크를 설치하고, 운영체제를 설치할 필요가 없습니다. 

 

 

 

어플리케이션 문제

요즘 온라인 쇼핑몰에서 특정 상품에 타임세일을 많이 합니다. 이 기간에는 이벤트 서비스의 사용량이 많이 몰리게 됩니다. 이 쇼핑몰은 다른 서비스도 많이 운영하는데 이 서비스 때문에 다른 서비스도 영향을 많이 받게 됩니다. 즉 이 이벤트에 참가하는 사용량 때문에 전체의 서비스 성능이 저하되기 마련인데요. 이때 시스템의 성능을 향상시키는 방법이 무엇일까요? 우선은 초기부터 사용량 증가를 예상하고 큰 물리적 인프라를 준비해놓는 것입니다. 그렇지만 평상시에는 이런 사용량을 보이질 않으니 이런 큰 용량을 고려하여 만들어 놓으면 굉장히 낭비입니다.

두 번째는 이런 이벤트 시, 전체 시스템을 복사하여 증설시키는 방법입니다. 첫 번째 방법을 scale-up, 수직 확장이라고 하고, 두 번째 방법을 scale-out, 수직 확장이라고 합니다. 그리고 클라우드 환경에서는 이 scale-out 방법을 많이 사용합니다. 그런데 이 경우에는 문제가 있습니다.

사실 특정 타임세일만 제공하는 서비스를 수평 확장하고 싶은데 전체 어플리케이션을 수평 확장하면 이 또한 역시 낭비입니다. 그럼 타임세일 서비스만 확장하는 방법을 생각해봐야 되는데요. 그러려면 당연히 전체 시스템에서 타임 서비스만 분리해서 독립적으로 서비스되어야 합니다.

이것이 바로 마이크로서비스입니다. 즉 시스템이 큰 한 덩어리가 아니라 쉽게 분리가 되는 부분으로 이루어져 있어야 한다는 것입니다. 따라서 인프라가 가변적으로 쉽게 변경되는 클라우드 환경에서 수평 확장을 위한 가장 효율적인 시스템의 유형이 바로 마이크로서비스가 되는 것입니다.

 

애플리케이션 구조도

 

왼쪽의 그림은 하나의 덩어리로 구축되는 monolithic 방식의 구조도입니다. 살펴보면 내부적으로는 어플리케이션이 나눠져 있지만 데이터베이스를 한 덩어리로 사용하고 있습니다. 분리할 수가 없습니다.

오른쪽은 마이크로서비스 기반의 어플리케이션 모습을 보여줍니다. 업무 영역은 서비스 단위 묶음으로 격리가 되어 있고, 데이터베이스도 별도로 사용하고 있습니다. 필요에 따라 일부 서비스를 대체하거나 확장할 수 있는 구조입니다. 당연히 사용한 만큼만 과금할 수 있는 클라우드 인프라 환경에서 가장 효율적인 어플리케이션 구조라 할 수 있습니다.

오늘날 기업의 민첩한 비즈니스 대응을 위해서는 시스템적으로는 필요에 따라 쉽게 이용 가능한 클라우드 인프라 환경과, 클라우드 환경의 가장 효율적인 독립적으로 배포되고 쉽게 대체될 수 있고 쉽게 확장 가능한 마이크로서비스 기반의 시스템이 필요한 것입니다. 이것을 클라우드 네이티브 인프라, 클라우드 네이티브 어플리케이션이라고 부릅니다. 또한 개발과 운영을 모두 책임지는 자율적인 Devops 문화도 도입하게 된 것입니다.