SaaS 를 위한 컨트롤 플레인의 모든 것

🐧: 안녕하세요, 이번에는 지난 뉴스레터에서 함께 봤던 컨트롤 플레인 아키텍처의 중요성에 이어, SaaS 를 위한 컨트롤 플레인에 대해서 다루어 보고자 합니다. (아직 지난 뉴스레터를 안보셨다면 보고 오셔야 이해하실 수 있습니다. )

SaaS 를 개발하시면서 한번쯤은 들어보았을 컨트롤 플레인에 대해서 알아보는 시간이 되었으면 좋겠습니다. 오늘 다룰 주제가 담긴 원문은 여기 에서 보실 수 있습니다.

몇 달 전, 성공적인 제품을 구축하기 위해 모든 인프라 SaaS 회사가 컨트롤 플레인과 데이터 플레인을 분리해야 한다는 트윗을 본 적이 있습니다. 이 글을 읽고 저희는 이 작업을 정말 쉽게 만들어줄 플랫폼을 개발 중이었기 때문에 흥분했습니다. 이미 이러한 패턴에 익숙하고 인프라스트럭처 SaaS 제품을 구축 중이신 분들과 이야기를 나누고 싶습니다.

지난 6년 동안 Confluent에서 근무하며 세계적인 수준의 인프라 SaaS 회사로 변모하는 데 기여했습니다. 신뢰할 수 있는 컨트롤 플레인을 개발하는 데 도움이 되는 플랫폼이 있다면 인프라 SaaS 제품 구축이 훨씬 더 간단해질 수 있다고 생각합니다. 기업은 상당한 비용과 시간을 절약할 수 있고, 엔지니어가 핵심 제품에 더 집중할 수 있습니다. 인프라스트럭처 SaaS 제품의 엔드투엔드 아키텍처, 데이터 플레인과 컨트롤 플레인의 역할, 그리고 이를 어렵게 만드는 문제를 설명하는 것이 도움이 될 것이라고 생각했습니다.

인프라스트럭처 SaaS란 무엇인가요?

인프라 SaaS는 서비스로 제공되는 모든 인프라 또는 플랫폼 제품을 의미합니다. 여기에는 데이터 인프라, 데이터 분석, 머신 러닝/AI, 보안, 개발자 생산성 및 통합 가시성 제품이 포함됩니다. Redpoint의 사이 센틸쿠마르가 이 주제에 대한 훌륭한 글과 가장 빠르게 성장하는 기업 중 하나인 인프라스트럭처 SaaS 기업에 대한 글을 작성했습니다.

인프라 SaaS 기업은 SaaS 플랫폼을 구축하기 위해 플랫폼 팀에 투자합니다. 플랫폼 팀은 컨트롤 플레인을 구축하는 데 필요한 빌딩 블록을 개발할 책임이 있습니다. 제품이 성공함에 따라 플랫폼 팀에 대한 투자는 계속 크게 증가하며 일반적으로 엔지니어링 조직의 25~50%에 달합니다. 대규모 인프라 SaaS를 구축한 경험과 다른 기업들과의 대화를 통해 플랫폼 투자가 엔지니어링 조직에서 가장 높은 비용을 차지한다는 사실을 확인했습니다.

데이터 플레인과 컨트롤 플레인 - 언제 필요한가요?

컨트롤 플레인은 일반적으로 SaaS 기능, 메타데이터 관리, 모든 데이터 플레인의 수명 주기 제어를 담당합니다. 제어 플레인과 데이터 플레인을 분리하는 것은 인프라 SaaS 제품을 구축할 때 일반적입니다. 여기에는 이유가 있습니다.

오픈 소스 인프라를 SaaS 제품으로 제품화하기

대부분의 오픈 소스 인프라 프로젝트는 데이터 플레인에서만 시작됩니다. 프로젝트 담당자는 다음 단계가 오픈 소스 인프라를 SaaS 제품으로 제품화하는 것임을 알고 있습니다. 독립적인 컨트롤 플레인은 SaaS 환경을 구현하고 핵심 오픈 소스 데이터 플레인을 분리하는 데 이상적입니다. 컨트롤 플레인은 여러 지역과 클라우드 제공업체에 걸쳐 여러 데이터 플레인을 관리하는 데 도움이 됩니다.

