온프레미스 설치형 소프트웨어 성장은 멈추지 않았다

안녕하세요 구독자 님

주간 SaaS 는 B2B SaaS 비즈니스 모델과 기술 아키텍처 설계를 일 로 하는 사람들이 한 주간 배움의 과정에서 만난 좋은 콘텐츠를 골라 담은 뉴스레터 입니다. SaaS 비즈니스 모델과 이를 구현하는데 활용되는 다양한 기술(Technology)에 관한 콘텐츠를 균형있게 담았습니다.

이번에는 SaaS 비즈니스 주제 2 가지와 SaaS 기술 주제 1 가지를 준비해 보았습니다. 재밌는 글들을 발견해서 생각보다 뉴스레터가 길어졌는데, 커피 한잔과 함께 읽어보시면 좋을 것 같습니다. :-) 

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

인프라는 곧 유통 입니다.

Canva 는 누구나 훌륭한 디자인 결과물 을 만들어 낼 수 있도록 돕는 도구를 SaaS 형태로 제공 합니다. 어느새 기업 가치는 데카콘이 되었습니다.

Canva engineering 블로그에 게시된 “Infrastructure is Distribution” 이라는 제목의 아티클을 한글로 의역해봤습니다.

일반적으로 B2B SaaS 기업은 두 개의 플랫폼을 통해 태어나고 성장 한다고 생각 합니다. 서비스가 구동되는 환경을 제공하는 상용 클라우드 플랫폼과 서비스를 고객에게 전달하는 과정(우리가 흔히 말하는 배포 또는 딜리버리)에서 활용되는 내부 개발 플랫폼이 그 두 개 입니다. B2B SaaS 기업이 성장하며 이 두 개의 플랫폼의 진화를 고민 합니다. 이 고민에는 수익성, 성장성, 성능, 효율성, 생산성, 미래 가치 등 많은 요소가 결부되어 있습니다.

이 글은 Canva가 이 고민을 어떻게 바라보고 있으며 어떤 계획을 갖고 있는지 보여 줍니다. 너무 멋진 생각에 개인적으로 흥분하며 읽었습니다. 원문도 꼭 함께 보시길 추천 합니다!

▼

우리가 인프라 엔지니어링을 가치를 더하는 것으로 포지셔닝 하는 방법

Canva의 인프라(Infra) 그룹은 빠르게 성장하고 있습니다. 이 그룹은 엔지니어링 워크스테이션, 소프트웨어 개발 도구, 생산 워크로드 스케줄링, 확장 가능하고 내구성 있는 데이터 저장소 그리고 가장 중요한, 제품 엔지니어링 팀과 함께 전 세계 모든 사람이 무엇이든 디자인하고 어디서든 게시할 수 있게 하는 중요한 부분을 책임지는 약 200명의 엔지니어로 구성되어 있습니다.

인프라는 Canva 사용자가 이미 알고 있거나 관심 갖을 제품을 만들어 출시하는 엔지니어링 그룹이 아닙니다. 누군가는 인프라를 비용을 만드는 부분(Cost Center)으로 생각할지 모릅니다. 하지만 저희는 조금 다르게 인프라를 바라보고 있습니다. 즉 인프라는 Canva의 비즈니스 모델에 가치를 더하는 핵심적인 차별화 요소로 보고 있습니다.

인프라 엔지니어링은 유통입니다

닷컴 이전 시대에는 유통이 비즈니스 비용에서 가장 큰 비중을 차지하며 핵심적인 차별화 요소 였습니다. 예를 들 포드 모델 T와 같은 획기적인 제품을 설계하고 프로토타입을 검증한 후에는 제조, 배송, 창고 보관 및 배송이 포드의 차별화 요소가 되었습니다. 또 다른 예로, 맥도날드가 전 세계를 지배 하게 된 것은 치즈 버거덕이 아니라 부동산 제국과 양질의 제품을 대규모로 재생산할 수 있는 능력 덕분이었습니다. 시장에 맥도날드 보다 더 좋은 햄버거가 있다고 장담할 수 있지만, 맥도날드처럼 유통망을 확장할 수 있는 기업은 없습니다.

