1-1. Biz민첩성과 아키텍처 요건

최근에 IT 업계에서 클라우드가 핫이슈죠. 이런 클라우드의 대표적인 어플리케이션 architecture로 마이크로서비스 기반 architecture를 말하고 있는데요. 본 주차에서는 마이크로서비스 기반 architecture의 필요성 및 특징, 개념에 대해서 알아보도록 하겠습니다. 첫 번째 차시에서는 민첩한 비즈니스를 위해 필요한 시스템의 조건에 대해 알아보고, 두 번째 차시에서는 기존의 monolithic 시스템과 비교한 마이크로 개념에 대해서 알아보고, 세 번째, 네 번째 차시에서는 마이크로서비스 architecture가 가진 주요 특징들을 상세히 살펴볼 계획입니다.

이번 차시에서는 비즈니스 속도 및 민첩성과 관련해서 왜 시스템의 유연성과 확장성이 중요하게 되었는지를 알아보도록 하겠습니다. 다음은 가장 전 세계적으로 유명한 온라인 기업들인데요. 특히 주목할 만한 것은 이들 기업들이 남들이 오래된 산업이라 관심 없었던, 이미 존재했던 서비스들을 온라인 기술과 접목하여 새로운 서비스들로 만들어낸 기업들이라는 것입니다. 아마존닷컴과 같은 경우는 이미 일반화되었던 쇼핑몰 사업을 가지고 성공을 만들어냈고, 넷플릭스는 비디오 대여 사업으로 시작한 회사였죠. 또한 이들 회사들이 주목할 만한 점은 이들이 끊임없는 비즈니스의 변화를 통해 새로운 가치들을 만들어내고 있다는 것입니다. 그렇다면 어떻게 그러한 일들이 이루어지고 있을까요? 우리의 방식과 어떻게 다를까요? 11.6초. 본 수치는 몇 년 전에 아마존닷컴이 유명한 IT 컨퍼런스를 통해 발표한 수치입니다. 무엇일까요? 100m 달리기 기록인가요? 그렇다면 매우 빠른 기록이네요. 정답은 아마존닷컴이 어플리케이션을 배포하는 주기입니다. 어플리케이션을 배포한다는 의미는 무엇일까요? 보통 온라인 기업에서는 새로운 서비스나 상품을 기획하고 이를 서비스하고 지원할 어플리케이션을 개발해서 배포합니다. 또한 비즈니스상의 문제점이나 개선 사항이 있을 경우에도 이를 수정해서 배포해야 합니다. 즉 그렇기 때문에 이 의미는 아마존 닷컴은 11.6초마다 새로운 서비스와 상품을 배포하고, 또한 서비스의 반응을 보아 개선이 필요할 때나 버그가 발생했을 때 이를 즉시 개선하고 있다는 것입니다. 그럼 우리의 기업들은 어떨까요? 제가 아는 국네 쇼핑몰은 1주일에 2번씩 배포합니다. 즉 이를 단순비교하면 아마존닷컴의 서비스는 변경 속도가 11.6초이고 제가 아는 국내 쇼핑몰의 서비스 변경 속도는 3일인 것입니다. 11.6초 대 3일. 놀라운 차이 아닌가요? 최근에 비즈니스 흐름은 굉장히 빨리 변하고 기업은 서비스를 고객에게 빨리 보여줘야 하고, 그러한 피드백을 기반으로 서비스를 개선하거나 런칭해야 합니다. 이를 비즈니스 민첩성이라고 말합니다. 배포 주기와 같이 따라서 시스템도 이런 비즈니스 변화에 빨리 대응할 수 있는 조건을 갖춰야 합니다. 우선 이런 시스템을 만드는 사람들의 일하는 방식에 대해 살펴보도록 하겠습니다. 이분은 아마존의 CTO이자 부사장인 버너 보겔스인데요. 그 분의 말을 한 번 들어볼까요? 제가 한 번 해석해보도록 하겠습니다. 전통적인 소프트웨어 개발 모델은 개발 조직과 운영 조직이 분리되어 있고, 개발 조직은 개발이 끝난 후에 운영 조직에게 시스템을 건네 준 이후로 그 시스템을 잊어버렸다. 그렇지만 아마존에서는 그렇게 하지 않는다. 당신이 만들고 당신이 운영한다. 이렇게 말하고 있습니다. 즉 아마존에서는 개발 조직이 운영까지 같이 하고 책임진다는 말입니다. 그렇다고 한다면 다른 회사들은 어떻다는 건가요? 보통의 시스템을 만드는 회사에서는 크게 개발팀, 운영팀으로 나누어져 있고, 개발팀 내에서도 서비스 기획 파트, 디자이너 파트, 개발 파트, 품질 파트 등으로 나눠져 있습니다. 개발하는 동안에도 이런 다양한 파트들과 협업을 위해 많은 시간이 필요하다는 말이죠. 그리고 개발팀이 개발을 다 하면 시스템을 운영 매뉴얼과 함께 운영팀에 넘기고 개발팀은 또 다른 시스템을 개발하는 것이 일반적이었다는 거죠. 이렇게 개발 조직과 운영 조직이 분리되어 있다. 그리고 개발 조직 내부에서도 산로가 있어서 의사소통 시간이 많이 걸린다. 그게 현재의 일반적인 상황이었다는 거죠. 그런데 만약 하나의 팀에서 여러 역할을 수행하는 기획자, 디자이너, 설계자, 개발자, 테스터들이 같이 있다면 어떨까요? 당연히 의사소통이 빠르기 때문에 어플리케이션을 신속하게 만들 수 있겠죠. 그리고 만든 사람들이 운영을 해야 한다고 생각하면 운영을 고려해서 좀 더 신경 써서 만들 수밖에 없겠죠? 즉 다양한 기능을 보유한 하나의 팀이 개발도 하고 운영도 한다면, 만드는 속도도 빠르게 되고, 처음부터 운영을 고려해서 책임감 있게 잘 만들고, 운영 시 발생되는 문제도 다른 사람에게 물어보지 않고 쉽게 개선할 수가 있는 것입니다. 이것을 보통 Devops 조직이라고 합니다. 다음은 도식화된 enterprise 어플리케이션 개발 피라미드인데요. 방금 우린 아마존의 개발 조직, 그 문화인 Devops에 대해서 얘기했죠. 그렇지만 비즈니스 민첩성을 위해 Devops만 필요한 것이 아닙니다. 이 Devops 문화에서, 어떤 개발 환경에서 어떠한 구조의 어플리케이션을 만드는가 하는 것도 매우 중요합니다. 그럼 개발 환경이 이루는 물리적인 하드웨어 인프라를 한 번 살펴볼까요? 예전에는 어플리케이션을 개발하기 위해 많은 시간들이 필요했습니다. 어플리케이션이 돌아가기 위한 컴퓨터 장비들을 설치하고 어플리케이션 구동에 필요한 프로그램들을 설치했죠. 서버 장비를 구입하고 데이터 센터에 옮기고 네트워크를 연결하고 운영체제를 설치하고 필요한 소프트웨어를 설치하는 기간이 적어도 수주에서 길게는 몇 달이 걸리기도 했습니다. 요즘은 어떨까요? 요즘은 클라우드 환경이 등장을 했죠. 필요한 만큼 자원을 쉽게 쓸 수 있습니다. 아마존의 AWS나 구글의 구글 클라우드, 마이크로소프트사의 Azure, IBM의 Bluemix, 그리고 SK주식회사의 클라우드Z. 클라우드 인프라는 필요한 시기에 필요한 만큼 쉽고 편한 서비스 형태로 인프라를 사용할 수가 있습니다. 따라서 비용도 사용하는 만큼만 내면 됩니다. 새로운 서비스를 출시해야 하는데 예전처럼 며칠에 걸쳐 서버를 주문하고, 배송을 기다리고, 네트워크를 설치하고, 운영체제를 설치할 필요가 없습니다. 그렇다면 이렇게 하드웨어가 가변적으로 쉽게 변경될 수 있는데, 이 하드웨어에서 구동되는 소프트웨어는 어때야 할까요? 요즘 온라인 쇼핑몰에서 특정 상품에 타임세일을 많이 합니다. 이 기간에는 이벤트 서비스의 사용량이 많이 몰리게 되죠. 이 쇼핑몰은 다른 서비스도 많이 운영하는데 이 서비스 때문에 다른 서비스도 영향을 많이 받게 됩니다. 즉 이 이벤트에 참가하는 사용량 때문에 전체의 서비스 성능이 저하되기 마련인데요. 이때 시스템의 성능을 향상시키는 방법이 무엇일까요? 우선은 초기부터 사용량 증가를 예상하고 큰 물리적 인프라를 준비해놓는 것입니다. 그렇지만 평상시에는 이런 사용량을 보이질 않으니 이런 큰 용량을 고려하여 만들어 놓으면 굉장히 낭비겠죠? 두 번째는 이런 이벤트 시, 전체 시스템을 복사하여 증설시키는 방법입니다. 첫 번째 방법을 scale-up, 수직 확장이라고 하고요. 두 번째 방법을 scale-out, 수직 확장이라고 합니다. 그리고 클라우드 환경에서는 이 scale-out 방법을 많이 사용하는데요. 그런데 이 경우에는 문제가 있습니다. 사실 특정 타임세일만 제공하는 서비스를 수평 확장하고 싶은데 전체 어플리케이션을 수평 확장하면 이 또한 역시 낭비겠죠? 그럼 타임세일 서비스만 확장하는 방법을 생각해봐야 되는데요. 그러려면 당연히 전체 시스템에서 타임 서비스만 분리해서 독립적으로 서비스되어야 합니다. 이것이 바로 마이크로서비스입니다. 즉 시스템이 큰 한 덩어리가 아니라 쉽게 분리가 되는 부분으로 이루어져 있어야 한다는 것입니다. 따라서 인프라가 가변적으로 쉽게 변경되는 클라우드 환경에서 수평 확장을 위한 가장 효율적인 시스템의 유형이 바로 마이크로서비스가 되는 것입니다. 왼쪽의 그림은 하나의 덩어리로 구축되는 monolithic 방식의 구조도입니다. 살펴보면 내부적으로는 어플리케이션이 나눠져 있지만 데이터베이스를 한 덩어리로 사용하고 있죠? 분리할 수가 없습니다. 오른쪽은 마이크로서비스 기반의 어플리케이션 모습을 보여줍니다. 업무 영역은 서비스 단위 묶음으로 격리가 되어 있고, 데이터베이스도 별도로 사용하고 있습니다. 필요에 따라 일부 서비스를 대체하거나 확장할 수 있는 구조입니다. 당연히 사용한 만큼만 과금할 수 있는 클라우드 인프라 환경에서 가장 효율적인 어플리케이션 구조라 할 수 있습니다. 정리하면 오늘날 기업의 민첩한 비즈니스 대응을 위해서는 시스템적으로는 필요에 따라 쉽게 이용 가능한 클라우드 인프라 환경과, 클라우드 환경의 가장 효율적인 독립적으로 배포되고 쉽게 대체될 수 있고 쉽게 확장 가능한 마이크로서비스 기반의 시스템이 필요하다는 것을 알았습니다. 이것을 클라우드 네이티브 인프라, 클라우드 네이티브 어플리케이션이라고 부릅니다. 또한 개발과 운영을 모두 책임지는 자율적인 Devops 문화도 필요하다는 것을 알았습니다. 이상으로 기업의 비즈니스 민첩성과 이에 필요한 시스템 요건에 대해 알아보았습니다.