플랫폼은 ‘기틀’과 유사한 의미다. 시장의 야채 상점에 야채를 주르륵 올려놓은 매대가 일종의 야채 플랫폼으로 해석될 수도 있겠다. ‘플랫폼 전쟁’이라는 책에서는 다양한 분야의 시장의 기틀이 되는 ‘판’을 점령하는 전략에 대해 소개하기도 한다. 미디어에서 넷플릭스, 온라인 상거래에서 아마존, 모바일 애플리케이션의 생태계에 있어서 애플·구글과 같은 회사들은 ‘판’을 점령해서 전체 시장을 장악하려는 전략을 담고 있다. 이런 것들 역시 플랫폼의 형태라고 이해할 수 있다.

‘배타적 생태계’라는 다소 모순적인 의미를 포함하는 것이 사업 전략적 개념으로서의 플랫폼이다. 내가 제공하는 서비스를 바탕으로 다른 사업자들이 내 서비스의 기능을 사용해서 다시 다양한 서비스를 내놓는 다는 의미로 해석될 수 있겠다.

엔지니어링에서 말하는 플랫폼은 이것과는 조금 다르다. 하지만 기본적으로 생태계를 의미하는 것은 동일하다. API를 통해 서로 다른 사업 주체들이 연동하는 것이 대표적 사례다. 최근의 다양한 모바일 애플리케이션들은 로그인을 직접 회원 가입을 통해 처리하는 경우도 있지만, 페이스북이나 아마존, 카카오와 같은 서비스의 사용자 인증을 연동하는 경우가 많다. 이 경우 페이스북이나 아마존, 카카오는 사용자 인증 플랫폼을 제공한다고 할 수 있다.

저마다 다른 플랫폼은 그것을 제공하는 회사마다 주창하는 플랫폼에 대한 범위가 약간씩 다르다. ‘세일즈포스(Sales Force)’와 같은 서비스의 경우 제품의 판매를 위한 다양한 영업 프로세스와 고객 관리가 플랫폼에서 제공하는 기능의 범위다. 따라서 세일즈포스가 제공하는 API 를 사용하면 굳이 세일즈포스가 직접 제공하는 기능이 아니더라도, 세일즈포스의 고객으로서 직접 기능의 확장이 가능하다.

예를 들어 마케팅 행사에서 발생한 설문 조사를 바탕으로 응답한 사용자들을 구분지어 영업 대상으로 연결하는 일련의 과정을 생각해 보자. 이전에는 설문의 내용을 예상 참석자의 수만큼 종이로 출력하고, 이를 행사에 입장하는 참석자들에게 배포하고, 마케팅 에이전시가 이 종이를 회수하고 누군가 엑셀 파일로 설문 응답의 내용을 정리하면 다시 누군가 세일즈 포스에 엑셀의 내용을 입력한다.

하지만 최근에는 이렇게 하는 것은 여러모로 낭비다. 서베이몽키(Survey Monkey)라는 회사는 웹과 모바일 기반으로 쉽게 설문을 작성할 수 있는 방법을 제공한다. 서베이몽키 사용자는 서비스에서 제공하는 편리한 인터페이스를 사용해서 설문지를 작성할 수 있다. 작성된 설문지는 웹 주소 링크 또는 회사의 모바일 애플리케이션이나 앱에 포함돼 행사에 참석한 사람들에게 공개된다. 행사에 참석한 사람들은 간단한 링크의 클릭을 통해 설문에 응답한다. 그럼 이 응답 정보는 서베이몽키에 저장된다. 물론 csv 파일로 내려 받을 수 있으며, 이렇게 생성된 csv 파일을 세일즈 포스에 업로드 하는 것으로 일이 더 간단해 질 수 있다. 심지어 서베이몽키는 세일즈 포스 서비스가 제공하는 API를 사용해 자사의 서비스에 유입된 정보를 세일즈 포스에 즉시 전달하도록 구성할 수 있다.

종이와 사람들의 노동이 사라지고, 힘든 일은 컴퓨터가 처리하게 된다. 마케팅 이벤트를 통해 유입된 고객 정보들은 최소 며칠간의 설문 정리 시간 없이 행사가 끝나자마자 영업사원에게 전달된다. 행사에서 소개된 신제품이나 새로운 기능에 관심이 많다고 응답한 참석자들 부터 차례대로 영업 사원의 연락을 받도록 구성할 수 있다. 참석자가 행사의 내용을 잊기 전에 무언가 시작할 수 있다면, 아마도 판매 성공 확률을 높일 수 있을지도 모른다. 여기에 사업의 가치가 존재한다.