포드와 맥도날드는 경쟁사보다 더 효과적으로 제품을 고객에게 전달하고 고객 만족도를 유지할 수 있었습니다. Canva와 같은 최신 SaaS(서비스형 소프트웨어) 기업에게 인프라 엔지니어링을 통한 배포는 포드와 맥도날드의 유통망 입니다. Canva 제품 팀이 시장의 요구를 충족하는 제품을 개발할 때, 짧은 지연 시간, 고가용성, 완벽한 내구성, 타협하지 않는 보안 및 개인 정보 보호로 제품을 사용자에게 경쟁사보다 앞서 제공해야 하는 Infra는 Canva의 운명을 함께 책임집니다.

대규모 배포(유통) 체계 구축은 아직 해결된 문제가 아닙니다

eBay나 Yahoo와 같은 기업은 자체 유통망을 구축하지 않고도 수백만 명의 사용자에게 제품을 제공할 수 있게 되었습니다. 인터넷은 고객이 하루 중 언제라도 집에서 편안하게 방문할 수 있는 저렴하고 쉽게 액세스할 수 있는 플랫폼을 만들었습니다. 그리고 클라우드 컴퓨팅이 등장했습니다.

이제 인터넷을 통한 배포의 어려운 부분 중 많은 부분을 강력하고 정교한 서비스를 제공하는 세계적 수준의 클라우드 컴퓨팅 제공 업체에 아웃소싱할 수 있게 되었습니다.

그렇다면 배포를 담당하는 인프라 엔지니어가 필요한 이유는 무엇 일까요? 사실 대부분의 소규모 기업은 필요하지 않을 수 있습니다. 클라우드 제공업체와 서비스형 플랫폼(PaaS) 제공업체는 소규모 기업이 겨우 상품화 기술 역량만을 활용해 수백만 명의 사용자에게 제품을 제공할 수 있는 여러 서비스를 제공 합니다.

그런데 만약 수천만 또는 수억 명의 사용자에게 도달하거나 페타바이트 또는 엑사바이트의 데이터를 제공하고자 하는 다른 레벨의 기업에게는 어떤 옵션이 있을까요?

대규모 배포 체계 구축은 아직 해결된 문제가 아닙니다. 제가 생각하는 인터넷을 통한 배포를 위한 솔루션은 규모에 따라 세 가지로 분류할 수 있습니다. 바로 아웃소싱, 통합, 맞춤형 입니다.

아웃소싱

아웃소싱은 대부분의 기업이 처음 선택하는 옵션 입니다. 배포 요구 사항이 아직 차별화 되어 있지 않으므로 거의 모든 것을 클라우드/PaaS 제공업체에서 제공하는 서비스를 통해 아웃소싱하고 제품/시장 적합성을 개발하는 데 집중할 수 있습니다.

통합

통합은 배포 요구 사항이 이제 단일 클라우드/PaaS 제공업체가 제공하는 서비스를 통해 커버할 수 없을 정도로 다양해지고 복잡해져서 여러 제공업체의 솔루션을 통합해야 하는 기업들이 선택하는 옵션 입니다. 여기에 해당되는 기업은 AWS, Github, BuildKite, Datadog, Sentry.io, Snowflake, Snyk 등으로부터 많은 비용을 지출 하기도 합니다. 제품 팀을 위해 이러한 솔루션들을 선별하고 하나의 일관된 플랫폼으로 통합하는 작업은 인프라 엔지니어의 업무입니다. 인프라 엔지니어가 이 작업을 제대로 수행한다면 이러한 비용에 대한 투자는 매우 긍정적인 결과를 가져올 것입니다.

이러한 통합을 통해 서비스를 배포하는 과정에서 보안 취약성, 다양한 설정, 제품 개발 과정에서 추가된 인위적인 제약 등 내재된 위험이 따라옵니다. 인프라의 역할은 마치 퍼블릭 PaaS 플랫폼 오퍼링 처럼 보이지만 우리 서비스만들 위해 고도로 튜닝되고 통합된 3rd party 솔루션들을 통합해 먼저 언급한 위험을 없앨 수 있는 프라이빗 PaaS 플랫폼을 만들어 제공 하는 것입니다.

맞춤형