오픈소스에서의 컨트롤 플레인의 필요성은 높습니다. 그러나 컨트롤 플레인의 필요성은 오픈 소스 인프라에만 국한되지 않습니다. 오픈 소스가 아니더라도, 모든 인프라 SaaS 제품의 핵심 요구 사항이 됩니다. 거의 모든 인프라 SaaS에는 테넌트 관리, 사용자 관리, 클러스터 관리, 모든 데이터 플레인의 오케스트레이션을 가능하게 하는 중앙 관리 계층이 필요합니다. 컨트롤 플레인은 최종 사용자에게 단일 창 환경을 제공하며, 모든 데이터 플레인과 조정하고 전반적인 수명 주기 관리를 담당합니다.  

인프라 SaaS를 사용하면 일반적으로 몇 가지 이유로 데이터 플레인을 고객 위치에 가깝게 유지해야 합니다.

    1. 비용

    데이터 플레인이 네트워크 집약적인 경우 데이터 전송 비용이 엄청나게 비쌀 수 있습니다.     일반적으로 고객과 같은 지역에 위치하여 이 비용을 없애고 싶어합니다.

    2.  보안

    기업 고객의 경우, 데이터 플레인 위치는 상당한 규정 준수 및 규제 요건에 따라 달라집니다. 보안에 매우 민감한 고객은 계정의 데이터 플레인이 액세스를 더욱 엄격하게 제어하기를 원할 수 있습니다.

    3.  지연 시간

    미션 크리티컬 인프라는 일반적으로 레이턴시 요구 사항이 낮습니다. 우수한 성능을 보장하려면 데이터 플레인이 고객과 동일한 지역에 있어야 합니다.

    4. 고가용성

    고가용성을 위해서는 데이터 플레인에 대한 연결이 GEO를 가로지르지 않아야 하며, 지역 간 또는 클라우드 간 네트워크 장애에 대한 복원력이 높아야 합니다. 또한 단일 데이터 플레인 클러스터는 용량 문제로 인해 확장하기 어렵고 샤딩이 필요할 수 있습니다. 데이터 플레인을 컨트롤 플레인에서 분리하면 데이터 플레인을 훨씬 쉽게 확장할 수 있습니다.

    5. 멀티 클라우드     

    마지막으로, 여러 클라우드 제공업체를 지원하는 것이 인기를 얻고 있습니다. 이를 지원하는 한 가지 모델은 제어 플레인을 하나의 클라우드에 중앙 집중화하고 데이터 플레인은 동일한 고객을 위해 서로 다른 클라우드 제공업체에 배포하는 것입니다. 여기에는 더 많은 변형이 있으며 나중에 살펴보겠습니다.

세계적 수준의 컨트롤 플레인에는 무엇이 필요하나요?

컨트롤 플레인이 지원해야 하는 기능을 이해하는 것이 도움이 될 것입니다. 이러한 요구 사항은 인프라스트럭처 SaaS 제품의 아키텍처에 영향을 미칩니다.

사용자, 조직 및 메타데이터 관리

사용자 및 조직 관리는 인프라 SaaS 제품의 기본 요구 사항입니다. 사용자 관리에는 사용자 인증, 사용자 수명 주기 관리(추가, 초대, 삭제, 업데이트), 사용자 그룹 및 타사 ID 통합 지원이 포함되며, 컨트롤 플레인은 사용자 수명 주기 API가 호출될 때 사용자에 대한 액세스 제어가 데이터 플레인에 반영되도록 해야 합니다.

테넌트 관리라고도 하는 조직 관리에는 조직 계층 구조 데이터 모델 지원, 할당량, 조직 범위의 보안 정책 적용, 엔드투엔드 수명 주기 관리가 포함됩니다. 멀티테넌시는 SaaS 애플리케이션의 기본적인 요구 사항이며, 인프라 SaaS도 다르지 않습니다.

대규모 고객의 경우, 둘 이상의 조직을 병합하는 플로우 지원, 조직 일시 중단, 규제 요건(GDPR - EU 개인 정보보호 규정, FedRAMP - 연방정부 클라우드 보안/인증 관리 프로그램 등)에 따른 깨끗한 조직 삭제 구현 등 조직 관리가 상당히 복잡해지며, 컨트롤 플레인은 테넌트 수명 주기 관리가 데이터 플레인에도 반영되도록 해야 합니다. 예를 들어, 조직이 일시 중단되면 컨트롤 플레인은 데이터 플레인이 일시적으로 액세스를 차단하도록 해야 합니다.

