이름만 SaaS 인것을 조심해야 하는 이유

안녕하세요 구독자 님

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

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

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

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

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

SaaS 기술

대규모 트래픽을 위한 Shopify 의 멀티 테넌트 아키텍처

Shopify 는 미국 내 이커머스 시장에서 총 거래금액 기준으로 아마존에 이은 2위의 이커머스 서비스 기업 입니다. Shopify 는 셀러라 불리는 고객에게 손쉬운 온라인 스토어를 제작 부터 쇼핑몰 호스팅, 쇼핑몰 운영에 필요한 각종 편의 서비스를 제공 합니다.

Shopify 의 플랫폼은 멀티 테넌트 아키텍처로 이루어져 있습니다. 따라서 Shopify 에게는 특정 셀러의 예고 없는 대규모 판매 행사로 인한 부하가 아키텍처 전반에 가중되는, Noisy Neighbor 가 아주 중요한 문제 입니다.

이 영상에서 Shopify 는 자신들의 아키텍처가 싱글 테넌트로 시작해 대규모의 멀티 테넌트 서비스를 안정적으로 운영 하기까지의 과정을 몇 개의 기술적 변곡점을 예로 들며 소개 합니다.

개인적으로 인상적 이었던 부분은 Pod 이라는 독특한 개념을 바탕으로(*Kubernete의 Pod 이 아님) 멀티 테넌트간 격리를 유지하며 Noisy Neighbor 문제 해결과 아키텍처의 안정성(Resiliency)까지 달성한 부분이었습니다. 특히 Shopify 를 통해 생성된 온라인 스토어(테넌트)로 트래픽을 라우팅 하기 위해 OpenResty를 활용한 부분이 인상적 이었습니다.

멀티 테넌트 환경에서의 Noisy Neighbor 문제 그리고 테넌트 별 요청에 대한 라우팅 문제는 멀티 테넌트 아키텍처를 설계하면 만나게 되는 단골 주제 인데요, 이를 해결하는데 힌트를 얻을 수 있는 좋은 콘텐츠 입니다.

마지막으로 세계에서 가장 큰 플래시 세일을 처리하기 위한 Shopify 의 아키텍처 라는 제목의 발표도 함께 보면 좋은 콘텐츠 입니다.

--

SLO와 Error Budgets을 통해 서비스 신뢰성 관리 하기

SaaS 운영팀 입장에서 SLA(Service Level Agreement) 는 고객과의 약속이 될 뿐 아니라 SaaS 아키텍처의 건강 상태를 평가 할 수 있는 중요한 기준점이 됩니다. 그리고 이 SLA 는 SLO(Service Level Objective), SLI(Service Level Indicator) 를 바탕으로 하고 있습니다.

SaaS 기술팀은 사전에 정한 SLI 와 SLO 를 기준으로 우리가 무엇을 모니터링 하고 개선해 나가야 하는지 이해할 수 있습니다. 따라서 명확한 SLI, SLO 가 SaaS 서비스 기술팀의 명확한 목표가 되기 때문에 정교하고 합리적으로 설정된 SLO, SLI 를 정의 할 필요가 있습니다.

이 아티클은 SLO와 SLO 임계치를 상대로적으로 표현하는 Error Budget 이 어떻게 서비스 신뢰성 향상에 도움을 주는지 간단한 예시와 일러스트로 설명 해주고 있습니다. 다음은 간단한 요약 입니다.

SLO와 SLI 는 무엇일까?

Error Budget은 무엇일까?

어떻게 SLO와 Error Budget이 서비스 신뢰성 유지에 도움을 주는걸까?

SaaS 서비스 출시 전 엔지니어링 팀이 무엇을 어떻게 모니터링 하고 측정해야 하는지 고민하는 모습을 많이 봤습니다. 이 아티클이 그 힌트를 찾는데 도움이 되면 좋겠습니다.

--

SaaS 기반 API 서비스를 위한 사용자 미터링 서비스 아키텍처

일반적으로 SaaS 서비스들은 사용량 기반 과금 정책을 선택하는 경우가 많이 있습니다. 사용량 기반 과금 정책을 위해 필요한 기본은 정확하게 사용자 또는 테넌트의 서비스 사용량을 측정 하는 것입니다. 우리는 이것을 미터링이라고 합니다. 이 미터링된 데이터는 최종적으로 사용자 또는 테넌트에게 부과되는 사용 요금 산정의 기초 데이터가 되기 때문에 적시적소에 정확하게 수집되어야 합니다.