사실 맞춤형 영역은 퍼블릭 클라우드/PaaS 제품을 통합해 지원할 수 있는 것보다 더 다양하고 복잡한 배포 요구가 있는 일부 유니콘 기업들 만의 레벨이었습니다. 이 레벨이되면 규모의 경제를 통해 세계적 수준의 인재를 고용하여 맞춤형 소프트웨어를 구축하는 것이 오히려 PaaS 제공업체가 제공하는 서비스를 통해 아웃소싱하는 것보다 더 저렴합니다. 또한 이 레벨이 되면 클라우드 제공 업체를 사용하는 것 보다 자체 데이터센터를 구축하고 운영하는 것이 더 저렴 합니다. 이 영역은 수억 명 또는 실제 수십억 명의 월간 활성 사용자를 보유한 기업의 영역입니다. 이것은 맞춤형 프로그래밍 언어와 데이터베이스를 만들어 사용하는 영역입니다.

Canva의 현재 위치는

Canva는 아웃소싱 단계에서 시작해 통합 수준으로 빠르게 성장해 왔습니다. 우리의 야망이 성공한다면 곧 맞춤형 단계를 고민해야할 것 같습니다.

이 모델에서는 자체 구축한 배포 인프라를 마련하는 것이 필요하고 그것을 위한 부담 역시 가져가야 한다는 사실을 겸허하게 받아들일 겁니다. 하지만 그에 따른 엄청난 기회가 분명 있을거라 생각 합니다.

Canva는 경쟁사에는 없는 안전하고 신뢰할 수 있는 제품으로 수천만 명의 월간 활성 사용자에게 서비스를 제공할 수 있는 플랫폼과 배포 네트워크를 보유하고 있습니다. 그리고 이것을 인프라 팀이 구축하고 있습니다. 우리가 이 모든 것을 대차 대조표에서 더 저렴한 단일 항목으로 아웃소싱하기를 바라고 있냐구요? 아마도 그럴 수도 있습니다. 하지만 그걸 바란다면 우리가 시장 도달 범위의 한계를 뛰어넘는 것이 아니라 현재의 영역에서 경쟁하고 있다는걸 의미 하겠죠.

인프라 엔지니어링은 Canva를 경쟁 업체들이 도달 할 수 있는 범위를 넘어 더 넓은 시장으로 진출할 수 있게 해줍니다. 인프라 엔지니어링은 신뢰성, 보안, 확장성, 이미 구축된 브랜드 신뢰를 통해 Canava가 새로운 시장을 개척할 수 있는 플랫폼을 제공합니다. 인프라 엔지니어링은 출시 기간을 단축하고 뛰어난 제품 개발 팀이 획기적인 새로운 기능을 쉽게 구축하고 출시할 수 있도록 지원합니다.

Canva의 비즈니스 규모가 커질수록 상용 솔루션으로 해결 가능한 문제는 줄어들 겁니다. 그리고 이 문제들을 해 결 하기 위해 인프라 엔지니어링을 통해 확보한 경쟁력을 더욱 활용 해야할 겁니다. Canva 는 성장중 입니다.

온프레미스 소프트웨어의 성장은 멈추지 않았다

주간SaaS는 SaaS 에 관한 내용을 다루는 뉴스레터지만! 오늘 굉장히 도전적인 제목의 콘텐츠를 소개 합니다. SaaS 가 아니네? 하고 지나치지 마시고 한 번 읽어보시면 새로운 시각을 얻으실 수 있을 것입니다.

개인적으로 이 글이 온프레미스 소프트웨어만을 강조한다고 생각하지 않습니다. 이보다 SaaS 와 온프레미스 소프트웨어 혹은 클라우드 소프트웨어를 "이것 아니면 저것"이 아닌 "이것과 저것"이라는 관점에서 바라볼 필요가 있다는 것입니다. 즉 타겟 고객의 분류(Segmentation)에 따라 이것(SaaS)와 저것(온프레미스 설치 소프트웨어, 클라우드 설치 소프트웨어)을 오퍼링에 담는 결정이 필요할 수 있다는 겁니다.