SaaS 애플리케이션에 필요한 많은 표준 SaaS 엔티티가 있으며, 사용자와 조직이 그 예입니다. 동시에 애플리케이션별 메타데이터도 많이 있습니다. 예를 들어, 사용자가 일련의 데이터베이스 클러스터를 관리할 수 있는 인프라 제품은 '클러스터', '네트워크', '환경' 등의 메타데이터를 정의할 수 있습니다. 메타데이터를 정의하고, 이를 관리하기 위한 CRUD API를 작성해야 하며, 사용자 및 조직에 대해 정의된 동일한 보안 정책에 따라 액세스를 제어해야 합니다. 중앙 제어 영역은 이러한 메타데이터에 대한 신뢰할 수 있는 소스가 되어야 하며 메타데이터 관리를 지원해야 합니다.

데이터 플레인과의 오케스트레이션 및 통합

컨트롤 플레인의 핵심 요구 사항 중 하나는 데이터 플레인의 엔드투엔드 수명 주기를 관리하는 것입니다. 일반적으로 여기에는 데이터 플레인에서 리소스를 생성, 업데이트 및 삭제하는 작업이 포함됩니다. 인프라 SaaS의 경우 이러한 모든 작업은 비동기식이며, 컨트롤 플레인이 엔드투엔드 흐름을 관리하기를 원합니다. 최종 사용자가 이러한 수명 주기 작업을 호출할 때 탁월한 경험을 제공하고, 이러한 비동기 수명 주기 작업을 실행할 때 짧은 지연 시간과 정확성을 보장해야 하며, 여러 지역과 클라우드 제공업체에 걸쳐 수백에서 수천 개의 데이터 플레인에 대해 대규모로 이러한 관리를 수행할 수 있어야 합니다.

데이터 플레인의 수명 주기 관리

컨트롤 플레인의 핵심 요구 사항 중 하나는 데이터 플레인의 엔드투엔드 수명 주기를 관리하는 것입니다. 일반적으로 여기에는 데이터 플레인에서 리소스를 생성, 업데이트 및 삭제하는 작업이 포함됩니다. 인프라 SaaS의 경우 이러한 모든 작업은 비동기식이며, 컨트롤 플레인이 엔드투엔드 흐름을 관리하기를 원합니다. 최종 사용자가 이러한 수명 주기 작업을 호출할 때 탁월한 경험을 제공하고, 이러한 비동기 수명 주기 작업을 실행할 때 짧은 지연 시간과 정확성을 보장해야 하며, 여러 지역과 클라우드 제공업체에 걸쳐 수백에서 수천 개의 데이터 플레인에 대해 대규모로 이러한 관리를 수행할 수 있어야 합니다.

보안 정책

보안 정책에는 각 조직과 사용자에 대한 액세스 제어, 할당량, 데이터 거버넌스가 포함됩니다. 액세스 제어는 단순한 권한부터 복잡한 RBAC ( RBAC 은 역할 기반 액세스 제어를 의미합니다. 여기 에서 설명을 보실 수 있습니다 ) 지원까지 다양합니다. 일반적으로 이러한 액세스 제어는 제어 플레인과 데이터 플레인 모두에 적용되어야 합니다. IDP 통합이 있는 경우, 제어 플레인은 IDP에 정의된 내용에 따라 액세스 제어를 적용해야 할 수 있습니다. 할당량은 사용자와 테넌트가 인프라에서 수행할 수 있는 작업 집합에 대한 제한입니다. 이는 일반적으로 서비스 거부 공격을 방어하고 건강한 멀티테넌트 시스템을 구축하기 위해 수행됩니다. 액세스 제어와 마찬가지로 쿼터는 컨트롤 플레인 및 데이터 플레인 작업에 적용될 수 있습니다. 데이터 거버넌스는 대규모 고객에게 점점 더 중요해지고 있습니다. 거버넌스에는 데이터를 쉽게 찾고, 국가별 정책에 따라 데이터를 저장하고, 데이터 보존 규칙에 따라 데이터를 삭제할 수 있는 기능이 포함됩니다. 모든 보안 정책의 경우, 컨트롤 플레인은 테넌트 위치, 정책, 사용자 규칙에 따라 모든 데이터 플레인에 일관되게 적용될 수 있도록 해야 합니다.

매트릭, 알림 및 인사이트

