이 게시물은 Tanzu CloudHealth(VMware by Broadcom)의 Rivlin Pereira 및 Vaibhav Pandey와 공동으로 작성한 게시물입니다.

VMware Tanzu CloudHealth 는 전 세계 20,000개 이상의 조직이 선택한 클라우드 비용 관리 플랫폼으로, 이 플랫폼을 사용하여 가장 크고 복잡한 멀티 클라우드 환경을 최적화하고 관리합니다. 이 게시물에서는 VMware Tanzu CloudHealth DevOps 팀이 자체 관리형 Apache Kafka 워크로드(버전 2.0 실행)를 Apache Kafka 용 Amazon Managed Streaming (Amazon MSK) 버전 2.6.2를 실행 중입니다. 시스템 아키텍처, 배포 파이프라인, 주제 생성, 관찰 가능성, 액세스 제어, 주제 마이그레이션 및 기존 인프라에서 직면한 모든 문제에 대해 논의하고 새로운 Kafka 설정으로 마이그레이션한 방법과 이유, 그리고 몇 가지 교훈을 얻었습니다.

Kafka 클러스터 개요

빠르게 진화하는 분산 시스템 환경에서 VMware Tanzu CloudHealth의 차세대 마이크로서비스 플랫폼은 Kafka를 메시징 백본으로 사용합니다. 우리에게 Kafka의 고성능 분산 로그 시스템은 대규모 데이터 스트림을 처리하는 데 탁월하므로 원활한 통신에 없어서는 안 될 요소입니다. 분산 로그 시스템 역할을 하는 Kafka는 HTTP 서버 액세스 로그부터 보안 이벤트 감사 로그까지 다양한 로그를 효율적으로 캡처하고 저장합니다.

Kafka의 다재다능함은 주요 메시징 패턴 지원, 메시지를 기본 로그 또는 구조화된 키-값 저장소로 처리하는 데서 빛을 발합니다. 동적 분할과 일관된 순서로 효율적인 메시지 구성이 보장됩니다. Kafka의 흔들리지 않는 신뢰성은 데이터 무결성에 대한 우리의 약속과 일치합니다.

Kafka와 Ruby 서비스의 통합은 더 높은 수준의 래퍼 역할을 하는 Karafka 라이브러리를 통해 간소화됩니다. 당사의 다른 언어 스택 서비스는 유사한 래퍼를 사용합니다. Kafka의 강력한 디버깅 기능과 관리 명령은 원활한 운영과 인프라 상태를 보장하는 데 중추적인 역할을 합니다.

건축의 기둥으로서의 카프카

VMware Tanzu CloudHealth의 차세대 마이크로서비스 플랫폼에서 Kafka는 중요한 아키텍처 기둥으로 등장합니다. 높은 데이터 속도를 처리하고, 다양한 메시징 패턴을 지원하고, 메시지 전달을 보장하는 기능은 우리의 운영 요구 사항에 완벽하게 부합합니다. 우리가 계속 혁신하고 확장함에 따라 Kafka는 변함없는 동반자로 남아 탄력 있고 효율적인 인프라를 구축할 수 있도록 해줍니다.

Amazon MSK로 마이그레이션한 이유

우리의 경우 Amazon MSK로 마이그레이션하는 데 있어 세 가지 주요 결정 사항이 있었습니다.

• 단순화된 기술 운영 – 자체 관리형 인프라에서 Kafka를 실행하는 것은 우리에게 운영 오버헤드였습니다. 한동안 Kafka 버전 2.0.0을 업데이트하지 않았으며 Kafka 브로커가 프로덕션 단계에서 중단되어 주제가 오프라인으로 전환되는 문제가 발생했습니다. 또한 복제 요소를 늘리고 리더의 균형을 재조정하기 위해 스크립트를 수동으로 실행해야 했는데, 이는 추가적인 수동 작업이었습니다.
• 더 이상 사용되지 않는 레거시 파이프라인 및 단순화된 권한 – 우리는 기존 파이프라인에서 벗어나려고 했습니다. 책임감있는 클러스터에 Kafka 주제를 생성합니다. 또한 우리는 스테이징 및 프로덕션 과정에서 팀 구성원에게 Kafka 머신에 대한 액세스 권한을 부여하는 번거로운 프로세스를 갖고 있었고 이를 단순화하고 싶었습니다.
• 비용, 패치 및 지원 - 때문에 아파치 사육사 AWS에서 완전히 관리하고 패치하므로 Amazon MSK로 이전하면 시간과 비용이 절약될 것입니다. 또한 동일한 유형의 브로커를 사용하여 Amazon MSK를 실행하는 것을 발견했습니다. 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2)는 Amazon MSK에서 실행하는 것이 더 저렴했습니다. AWS에서 브로커에 보안 패치를 적용한다는 사실을 고려하면 Amazon MSK로 마이그레이션하는 것은 쉬운 결정이었습니다. 이는 또한 팀이 다른 중요한 업무에 집중할 수 있다는 것을 의미했습니다. 마지막으로, AWS로부터 엔터프라이즈 지원을 받는 것도 관리형 솔루션으로 전환하기로 한 최종 결정에 매우 중요했습니다.