여러분들은 어떻게 생각하실지 궁금합니다. 아래 한글로 요약 합니다. 원문에 다양한 데이터와 이를 시각화한 자료가 포함되어 있습니다. 꼭 원문과 함께 보시길 추천 합니다.

▼

매년 Replicated는 독립 리서치 회사에 의뢰하여 고객이 관리하는 모든 환경에 배포된 상용 소프트웨어 시장을 조사합니다. 놀랍게도 올해의 보고서는 On-prem 소프트웨어에 대한 수요가 계속해서 얼마나 강력한지를 보여주고 있습니다.

1. On-prem 소프트웨어는 성장하는 비즈니스입니다.

소프트웨어 기업 10곳 중 4곳은 On-prem 비즈니스가 매출의 절반 이상을 차지한다고 답할 정도로 On-prem 비즈니스가 계속 성장하고 있습니다. On-prem를 제공하는 기업의 75%는 해당 시장 부문이 성장하고 있다고 답했습니다.

SaaS 사용은 분명 증가하고 있습니다. 하지만 최근 3년 동안 고객의 요구 사항을 충족하기 위해 On-prem 소프트웨어(클라우드의 VPC를 비롯한 고객이 제어하는 환경에 배포 가능)를 제공하기 시작한 기업은 30%에 불과합니다.

10명 중 4명 이상이 SaaS만 제공함으로써 회사가 매출 손실을 보고 있다고 답했으며, 약 70%의 기업이 On-prem 옵션을 제공할 계획이라고 답하였습니다.

2. On-prem 솔루션에 대한 수요가 증가하고 있습니다.

고객의 93%가 On-prem 소프트웨어에 만족하고 있습니다. 상당히 많은 숫자죠?

고객은 다양한 환경에 대응할 수 있는 유연한 설치 옵션이 필요합니다. 스마트한 소프트웨어 회사는 고객이 소프트웨어를 실행하고자 하는 모든 곳에서 서비스를 제공합니다.

On-prem 소프트웨어 요구사항은 보안, 데이터 주권, 비용, 제어, 문화 및 기타 여러 요인에 대한 우려로 인해 발생합니다. 고객에게 On-prem 배포 옵션을 제공하면 이러한 요구 사항을 충족하고 제품의 가치를 확장하는 데 도움이 될 수 있습니다.

그러나 많은 소프트웨어 회사가 오늘날 고객이 운영해야 하는 모든 환경을 지원하지 않기 때문에 시장에는 격차가 존재합니다. 정부, 금융, 의료와 같은 분야에서는 민감한 데이터에 대한 지원이 필요합니다. 소프트웨어 공급업체의 40% 미만이 이를 지원할 수 있으며, 46%만이 모든 주요 퍼블릭 클라우드 플랫폼에 설치를 지원할 수 있어 고객은 보안 이나 선택권을 포기해야 합니다.

3. 소프트웨어는 더 빠르게 설치되어야 합니다.

오늘날 10곳 중 8곳 이상의 기업이 더 많은 플랫폼에서 더 쉬운 패키징과 설치를 제공하는 Kubernetes 기반 소프트웨어를 출시하고 있지만, 대다수의 기업은 고객의 절반 이상이 Kubernetes를 처음 사용한다고 답했습니다.

거의 모든 기업(96%)이 6명 이상의 직원이 On-prem 배포만을 전담하고 있으며, 1/3은 50명 이상의 팀원을 배치하고 있다고 답했습니다. POC가 많을수록 이를 지원하는 현장 엔지니어와 개발자의 부담도 커집니다.

이 문제는 POC 에만 국한되지 않습니다. 응답자의 84%는 고객의 프로덕션 환경에 소프트웨어를 설치하고 구성하는 데 일주일 이상 걸렸다고 답했으며, 소프트웨어 문제와 제한된 배포 인력으로 인해 지연이 더 길어졌다고 답했습니다.

4. 설치가 완료된 후에도 문제가 발생할 수 있습니다.

기업 10곳 중 7곳 이상이 매달 4건 이상의 새로운 지원 문제를 받는다고 답했으며, 83%는 On-prem 고객의 각 문제를 해결하는 데 보통 하루 이상이 걸린다고 답했습니다.

결론