AWS 에서 제공하는 이 실습 안내서는 Amazon API Gateway 를 통해 API를 제공하는 SaaS 서비스를 가정하여 사용자의 API 사용량을 측정하는 아키텍처를 구성 방법을 예제 코드와 함께 제공 합니다.

실제로 Asleep 이라는 국내의 스타트업이 Youtube 를 통해 자사의 B2B API SaaS 서비스 미터링을 위해  이 아키텍처 패턴을 실제 운영 서비스에 반영한 경험을 나누기도 했습니다.

SaaS 미터링을 어디서 부터 시작해야 할 지 막막해 하는 모습을 종종 봐왔습니다. 이 콘텐츠가 여러분의 SaaS 서비스를 위한 미터링 구조 설계에 도움이 되면 좋겠습니다.

SaaS 비즈니스

버티컬 SaaS 의 기회

흥미로운 문장으로 시작하는 이 글은 Vertical SaaS 가 무엇인지, Vertical SaaS 전략이 어떤 장점을 발휘할 수 있는지 쉽게 풀어 설명 해주고 있습니다. 다소 생소할 수 있는 Vertical SaaS 라는 주제를 다루는 이 글에서 인상적인 부분들은 이렇습니다.

Vertical SaaS vs Horizontal SaaS의 차이점

Vertical SaaS 장점

실제로 Vertical SaaS 로 자리 잡은 기업들의 MS(Market Share) 예시도 들고 있어 Vertical SaaS 가 생소한 분들께 좋은 배움의 기회가 되는 글 입니다.

--

이름만 SaaS 인것을 조심해야 하는 이유

🔗레포트 전체 읽어보기(pdf파일)

B2B SaaS 시장이 급성장 하면서 다양한 서비스들이 나오고 있어 SaaS 서비스 구매자 입장에서는 고민이 늘어 갑니다. "이 SaaS 서비스 도입 결정이 옳바른 결정 일까? "이 SaaS 서비스를 통해 우리의 문제를 해결할 수 있을까?"

따라서 좋은 SaaS 서비스를 판별하는 "눈"을 가질 필요가 있는데요, 이런 "눈"은 SaaS 서비스를 만드는 공급자 입장에서도 필요합니다. 이 눈을 바탕으로 좋은 SaaS 를 만들어 구매자로 부터 선택을 이끌어낼 수 있으니까요.

Forrester 가 2014년 발행한 이 레포트 는 "좋은 SaaS 서비스라면 이런 모습 이어야해!" 라고 말하고 있어 SaaS 를 만들어가는 팀에서 꼭 보았으면 하는 레포트 입니다. 게다가 2014년 이면 미국에서도 막 B2B SaaS 시장이 성장하던 시점이어서 지금의 우리에게 많은 인사이트를 줍니다.

레포트 내용 중 SaaS 를 만드는 사람 입장에서 중요한 포인트 일부를 골라 번역한 것을 아래 남겨 두었습니다. 시간을 내어 레포트 전문을 읽어보시는 것도 추천 드립니다.

SaaS? Not SaaS? 어떻게 알수 있을까? 그리고 왜 알아야 할까?

당신이 오래된 HCM(Human Capital Management)시스템을 보다 유연하고 최신의 비즈니스 프로세스를 수용할 수 있는 현대화된 솔루션으로 변경 하기로 마음 먹었다고 가정해보자. 이럴 땐 특별히 고민할 필요 없이 SaaS 도입을 고려해볼만 하다.

자 당신의 전략 벤더들 가운데 한곳이 꽤나 매력적인 HCM SaaS 솔루션을 보유 하고 있다. 클라우드 기반이고 모바일 접근도 가능하다! 기능 업그레이드도 선택할 수 있고 SLA, 보안 그리고 심지어 배포 옵션 역시 설정 가능하다. 그런데 최소 5년 단위의 연간 계약을 커밋해야 한다. 음 이게 정말 SaaS 일까? 매력적인 솔루션으로 보이지만 장기적으로 봤을 때는 그렇지 않을 수 있다.

SaaS washed 세계에 온 걸 환영해

시장이 SaaS와 클라우드에 대해 많은 관심을 가질 수록, 솔루션 벤더들 역시 자사의 솔루션을 SaaS 중 하나로 시장에 인식시켜야 할 필요가 있다고 느낀다. 그래야만 바이어의 구매 선택지에 들수 있으니까! SaaS 가 전통적인 모델을 먹어 치우고 있지만 여전히 많은 카테고리에서는 SaaS 는 진입 초기에 있는게 사실 이다. 그래서 이런곳에서는 위와 같은 상황이 더욱 자주 목격된다. 극단적으로는 SaaS 인지 아닌지 차이점을 정확히 알지 못하고 도입을 결정 했다가 나중에 내 선택이 SaaS 가 아니었다는 것을 깨닫게 되기도 한다.

