2021.01.11

'하나의 오픈소스, 많은 기여자' 프로메테우스가 작동하는 아름다운 방식

Matt Asay | InfoWorld
2000여년 전, 로마 역사학자 타키투스는 “모두가 승리는 자신의 공이라고 주장한다”고 했는데, “성공의 아버지는 많다”는 말로 번역되기도 한다. 오픈소스도 비슷하다. 예를 들어 AWS는 최근 그라파나 랩(Grafana Labs)과 협력해 관리형 프로메테우스(Prometheus) 서비스를 구축, 출범했다. 두 회사가 손을 잡고 클라우드 서비스로 이 오픈소스 모니터링 소프트웨어를 제공한다. 정말 보이는 것처럼 간단할까?
 
아니, 그렇지 않다.
 
프로메테우스 서비스가 실행되기까지의 과정에는 여러 기업과 오픈소스 커뮤니티가 각자의 역할을 한다. 프로메테우스를 만든 사운드클라우드(SoundCloud), 스코프(Scope)를 통해 코텍스(Cortex)의 기반 개념을 제공한 하이퍼릭(Hyperic), 모니터링의 비즈니스 가치를 인지한 스프링소스(SpringSource), 그리고 모든 것의 중심에는 깃옵스(GitOps)로 유명하지만 코텍스를 만든 기업이기도 한 위브웍스(Weaveworks)가 있다.
 
ⓒ Getty Images Bank

코텍스의 역사는 그 자체로 오픈소스의 공로 배분 방식에 관한 수업이다. 길고 복잡하고 장황한 이야기지만 이것이 오픈소스가 움직여야 할 본연의 모습이기도 하다.
 

돈과 오픈소스

코텍스의 경우 시작은 돈, 더 정확히는 돈을 벌여야 할 필요성이었다.
 
위브웍스의 CEO 알렉시스 리차드슨은 한 인터뷰에서 “로드(스프링소스 CEO 로드 존슨)와 대화를 나눈 적이 있는데, 그때 로드는 스프링소스의 비즈니스에서 가장 크게 후회되는 부분은 하이퍼릭을 곧바로 인수하지 않고 가치가 계속 올라가도록 뒀던 것이라고 말했다. 그 말이 내 머리에 각인됐다”고 말했다.
 
리차드슨은 오픈소스를 수익화하기 위한 열쇠는 모니터링과 관리임을 확신했고, 결국 2014년 자신이 스프링(Spring)과 v패브릭(vFabric) 제품을 이끌었던(물론 래빗MQ(RabbitMQ)와 같은 다른 제품도 있음) 피보탈(Pivotal)을 나와 위브웍스를 창업했다.
 
리차드슨은 도커 컨테이너 세계가 스프링 애플리케이션 시장과 비슷한 양상으로 전개되어 모니터링과 관리가 중요한 요소가 될 것으로 판단했다. 그래서 탄생한 것이 도커 호스트, 컨테이너, 서비스를 실시간으로 시각화하는 위브 스코프(Weave Scope)다. 스코프는 멋진 오픈소스 프로젝트다. 그러나 그보다 앞서 이야기해야 할 부분이 있다. 스코프가 시작된 곳은 위브웍스가 아니라는 것이다.
 
위브웍스는 컨테이너화된 애플리케이션을 매핑하고 시각화할 방법을 연구하던 중에 전 사운드클라우드 엔지니어인 피터 부르곤을 인터뷰했는데, 인터뷰에서 부르곤이 위브웍스가 구상한 것과 상당부분 일치하는 아이디어를 위해 작업을 해왔음을 알게 됐다. 부르곤은 사운드클라우드에서 친구인 데이비드 칼슈미트(당시 자신이 창업한 타입 타입 타입(Type Type Type)을 경영 중이었음)와 함께 모니터링 및 시각화 솔루션을 개발 중이었고 이것이 리차드슨의 눈에 들어왔다. 두 사람이 위브웍스에 합류했고 이들이 개발 중이었던 초기 모니터링 솔루션이 스코프가 됐다.
 
스코프는 뛰어났지만 메트릭 면에서 보완이 필요했다. 사운드클라우드에서 막 나온 부르곤은 프로메테우스에 빠져 있었고, 메트릭을 구현할 방법으로 프로메테우스를 채택할 것을 회사에 종용했다. 그러나 스코프에 프로메테우스를 추가할 때 문제는 앱의 메트릭을 보려고 할 때마다 아마존 EC2 인스턴스를 가동하는 비용을 누군가가 지불해야 한다는 것이었다. 비용이 상당히 높아질 수도 있었다. 코텍스를 향한 워브웍스의 여정은 수익을 얻기 위한 목적으로 시작되었는데(프로메테우스) 이제는 서비스의 현실화를 위해 비용을 절약할 방법을 찾아야 했다(프로메테우스가 아닌 다른 것으로).
 