보고서의 내용을 요약한 것을 잘 보셨나요? 이처럼, On-prem 소프트웨어는 SaaS 소프트웨어 성장에 반비례 하는 것이 아닌, 계속해서 성장하고 있는 시장입니다.

기업은 다양한 환경에 소프트웨어를 쉽고 유연하게 설치할 수 있는 방법이 필요합니다. 또한 POC, 온프레미스 배포 및 지원에 드는 인건비를 절감할 수 있는 솔루션이 필요합니다. 문제를 줄이면서 더 빠르게 배포하는 것은 고객과 수익성 모두에 도움이 됩니다.

멀티 테넌시 아키텍쳐 소개

멀티 테넌시는 단일 소프트웨어 인스턴스가 여러 사용자에게 서비스를 제공할 수 있는 소프트웨어 및 데이터베이스 관리 아키텍처의 일종이라는 것이 일반적인 개념입니다. 이번에는 SaaS 를 시작하면서 가장 많이 듣는 기술 개념인 멀티 테넌시 또는 멀티 테넌트에 대해 쉽게 다룬 콘텐츠를 소개 합니다. 글이 조금 길지만, 커피 한잔과 함께라면 금방 읽으실 수 있을 것입니다 :-)

▼

단일 테넌트

단일 테넌트 아키텍처는 단일 소프트웨어의 전용 인스턴스로 한 명의 고객에게만 서비스를 제공하는 프로그램으로 정의할 수 있습니다.

단일 테넌시 아키텍처의 주요 이점

이러한 장점에도 불구하고 단일 테넌트 시스템에는 클라우드 서비스의 근본적인 한계, 즉 높은 비용과 확장성 문제가 있습니다. 특히 복잡한 설정과 시스템에 따른 전체 사용자 수를 고려하면 각 테넌트를 위한 별도의 환경을 운영하는 데 상당한 비용이 들 수 있습니다.

또한 단일 테넌시 모델에서는 서버 성능이 시스템 자체와 사용자 활동으로 인한 최대 부하를 모두 처리할 수 있어야 합니다. 즉, 각 서버 머신은 클라이언트가 생성할 수 있는 최대 부하만큼 성능이 좋아야 합니다

단일 테넌트 시스템의 주요 단점

멀티 테넌트

이러한 단점 때문에 멀티 테넌트 솔루션은 대규모 클라우드 기반 시스템 및 SaaS 애플리케이션에 훨씬 더 편리하고 미래 지향적이며 확장성이 뛰어납니다.

소규모 기업의 경우에도 하드웨어 요구 사항이 적고 온보딩 프로세스가 더 원활하기 때문에 이러한 접근 방식이 유용할 수 있습니다.

멀티테넌트 이점

하나의 애플리케이션 서버와 다수의 고객

SaaS는 서비스형 소프트웨어의 약자입니다. 이는 일반적으로 제품, 도구 또는 서비스에 액세스하기 위한 구독 모델과 관련된 소프트웨어를 배포하는 방식입니다.

SaaS 솔루션은 주로 멀티 인스턴스와 멀티 테넌트라는 두 가지 유형의 아키텍처를 기반으로 구축되며, 서로 혼동될 수 있습니다. 멀티 인스턴스 접근 방식의 경우 소프트웨어가 개발자의 하드웨어에 설치됩니다. 이를 유지 관리하는 것은 개발자의 책임입니다. 사용자는 클라우드 시스템을 통해 구매한 여러 애플리케이션에 액세스할 수 있습니다.

그러나 이 SaaS 모델에서는 여전히 자체 데이터베이스가 있는 전용 서버에 각 테넌트에 대해 별도의 인스턴스가 생성된다는 점을 기억해야 합니다. 멀티테넌트 SaaS 시스템은 애플리케이션에서 실행 중인 소프트웨어의 단일 인스턴스가 동시에 여러 클라이언트에 서비스를 제공하는 환경입니다. 각 고객은 기본 소프트웨어 인스턴스와 단일 데이터베이스를 공유하지만 각 테넌트의 데이터는 격리되어 다른 사용자에게는 보이지 않습니다.

💡 그렇다면 SaaS 제품을 개발할 때 어떤 것을 선택해야 할까요?

