BLOG
오늘날 많은 기업들이 고객 경험을 개선하고 데이터를 통한 즉각적인 통찰력을 얻기 위해 실시간 애플리케이션을 구축하고 있습니다. 그 결과 Apache Kafka와 같은 개발자를 위한 데이터 스트리밍 서비스 제공에 대한 수요가 증가했습니다. 이러한 수요를 충족하기 위해 기업은 일반적으로 중소 규모의 중앙 집중식 Apache Kafka 클러스터로 시작하여 글로벌 스트리밍 서비스를 구축하고, 시간이 지남에 따라 스트리밍 수요에 맞게 클러스터 용량을 확장하고 있습니다. 모놀리식 클러스터를 유지하여 모든 기술 전문 지식을 한 곳에서 가져옴으로써 인력 배치 및 교육을 단순화하는 것인데요, 이러한 접근 방식은 기술 부채, 전체 운영 비용 및 복잡성을 줄이기 때문에 비용 이점도 있습니다. 모놀리식 클러스터에서는 추가 용량이 모든 애플리케이션에서 공유되므로 일반적으로 전체 스트리밍 인프라 비용이 줄어드는 것이죠.
오늘 포스팅에서는 중앙 집중식 접근 방식의 몇 가지 문제를 설명하고 Amazon MSK Serverless를 사용하여 분산 접근 방식을 구현하기 위한 두 가지 전략을 소개해 드리고자 합니다. 분산 전략을 사용하면 모놀리식 클러스터 대신 여러 Apache Kafka 클러스터를 프로비저닝할 수 있습니다. 이 전략이 애플리케이션의 보안, 스토리지 및 성능 요구 사항에 따라 클러스터를 최적화하는데 어떻게 도움이 되는지 알아보겠습니다. 또한 분산 모델의 이점과 모놀리식 클러스터에서 다중 클러스터 배포 모델로 마이그레이션하는 방법에 대해서도 설명할 예정입니다.
MSK Serverless는 Apache Kafka 클러스터 관리의 오버헤드와 비용을 줄여줍니다. Apache Kafka 클러스터에 대한 컴퓨팅 및 스토리지 리소스를 자동으로 프로비저닝 및 확장하고 클러스터 용량을 자동으로 관리할 수 있습니다. 파티션이 백엔드 노드에 어떻게 분산되어 있는지 모니터링하고 필요할 때 파티션을 자동으로 재할당할 뿐만 아니라 클러스터 상태를 모니터링할 수 있는 Amazon CloudWatch와 같은 다른 AWS 서비스와도 통합이 가능합니다.
솔루션 개요
Apache Kafka는 실시간 스트리밍 데이터 파이프라인 및 애플리케이션을 구축하기 위한 확장 가능한 고성능 내결함성 오픈 소스 플랫폼입니다. 생산자와 소비자를 분리하여 스트리밍 데이터 생성 및 소비를 단순화하며 생산자는 단순히 단일 데이터 저장소(Apache Kafka)와 상호 작용하여 데이터를 보냅니다. 소비자는 생산자의 아키텍처나 프로그래밍 언어와 무관하게 지속적으로 흐르는 데이터를 읽습니다.
Apache Kafka는 다음과 같은 많은 사용 사례에서 널리 사용되고 있습니다.
- 실시간 웹 및 로그 분석
- 거래 및 이벤트 소싱
- 메시징
- 마이크로서비스 분리
- 스트리밍 ETL(추출, 변환 및 로드)
- 측정 항목 및 로그 집계
모놀리식 Apache Kafka 클러스터의 과제
모놀리식 Apache Kafka를 사용하면 기업이 데이터 센터에 여러 클러스터를 설치하고 유지 관리할 필요가 없습니다. 그러나 이 접근 방식에는 다음과 같은 일반적인 단점이 있습니다.
- 전체 스트리밍 용량이 한 곳에 통합되어 용량 계획이 어렵고 복잡합니다. 일반적으로 클러스터를 계획하고 재구성하는 데 더 많은 시간이 필요합니다. 예를 들어, 판매 또는 대규모 캠페인 이벤트를 준비할 때 모든 애플리케이션에서 필요한 용량의 집계를 예측하고 계산하기가 어렵습니다. 또한 새 워크로드에 대해 대규모 클러스터를 재구성하는 것은 소규모 클러스터보다 시간이 오래 걸리기 때문에 회사의 성장을 저해할 수도 있습니다.
- 모놀리식 클러스터는 공유 리소스이기 때문에 Apache Kafka 클러스터의 소유권 및 유지 관리와 관련하여 조직적 충돌이 발생할 수 있습니다.
- Apache Kafka 클러스터는 단일 실패 지점이 됩니다. 다운 타임은 모든 관련 애플리케이션의 중단을 의미합니다.
- 다중 데이터 센터 배포로 Apache Kafka의 복원력을 높이도록 선택한 경우 일반적으로 다른 데이터 센터에 동일한 크기(큰 크기)의 클러스터가 있어야 하므로 비용이 많이 듭니다.
- 버전 업그레이드 또는 OS 패치 설치 와 같은 유지 관리 및 운영 활동은 Apache Kafka 아키텍처의 분산 특성으로 인해 대규모 클러스터의 경우 훨씬 더 오래 걸립니다 .
- 결함이 있는 응용 프로그램은 전체 클러스터 및 기타 응용 프로그램의 안정성에 영향을 줄 수 있습니다.
- 버전 업그레이드는 모든 애플리케이션이 새로운 Apache Kafka 버전으로 테스트될 때까지 기다려야 합니다. 이는 모든 애플리케이션이 Apache Kafka 기능을 빠르게 실험하는 것을 제한합니다.
- 이 모델을 사용하면 차지백 목적으로 클러스터를 실행하는 비용을 애플리케이션에 귀속시키기가 어렵습니다.
다음 다이어그램은 모놀리식 Apache Kafka 아키텍처를 보여줍니다.
탈중앙화 모델
분산형 Apache Kafka 배포 모델에는 여러 클러스터의 프로비저닝, 구성 및 유지 관리가 포함됩니다. 여러 클러스터를 관리하려면 온프레미스 환경에서 운영 우수성, 고급 모니터링, 코드형 인프라, 보안 및 하드웨어 조달에 막대한 투자가 필요하기 때문에 이 전략은 일반적으로 선호되지는 않습니다.
그러나 MSK Serverless를 사용하여 분산형 Apache Kafka 클러스터를 프로비저닝하는 데는 이러한 투자가 필요하지 않습니다. 애플리케이션 요구 사항에 따라 용량과 스토리지를 즉시 확장 및 축소하여 복잡한 용량 계획 없이 새로운 워크로드를 추가하거나 작업을 확장할 수 있습니다. 또한 처리량 기반 가격 책정 모델을 제공하며 애플리케이션에서 사용하는 스토리지 및 처리량에 대해 비용을 지불합니다. 또한 MSK Serverless를 사용하면 Apache Kafka 버전 업그레이드, 파티션 재할당 또는 OS 패치와 같은 표준 유지 관리 작업을 더 이상 수행할 필요가 없습니다.
MSK Serverless를 사용하면 일반적으로 자체 관리형 Apache Kafka 배포와 함께 제공되는 운영 부담 없이 분산 배포의 이점을 누릴 수 있습니다. 이 전략에서 DevOps 관리자는 여러 클러스터를 프로비저닝, 구성, 모니터링 및 운영하는 데 시간을 할애할 필요가 없습니다. 대신 더 많은 실시간 애플리케이션을 온보딩하기 위해 더 많은 운영 도구를 구축하는 데 더 많이 투자합니다.
앞으로 분산 모델을 구현하기 위한 다양한 전략에 대해 설명두랄 예정인데요, 각 전략의 이점과 과제를 강조하여 조직에 가장 적합한 것이 무엇인지 결정하는데 도움이 될 것입니다.
쓰기 클러스터 및 읽기 클러스터
이 전략에서 쓰기 클러스터는 생산자로부터 데이터 수집을 담당합니다. 새 주제를 만들거나 새 MSK Serverless 클러스터를 만들어 새 워크로드를 추가할 수 있으며, 현재 워크로드의 크기를 조정해야 할 때 순서가 중요하지 않다면 단순히 주제의 파티션 수를 늘리기만 하면 됩니다. MSK Serverless는 새로운 구성에 따라 즉시 용량을 관리합니다.
각 MSK 서버리스 클러스터는 최대 200MBps의 쓰기 처리량과 400MBps의 읽기 처리량을 제공합니다. 또한 파티션당 최대 5MBps의 쓰기 처리량과 10MBps의 읽기 처리량을 할당합니다.
조직 내 데이터 소비자는 일반적으로 두 가지 주요 범주로 나눌 수 있습니다.
- 매우 짧은 지연 시간(예: 밀리초 또는 1초 미만)의 데이터가 필요하고 매우 짧은 RTO(Recovery Time Objective)만 허용할 수 있는 시간에 민감한 워크로드
- 더 긴 대기 시간(10초 미만에서 분 수준의 대기 시간)과 더 긴 RTO를 허용할 수 있는 시간에 민감하지 않은 워크로드
이러한 각 범주는 데이터 분류, 규정 준수 또는 SLA(서비스 수준 계약)와 같은 특정 조건에 따라 하위 범주로 더 나눌 수도 있습니다. 읽기 클러스터는 특정 소비자 그룹이 사용할 수 있는 비즈니스 또는 기술 요구 사항 또는 조직 경계에 따라 설정할 수 있습니다. 마지막으로 소비자는 연결된 읽기 클러스터에 대해 실행되도록 구성됩니다.
쓰기 클러스터를 읽기 클러스터에 연결하려면 데이터 복제 파이프라인이 필요합니다. 다양한 방법으로 데이터 복제 파이프라인을 구축할 수 있습니다. MSK Serverless는 표준 Apache Kafka API를 지원하므로 MirrorMaker 2와 같은 표준 Apache Kafka 도구를 사용하여 Apache Kafka 클러스터 간의 복제를 설정할 수 있습니다 .
다음 다이어그램은 이 전략의 아키텍처를 보여줍니다.
이 접근 방식에는 다음과 같은 이점이 있습니다.
- 생산자와 소비자가 분리됨에 따라 쓰기 처리량 또한 읽기 처리량과 독립적으로 확장할 수 있습니다. 예를 들어 기존 클러스터의 최대 읽기 처리량에 도달하여 새 소비자 그룹을 추가해야 하는 경우 새 MSK Serverless 클러스터를 프로비저닝하고 쓰기 클러스터와 새 읽기 클러스터 간에 복제를 설정하기만 하면 됩니다.
- 보안 및 규정 준수를 강화하는 데 도움이 됩니다. 데이터를 복제하는 동안 개인 식별 정보(PII)와 같은 데이터 이벤트의 민감한 필드를 마스킹하거나 제거할 수 있는 스트리밍 작업을 빌드할 수 있습니다.
- 다른 클러스터는 보존 측면에서 다르게 구성될 수 있습니다. 예를 들어 읽기 클러스터는 요구 사항에 따라 스토리지 비용을 절약하기 위해 서로 다른 최대 보존 기간으로 구성할 수 있습니다.
- 특정 클러스터의 중단에 대한 응답 시간을 다른 클러스터보다 우선시할 수 있습니다.
- 향상된 복원력을 구현하기 위해 쓰기 클러스터의 데이터만 복제하여 백업 지역에 더 적은 수의 클러스터를 가질 수 있습니다. 워크로드 장애 조치가 호출될 때 읽기 클러스터와 같은 다른 클러스터를 프로비저닝할 수 있습니다. 이 모델에서는 MSK Serverless 가격 책정 모델을 사용하여 백업 리전에서 사용한 만큼(경량 복제본)에 대해 추가 비용을 지불합니다.
이 전략을 선택할 때 염두에 두어야 할 몇 가지 중요한 참고 사항이 있습니다.
- 클러스터 간에 여러 복제를 설정해야 하므로 운영 및 유지 관리가 더 복잡해집니다.
- MirrorMaker 2와 같은 복제 도구는 최소 한 번 처리만 지원합니다. 즉, 실패 및 재 시작 중에 데이터 이벤트가 복제될 수 있습니다. 데이터 복제를 허용할 수 없는 소비자가 있는 경우 MirrorMaker 2를 사용하는 대신 Apache Flink 와 같이 데이터 복제를 위한 정확히 한 번 처리 의미 체계를 지원하는 데이터 파이프라인을 구축하는 것이 좋습니다 .
- 소비자는 쓰기 클러스터에서 직접 데이터를 사용하지 않기 때문에 기록기와 판독기 사이의 대기 시간이 늘어납니다.
- 이 전략에서는 Apache Kafka 클러스터가 여러 개 있어도 소유권과 제어 권한은 여전히 한 팀에 있고 리소스는 단일 AWS 계정에 있습니다.
클러스터 분리
일부 회사의 경우 중앙 데이터 플랫폼을 통해 Apache Kafka에 대한 액세스를 제공하면 확장, 소유권 및 책임 문제가 발생할 수 있습니다. 인프라 팀은 데이터 최신성 또는 대기 시간 요구 사항, 보안, 데이터 스키마 또는 데이터 수집에 필요한 특정 방법과 같은 애플리케이션의 특정 비즈니스 요구 사항을 이해하지 못할 수 있습니다.
애플리케이션을 소유한 팀에 소유권과 자율성을 부여하여 이러한 문제를 줄일 수 있습니다. 공통 중앙 플랫폼만 사용하는 것이 아니라 애플리케이션과 필요한 인프라를 구축하고 관리할 수 있습니다. 예를 들어 개발 팀은 자체 Apache Kafka 클러스터를 프로비저닝, 구성, 유지 관리 및 운영할 책임이 있습니다. 그들은 애플리케이션 요구 사항의 도메인 전문가이며 애플리케이션 요구 사항에 따라 클러스터를 관리할 수 있습니다. 이렇게 하면 전반적인 마찰이 줄어들고 애플리케이션 팀이 광고된 SLA에 대해 책임을 지게 됩니다.
앞서 언급했듯이 MSK Serverless는 Apache Kafka 클러스터와 관련된 운영 및 유지 관리 작업을 최소화합니다. 이를 통해 자율 애플리케이션 팀은 AWS에서 고가용성 Apache Kafka 클러스터를 실행하는 전문가가 아니더라도 업계 모범 사례에 따라 클러스터를 관리할 수 있습니다. MSK Serverless 클러스터가 AWS 계정 내에서 프로비저닝된 경우 애플리케이션 및 데이터 스트리밍 서비스 운영과 관련된 모든 비용도 소유합니다.
다음 다이어그램은 이 전략의 아키텍처를 보여줍니다.
이 접근 방식에는 다음과 같은 이점이 있습니다.
- MSK Serverless 클러스터는 다른 팀에서 관리합니다. 따라서 전반적인 관리 작업이 최소화됩니다.
- 응용 프로그램은 서로 격리되어 있습니다. 결함이 있는 애플리케이션이나 클러스터의 다운 타임은 다른 애플리케이션에 영향을 미치지 않습니다.
- 소비자는 데이터가 기록되는 동일한 클러스터에서 짧은 대기 시간으로 데이터를 직접 읽습니다.
- 각 MSK Serverless 클러스터는 쓰기 및 읽기 처리량에 따라 다르게 확장됩니다.
- 단순 비용 속성은 애플리케이션 팀이 인프라와 비용을 소유한다는 것을 의미합니다.
- 스트리밍 인프라의 전체 소유권을 통해 개발자는 스트리밍을 더 빨리 채택하고 더 많은 기능을 제공할 수 있습니다. 또한 장애 및 중단에 대한 응답 시간을 단축하는 데 도움이 될 수 있습니다.
이전 전략과 비교하여 이 접근 방식은 다음과 같은 단점이 있습니다.
- 여러 팀에 걸쳐 통합 보안 또는 규정 준수를 시행하는 것은 어렵습니다.
- 동일한 데이터의 중복 복사본이 여러 클러스터에서 수집될 수 있습니다. 이는 전체 비용을 증가시킵니다.
- 복원력을 높이려면 각 팀 이 MSK Serverless 클러스터 간의 복제를 개별적으로 설정해야 합니다 .
중앙 집중식에서 분산형 전략으로 이동
MSK Serverless는 AWS 명령줄 인터페이스 (AWS CLI) 도구를 제공하고 몇 분 만에 클러스터를 프로비저닝하기 위한 AWS CloudFormation 템플릿을 지원합니다. AWS가 제공하는 방법을 통해 앞서 언급한 모든 전략을 구현하고 새 클러스터가 준비되면 생산자와 소비자를 마이그레이션할 수 있습니다.
다음 단계는 이러한 전략의 구현에 대한 추가 지침을 제공합니다.
- 모놀리식 Apache Kafka의 현재 문제에 초점을 맞춰 시작합니다. 다음으로 각 전략에 나열된 대로 문제점과 장점 및 단점을 비교하십시오. 이를 통해 회사에 가장 적합한 전략을 결정할 수 있습니다.
- 각 애플리케이션의 성능, 탄력성, SLA 및 소유권 요구 사항을 개별적으로 식별하고 문서화합니다.
- 요구 사항이 유사한 응용 프로그램을 그룹화하십시오. 예를 들어 일괄 분석을 실행하는 몇 가지 응용 프로그램을 찾을 수 있습니다. 따라서 데이터 신선도에 민감하지 않으며 민감한(또는 PII) 데이터에 액세스할 필요도 없습니다. 클러스터를 분리하는 것이 회사에 적합한 전략이라고 결정했다면 애플리케이션을 소유한 팀별로 애플리케이션을 그룹화하도록 선택할 수 있습니다.
- MSK Serverless 할당량 과 각 애플리케이션의 스토리지 및 스트리밍 처리량 요구 사항 그룹을 비교 합니다. 이를 통해 하나의 MSK Serverless 클러스터가 필요한 집계 스트리밍 용량을 제공할 수 있는지 여부를 결정할 수 있습니다. 그렇지 않으면 더 큰 그룹을 더 작은 그룹으로 나눕니다.
- AWS Management Console , AWS CLI 또는 CloudFormation 템플릿 을 통해 이전에 식별한 각 그룹별로 MSK Serverless 클러스터를 생성합니다 .
- 각각의 새로운 MSK Serverless 클러스터에 해당하는 주제를 식별하십시오.
- 복제 요구 사항에 따라 Amazon MSK로의 최상의 마이그레이션 패턴을 선택합니다 . 예를 들어 데이터 변환이 필요하지 않고 애플리케이션에서 중복 데이터 이벤트를 허용할 수 있는 경우 MirrorMaker 2.0과 같은 Apache Kafka 마이그레이션 도구를 사용할 수 있습니다.
- 데이터가 새 클러스터에 올바르게 복제되는지 확인한 후 먼저 새 클러스터에 대해 소비자를 다시 시작합니다. 이렇게 하면 마이그레이션 결과로 데이터가 손실되지 않습니다.
- 소비자가 데이터 처리를 재개한 후 새 클러스터에 대해 생산자를 다시 시작하고 이전에 생성한 복제 파이프라인을 종료합니다.
현재는 MSK Serverless는 인증 및 액세스 제어를 위해 AWS Identity and Access Management (IAM)만 지원합니다. 자세한 내용은 Amazon MSK용 IAM 액세스 제어에 대한 쉽고 친숙한 Apache Kafka 보안을 참조하십시오. 애플리케이션이 Apache Kafka에서 지원하는 다른 방법을 사용하는 경우 IAM 액세스 제어를 대신 사용하거나 Amazon MSK 프로비저닝된 제품을 사용하도록 애플리케이션 코드를 수정해야 합니다.
요약
MSK Serverless는 고가용성 Apache Kafka의 프로비저닝, 구성 및 유지 관리를 포함한 운영 오버헤드를 제거합니다. 오늘 포스팅에서는 Apache Kafka 클러스터를 분할하여 전체 데이터 스트리밍 서비스 및 애플리케이션의 보안, 성능, 확장성 및 안정성을 개선하는 방법을 설명드렸습니다. 또한 MSK Serverless를 사용하여 모놀리식 Apache Kafka 클러스터를 분할하는 두 가지 주요 전략에 대해서도 설명했습니다. Amazon MSK 프로비저닝된 제품을 사용하는 경우 이러한 전략은 중앙 집중식 모델에서 분산형 모델로의 전환을 고려할 때 여전히 관련이 있습니다. 회사의 특정 요구 사항에 따라 올바른 전략을 결정할 수 있습니다.
Amazon MSK에 대한 자세한 내용은 공식 제품 페이지를 방문해 주세요.
메가존클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.