어떤 서비스의 API가 제공하는 기능이 풍부하고 많아지면, 그래서 다른 서비스들과 하나의 생태계를 이룰 수 있다면, 이를 플랫폼이라고 부를 수 있다. 서베이몽키와 세일즈포스의 사례는 다양한 세일즈 포스의 영업 플랫폼을 API를 통해 설문으로 확장하는 플랫폼이라고 할 수 있다. 그리고 이 두개의 서로 다른 사업은 함께할 때, 즉 더 거대한 생태계를 이룰 수 있을 때 더 많은 사용자를 확보하고 더 많은 이익을 창출할 수 있다.

마이크로서비스와 플랫폼
서로 다른 서비스 간의 API 연동을 통해 목적을 구현하는 것과 유사하게, 마이크로서비스로 구성된 하나의 서비스 내에서도 플랫폼의 역할이 존재한다. 이 모습은 서베이몽키의 설문과 세일즈포스의 영업 기능을 그대로 마이크로서비스에 대입해보면 쉽게 이해할 수 있다.

먼저 마이크로서비스란 다양한 기능을 하는 서비스들이 모여서 하나의 거대한 애플리케이션을 이루는 것을 말한다. 이런 비유가 적절하지는 않지만, 로그인을 하는 서비스는 로그인만, 검색을 처리하는 서비스는 검색만을 전문적으로 서비스한다. 사용자는 마치 하나의 앱을 사용하는 것 같지만, 내부적으로는 이 다양한 기능을 하는 서비스의 조합으로 이루어진 형태가 마이크로서비스 구조다.

마이크로서비스 구조에서 필요한 것은 무엇일까. 대부분의 엔지니어들은 마이크로서비스를 구분하는 방법에 주목하곤 한다. 그리고 그 분산의 수준이 기능 기반인지, 오브젝트 기반인지, 또는 어떤 다른 구조적 분류 방법을 따르는지 등을 매우 궁금해 한다. 물론 이 역시 중요한 부분이기는 하지만 서비스의 형태와 구성에 따라 각 마이크로 서비스의 규모가 다 다르기 때문에 특별한 답이 있다고 보기는 힘들겠다.

사실 더 중요하게 취급돼야 하는 것은 마이크로서비스들을 어떻게 운용할 것인가 하는 부분이다. 이 부분에서 역시 컨테이너 레벨인가, 가상머신 레벨인가, 아니면 물리 서버의 모델인가에 대해 의견이 분분하다. 그리고 이 분야의 플랫폼 시장에서 잘못 이해되고 있는 부분 중 가장 큰 오해가 여기에 있다. 주로 도커 기반의 워크로드를 오케스트레이션 할 수 있는 환경을 플랫폼으로 인식한다는 점이다. 이것은 플랫폼의 아주 일부 기능만을 한정적으로 이해하는 현상에서 비롯되었다고 할 수 있다.

다양한 마이크로서비스의 배포, 확장, 업데이트를 지원하기 위해서는 단순히 런타임 또는 컨테이너 오케스트레이션 이상의 것이 필요하다. 사실 오케스트레이션과 같은 것은 그 시작에 불과할 뿐이다. 더 중요한 것은, 각각의 마이크로서비스가 이루는 생태계에 무엇이 포함돼야 하는가다.

어떤 애플리케이션이 동작하기 위해서는 일반적으로 그 애플리케이션 자체, 즉 코드 또는 코드가 빌드돼 시스템에서 직접 구동하거나 다른 런타임의 도움을 받아서 구동하는 환경이 필요하다. 그리고 이 구동에는 설정이 필요하다. 이 설정에는 연결해야 하는 데이터베이스, 사용할 메모리의 크기 및 각 애플리케이션이 지녀야할, 그리고 환경에 따라 다른 값을 가질 수도 있는 내용들이 포함된다.

클라우드 기반에서 사용자의 유입량, 또는 서비스의 처리량에 따라 애플리케이션이 늘어나고 줄어드는 환경에서는 애플리케이션에 설정을 제공하는 방법, 그리고 애플리케이션이 동작하는 물리 또는 논리적 위치를 다루는 방법이 포함돼야 한다.