SaaS 제공업체가 최종 솔루션을 개발하여 출시할 시간이 거의 없다면 멀티테넌트 아키텍처에 집중하는 것이 훨씬 낫습니다. 개발 프로세스가 더 빠르며 이 선택은 향후 확장성 측면에서 더 수익성 있는 옵션을 제공합니다.

여러 클라이언트를 위한 데이터베이스

앞서 언급했듯이 멀티 테넌시는 매우 광범위한 범주이므로 애플리케이션 관점에서부터 데이터베이스 관리에 이르기까지 다양한 수준에서 분석할 수 있습니다. 이 소개 글에서는 데이터베이스 관리에 초점을 맞추겠습니다.

멀티테넌트 데이터베이스의 유형

멀티테넌트 데이터 스토리지 시스템에 대한 다양한 접근 방식을 다룰 때 양치기 비유를 들어보겠습니다.

목동은 모든 고객의 양들을 안전하게 지키기 위해 외양간을 지을 때 몇 가지 다른 방식으로 외양간을 지을 수 있습니다. 특정 양만을 위한 작은 외양간을 여러 개 만들거나 훨씬 큰 외양간 안에 별도의 상자를 설치할 수 있습니다.

IT 세계에서는 멀티테넌트 데이터베이스를 크게 세 가지 유형으로 구분할 수 있습니다. 어떤 접근 방식이 가장 적합한지는 전적으로 특정 사용 사례에 대한 목표와 요구 사항에 따라 달라집니다. 아래에서 각각의 접근 방식을 자세히 살펴보겠습니다.

유형 1: 공유 데이터베이스

양치기가 비용을 절감하기 위해 고객의 모든 양을 하나의 큰 헛간에 보관하기로 결정했다고 가정해 봅시다. 양들을 혼동하지 않기 위해 각 양에게 소유자에 대한 정보가 담긴 태그가 달린 특수 목걸이를 제공했습니다.

이것이 바로 첫 번째 유형의 다중 테넌트 데이터베이스가 작동하는 방식입니다. 이 유형을 공유 데이터 저장 방식이라고 합니다. 이 방식은 사용자의 데이터를 여러 데이터베이스(샤드)에 분산하며, 특정 테넌트에 대한 모든 데이터는 단일 샤드에 포함됩니다.

샤딩 키/테넌트 식별자는 공유 데이터베이스 스키마(기본 데이터베이스 내부의 논리적으로 분리된 영역)에 의해 관리되고 부과됩니다. 양치기가 관리하는 양에 대한 모든 데이터는 하나의 큰 차트에 보관되며, 특정 양의 소유자가 누구인지 확인하기 위해 특수 식별자가 있는 추가 열을 추가합니다. 일반적으로 이를 테넌트 ID라고 합니다.

여러 테넌트에 서비스를 제공하는 소프트웨어 아키텍처를 설계하는 것은 보다 강력한 시스템에서 사용자와 데이터베이스 간의 복잡한 매핑을 유지해야 하기 때문에 어려울 수 있습니다. 또한 애플리케이션은 샤드와 각 사용자의 전체 카탈로그를 유지 관리해야 합니다.

멀티테넌시에서 공유 데이터베이스의 장점

멀티 테넌시에서 공유 데이터베이스의 단점

유형 2: 테넌트당 하나의 스키마

이 시나리오에서 양치기는 여전히 모든 양을 하나의 큰 헛간에 보관하되, 각 주인이 소유한 양 전용 상자를 따로 설치하기로 결정했습니다. 이렇게 하면 양들이 태그가 달린 불편한 목걸이를 착용할 필요가 없습니다. 따라서 양들이 더 많이 분리되어 있기 때문에 양 사육 사업의 전반적인 관리가 크게 간소화될 수 있습니다.

이것이 멀티테넌시 접근 방식에서 두 번째 유형의 데이터베이스 아키텍처에 대한 기본적인 설명입니다.

이 유형의 데이터 저장소 인프라에서는 동일한 데이터베이스에 여러 스키마를 생성하여 사용자에게 어느 정도 수준의 데이터 격리를 제공합니다. 스키마는 데이터베이스 내부에서 논리적으로 분리된 영역으로, 그 안에 사용자 데이터가 포함된 테이블로 하위 디렉터리의 이름을 지정할 수 있습니다. 스키마의 테이블은 기본 스키마의 테이블과 함께 서로를 봅니다.