클라우드 그 이상의 SaaS

CIO가 SaaS 도입을 고려할 때 SaaS 로 부터 기대하는 것들은 이렇다.

더 나은 비용효율성을 제공하는 멀티 테넌트

SaaS 는 일반적으로 멀티테넌트 형태로 제작 된다. 멀티테넌트를 통해 서비스가 모든 고객에게 동일한 기능을 제공 한다. 모든 고객에게는 사실상 사든지, 사지말든지(take it or leave it) 이다. 고객 별로 원하는 커스터마이징은 사실상 극히 제한적이다. 이런 접근을 통해 SaaS 공급자는 기능 하나 제작에 들어가는 비용을 여러 고객에게 분산시킬 수 있으며 이를 통해 낮은 운영 비용을 기대할 수 있다. 그리고 결국 이것 낮은 가격 책정이 가능하게 한다.

민첩함을 극대화 하는 하나의 구현체

모든 고객들은 현재 동일한 버전의 애플리케이션을 사용하기 때문에 SaaS 벤더들은 새로운 기능과 버전을 빠르게 배포할 수 있다. 예를 들어 CI/CD 프랙티스를 도입한 벤더들의 경우 새로운 기능과 버전을 격주 마다 빠르게 배포할 수 있고 이를 바탕으로 보다 빠르고 많은 가치를 얻어갈 수 있다. 만약 이런 형태가 아니라 모든 고객들이 그들을 위한 고유한 버전을 사용하고 있다면 고객들은 아마도 새로운 메이저 업그레이드를 연 단위로 기대할 수 밖에 없을 것이다.

구독과 사용한 만큼 과금하는 모델은 큰 비용 유연성을 제공한다

SaaS는 보통 구독 형태나 종종 사용한 만큼 과금되는 형태를 따르며 이것은 고객에게 예측 가능한 비용이라는 장점을 제공한다. 실제로 어떤 SaaS 벤더들은 다른 벤더들이 최소 약정 또는 upfront payment 를 요구하는 반면 철저히 사용한 만큼 과금되는 모델을 제공한다. 이런 과금 모델을 통해 SaaS 구매 고객은 손쉽게 새로운 솔루션을 검토하고 테스트 한다음 검증이 되면 본격적인 사용 및 도입을 확대할 수 있는 기회를 가져갈 수 있다.

셀프 서비스와 자동화된 배포

SaaS 구매 고객은 단지 웹 페이지 이상의 것을 요구한다. 그들은 서비스가 사람의 개입, 세일즈 콜, 서비스 티켓, 또는 아주 긴 조달 과정없이 완전 자동으로 15분 이내로 배포될 수 있어야 한다. 즉 모든 조달 과정은 완전 자동화가 되어 있기를 기대한다. SaaS 벤더 입장에서도 이것은 가장 기본적으로 갖춰야 하는 덕목이다. 왜냐하면 솔루션을 고객에게 제공하는데 며칠 또는 몇 주가 걸린다면 이것은 배포를 위한 추가적인 비용이 발생한다는 것을 의미하고 궁극적으로 고객 경험에 좋지 않은 영향을 주기 때문이다.

비즈니스 사용자를 위한 증가된 자율성

조사에 따르면 고객 입장에서 SaaS 솔루션으로 부터 얻는 주요 장점 가운데 하는 비즈니스 민첩성이다. 즉 SaaS 를 통해 보다 빠르게 혁신하고 빠르게 변화 하는 비즈니스 전략에 따라 그들의 기술 체계를 신속하게 변화시킬 수 있다. 그럼 왜 SaaS 만이 이런 장점을 줄 수 있는걸까? SaaS 벤더들이 비즈니스 담당자들에게 보다 친숙하고 쉽게 사용할 수 있는기능과 도구를 제공하기 때문이다. 예를 들어 일부 SaaS 솔루션들은 비즈니스 담당자들이 IT 팀의 지원과 기술적인 노하우 없이 쉽게 필요한 레포트를 만들고 애플리케이션의 형태 일부를 변경하고 제 3자 도구를 추가할 수 있는 환경을 제공 한다. (이를 바탕으로 비즈니스 담당자들은 혁신의 속도를 높일 수 있다)

--

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

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