SaaS 산업이 빠르게 성장함에 따라 실시간 데이터 유입을 처리하기 위해서는 역동적이고 적응 가능한 아키텍처가 필요합니다. 빌드 방법은 다음과 같습니다.
실시간 데이터를 위한 확장 가능한 플랫폼 아키텍처를 구축하는 방법 (저자 Christina Lin) 에서 번역되었습니다 .
SaaS(Software as a Service) 산업은 거침없는 성장을 보이고 있으며, 시장 규모는 2024년에 3,175억 5,500만 달러에 달하고 2032년에는 거의 3배인 12억 2,887억 달러에 이를 것으로 예상됩니다 . 이러한 성장은 강화되고 강력한 데이터 전략에 대한 필요성이 커지고 있음을 강조합니다. 이러한 추세는 기업에서 생성되는 데이터의 양, 속도, 다양성이 증가하고 인공 지능이 통합되면서 발생합니다.
그러나 이러한 성장하는 환경은 피크 트래픽 관리, 온라인 트랜잭션 처리(OLTP)에서 온라인 분석 처리(OLAP)로 실시간 전환, 셀프 서비스 및 분리 보장, 클라우드 불가지론 및 다중화와 같은 몇 가지 중요한 과제를 안겨줍니다. 지역 배포. 이러한 문제를 해결하려면 시스템 성능을 저하시키지 않으면서 고가용성과 강력한 장애 조치 메커니즘을 보장하는 정교한 아키텍처 프레임워크가 필요합니다.
이 문서의 참조 아키텍처에서는 성장하는 SaaS 산업을 지원하기 위해 확장 가능하고 자동화되었으며 유연한 데이터 플랫폼을 구축하는 방법을 자세히 설명합니다. 이 아키텍처는 대규모 데이터 처리 에 필요한 기술적 요구 사항을 지원하는 동시에 민첩성, 비용 효율성 및 규정 준수에 대한 비즈니스 요구 사항에도 부합합니다.
데이터 집약적인 SaaS 서비스의 기술적 과제
서비스 및 데이터 볼륨에 대한 수요가 계속 증가함에 따라 SaaS 업계에서는 몇 가지 일반적인 문제가 발생합니다.
다양한 트래픽 패턴에 대처하기 위해 리소스를 효율적으로 할당하려면 트래픽 피크와 버스트를 처리하는 것이 중요합니다. 이를 위해서는 워크로드를 격리하고, 워크로드가 가장 많은 시간대에 확장하고, 사용량이 적은 시간에 컴퓨팅 리소스를 줄이는 동시에 데이터 손실을 방지해야 합니다.
OLTP를 OLAP에 실시간으로 유지한다는 것은 데이터 무결성에 중점을 두고 대량의 빠른 트랜잭션을 관리하는 OLTP와 신속한 분석 통찰력을 지원하는 OLAP 시스템을 원활하게 지원한다는 의미입니다. 이 이중 지원은 복잡한 분석 쿼리를 지원하고 최고의 성능을 유지하는 데 중요합니다. 또한 기계 학습(ML)을 위한 데이터 세트를 준비하는 데 핵심적인 역할을 합니다.
셀프 서비스 및 분리를 활성화하려면 중앙 IT 팀에 크게 의존하지 않고도 주제와 클러스터를 생성하고 관리할 수 있는 셀프 서비스 기능을 팀에 부여해야 합니다 . 이를 통해 애플리케이션과 서비스를 분리하고 독립적인 확장성을 달성하는 동시에 개발 속도를 높일 수 있습니다.
클라우드 불가지론과 안정성을 장려하면 AWS , Microsoft Azure 또는 AWS 와 같은 다양한 클라우드 환경에서 운영할 수 있는 민첩성과 능력이 가능해집니다.
SaaS 친화적인 아키텍처를 구축하는 방법
이러한 문제를 해결하기 위해 대규모 SaaS 회사는 여러 지역에 걸쳐 여러 클러스터를 실행하고 맞춤형으로 개발된 제어 플레인으로 관리하는 아키텍처 프레임워크를 채택하는 경우가 많습니다. 컨트롤 플레인의 설계는 기본 인프라의 유연성을 향상시키는 동시에 연결된 애플리케이션의 복잡성을 단순화합니다.
이 전략은 고가용성 및 강력한 장애 조치 메커니즘에 중요하지만, 성능에 영향을 미치거나 리소스 확장 또는 축소 문제를 발생시키지 않고 지리적으로 분산된 클러스터 전체에서 균일한 성능과 데이터 무결성을 유지하기에는 너무 복잡해질 수도 있습니다. 생기다.
또한 특정 시나리오에서는 규정 준수 또는 보안상의 이유로 데이터를 특정 클러스터 내에서 격리해야 할 수도 있습니다. 이러한 복잡성을 피하는 강력하고 유연한 아키텍처를 구축하는 데 도움이 되도록 몇 가지 제안 사항을 안내해 드리겠습니다.
1. 안정적인 기반 구축
SaaS 서비스의 주요 과제는 고주파 및 고용량 온라인 쿼리, 데이터 삽입, 내부 데이터 교환 등 다양한 트래픽 패턴을 처리하기 위해 리소스를 할당하는 것입니다.
트래픽을 비동기식 프로세스로 변환하는 것은 컴퓨팅 리소스를 보다 효율적으로 확장하고 신속하게 할당할 수 있는 일반적인 솔루션입니다. Apache Kafka 와 같은 데이터 스트리밍 플랫폼은 대용량 데이터를 효율적으로 관리하는 데 이상적입니다. 그러나 Kafka와 같은 분산 데이터 플랫폼을 관리하는 데에는 고유한 과제가 따릅니다. Kafka의 시스템은 클러스터 조정, 동기화, 확장 관리는 물론 추가 보안 및 복구 프로토콜도 필요하기 때문에 기술적 복잡성으로 악명이 높습니다. 카프카의 과제
Kafka의 JVM(Java Virtual Machine)은 주로 JVM의 가비지 수집 프로세스로 인해 예측할 수 없는 대기 시간 급증을 일으킬 수도 있습니다. JVM의 메모리 할당을 관리하고 Kafka의 높은 처리량 요구 사항에 맞게 조정하는 작업은 매우 지루하며 Kafka 브로커의 전반적인 안정성에 영향을 미칠 수 있습니다.
또 다른 장애물은 Kafka의 데이터 정책 관리입니다. 여기에는 스토리지 비용, 성능 및 규정 준수의 균형을 맞추는 동시에 데이터 보존 정책, 로그 압축 및 데이터 삭제 관리가 포함됩니다.
즉, SaaS 환경에서 Kafka 기반 시스템을 효과적으로 관리하는 것은 까다롭습니다. 결과적으로 많은 SaaS 회사는 JVM 또는 ZooKeeper와 같은 외부 종속성이 필요 없이 확장성이 뛰어난 데이터 스트리밍을 제공하는 Kafka 대안 으로 전환하고 있습니다.
2. 셀프 서비스 스트리밍 데이터 활성화
개발자가 개발부터 제작까지 테마를 직접 제작할 수 있는 셀프서비스 솔루션에 대한 수요가 늘어나고 있습니다. 인프라 또는 플랫폼 서비스는 중앙 집중식 제어 기능을 갖춘 솔루션을 제공하고, 로그인 세부 정보를 제공하며, 다양한 플랫폼과 단계에서 리소스의 신속한 생성 및 배포를 자동화해야 합니다.
이로 인해 다양한 형태로 제공되는 제어 평면에 대한 필요성이 높아집니다. 일부 제어 평면은 클러스터 또는 주제의 수명 주기를 관리하고 스트리밍 플랫폼에 권한을 할당하는 데만 사용됩니다. 다른 컨트롤 플레인은 대상을 가상화하고 사용자와 클라이언트로부터 인프라 세부 정보를 숨겨 추상화 계층을 추가합니다.
셀프 서비스 데이터 플랫폼의 컨트롤 플레인에 토픽이 등록되면 환경 단계에 따라 서로 다른 컴퓨팅 자원 최적화 전략이 적용됩니다. 개발 중에는 주제가 다른 프로세스와 클러스터를 공유하는 경우가 많으며 데이터 보존은 덜 강조되며 대부분의 데이터는 며칠 내에 삭제됩니다.
그러나 프로덕션 환경에서는 트래픽 양에 따라 리소스 할당을 신중하게 계획해야 합니다. 이 계획에는 소비자를 위한 파티션 수 결정, 데이터 보존 정책 설정, 데이터 위치 결정, 특정 사용 사례에 전용 클러스터가 필요한지 여부 고려가 포함됩니다.
컨트롤 플레인의 경우 스트리밍 플랫폼의 수명 주기 관리 프로세스를 자동화하는 것이 매우 유용합니다. 이를 통해 제어 플레인은 에이전트를 자동으로 디버깅하고, 성능 메트릭을 모니터링하고, 파티션 재조정을 시작 또는 중지하여 대규모 플랫폼 가용성과 안정성을 유지할 수 있습니다.
3. OLTP, OLAP 실시간 지원
일괄 처리에서 실시간 분석으로 전환함에 따라 OLAP 시스템을 기존 인프라에 통합하는 것이 중요해졌습니다. 그러나 이러한 시스템은 일반적으로 대량의 데이터를 처리하며 심층적인 다차원 분석을 위해 복잡한 데이터 모델이 필요합니다.
OLAP은 여러 데이터 소스에 의존하며, 회사의 성숙도에 따라 일반적으로 데이터를 저장하기 위한 데이터 웨어하우스나 데이터 레이크뿐만 아니라 데이터 소스에서 데이터를 이동하기 위해 정기적으로(보통 야간에) 실행되는 일괄 처리 파이프라인이 있습니다. . 이 프로세스는 다양한 OLTP 시스템과 기타 소스의 데이터를 병합합니다 . 이는 데이터 품질과 일관성을 유지하는 데 있어 복잡해질 수 있는 프로세스입니다.
오늘날 OLAP은 AI 모델과 대규모 데이터 세트도 통합합니다. 대부분의 분산 데이터 처리 엔진 및 스트리밍 데이터베이스는 이제 Kafka 또는 Redpanda와 같은 소스의 스트리밍 데이터에 대한 실시간 소비, 집계, 요약 및 분석을 지원합니다. 이러한 추세로 인해 실시간 데이터를 위한 추출, 변환, 로드(ETL) 및 추출, 로드, 변환(ELT) 파이프라인은 물론 데이터베이스에서 이벤트 로그를 스트리밍하는 변경 데이터 캡처(CDC) 파이프라인이 증가했습니다.
일반적으로 Java , Python 또는 Golang 으로 구현되는 실시간 파이프라인에는 신중한 계획이 필요합니다. 이러한 파이프라인의 수명주기를 최적화하기 위해 SaaS 회사는 파이프라인 수명주기 관리를 제어 플레인에 내장하여 모니터링 및 리소스 정렬을 최적화하고 있습니다.
4. 데이터 파이프라인 수명주기 이해(및 최적화)
첫 번째 단계는 기술 스택을 선택하고 파이프라인을 생성하는 사용자가 누릴 자유와 맞춤화 수준을 결정하는 것입니다. 이상적으로는 다양한 작업에 대해 다양한 기술을 선택하고 파이프라인 건설 및 확장을 제한하는 가드레일을 구현하도록 허용합니다.
다음은 파이프라인 수명주기와 관련된 단계에 대한 간략한 개요입니다.
빌드 및 테스트
소스 코드는 파이프라인 개발자가 직접 또는 제어 플레인의 사용자 지정 도구를 통해 Git 저장소로 푸시됩니다. 그런 다음 이 코드는 C++, Java 또는 C#과 같은 언어를 사용하여 이진 코드 또는 실행 가능한 프로그램으로 컴파일됩니다. 컴파일 후 코드는 인증된 종속성 및 구성 파일을 번들링하는 프로세스와 관련된 아티팩트로 패키지됩니다.
그런 다음 시스템은 자동화된 테스트를 실행하여 코드를 확인합니다. 테스트 중에 컨트롤 플레인은 특별히 이 목적을 위해 임시 주제를 생성하며 이러한 주제는 테스트가 완료되는 즉시 폐기됩니다.
배포
아티팩트는 기술 스택에 따라 가상 머신(예: Kubernetes ) 또는 스트리밍 데이터베이스에 배포됩니다. 일부 플랫폼은 빠른 롤백을 가능하게 하고 가동 중지 시간을 최소화하는 블루/그린 배포와 같은 릴리스 전략에 대한 보다 창의적인 접근 방식을 제공합니다. 또 다른 전략은 새 버전이 데이터의 작은 부분에만 적용되어 잠재적인 문제의 영향을 줄이는 카나리아 릴리스입니다.
이러한 전략의 단점은 롤백이 어려울 수 있고 새 버전의 영향을 받는 데이터를 격리하기가 어려울 수 있다는 것입니다. 전체 릴리스를 수행하고 전체 데이터 세트를 롤백하는 것이 더 간단한 경우도 있습니다.
확장하다
많은 플랫폼은 CPU 사용량에 따라 실행 중인 인스턴스 수를 조정하는 등 자동 확장을 지원하지만 자동화 수준은 다양합니다. 일부 플랫폼에서는 이 기능을 기본적으로 제공하지만 다른 플랫폼에서는 작업당 최대 병렬 작업 수 또는 작업자 프로세스 설정과 같은 수동 구성이 필요합니다.
배포 중에 컨트롤 플레인은 예상 수요에 따라 기본 설정을 제공하지만 계속해서 측정항목을 면밀히 모니터링합니다. 그런 다음 필요에 따라 작업자 프로세스, 작업 또는 인스턴스 수를 확장하여 주제에 추가 리소스를 할당합니다.
감시 장치
파이프라인에서 올바른 지표를 모니터링하고 관찰 가능성을 유지하는 것은 문제를 조기에 감지하는 주요 방법입니다. 데이터 처리 파이프라인의 효율성과 안정성을 보장하기 위해 사전에 모니터링해야 하는 몇 가지 주요 지표는 다음과 같습니다.
자원 지표
- CPU 및 메모리 사용량은 리소스가 소비되는 방식을 이해하는 데 매우 중요합니다.
- 디스크 I/O는 데이터 저장 및 검색 작업의 효율성을 평가하는 데 중요합니다.
처리량 및 대기 시간
- 입출력 기록은 초당 데이터 처리 속도를 측정합니다.
- 초당 처리되는 레코드는 시스템의 처리 능력을 나타냅니다.
- 엔드투엔드 대기 시간은 데이터 입력부터 출력까지 걸리는 총 시간으로, 실시간 처리 성능에 매우 중요합니다.
배압 및 히스테리시스
- 이는 데이터 처리의 병목 현상을 식별하고 잠재적인 속도 저하를 방지하는 데 도움이 됩니다.
오류율
- 오류율을 추적하면 데이터 무결성과 시스템 안정성을 유지하는 데 도움이 됩니다.
5. 신뢰성, 중복성 및 탄력성 향상
기업은 중단 중에도 지속적인 운영을 유지하기 위해 고가용성, 재해 복구, 탄력성을 우선시합니다. 대부분의 데이터 스트리밍 플랫폼에는 주로 여러 파티션, 데이터 센터 및 클라우드에 구애받지 않는 가용성 영역에 걸쳐 클러스터를 확장하는 강력한 보호 장치와 배포 전략이 이미 내장되어 있습니다.
그러나 대기 시간 증가, 데이터 중복 가능성, 비용 증가 등의 절충안이 있습니다. 고가용성, 재해 복구 및 복원성을 계획할 때 몇 가지 제안 사항은 다음과 같습니다.
고가용성
컨트롤 플레인에서 관리하는 자동화된 배포 프로세스는 강력한 고가용성 전략을 수립 하는 데 핵심적인 역할을 합니다 . 이 전략은 파이프라인, 커넥터 및 스트리밍 플랫폼이 클라우드 공급자 또는 데이터 센터를 기반으로 가용성 영역 또는 파티션에 전략적으로 분산되도록 보장합니다.
위험을 줄이기 위해서는 데이터 플랫폼이 모든 데이터 파이프라인을 여러 가용 영역(AZ)에 분산시키는 것이 중요합니다. 파티션 오류가 발생할 경우 중단 없이 데이터 처리를 유지하기 위해 서로 다른 AZ에서 파이프라인의 중복 복사본을 실행하여 연속성이 지원됩니다.
데이터 아키텍처의 기반이 되는 스트리밍 플랫폼은 이를 따라야 하며 복원력을 향상시키기 위해 여러 AZ에 걸쳐 데이터를 자동으로 복제해야 합니다. Redpanda와 같은 솔루션은 파티션 간 데이터 배포를 자동화하여 플랫폼의 안정성과 내결함성을 향상시킬 수 있습니다.
그러나 애플리케이션 및 서비스의 위치를 고려하여 잠재적인 관련 네트워크 대역폭 비용을 고려하십시오. 예를 들어 파이프라인을 데이터 저장소 가까이에 유지하면 네트워크 대기 시간과 오버헤드를 줄이는 동시에 비용도 줄일 수 있습니다.
재해 복구
오류 복구 속도가 빨라지면 데이터 복제 증가로 인해 비용이 높아지고 대역폭 오버헤드가 높아지며 항상 켜져 있는(활성-활성) 설정이 필요하므로 하드웨어 사용량이 두 배로 늘어납니다. 모든 스트리밍 기술이 이 기능을 제공하는 것은 아니지만 Redpanda와 같은 엔터프라이즈급 플랫폼은 데이터 및 클러스터 메타데이터를 클라우드 개체 스토리지에 백업하는 것을 지원합니다.
탄력
고가용성 및 재해 복구 외에도 일부 글로벌 기업에서는 데이터 저장 및 처리가 특정 지리적 규정을 준수하는지 확인하기 위한 지역 배포 전략이 필요합니다. 대신, 최소한의 관리로 여러 지역에서 실시간으로 데이터를 공유하려는 회사는 에이전트가 지역 간에 데이터를 복제하고 배포할 수 있는 공유 클러스터를 만드는 경우가 많습니다.
그러나 이 접근 방식은 데이터가 다음 파티션으로 지속적으로 전송되므로 상당한 네트워크 비용과 대기 시간이 발생합니다. 데이터 트래픽을 완화하기 위해 팔로어 가져오기는 데이터 소비자에게 지리적으로 가장 가까운 팔로어 파티션에서 데이터를 읽도록 지시합니다.
또한 데이터 백필을 위해 클러스터를 확장하면 데이터 센터 전체의 로드 밸런싱이 향상됩니다. 이러한 확장성은 증가하는 데이터 볼륨과 네트워크 트래픽을 관리하는 데 매우 중요하며 기업이 성능이나 안정성을 저하시키지 않고 확장할 수 있도록 지원합니다.
결론적으로
기업이 디지털 혁신을 통해 변화함에 따라 의사 결정을 안내하는 데 실시간 데이터가 점점 더 중요해지고 있습니다. 여기에는 대규모 데이터 세트에서 더 심층적인 통찰력을 추출하고 , 더 정확한 예측을 가능하게 하고, 자동화된 의사 결정 프로세스를 간소화하고, 보다 개인화된 서비스를 제공하는 동시에 비용과 운영을 최적화하는 것이 포함됩니다 .
한 가지 옵션은 C++로 구현된 플러그 앤 플레이 Kafka 대체품 인 Redpanda 와 같은 확장 가능한 데이터 스트리밍 플랫폼을 포함하는 참조 아키텍처를 채택하는 것입니다 . 이를 통해 기업은 원활한 확장, 수명 주기 자동화를 지원하는 관리 API , 스토리지 비용을 줄이기 위한 계층형 스토리지 , 비용 효율적인 읽기 전용 클러스터 설정을 단순화하는 원격 읽기 복제본 및 원활한 지리적 분산 데이터를 촉진하여 실시간을 방지할 수 있습니다. 처리 복잡성.
올바른 기술을 사용하면 SaaS 제공업체는 서비스를 강화하고 고객 경험을 개선하며 디지털 시장에서 경쟁 우위를 높일 수 있습니다. 향후 전략은 SaaS 플랫폼이 데이터 중심 세계에서 성공할 수 있도록 효율성과 적응성을 높이기 위해 이러한 시스템을 지속적으로 최적화해야 합니다.
1990년대에 태어난 프로그래머가 비디오 포팅 소프트웨어를 개발하여 1년도 안 되어 700만 개 이상의 수익을 올렸습니다. 결말은 매우 처참했습니다! 고등학생들이 성인식으로 자신만의 오픈소스 프로그래밍 언어 만든다 - 네티즌 날카로운 지적: 만연한 사기로 러스트데스크 의존, 가사 서비스 타오바오(taobao.com)가 가사 서비스를 중단하고 웹 버전 최적화 작업 재개 자바 17은 가장 일반적으로 사용되는 Java LTS 버전입니다. Windows 10 시장 점유율 70%에 도달, Windows 11은 계속해서 Open Source Daily를 지원합니다. Google은 Docker가 지원하는 오픈 소스 Rabbit R1을 지원합니다. Electric, 개방형 플랫폼 종료 Apple, M4 칩 출시 Google, Android 범용 커널(ACK) 삭제 RISC-V 아키텍처 지원 Yunfeng은 Alibaba에서 사임하고 향후 Windows 플랫폼용 독립 게임을 제작할 계획이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.