위브웍스는 뭔가 다른 것을 시도해야 했다. 겉으로는 프로메테우스와 비슷하지만 메트릭을 볼 때마다 프로메테우스 인스턴스를 가동해야 하는 비용 없이, 프로메테우스와 비슷한 메트릭을 제공할 수 있는 서비스가 필요했다.
 

프로메테우스를 가동하는 또 다른 방법

그 ‘뭔가 다른 것’이 전혀 다른 설계를 사용하는 코텍스였다. 리차드슨은 코텍스가 “프로메테우스에서 많은 코드를 가져왔지만 접근 방법은 아파치 카산드라에 더 가깝다”고 말했다. 즉, 아무 것도 공유하지 않고 샤딩된 속성이 있으며 데이터 저장을 위한 협력 없이 모든 데이터가 시스템의 다양한 지점으로 간다. 위브웍스 서비스는 프로메테우스처럼 보이고 프로메테우스와 같은 스타일의 메트릭을 사용하여 프로메테우스에 연결할 수 있지만 프로메테우스와는 다르게 설계됐다.
 
“오픈소스 공로 인정의 시작과 끝은 어디인가”라는 이 주제를 더욱 심화하는 요소는 위브웍스 설계 팀에 톰 윌키가 설계 리드로 소속됐다는 점이다. 현재 톰 윌키는 그라파나 랩에 속해서 코텍스 개발을 계속 이어 나가고 있다(켈시 하이타워가 말한 “같은 팀, 다른 회사”의 양상). 그러나 윌키는 풍부한 카산드라 경험을 등에 업고 위브웍스에 합류했고 이것이 코텍스 설계의 틀을 잡는 데 도움이 됐다. 이 팀에는 사운드클라우드 시절 프로메테우스를 공동 창업했으며 현재 위브웍스 자문으로 활동하는 줄리우스 볼츠도 포함됐다.
 
회사 창업자들은 쿠버네티스가 부상하면 프로메테우스가 성공하고 코텍스는 SaaS 수익화 경로를 실현해줄 것이라고 생각했다. 그러나 현실적으로 기술과 비즈니스 모두 개발하는 데에는 시간이 걸렸다. 위브웍스의 특별 엔지니어인 브라이언 보어햄은 코텍스를 현재의 성공으로 이끌기 위해 얼마나 많은 작업이 필요했는지를 강조했다.
 
코텍스는 몇 년의 작업 기간 동안 많은 부분이 다시 작성되고 다시 설계됐다. 테세우스의 배와 같다. 목재가 여러 번 교체됐다. 위브웍스에서 몇 년 동안 지속적으로 프로덕션을 거쳤다. 기본적인 부분은 원활했지만, NoSQL 측면에서 스키마 버전 11을 사용했다. 수많은 재고를 거쳐 사실상 NoSQL의 대부분을 프로메테우스 자체 시계열 데이터베이스와 비슷한 패턴으로 교체했다. 
 
시초의 코텍스는 유망했지만, 보어햄은 “광범위한 분산 시스템”에서 실행됨에도 불구하고 프로메테우스보다 속도가 현저히 느렸다고 말했다. 위브웍스는 코텍스의 속도를 높이기 위해 많은 노력을 기울였고(캐시 추가, 속도 저하 지점을 찾기 위한 재거(Jaeger) 트레이싱 등), 적어도 지난 2년만 보면 코텍스의 속도가 프로메테우스보다 빨랐다.
 
리차드슨은 코텍스의 약속을 현실화하기 위한 과정에 박차를 가한 네 가지 요소를 언급했다. 첫 번째는 대중을 위한 실제 서비스 실행에 연계됐다는 점이다. 리차드슨은 “프로메테우스를 온디맨드 방식으로 제공하기 위해 코텍스 서비스를 실행하면서 실제 환경에서 코텍스를 어떻게 실행해야 하는지에 관해 많은 것을 배웠다”고 말했다. 두 번째는 “다른 방법으로 해결하기 매우 어려운 실제 문제를 해결한다”는 점이다. 셋째, 위브웍스와 급성장 중인 코텍스 커뮤니티(현재 디지털오션(DigitalOcean) 등의 엔지니어들이 활발하게 참여 중)는 코텍스를 원래의 다이나모DB/아마존 S3 백 엔드에서 분리하는 결정을 내렸다. 리차드슨은 “더 많은 곳에서 실행이 가능하고 AWS에 묶이지 않으므로 유용성이 더 높아졌다.”고 말했다. 네 번째는 “오픈소스의 마법”이다. 위브웍스는 코텍스를 CNCF로 가져가서 노출을 늘려 큰 탄력을 받았다.
 