Amazon MSK로 마이그레이션한 방법

핵심 동인을 식별한 후 기존 자체 관리형 Kafka를 Amazon MSK로 마이그레이션하기 위해 제안된 설계를 진행했습니다. 실제 구현에 앞서 다음과 같은 사전 마이그레이션 단계를 수행했습니다.

• 평가:
  • 기존 EC2 Kafka 클러스터에 대한 세심한 평가를 수행하여 구성 및 종속성을 이해했습니다.
  • Amazon MSK와의 Kafka 버전 호환성 확인
• Terraform을 사용한 Amazon MSK 설정
• 네트워크 구성:
  • EC2 Kafka와 MSK 클러스터 간의 원활한 네트워크 연결 보장, 보안 그룹 및 방화벽 설정 미세 조정

마이그레이션 전 단계 후에 새로운 디자인을 위해 다음을 구현했습니다.

• MSK 클러스터를 위한 자동화된 배포, 업그레이드 및 주제 생성 파이프라인:
  • 새로운 설정에서는 IaC 도구를 사용하여 반복 가능한 방식으로 MSK 클러스터의 자동 배포 및 업그레이드를 원했습니다. 따라서 MSK 클러스터 배포 및 업그레이드를 위한 사용자 지정 Terraform 모듈을 만들었습니다. 이 모듈은 젠킨스 MSK 클러스터의 자동화된 배포 및 업그레이드를 위한 파이프라인입니다. Kafka 주제 생성을 위해 우리는 Ansible 기반 자체 개발 파이프라인을 사용하고 있었는데, 이는 안정적이지 않았고 개발팀으로부터 많은 불만을 불러일으켰습니다. 결과적으로 우리는 배포 옵션을 평가했습니다. Kubernetes 클러스터를 사용하여 Strimzi 주제 연산자 MSK 클러스터에 주제를 생성합니다. 주제 생성은 개발팀이 셀프 서비스할 수 있는 Jenkins 파이프라인을 사용하여 자동화되었습니다.
• 클러스터에 대한 관측 가능성 향상:
  • 이전 Kafka 클러스터는 관찰 가능성이 좋지 않았습니다. Kafka 브로커 디스크 크기에 대한 경고만 있었습니다. Amazon MSK를 통해 우리는 다음과 같은 이점을 활용했습니다. 개방형 모니터링 사용 프로 메테우스. 우리는 MSK 클러스터에서 지표를 스크랩하여 내부 관찰 도구로 보내는 독립형 Prometheus 서버를 구축했습니다. 향상된 관찰 가능성 덕분에 기존 설정에서는 불가능했던 Amazon MSK에 대한 강력한 알림을 설정할 수 있었습니다.
• 향상된 COGS 및 더 나은 컴퓨팅 인프라:
  • 기존 Kafka 인프라의 경우 Kafka, Zookeeper 인스턴스 관리 비용과 추가 브로커 스토리지 비용 및 데이터 전송 비용을 지불해야 했습니다. Amazon MSK로 이전하면서 Zookeeper는 AWS에서 완전히 관리되기 때문에 Kafka 노드, 브로커 스토리지, 데이터 전송 비용만 지불하면 됩니다. 그 결과, 프로덕션을 위한 최종 Amazon MSK 설정에서 인프라 비용뿐만 아니라 운영 비용도 절감했습니다.
• 단순화된 운영 및 강화된 보안:
  • Amazon MSK로 이전하면서 Zookeeper 인스턴스를 관리할 필요가 없었습니다. 브로커 보안 패치도 AWS에서 처리했습니다.
  • Amazon MSK로 이동하면서 클러스터 업그레이드가 더욱 간편해졌습니다. Amazon MSK 콘솔에서 시작하는 간단한 프로세스입니다.
  • Amazon MSK를 사용하면 브로커가 생겼습니다. 자동 스케일링 상자 밖으로. 결과적으로 브로커의 디스크 공간 부족에 대해 걱정할 필요가 없어 MSK 클러스터의 안정성이 더욱 높아졌습니다.
  • 또한 Amazon MSK는 기본적으로 저장 데이터 암호화를 지원하고 전송 중 암호화에 대한 다양한 옵션도 사용할 수 있으므로 클러스터에 대한 추가 보안을 확보했습니다. 자세한 내용은 다음을 참조하세요. Apache Kafka용 Amazon Managed Streaming의 데이터 보호.