이렇게 각 마이크로서비스가 가져야할 일종의 ‘기능 공집합’이 있다. 그리고 이 기능의 공집합을 사용하는 생태계를 마이크로서비스 플랫폼이라고 부를 수 있다. 그저 애플리케이션을 도커로 이미징 해서 어딘가에 구동하는 것이 아니라, 각각의 역할을 하는 애플리케이션이 어떻게 구성되고, 서로 어떻게 연결하고, 이런 동작이 정상적으로 동작하는지 아닌지를 살피는 것들이 바로 그것이다.

넷플릭스의 플랫폼
넷플릭스는 마이크로서비스 구조로 매우 유명한 회사다. 이 마이크로서비스는 다양한 효과를 제공하지만 목적에서는 벗어나므로 더 깊이 들어가지는 않기로 한다. 넷플릭스의 개략적인 전체 구조를 이해한다면 마이크로서비스에 필요한 플랫폼이 어떤 모양인지도 이해할 수 있을 것으로 생각한다.

어쨌든 마이크로서비스로 매우 유명한 이 회사에는 각 마이크로서비스가 동작 가능하도록 하는 특별한 플랫폼이 존재한다. 그리고 이 플랫폼을 이루는 구성요소는 다시 클라우드 환경에 최적화돼 강한 내결함성과 복구성을 자랑하기도 한다.

대표적인 넷플릭스의 플랫폼 도구로 ‘유레카(Eureka)’, ‘아카이어스(Archaius)’, ‘아틀라스(Atlas)’ 등이 있다. 워낙 유명한 도구들이라 약간만 검색하더라도 다양한 정보를 얻을 수 있을 것이다.

유레카는 ‘서비스 디스커버리’로 동작한다. 각각의 마이크로서비스가 어디서 어떻게 동작하는지에 대한 정보를 가지고 있는 일종의 ‘동적 전화번호부’ 개념으로 이해하면 편리하다. 아카이어스는 각 애플리케이션에 필요한 설정 정보를 제공하며, 넷플릭스의 거의 모든 서비스 설정에 관여한다. 심지어는 ‘레이가드’라 불리는 일레스틱서치 클러스터의 설치와 설정 도구 역시 아카이어스를 통해 필요한 설정을 수신하고, 유레카를 통해 멤버의 위치를 확인해서 설정 파일을 만들어내는 식이다. 아틀라스는 넷플릭스 서비스의 실시간에 가까운 ‘오퍼레이션 인텔리전스’를 위한 모니터링 도구다.

이 세 가지는 넷플릭스 서비스를 언급할 때 가장 자주 나오는 것들이다. 각 애플리케이션의 동적 위치 참조를 위한 체계가 곧 유레카이며, 수많은 마이크로서비스의 설정을 위한 체계가 아카이어스고, 모니터링을 위한 체계가 아틀라스다. 그리고 이것이 넷플릭스의 플랫폼 서비스들이다. 수많은 마이크로서비스들에 API를 통해 서비스를 제공한다.

API를 기반으로 플랫폼을 제공하는데서 그치면 안 된다. 용도와 목적에 맞게 각각의 마이크로서비스는 이런 플랫폼 도구들과 연동돼야 한다. 전체 서비스의 모니터링을 위해, 시시각각 변하는 서비스 유입 사용자의 수에 따라 내부 처리 속도를 늘리기 위해, 그리고 이 서비스들에 문제가 발생하더라도 즉시 복구가 가능할 수 있도록 지원하기 위해서다.

넷플릭스는 여기에 크게 두 가지의 방법을 제공한다. 하나는 자바 라이브러리를 제공하는 것이고, 다른 하나는 사이드카 패턴을 사용하는 것이다. 넷플릭스의 서비스들은 오래전부터 자바로 구현해 왔기 때문에 라이브러리를 제공하는 방식은 매우 당연하다고도 볼 수 있다.

유레카가 있으면 유레카 클라이언트 라이브러리가 존재한다. 이 라이브러리를 플랫폼과 연동해서 제공하는 것이 하나의 핵심이다. 마치 데이터베이스와 데이터베이스 클라이언트에서 접근을 위한 라이브러리 사용처럼, 로깅을 위해서, 다른 서비스의 네트워크 위치 참조를 위해서, 그리고 내 서비스의 상태를 모니터링 서비스에 전달하기 위해서 각 플랫폼 도구가 제공하는 라이브러리를 사용한다. 라이브러리를 사용하는 방법은 각각의 팀에서 자신이 개발하고 운용하는 마이크로서비스의 핵심 기능을 위해 넷플릭스 전체에서 필요로 하는 기능을 쉽게 가져다가 사용할 수 있도록 하는 편의를 제공한다.