이 마법은 여전히 코텍스의 가장 중요한 기여자인 위브웍스가 더 이상 모든 짐을 혼자서 끌 필요가 없음을 의미한다. 현재 코텍스의 가장 큰 기여자는 그라파나 랩이지만(위브웍스가 두 번째) 레드 햇, 로빈후드(Robinhood), 스플렁크(Splunk), 디지털오션을 비롯한 다른 많은 기업도 적극적으로 참여하고 있다. 이는 오픈소스의 놀라운 “마법”을 보여주는 신호이자 위브웍스가 한 벤더의 통제가 아닌 진정한 오픈소스 커뮤니티 거버넌스 모델을 성공적으로 촉진하고 있음을 보여준다.
 
이것이 원래 오픈소스가 움직이는 방식이다. 로키(Loki, 프로메테우스에서 촉발된 오픈소스 로깅 프로젝트) 또는 엔보이(Envoy)와 같은 프로젝트는 한 회사에서 시작되어 다른 회사에서 더 심층적으로 개발되고 또 다른 많은 기업을 거쳐 운영화되고 향상된다. 로키의 개념은 톰 윌키가 위브웍스에서 고안했지만 개발한 것은 그라파나 랩이다. 엔보이는 리프트(Lyft)의 맷 클라인이 시작했지만 작년의 가장 큰 기여자는 구글이다. 다른 많은 오픈소스 프로젝트도 같은 패턴으로 움직이고 있다.
 
버그가 아니라 기능이란 말처럼 이러한 패턴은 문제가 아니라 정상이며, 오픈소스를 제대로 하고 있다는 가장 분명한 신호다. editor@itworld.co.kr



2021.01.11

'하나의 오픈소스, 많은 기여자' 프로메테우스가 작동하는 아름다운 방식

Matt Asay | InfoWorld
2000여년 전, 로마 역사학자 타키투스는 “모두가 승리는 자신의 공이라고 주장한다”고 했는데, “성공의 아버지는 많다”는 말로 번역되기도 한다. 오픈소스도 비슷하다. 예를 들어 AWS는 최근 그라파나 랩(Grafana Labs)과 협력해 관리형 프로메테우스(Prometheus) 서비스를 구축, 출범했다. 두 회사가 손을 잡고 클라우드 서비스로 이 오픈소스 모니터링 소프트웨어를 제공한다. 정말 보이는 것처럼 간단할까?
 
아니, 그렇지 않다.
 
프로메테우스 서비스가 실행되기까지의 과정에는 여러 기업과 오픈소스 커뮤니티가 각자의 역할을 한다. 프로메테우스를 만든 사운드클라우드(SoundCloud), 스코프(Scope)를 통해 코텍스(Cortex)의 기반 개념을 제공한 하이퍼릭(Hyperic), 모니터링의 비즈니스 가치를 인지한 스프링소스(SpringSource), 그리고 모든 것의 중심에는 깃옵스(GitOps)로 유명하지만 코텍스를 만든 기업이기도 한 위브웍스(Weaveworks)가 있다.
 
ⓒ Getty Images Bank

코텍스의 역사는 그 자체로 오픈소스의 공로 배분 방식에 관한 수업이다. 길고 복잡하고 장황한 이야기지만 이것이 오픈소스가 움직여야 할 본연의 모습이기도 하다.
 

돈과 오픈소스

코텍스의 경우 시작은 돈, 더 정확히는 돈을 벌여야 할 필요성이었다.
 
위브웍스의 CEO 알렉시스 리차드슨은 한 인터뷰에서 “로드(스프링소스 CEO 로드 존슨)와 대화를 나눈 적이 있는데, 그때 로드는 스프링소스의 비즈니스에서 가장 크게 후회되는 부분은 하이퍼릭을 곧바로 인수하지 않고 가치가 계속 올라가도록 뒀던 것이라고 말했다. 그 말이 내 머리에 각인됐다”고 말했다.
 
