원조 SaaS 회사의 멀티테넌트 아키텍처 비결

안녕하세요 구독자 님

주간 SaaS 는 B2B SaaS 비즈니스 모델과 기술 아키텍처 설계를 일 로 하는 사람들이 한 주가 배움의 과정에서 만난 좋은 SaaS 기술 및 SaaS 비즈니스 관련 콘텐츠를 모아 짧은 요약과 함께 제공하는 뉴스레터 입니다.

주간 SaaS 뉴스레터에 담길 콘텐츠는 SaaS 기술 팀을 위한 콘텐츠와 SaaS 비즈니스 팀을 위한 콘텐츠가 사이좋게 담깁니다.

구독자 님 주변에 SaaS 와 관련된 좋은 콘텐츠를 찾고 있는 SaaS 기술 팀, SaaS 비즈니스 팀이 있다면 주간 SaaS 메일을 포워딩 해주세요 🙏🏼

호기심을 바탕으로 늘 배움을 멈추지 않는 마음으로 주간 SaaS 시작 합니다.

주간 SaaS 는 SaaS 기술, SaaS 비즈니스 콘텐츠 순서로 구성 됩니다.

SaaS 기술

세일즈포스가 퍼블릭 클라우드에서 대규모 멀티테넌트 kuberntes 클러스터를 운영하는 방법

원조 SaaS 격으로 SaaS, 멀티 테넌트 사례를 이야기하면 빠지지 않는 Salesforce는 2015년부터 워크로드를 Kubernetes 기반으로 운영해오고 있고 시간이 지남에 따라 비즈니스가 크게 성장하며 다양한 플랫폼 운영 이슈들이 발생했다고 합니다.

오늘 소개할 세일즈포스(Salesforce) 팀의 아티클은 대규모 멀티 테넌트 Kubernetes를 운영하면서 만난 그 다양한 문제들을 어떤 방식으로 해결해 왔는지 보여 줍니다. 

많은 B2B SaaS 기업들이 Kubernetes 기반의 멀티 테넌트 아키텍처를 선택 합니다.(*표준이 되어가는 것 같은 기분이 들 정도) 멀티 테넌트 원조집은 어떤 비결이 있는지 살펴볼 수 있는 기회 입니다.

아래 한글로 짧게 정리 했습니다. 하지만 Salesforce가 사용한 도구와 추가적인 자세한 설명이 있는  원문을 꼭 함께 보시길 추천 합니다.👍🏼

-

프로비저닝과 관리 문제

Public cloud 상에서 k8s 를 운영하면서, control/data plane 의 수명주기를 관리하는 방법을 찾아야 했습니다. k8s 와 운영 체계 업데이트 등 의 클러스터 업데이트가 필요할 때 한 번에 이를 할 수 있는 방법도 필요했습니다.

✅이를 위해 Spinnaker, Terraform, Helm 을 활용하고 있습니다. 또한 클러스터 관리를 위해서 node recycler 를 개발해서 사용중입니다. 이는 곧 오픈소스화 될 예정입니다.

클러스터 가시성 문제

팀마다 클러스터를 관리하고 있기 때문에 개별 상태와 몇 개가 돌아가고 있는 지를 알지 못했습니다. 이를 중앙집중적으로 파악하고 관리하는 모니터링 시스템이 필요했습니다.

✅ 클러스터의 추세를 확인할 수 있는 파이프라인을 구축했으며, kafka와 mysql 을 이용하고 있습니다. mysql 과 연결되어 있는 http 서버를 통해 kubeapi 형태의 rest api 요청을 받으면 이를 mysql 쿼리로 변환해서 수행후 결과를 클라이언트에게 전달하는 형태로 구축하였습니다. 이렇게 구축해 놓고, k8s 의 상태를 중앙으로 저장해 놓으니, 수백개의 클러스터에 대한 가시성을 확보할 수 있었습니다. 이를 바탕으로 전체적인 클러스터 시각화를 위해

을 사용 합니다.

어플리케이션 배포 문제

많은 마이크로서비스를 배포하면서 배포 모니터링이 필요해졌고, 서로 다른 배포 전략을 이용해야 할 순간들도 생겨났습니다.

✅ Helm 과 Spinnaker 를 통해 어플리케이션 수명 주기를 관리하였으며, 새로운 버젼을 배포할 때에는 Argo 를 사용합니다.