사이드카 패턴은 생소한 사람이 많을 수 있겠다. 사이드카는 모터사이클, 즉 2륜 자동차 옆에 보조 좌석을 의미한다. 바퀴가 달린 작은 자동차처럼 생긴 사이드카는 한명의 사람이 탑승할 수 있는 공간을 제공하기 위한 목적으로 사용된다.

마이크로 서비스에서의 사이드카의 의미는 핵심 역할을 수행하는 애플리케이션이 플랫폼과 연동할 수 있도록 돕는 역할을 한다. 즉, 플랫폼 연동의 역할을 맡고 있는 것이 사이드카이며, 이 경우 애플리케이션은 자바가 아닌, 자바 라이브러리를 사용할 수 없는 다른 언어로 구성된 애플리케이션이다. 이 다른 언어나 프레임워크 마다 라이브러리를 만드는 것은 매우 오버헤드가 큰 일이므로, 플랫폼 기능을 제공하는 사이드카는 HTTP를 통해 애플리케이션과 통신한다. 다른 언어로 구현된 애플리케이션과 플랫폼 사이에서 동작하는 것이다.

넷플릭스에서 사용하는 사이드카는 종류가 여러가지 있는데, 그중에 가장 잘 알려진 것이 바로 ‘프라나(Prana)’다. 위의 그림을 보면 넷플릭스의 플랫폼, 그리고 이 플랫폼을 사용하는 사이드카와 클라이언트가 잘 나타나 있다. 일반적으로 JVM 기반이 아닌 애플리케이션은 프라나와 동일한 가상머신에서 동작하며, HTTP를 사용해서 필요한 정보를 주고받는다. 동시에 이 가상머신의 프라나는 플랫폼을 통해 애플리케이션에 공급할, 또는 애플리케이션에서 플랫폼에 정보를 공급하는 역학을 수행한다.

이것은 폴리글럿(polyglot)이라고 불리는 체계의 핵심이기도 하다. 데이터서비스와 애플리케이션은 각각의 목적에 맞게 알맞은 언어와 프레임워크, 데이터 소스를 선택해서 사용할 수 있어야 한다. 하지만 관리가 부적절한 상태에서, 즉 플랫폼에 대한 아이디어가 없는 상태에서 폴리글럿을 시도하는 것은 그야말로 재앙이 될 것이다. 동일한 역할을 하는 라이브러리를 언어와 프레임워크별로 제공하는 것은 서비스의 규모가 커질수록 끔찍한 경험이 될 가능성이 높다. 이에 대한 하나의 해법이 바로 사이드카 패턴인 것이다.

아틀라스에 애플리케이션의 모니터링 상태를 공급하는 역할을 하는 클라이언트 도구는 ‘서보(Servo)’ 또는 ‘스펙테이터(Spectator)’다. 이들 역시 라이브러리 또는 사이드카로서 애플리케이션이 동작하는 머신에 함께 배포돼 동작한다. 따라서 애플리케이션은 시작하는 순간 아카이어스를 통해 설정 정보를 받아 자신을 설정하고, 동작을 시작한 이후로부터는 서보나 스펙테이터를 통해 아틀라스에 자신의 정보를 제공한다. 원격 로깅도 이런 방식으로 동작한다.

아래의 그림은 넷플릭스의 대표적인 캐시 서비스인 ‘EVCache’ 와 애플리케이션이 연동하는 방법을 보여준다. 주목할 것은 EVCache 서버에서도 프라나가 동작한다는 사실이다. EVCache 클러스터 역시 유레카와 모니터링을 위해 아틀라스를 사용하고 있으므로 프라나가 필요하다. EVCache 서버는 또한 JVM 기반으로 만들어진 도구가 아니기 때문에 프라나를 사용하고 있다. 반면 이 EVCache 서비스에 접근해야 하는 클라이언트는 클라이언트 라이브러리를 통해 EVCache 서버의 동적 위치를 참조해서 접근한다. 이것이 넷플릭스의 다양한 플랫폼 도구가 각각의 마이크로서비스와 연동해 동작하는 방법이다.

클라우드 파운드리와 스프링
엔터프라이즈에서 넷플릭스의 견고한 구조를 가장 빨리 구성할 수 있는 방법은 다양한 스프링 프로젝트와 클라우드 파운드리를 사용하는 방법이다.