리차드슨은 오픈소스를 수익화하기 위한 열쇠는 모니터링과 관리임을 확신했고, 결국 2014년 자신이 스프링(Spring)과 v패브릭(vFabric) 제품을 이끌었던(물론 래빗MQ(RabbitMQ)와 같은 다른 제품도 있음) 피보탈(Pivotal)을 나와 위브웍스를 창업했다.
 
리차드슨은 도커 컨테이너 세계가 스프링 애플리케이션 시장과 비슷한 양상으로 전개되어 모니터링과 관리가 중요한 요소가 될 것으로 판단했다. 그래서 탄생한 것이 도커 호스트, 컨테이너, 서비스를 실시간으로 시각화하는 위브 스코프(Weave Scope)다. 스코프는 멋진 오픈소스 프로젝트다. 그러나 그보다 앞서 이야기해야 할 부분이 있다. 스코프가 시작된 곳은 위브웍스가 아니라는 것이다.
 
위브웍스는 컨테이너화된 애플리케이션을 매핑하고 시각화할 방법을 연구하던 중에 전 사운드클라우드 엔지니어인 피터 부르곤을 인터뷰했는데, 인터뷰에서 부르곤이 위브웍스가 구상한 것과 상당부분 일치하는 아이디어를 위해 작업을 해왔음을 알게 됐다. 부르곤은 사운드클라우드에서 친구인 데이비드 칼슈미트(당시 자신이 창업한 타입 타입 타입(Type Type Type)을 경영 중이었음)와 함께 모니터링 및 시각화 솔루션을 개발 중이었고 이것이 리차드슨의 눈에 들어왔다. 두 사람이 위브웍스에 합류했고 이들이 개발 중이었던 초기 모니터링 솔루션이 스코프가 됐다.
 
스코프는 뛰어났지만 메트릭 면에서 보완이 필요했다. 사운드클라우드에서 막 나온 부르곤은 프로메테우스에 빠져 있었고, 메트릭을 구현할 방법으로 프로메테우스를 채택할 것을 회사에 종용했다. 그러나 스코프에 프로메테우스를 추가할 때 문제는 앱의 메트릭을 보려고 할 때마다 아마존 EC2 인스턴스를 가동하는 비용을 누군가가 지불해야 한다는 것이었다. 비용이 상당히 높아질 수도 있었다. 코텍스를 향한 워브웍스의 여정은 수익을 얻기 위한 목적으로 시작되었는데(프로메테우스) 이제는 서비스의 현실화를 위해 비용을 절약할 방법을 찾아야 했다(프로메테우스가 아닌 다른 것으로).
 
위브웍스는 뭔가 다른 것을 시도해야 했다. 겉으로는 프로메테우스와 비슷하지만 메트릭을 볼 때마다 프로메테우스 인스턴스를 가동해야 하는 비용 없이, 프로메테우스와 비슷한 메트릭을 제공할 수 있는 서비스가 필요했다.
 

프로메테우스를 가동하는 또 다른 방법

그 ‘뭔가 다른 것’이 전혀 다른 설계를 사용하는 코텍스였다. 리차드슨은 코텍스가 “프로메테우스에서 많은 코드를 가져왔지만 접근 방법은 아파치 카산드라에 더 가깝다”고 말했다. 즉, 아무 것도 공유하지 않고 샤딩된 속성이 있으며 데이터 저장을 위한 협력 없이 모든 데이터가 시스템의 다양한 지점으로 간다. 위브웍스 서비스는 프로메테우스처럼 보이고 프로메테우스와 같은 스타일의 메트릭을 사용하여 프로메테우스에 연결할 수 있지만 프로메테우스와는 다르게 설계됐다.
 
“오픈소스 공로 인정의 시작과 끝은 어디인가”라는 이 주제를 더욱 심화하는 요소는 위브웍스 설계 팀에 톰 윌키가 설계 리드로 소속됐다는 점이다. 현재 톰 윌키는 그라파나 랩에 속해서 코텍스 개발을 계속 이어 나가고 있다(켈시 하이타워가 말한 “같은 팀, 다른 회사”의 양상). 그러나 윌키는 풍부한 카산드라 경험을 등에 업고 위브웍스에 합류했고 이것이 코텍스 설계의 틀을 잡는 데 도움이 됐다. 이 팀에는 사운드클라우드 시절 프로메테우스를 공동 창업했으며 현재 위브웍스 자문으로 활동하는 줄리우스 볼츠도 포함됐다.
 