웹훅과 사이드카 관리

웹훅과 사이드카를 관리할 수 있는 솔루션이 필요했습니다.

✅ 사이드카를 사용할 때에 사이드카 구성과 사이드카의 injection을 trigger 하는 것을 분리해서 다양한 팀이 자유롭게 사용할 수 있도록 솔루션을 개발했습니다. 여기에서 확인 할 수 있습니다.

클러스터 네트워크 문제

클러스터 내 어플리케이션 간, 외부 어플리케이션 간 등 다양한 부분의 네트워킹을 안전하게 관리할 수 있는 기능이 필요했습니다.

✅ 서비스 간 인증을 위해 Istio 를 이용합니다.

코드 체크인과 런타임 시점에서의 문제

보안 문제 발견 시, 개발자가 코드 체크인을 하지 못하게 하는 사전 코드 scanning 도구가 필요했으며, 런타임 시점에과 요청에 대한 응답 상황에서도 보안 문제를 scanning 하는 도구 또한 필요했습니다.

✅ 런타임에 보안 정책을 적용하기 위해 OPA(Open Policy Agent) 를 도입했습니다.

클러스터 내 서비스 사용량 측정

서비스에 따른 정확한 비용을 산정하기 위해 데이터를 수집하고 볼 수 있는 공간이 필요했습니다.

✅ 테넌트 별로 리소스 소비량, RAM/ CPU 할당량과 같은 지표들을 볼 수 있는 대시보드를 만들어서 사용중입니다.

코드 배포 문제

다중 가용 영역에서의 배포를 했어야 했습니다.

✅ 통신 비용 오버헤드를 해결하기 위해 일부 어플리케이션은 단일 가용 영역에서 운용하고, 다른 가용 영역은 장애 조치용으로 사용하는 것을 목표로 하고 있습니다.

SaaS 비즈니스

우리가 MVP 전략을 따르지 않은 이유

MVP(Minimum Viable Product) 전략은 많은 기업들이 제품 출시 과정에서 선택하는 전략 입니다. 빠른 피드백 수집과 개선의 순환을 만들어 소위 시장에 먹히는 제품(Product Market Fit)을 찾을 수 있기 때문이죠.

그런데 이 전략이 늘 정답은 아닌 것 같습니다. 특히 B2B SaaS 는 B2C SaaS 대비 사용자(User) 혹은 구매자(Buyer)가 기대하는 제품의 수준이 높은 편입니다. 생각해보면 당연한 것 같습니다. 우리에게 돈을 벌어다주는 비즈니스에 사용하는 제품에 대한 기대치는 높을 수 밖에요. 실제로 B2B SaaS 제품을 출시한 CTO 한 분도 비슷한 말씀을 하신적이 있습니다.

소개하는 아티클 역시 MVP 전략이 늘 옳은 것은 아니라고 이야기 합니다. Rockelane Co-founder 이자 CEO인 저자는 이 글을 통해 자사의 제품 개발 과정에서 MVP 가 아닌 상당 수준 완성된 제품을 바탕으로 잠재 고객을 확보해 나갔으며 이것이 MVP 대비 효과적 이었던 이유를 설명 합니다. 아래에 내용을 한글로 정리 했습니다.

-

MVP(Minimum Viable Product) 전략은 일반적으로 많은 스타트업들 제품을 검증하기 위한 첫 번째 단계로 선택하는 전략이다. MVP를 사용하면 초기 버전 제품을 신속하게 출시하여 개선을 위한 고객 피드백을 수집할 수 있다. 이것을 통해 스타트업은 우리 제품의 특별한 셀링 포인트를 찾을 수 있다.

Rockelane은 조금 다른 전략을 선택했다. 우리는 MVP 전략 대신에 완전한 기능을 모두 갖추고 성숙한 상태의 제품을 가지고 잠재 고객에게 사용을 요청하고 피드백을 얻었다.

제품을 출시하는 다양한 전략이 있다는 관점에서 우리가 선택한 접근 방식 역시 MVP 전략 만큼이나 고려해볼만 하다고 생각하며 그 이유는 다음과 같다.

왜 틀(MVP전략을 따르는)을 깼을까?