런타임에 해결해야 할 기준에 따라 요청이 특정 스키마로 리디렉션됩니다. 모든 테넌트에 대한 데이터를 보관하는 데이터베이스 인스턴스는 하나뿐입니다. 하지만 각 클라이언트에 대해 별도의 테이블이 있으며, 각 테이블은 테넌트별 스키마에 따라 설정됩니다.

이 경우 테이블이 특정 스키마에 포함되어 있으면 소유자에 대한 직접적인 정보를 제공하기 때문에 테넌트 ID로 추가 열을 만들 필요가 없습니다.

테넌트당 하나의 스키마의 장점

테넌트당 하나의 스키마의 단점

유형 3: 테넌트당 하나의 데이터베이스

세 번째 옵션을 선택한 목자는 각 사용자가 소유한 양을 위한 별도의 작은 외양간을 만들기로 결정했습니다. 이 접근 방식은 한 유형의 양이 다른 양에게 적대적으로 행동하는 경우나 새로운 고객이 방문하는 경우에 특히 유용할 수 있습니다. 그러면 야심찬 목동 사업가가 사업을 확장하는 것이 더 쉬워질 수 있습니다. 반면에 축사 인프라의 전반적인 관리 및 유지 관리에 문제가 발생할 수도 있습니다.

비유에서 알 수 있듯이, 세 번째 유형의 멀티테넌시 데이터베이스에서는 각 사용자가 자신의 전용 데이터베이스를 갖게 됩니다. 시스템에 새로운 테넌트가 추가될 때마다 새로운 데이터베이스가 생성됩니다. 메인 서버 내부에는 특정 테넌트만을 위한 별도의 데이터베이스가 있습니다.

양 주인마다 전용 외양간이 따로 있는 것과 마찬가지로, 각 외양간에는 서로 다른 테이블 세트가 있습니다. 이 솔루션은 이 세 가지 유형 중 가장 높은 수준의 데이터 보안을 제공합니다. 이 접근 방식을 사용하면 데이터베이스 이름 자체로 소유자를 알 수 있기 때문에 테넌트 ID 테이블을 추가할 필요가 없습니다.

테넌트당 하나의 데이터베이스의 장점

테넌트당 하나의 데이터베이스의 단점

그렇다면, 멀티테넌트 아키텍처가 중요한 이유는 무엇인가요?

멀티 테넌트 아키텍처는 최신 클라우드 컴퓨팅의 원동력이 되는 주요 기술입니다. 거의 모든 퍼블릭 및 프라이빗 클라우드에서 활발히 사용되고 있습니다.

멀티테넌트 아키텍처는 많은 고객이 공유 인프라를 활용하고 동일한 애플리케이션 인스턴스를 사용할 수 있게 함으로써 클라우드 컴퓨팅을 경제적으로나 기술적으로 실현 가능하게 합니다.

이미 언급했듯이 멀티 테넌트 아키텍처의 또 다른 중요한 장점은 높은 수준의 확장성을 지원한다는 것입니다. 프라이빗 클라우드 제공업체는 단일 플랫폼으로 여러 테넌트에 서비스를 제공할 수 있기 때문에 고객에 대한 서비스를 훨씬 빠르게 확장할 수 있습니다.

기업은 노후화된 데이터 센터를 클라우드로 마이그레이션하여 더 많은 컴퓨팅 성능과 다양한 클라우드 기반 도구에 액세스할 수 있습니다. 이러한 클라우드 배포는 멀티 테넌시가 방대한 양의 데이터를 효과적으로 처리할 수 있는 강력하고 견고한 아키텍처 이기때문에 가능합니다.

어떠신가요? 저희가 글을 읽으면서 재미를 느꼈던 것처럼, 여러분도 재미를 느끼셨으면 좋겠습니다. 글을 읽고 나누실 생각이나, 뉴스레터에서 다루어 주었으면 하는 내용, 건의사항 등이 있으시면 언제든 댓글과 연락으로 알려주세요! 기다리겠습니다 ^^ 

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