회사 창업자들은 쿠버네티스가 부상하면 프로메테우스가 성공하고 코텍스는 SaaS 수익화 경로를 실현해줄 것이라고 생각했다. 그러나 현실적으로 기술과 비즈니스 모두 개발하는 데에는 시간이 걸렸다. 위브웍스의 특별 엔지니어인 브라이언 보어햄은 코텍스를 현재의 성공으로 이끌기 위해 얼마나 많은 작업이 필요했는지를 강조했다.
 
코텍스는 몇 년의 작업 기간 동안 많은 부분이 다시 작성되고 다시 설계됐다. 테세우스의 배와 같다. 목재가 여러 번 교체됐다. 위브웍스에서 몇 년 동안 지속적으로 프로덕션을 거쳤다. 기본적인 부분은 원활했지만, NoSQL 측면에서 스키마 버전 11을 사용했다. 수많은 재고를 거쳐 사실상 NoSQL의 대부분을 프로메테우스 자체 시계열 데이터베이스와 비슷한 패턴으로 교체했다. 
 
시초의 코텍스는 유망했지만, 보어햄은 “광범위한 분산 시스템”에서 실행됨에도 불구하고 프로메테우스보다 속도가 현저히 느렸다고 말했다. 위브웍스는 코텍스의 속도를 높이기 위해 많은 노력을 기울였고(캐시 추가, 속도 저하 지점을 찾기 위한 재거(Jaeger) 트레이싱 등), 적어도 지난 2년만 보면 코텍스의 속도가 프로메테우스보다 빨랐다.
 
리차드슨은 코텍스의 약속을 현실화하기 위한 과정에 박차를 가한 네 가지 요소를 언급했다. 첫 번째는 대중을 위한 실제 서비스 실행에 연계됐다는 점이다. 리차드슨은 “프로메테우스를 온디맨드 방식으로 제공하기 위해 코텍스 서비스를 실행하면서 실제 환경에서 코텍스를 어떻게 실행해야 하는지에 관해 많은 것을 배웠다”고 말했다. 두 번째는 “다른 방법으로 해결하기 매우 어려운 실제 문제를 해결한다”는 점이다. 셋째, 위브웍스와 급성장 중인 코텍스 커뮤니티(현재 디지털오션(DigitalOcean) 등의 엔지니어들이 활발하게 참여 중)는 코텍스를 원래의 다이나모DB/아마존 S3 백 엔드에서 분리하는 결정을 내렸다. 리차드슨은 “더 많은 곳에서 실행이 가능하고 AWS에 묶이지 않으므로 유용성이 더 높아졌다.”고 말했다. 네 번째는 “오픈소스의 마법”이다. 위브웍스는 코텍스를 CNCF로 가져가서 노출을 늘려 큰 탄력을 받았다.
 
이 마법은 여전히 코텍스의 가장 중요한 기여자인 위브웍스가 더 이상 모든 짐을 혼자서 끌 필요가 없음을 의미한다. 현재 코텍스의 가장 큰 기여자는 그라파나 랩이지만(위브웍스가 두 번째) 레드 햇, 로빈후드(Robinhood), 스플렁크(Splunk), 디지털오션을 비롯한 다른 많은 기업도 적극적으로 참여하고 있다. 이는 오픈소스의 놀라운 “마법”을 보여주는 신호이자 위브웍스가 한 벤더의 통제가 아닌 진정한 오픈소스 커뮤니티 거버넌스 모델을 성공적으로 촉진하고 있음을 보여준다.
 
이것이 원래 오픈소스가 움직이는 방식이다. 로키(Loki, 프로메테우스에서 촉발된 오픈소스 로깅 프로젝트) 또는 엔보이(Envoy)와 같은 프로젝트는 한 회사에서 시작되어 다른 회사에서 더 심층적으로 개발되고 또 다른 많은 기업을 거쳐 운영화되고 향상된다. 로키의 개념은 톰 윌키가 위브웍스에서 고안했지만 개발한 것은 그라파나 랩이다. 엔보이는 리프트(Lyft)의 맷 클라인이 시작했지만 작년의 가장 큰 기여자는 구글이다. 다른 많은 오픈소스 프로젝트도 같은 패턴으로 움직이고 있다.
 
버그가 아니라 기능이란 말처럼 이러한 패턴은 문제가 아니라 정상이며, 오픈소스를 제대로 하고 있다는 가장 분명한 신호다. editor@itworld.co.kr

X