인프라 SaaS의 경우, 사용자는 일반적으로 인프라에서 몇 가지 명령을 실행하고 실행이 어떻게 진행되고 있는지 알고 싶어합니다. 문제가 발생하거나 주의가 필요한 경우 알림이나 경고를 받기를 원할 수도 있습니다. 예를 들어, 데이터베이스 제품에서는 사용자가 일련의 쿼리를 실행하고 쿼리 메트릭을 확인하여 응답 시간, 오류 및 사용량을 파악할 수 있습니다. 또한 쿼리가 실패하기 시작하면 사용자에게 알림을 받기를 원할 수도 있습니다. 또한 사용자는 여러 지역 및 클라우드 제공업체의 데이터베이스에 걸쳐 집계된 메트릭이 필요합니다. 컨트롤 플레인은 데이터 플레인 전반의 모든 메트릭을 집계하고, 인사이트를 제공해야 합니다.

인프라 SaaS 아키텍처

컨트롤 플레인과 인프라스트럭처 SaaS 요구 사항에 대한 이해를 바탕으로 일반적인 인프라스트럭처 SaaS 제품의 아키텍처에 대해 자세히 살펴보겠습니다. 기본 빌딩 블록을 검토하고 몇 가지 아키텍처 고려 사항에 대해 논의하겠습니다.

컨트롤 플레인의 기본 구성 요소

인프라 SaaS 제품은 고객에게 세계 최고 수준의 SaaS 경험을 제공해야 합니다. 여기에는 사용자 인증 및 사용자 관리, 조직 관리, 액세스 제어를 위한 권한 모델 제공, 다양한 제품 오퍼링에 대한 다양한 정의, 제품 구독 또는 사용량에 따른 청구 기능 등이 포함됩니다. 이는 모든 Infrastructure SaaS 제품에 대한 최종 사용자의 기본적인 기대치입니다. 나열된 모든 기능의 기본 버전은 일부 할당량이 있는 무료 티어 제품에는 충분할 수 있으며, 더 높은 세그먼트(예: 엔터프라이즈)에 서비스를 제공하면 기능이 복잡해집니다. 예를 들어, 중견 및 엔터프라이즈 고객은 제품에서 제공하는 기본 제공 기능 대신 인증을 위해 ID 관리 시스템과 통합해야 할 수 있습니다.

또한 'SaaS 플로우'라고 부르는 SaaS 기능 간에는 복잡한 상호 연결이 있습니다. 인프라 SaaS의 SaaS 경험은 여러 SaaS 플로우로 구성됩니다. 예를 들어 사용자가 제품에 가입할 때 마케팅 도구에 항목을 만들어 캠페인을 보낼 수도 있습니다. SaaS 플로우의 더 복잡한 예로는 특정 조직의 신용 카드가 만료되는 경우를 들 수 있습니다. 만료 시 고객에게 몇 차례 알림을 보내 신용 카드 정보를 업데이트하려고 합니다. 고객의 응답이 없으면 계정을 일시적으로 일시 중단하고 데이터 플레인에 대한 액세스를 비활성화한 다음 인프라 비용이 발생하지 않도록 충분한 시간을 기다린 후 계정을 다시 회수할 수 있습니다. 이 SaaS 플로우 예에서는 사용자 관리, 조직 관리, 청구, 알림 및 데이터 플레인을 연결합니다. 서로 다른 SaaS 기능 간의 이러한 상호 연결을 'SaaS 메시'라고 부릅니다. 다양한 SaaS 플로우를 구축하려면 SaaS 메시가 필요합니다. SaaS 흐름에는 고객 대면 경험과 회사의 다른 이해관계자를 위한 백오피스 흐름이 포함됩니다.

중앙 컨트롤 플레인의 핵심 책임 중 하나는 다양한 데이터 플레인을 오케스트레이션하는 것입니다. 일반적으로 단일 고객이 여러 지역 또는 클라우드 제공업체에 애플리케이션 또는 클러스터를 보유할 수 있습니다. 고객과 데이터 플레인이 많아지면 다음과 같은 몇 가지 사항을 지원해야 합니다.

컨트롤 플레인은 모든 데이터 플레인에서 신뢰할 수 있는 소스입니다. 데이터 플레인 정보를 중앙에서 관리하면 최종 고객이 애플리케이션 또는 클러스터에 대한 모든 정보에 액세스할 수 있는 단일 창 환경을 제공하는 데 도움이 됩니다.