위에 소개한 넷플릭스의 플랫폼과 이를 사용하는 클라이언트의 구성은 넷플릭스를 이루는 몇 가지 핵심중 하나다. 설정, 서비스 디스커버리, 로깅, 모니터링의 가장 기본적이라 할 수 있는 기능성을 플랫폼으로 제공하고, 이를 각각의 마이크로서비스에서 사용할 수 있도록 제공해야 한다. 이때 플랫폼으로 제공하는 기능을 담당하는 부분이 클라우드 파운드리이며, ‘스프링 부트’와 ‘스프링 클라우드’를 통해 넷플릭스와 같은 서비스 구조를 엔터프라이즈의 방법으로 빠르게 전개할 수 있다.

물론 스프링 부트와 스프링 클라우드는 반드시 클라우드 파운드리와 함께 사용해야 하는 것은 아니다. 스프링 팀의 헌신적인 노력은 스프링 자체를 배타적으로 만들기 보다는, 가급적이면 많은 환경에서 많은 사용자가 사용할 수 있는 편의를 제공한다. 클라우드 파운드리 역시 스프링 또는 JVM 기반의 워크로드만 구동하는 것은 아니다. 닷넷, 파이썬, 노드, 루비, 고, 심지어 x86_64 로 빌드된 애플리케이션의 동작을 지원한다.

앞서 언급했듯 단순히 런타임 또는 이를 오케스트레이션 하는 환경을 제공하는 것이 진정한 플랫폼의 역할은 아니다. 마이크로서비스를 위한 플랫폼의 가치는 각각의 서비스가 처리해야하는 다양한 워크로드에 따라 적절한 데이터 연동 구조의 선택, 그리고 이 선택을 바탕으로 한 손쉬운 사용에 있다. 클라우드 파운드리에서 카프카(Kafka) 서비스를 준비했다면, 스프링 클라우드 스트림을 통해 즉시 바인딩해서 사용할 수 있는 구조가 바로 이것이다.

개발자에게 도커의 편의는 절대적이다. 도커의 유행은 애플리케이션을 구동하기 위한 JVM 환경을 코드와 함께 이미징할 수 있기 때문이라기보다는, 클라우드 서비스에 필요한 다양한 도구들의 설치와 실행을 손쉽게, 그리고 가능한 한 랩톱을 망가트리지 않고 사용할 수 있는 기능을 제공했기 때문이었다고 생각한다.

그러나 개발자 랩톱에서 손쉽게 구동되는 환경은 프로덕션 수준에서 수용이 힘들었다. 먼저 운영팀이 도커를 프로덕션 수준으로 구동해 줄 수 있는 환경의 준비와 운영에 대한 준비가 쉽지 않으며, 더군다나 그 위에서 동작하는 다양한 데이터 서비스들, 이를테면 카프카나 메세지큐와 같은 새로운 도구들의 운영에 익숙치않기 때문이었다.

도커 이미지의 프로덕션 운영에 대한 해답으로 쿠버네티스(Kubernetes)가 급부상하고 있다. 물론 쿠버네티스는 훌륭한 도구이지만, 마찬가지로 전체 플랫폼 구성의 일환으로 생각해야 한다.

만약 카프카 도커 이미지를 쿠버네티스에 즉시 배포하고, 이를 스프링 클라우드 스트림을 통해 즉시 바인딩해서 사용할 수 있는 환경이 제공된다면 어떨까. 스프링 클라우드를 사용한 애플리케이션은 다시 언제든 다운타임 없이 업데이트를 수행할 수 있고, 동적 확장을 지원한다면 어떨까. 스프링 부트의 액추에이터를 통해 넷플릭스 서보나 스펙테이터와 같이 쿠버네티스위에 도커 이미지를 통해 구동되는 모니터링 플랫폼에 메트릭을 전달할 수 있다면 어떻게 될 것인가.

바로 이런 넷플릭스 플랫폼의 구조를 스프링 프로젝트 체계와 클라우드 파운드리의 애플리케이션 플랫폼과 컨테이너 플랫폼을 통해 사용할 수 있다. 종전의 클라우드 파운드리와 쿠버네티스가 결합된 이 환경은, 비단 스프링 뿐만 아니라 다양한 환경에도 넷플릭스 플랫폼이 제공하는 장점을 가장 빠르게 흡수 할 수 있는 방법이 될 것이다.