MVP 는 새로운 시장의 새로운 제품을 만들 때나 작은 고객 군을 대상으로 한 간단한 포인트 솔루션을 만들 때 잘 작동하는 전략 입니다. 하지만 만약 여러분의 제품이 특수한 목적을 위해 사용 되며 이미 시장에서 성숙 단계에 접어든 horizontal 제품을 대체해야 상황에 있다면, MVP 를 바탕으로한 제품 전략은 성공하지 못할 겁니다.

우리 제품의 핵심 기능을 이야기할 때 “all in one” 과 “통합” 기능은 매우 중요한 부분이었다. 따라서 우리팀은 이 중요한 요소를 달성하는 필요한 구성 요소들을 가장 첫 번째 버전의 제품에 반영하여 상당히 다양히 다양한 기능을 갖춘 제품을 고객에게 제공해야 했다. 고객의 관심을 끌기위해 우리 초기 버전 제품 역시 이미 시장에 나와 있는 horizontal solution이 제공하는 기능의 80% 이상은 고객에게 약속 해야만 했다.

집중을 방해하는 접근

만약 여러분이 이미 시장에 안착해 각기 개별적으로 제공되는 기능/도구 를 한곳에 모아 “all-in-one” 형태의 제품을 만들고 있다고 가정하자. 이때 만약 각 기능/도구를 일종의 모듈 단위로 나눠 MVP 형태로 개발한 잠재 고객에게 제공하여 테스트 하는 것은 좋은 생각이 아니다. 왜냐하면, 고객의 피드백은 그 모듈 단위에 한정될 것이며 이는 당신을 “all-in-one” 제품을 만들어 시장에 진출 한다는 당신의 비전이 아닌 개별 모듈 단위에 집중하게 하게 만들 것이다. 결국 이것은 “all-in-one” 제품의 완성도에 기여하는 테스트가 되지 않을 것이다.

이것보다 완벽한 비전과 차별성을 가진 제품을 고객에게 제공 한다음 이것이 포함하고 있는 구체적인 기능별 피드백을 받고 이를 개선하는데 시간을 할애하는 접근이 낫다.

제품을 적시에 만들기

MVP 보다는 늦은 시점에 완전한 기능을 모두 갖춘 제품을 통해 잠재 고객과 소통을 시작하는 또 다른 이유는 고객들은 민첩성과 제품의 인도 속도를 중요한 기준으로 생각하기 때문 입니다. 예를 들어서 고객은 어느 정도 완벽함이 떨어지는 제품의 개선을 기다려주는 것에 환멸을 느낄 수 도 있습니다. 반면 80% 정도의 완성도를 갖춘 제품이라면 고객이 빠르게 사용하고 그들의 피드백을 수집하고 개선하는 과정을 거쳐 PMF(Product Market Fit)을 찾는 것을 어렵지 않게 달성 할 수 있을 것 입니다.

또한 고객은 이미 여러분의 제품이 성공적으로 작동하는 모습을 보기 때문에 여러분의 제품 비전과 가치를 보다 잘 이해할 수 있을 겁니다.

위험 관리

제품 개발 단계의 후반부에 잠재 고객을 제품 검증과정에 참여 시키는 것은 다소 위험할 수 있습니다. 잠재 고객을 참여 시키기 보다는 여러분의 제품을 리뷰 해줄 패널 정도를 참여시키는게 좋습니다. 이 패널들을 설계 단계에 부터 참여 시켜 여러분의 제품의 완전한 모습을 담고 있는 모형(Mockup)또는 데모를 보여주고 피드백을 받을 수 있다면 여러분들은 제품의 잠재적인 리스크를 줄여 나갈 수 있을 겁니다.

성숙한 제품이 가장 실행 가능한 제품이다.(most viable product)

특히 horizontal 하고 경쟁이 심한 시장에서는 제품을 만드는 전략이 하나 이상이다. MVP 를 만드는 대신, 고객에게 혁신적인 경험을 줄 수 있는 폭 넓고 준비된 제품을 만들 필요가 있을 겁니다. 결국 이것은 여러분의 제품의 특별한 셀링 포인트를 만들고 여러분의 제품이 특정 유즈 케이스에서 최고의 선택인지 보여줄 겁니다.

--

이번 주간 SaaS 여기서 마무리 합니다. 이번 주간 SaaS 에서 다룬 콘텐츠에 대한 여러분의 의견이 궁금합니다. 아래 👇🏽댓글에 남겨 주세요. 함께 토론하며 배움을 확장하면 좋겠습니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요