데이터 플레인은 실제 고객 애플리케이션 또는 클러스터가 배포되는 곳입니다. 배포는 Kubernetes 클러스터 또는 클라우드 인스턴스에서 직접 수행할 수 있습니다. 클러스터 또는 애플리케이션은 하나의 Kubernetes 클러스터에 함께 위치할 수도 있고 별도로 위치할 수도 있습니다. 일반적으로 이러한 데이터 플레인에는 컨트롤 플레인의 명령에 따라 데이터 플레인에서 로컬 라이프사이클 작업을 실행하는 데 도움이 되는 에이전트가 실행됩니다. 에이전트는 어떤 의미에서 데이터 플레인에 함께 배치된 미니 컨트롤 플레인처럼 작동합니다. 다른 아키텍처와 마찬가지로 데이터 플레인을 관리하는 방법에는 여러 가지가 있습니다. 각 데이터 플레인의 수명 주기를 관리하는 데 사용할 수 있는 도구로는 Kubernetes, Terraform 또는 Temporal이 있습니다.

모든 컨트롤 플레인 아키텍처는 데이터 플레인과의 Closed 피드백 루프 ( Closed feedback loop - 고객의 피드백에 바로 응답할 수 있는 것, 여기를 참고하세요. ) 없이는 완전하지 않습니다. 앞서 언급했듯이, 컨트롤 플레인은 고객 애플리케이션 또는 클러스터의 현재 상태에 대한 진실의 원천입니다. 데이터 플레인은 작업 상태를 컨트롤 플레인에 보고해야 합니다. 또한 컨트롤 플레인은 사용자에게 인프라에 대한 인사이트를 보여주기 위해 애플리케이션 메트릭과 메타데이터를 수집해야 합니다.

완전 호스팅 모델에서는 데이터 플레인이 서비스 제공업체의 클라우드 계정에 배포됩니다. 규정 준수 요구 사항으로 인해 일부 기업과 고객은 자체 클라우드 계정에 인프라를 배포할 것을 요구합니다. 일부 인프라 SaaS 기업은 두 모델을 모두 지원해야 합니다. 이러한 서로 다른 배포 모델에 대한 아키텍처를 통합할 수 있습니다. 고객 계정에 인프라를 배포하려면 고객 계정의 권한 모델, 청구 플랜(고객이 클라우드 청구서에서 사용 비용을 받음), 지원(액세스 권한이 있는 사람) 및 개발 오버헤드를 통합해야 합니다.

중앙 컨트롤 플레인에 대해 새로운 데이터 플레인 변경 사항을 테스트하면 복잡성이 증가합니다. 일반적으로 새로운 데이터 플레인 기능을 활성화하려면 제어 플레인을 변경해야 하므로 엔드투엔드 테스트를 위해 전체 제어 플레인을 모킹하는 것은 바람직하지 않습니다. 합리적인 해결책은 각 개발자에게 자신의 변경 사항만 포함된 제어 영역의 로컬 샌드박스를 제공하는 것입니다. 이렇게 하면 변경 사항을 사전 프로덕션에 푸시하기 전에 로컬에서 테스트하는 데 도움이 됩니다. 컨트롤 플레인에 대한 적절한 테스트 전략이 없으면 제품과 팀이 확장됨에 따라 모든 변경 사항을 안정화하기가 더 어려워집니다.

컨트롤 플레인 설계의 필수적인 부분은 컨트롤 플레인을 완전히 사용할 수 없게 되었을 때를 대비한 올바른 전략을 세우는 것입니다. 사용자 관점에서는 컨트롤 플레인을 사용할 수 없는 경우에도 데이터 플레인을 사용할 수 있어야 합니다. 또한 동일한 지역 또는 다른 지역(때로는 다른 클라우드)에서 컨트롤 플레인을 다시 백업할 계획이 있어야 합니다. 데이터 손실 없이 데이터를 복원하는 것이 중요합니다. 백업 데이터에서 컨트롤 플레인을 자동으로 부트스트랩할 수 있다면 고가용성 서비스를 제공할 수 있습니다.

이런 것을 다 하는 것은 물론 어렵습니다.

설계 및 구축에 상당한 시간과 비용이 소요되는 몇 가지 질문을 아래에 나열했습니다.

🐧:  오늘은 다소 어렵고 긴 글을 가져와 보았습니다. 아마 컨트롤 플레인에 대해서 고민을 한번이라도 해보셨던 분들이라면, 공감가는 부분도 많고 새로운 부분도 많이 아셨을 것 같습니다. 여러분의 컨트롤 플레인은 어떻게 구성되어 있나요? 자유롭게 공유해 주시면 좋을 것 같습니다. 이상으로 이번 주간 SaaS 를 마무리하겠습니다. 

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