마이그레이션 전 단계에서 프로덕션을 진행하기 전에 준비 환경에서 설정을 검증했습니다.

Kafka 주제 마이그레이션 전략

MSK 클러스터 설정이 완료되면 Amazon EC2에서 실행되는 이전 클러스터에서 새 MSK 클러스터로 Kafka 주제의 데이터 마이그레이션을 수행했습니다. 이를 달성하기 위해 우리는 다음 단계를 수행했습니다.

• Terraform을 사용하여 MirrorMaker 설정 – 우리는 Terraform을 사용하여 미러메이커 15개의 노드로 구성된 클러스터. 이는 마이그레이션의 동시 복제 요구 사항에 따라 노드 수를 조정하여 확장성과 유연성을 입증했습니다.
• 동시 복제 전략 구현 – 마이그레이션 프로세스를 가속화하기 위해 15개의 MirrorMaker 노드로 동시 복제 전략을 구현했습니다. Terraform 기반 접근 방식은 마이그레이션 중에 리소스를 효율적으로 관리하여 비용 최적화에 기여했으며 MSK 및 MirrorMaker 클러스터의 안정성과 일관성을 보장했습니다. 또한 선택한 설정이 어떻게 데이터 전송을 가속화하고 시간과 리소스를 모두 최적화하는지 보여주었습니다.
• 데이터 마이그레이션 – 매우 짧은 시간 내에 2TB의 데이터를 성공적으로 마이그레이션하여 가동 중지 시간을 최소화하고 동시 복제 전략의 효율성을 보여주었습니다.
• 마이그레이션 후 모니터링 설정 – 마이그레이션 중에 강력한 모니터링 및 경고를 구현하여 문제를 신속하게 식별하고 해결함으로써 원활한 프로세스에 기여했습니다.

다음 다이어그램은 주제 마이그레이션이 완료된 후의 아키텍처를 보여줍니다.

도전과 교훈

특히 대규모 데이터 세트의 경우 마이그레이션 여정을 시작할 때 예상치 못한 문제가 수반되는 경우가 많습니다. 이 섹션에서는 MirrorMaker를 사용하여 EC2 Kafka에서 Amazon MSK로 주제를 마이그레이션하는 동안 직면한 문제를 살펴보고 마이그레이션 성공을 결정짓는 귀중한 통찰력과 솔루션을 공유합니다.

과제 1: 오프셋 불일치

우리가 직면한 문제 중 하나는 MirrorMaker에서 오프셋 동기화를 활성화한 경우에도 소스 클러스터와 대상 클러스터 간의 주제 오프셋 불일치였습니다. 여기서 배운 교훈은 오프셋 동기화가 활성화되어 있는 한 오프셋 값이 반드시 동일할 필요는 없다는 것입니다. 이를 통해 주제가 데이터를 읽을 수 있는 올바른 위치를 갖게 됩니다.

우리는 사용자 정의 도구를 사용하여 소비자 그룹에서 테스트를 실행하고 변환된 오프셋이 더 작거나 따라잡았는지 확인하여 MirrorMaker에 따른 동기화를 나타냄으로써 이 문제를 해결했습니다.

과제 2: 느린 데이터 마이그레이션

마이그레이션 프로세스는 병목 현상에 직면했습니다. 특히 상당한 2TB 데이터 세트의 경우 데이터 전송 속도가 예상보다 느렸습니다. 20노드 MirrorMaker 클러스터임에도 불구하고 속도가 부족했습니다.

이를 극복하기 위해 팀은 고유한 포트 번호를 기반으로 MirrorMaker 노드를 전략적으로 그룹화했습니다. 각각 고유한 포트가 있는 5개의 MirrorMaker 노드로 구성된 클러스터는 처리량을 크게 향상시켜 며칠이 아닌 몇 시간 내에 데이터를 마이그레이션할 수 있게 했습니다.

과제 3: 자세한 프로세스 문서가 부족합니다.

MirrorMaker를 사용하여 대규모 데이터 세트를 마이그레이션하는 미지의 영역을 탐색하면서 그러한 시나리오에 대한 자세한 문서가 없다는 점을 강조했습니다.

시행착오를 거쳐 팀은 Terraform을 사용하여 IaC 모듈을 제작했습니다. 이 모듈은 최적화된 설정으로 전체 클러스터 생성 프로세스를 간소화하여 몇 분 내에 마이그레이션을 원활하게 시작할 수 있도록 했습니다.

최종 설정 및 다음 단계

Amazon MSK로 이전한 결과, 주제 마이그레이션 후 최종 설정은 다음 다이어그램과 같았습니다.

우리는 다음과 같은 향후 개선 사항을 고려하고 있습니다.

결론

이 게시물에서는 VMware Tanzu CloudHealth가 기존 Amazon EC2 기반 Kafka 인프라를 Amazon MSK로 마이그레이션한 방법에 대해 논의했습니다. 새로운 아키텍처, 배포 및 주제 생성 파이프라인, 관찰 가능성 및 액세스 제어 개선, 주제 마이그레이션 과제, 기존 인프라에서 직면한 문제, 그리고 새로운 Amazon MSK 설정으로 마이그레이션한 방법과 이유를 살펴보았습니다. 또한 Amazon MSK가 제공한 모든 이점, 이번 마이그레이션을 통해 달성한 최종 아키텍처 및 배운 교훈에 대해서도 이야기했습니다.

우리에게는 오프셋 동기화, 전략적 노드 그룹화 및 IaC의 상호 작용이 장애물을 극복하고 Amazon EC2 Kafka에서 Amazon MSK로의 성공적인 마이그레이션을 보장하는 데 중추적인 역할을 한다는 것이 입증되었습니다. 이 게시물은 마이그레이션 문제에서 적응성과 혁신의 힘에 대한 증거로서 유사한 경로를 탐색하는 다른 사람들에게 통찰력을 제공합니다.

AWS에서 자체 관리형 Kafka를 실행하는 경우 관리형 Kafka 제품을 사용해 보시기 바랍니다. 아마존 MSK.

저자에 관하여

리블린 페레이라 VMware Tanzu Division의 직원 DevOps 엔지니어입니다. 그는 Kubernetes에 대한 열정이 매우 높으며 확장 가능하고 안정적이며 비용 효율적인 CloudHealth 플랫폼 구축 및 운영 클라우드 솔루션을 담당하고 있습니다.

바이바브 판데이Broadcom의 직원 소프트웨어 엔지니어인 는 클라우드 컴퓨팅 솔루션 개발에 핵심적으로 기여한 사람입니다. 데이터 스토리지 계층 설계 및 엔지니어링을 전문으로 하는 그는 최적의 성능을 위해 SaaS 애플리케이션을 구축하고 확장하는 데 열정을 갖고 있습니다.

라즈 라마수부 Amazon Web Services를 사용한 빅 데이터 및 분석 및 AI/ML에 중점을 둔 선임 분석 전문가 솔루션 설계자입니다. 그는 고객이 AWS에서 확장성과 성능이 뛰어나고 안전한 클라우드 기반 솔루션을 설계하고 구축하도록 돕습니다. Raj는 AWS에 합류하기 전 18년 이상 동안 데이터 엔지니어링, 빅 데이터 분석, 비즈니스 인텔리전스 및 데이터 과학 솔루션을 구축하는 데 기술 전문 지식과 리더십을 제공했습니다. 그는 의료, 의료 기기, 생명 과학, 소매, 자산 관리, 자동차 보험, 주택 REIT, 농업, 소유권 보험, 공급망, 문서 관리 및 부동산과 같은 다양한 산업 분야의 고객을 도왔습니다.

토드 맥그래스 Amazon Web Services의 데이터 스트리밍 전문가로서 고객에게 스트리밍 전략, 통합, 아키텍처 및 솔루션에 대해 조언합니다. 개인적 측면에서 그는 낚시, 피클볼, 아이스하키, 폰툰 보트에서 친구 및 가족과 함께하는 해피아워 등 자신이 추구하는 활동을 따르는 것뿐만 아니라 십대 3명이 선호하는 활동을 지켜보고 지원하는 것을 즐깁니다. LinkedIn에서 그와 연결해보세요.

사티아 파타나익 AWS의 수석 솔루션 아키텍트입니다. 그는 ISV가 AWS 클라우드에서 확장 가능하고 탄력적인 애플리케이션을 구축하도록 돕고 있습니다. AWS에 합류하기 전에는 엔터프라이즈 부문의 성장과 성공에 중요한 역할을 했습니다. 업무 외 시간에는 '맛있는 바비큐 요리 방법'을 배우고 새로운 요리법을 시도하는 데 시간을 보냅니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/