빅 데이터에 대한 Sprout Social의 접근 방식 재창조

Sprout Social은 본질적으로 데이터 기반 회사입니다. Sprout은 매일 여러 소셜 네트워크에서 수십억 개의 메시지를 처리합니다. 이로 인해 Sprout 엔지니어는 매우 많은 양으로 플랫폼에 들어오는 동일한 메시지(예: 리트윗, 댓글 등)의 여러 버전을 저장하고 업데이트하는 방법과 같은 고유한 문제에 직면해 있습니다.

여러 버전의 메시지를 저장하기 때문에 Sprout 엔지니어는 하루에도 여러 번 "세상을 다시 만드는" 작업을 수행합니다. 이는 소셜 메시지의 모든 부분을 하나의 "진실의 출처"로 통합하기 위해 전체 데이터 세트를 반복해야 하는 필수 프로세스입니다.

예를 들어 단일 Twitter 게시물의 좋아요, 댓글 및 리트윗을 추적합니다. 역사적으로 우리는 자체 관리형 Hadoop 클러스터에 의존하여 이러한 대량의 데이터를 유지 관리하고 작업했습니다. 각 Hadoop 클러스터는 Sprout 엔지니어링 팀 전체에서 빅 데이터 프로젝트를 대규모로 관리하기 위해 의존하는 방식인 Sprout 플랫폼의 서로 다른 부분을 담당합니다.

Sprout의 빅 데이터 접근 방식의 핵심

우리의 Hadoop 에코시스템은 확장 가능하고 분산된 NoSQL 데이터베이스인 Apache Hbase에 의존했습니다. 빅 데이터 처리에 대한 우리의 접근 방식에서 Hbase를 중요하게 만드는 것은 전체 데이터 세트에 대한 빠른 범위 스캔을 수행할 뿐만 아니라 빠르고 무작위로 단일 레코드 조회를 수행하는 기능입니다.

또한 Hbase를 사용하면 데이터를 대량으로 로드하고 임의 데이터를 업데이트할 수 있으므로 순서가 맞지 않거나 부분 업데이트로 도착하는 메시지 및 소셜 미디어 데이터와 함께 제공되는 기타 문제를 보다 쉽게 ​​처리할 수 있습니다. 그러나 자체 관리형 Hadoop 클러스터는 재해 복구 수동 관리, 클러스터 확장 및 노드 관리를 포함하여 인프라 엔지니어에게 높은 운영 비용 부담을 안겨줍니다.

수백 테라바이트의 데이터로 이러한 시스템을 관리하는 데 걸리는 시간을 줄이기 위해 Sprout의 인프라 및 개발 팀은 함께 모여 자체 관리형 Hadoop 클러스터를 실행하는 것보다 더 나은 솔루션을 찾았습니다. 우리의 목표는 다음과 같습니다.

• Sprout 엔지니어가 대규모 데이터 세트를 더 잘 구축, 관리 및 운영할 수 있도록 합니다.
• 시스템을 수동으로 소유하고 유지 관리하기 위해 엔지니어가 투자하는 시간 최소화
• 클러스터 확장으로 인한 과잉 프로비저닝의 불필요한 비용 절감
• 더 나은 재해 복구 방법 및 안정성 제공

현재 빅 데이터 시스템에 대한 대안을 평가하면서 현재 처리 및 패턴과 쉽게 통합되고 클러스터를 수동으로 관리할 때 발생하는 운영 수고를 덜 수 있는 솔루션을 찾기 위해 노력했습니다.

새로운 데이터 패턴 대안 평가

우리 팀에서 고려한 솔루션 중 하나는 데이터 웨어하우스였습니다. 데이터 웨어하우스는 데이터 분석 및 집계를 위한 중앙 집중식 저장소 역할을 하지만 Hbase에 비해 기존 관계형 데이터베이스와 더 유사합니다. 그들의 데이터는 구조화되고 필터링되며 엄격한 데이터 모델을 갖습니다(즉, 단일 개체에 대해 단일 행을 가짐).

여러 버전의 메시지가 나란히 있는 소셜 메시지를 저장하고 처리하는 사용 사례의 경우 데이터 웨어하우스는 우리의 요구에 비효율적인 모델을 가지고 있었습니다. 기존 모델을 데이터 웨어하우스에 효과적으로 적용할 수 없었고 성능도 예상보다 훨씬 느렸습니다. 데이터 웨어하우스 모델에 맞게 데이터를 다시 포맷하려면 우리가 보유한 타임라인에서 재작업하기 위해 많은 오버헤드가 필요했습니다.

우리가 조사한 또 다른 솔루션은 데이터 레이크하우스였습니다. 데이터 레이크하우스는 데이터 웨어하우스 개념을 확장하여 덜 구조화된 데이터, 더 저렴한 스토리지 및 민감한 데이터 주변의 추가 보안 계층을 허용합니다. 데이터 레이크하우스는 데이터 웨어하우스가 제공할 수 있는 것보다 더 많은 것을 제공했지만 현재 Hbase 솔루션만큼 효율적이지는 않았습니다. 병합 레코드와 삽입 및 삭제 처리 패턴 테스트를 통해 배치 작업에 허용 가능한 쓰기 대기 시간을 생성할 수 없었습니다.

AWS EMR로 오버헤드 및 유지 관리 감소

데이터 웨어하우징 및 레이크하우스 솔루션에 대해 배운 내용을 바탕으로 관리형 Hbase를 실행하는 대체 도구를 살펴보기 시작했습니다. 우리는 Hbase를 현재 사용하는 것이 Sprout에서 하는 일에 효과적이라고 판단하면서 "Hbase를 더 잘 운영하여 주요 사용 패턴을 유지하면서 운영 부담을 낮추려면 어떻게 해야 할까요?"라고 자문했습니다.

이때 Hbase용 Amazon EMR(Elastic Map Reduce) 관리 서비스를 평가하기 시작했습니다. EMR을 평가하려면 데이터 수집 테스트와 같이 데이터 웨어하우스 및 레이크하우스를 테스트한 것과 동일한 방식으로 성능을 평가하여 성능 요구 사항을 충족할 수 있는지 확인해야 했습니다. 또한 데이터 스토리지, 고가용성 및 재해 복구를 테스트하여 인프라/관리 ​​관점에서 EMR이 우리의 요구 사항에 적합한지 확인해야 했습니다.

EMR의 기능은 현재 자체 관리형 솔루션을 개선했으며 Hbase에서 했던 것과 동일한 방식으로 작업을 읽고 쓰고 실행하는 데 현재 패턴을 재사용할 수 있게 해주었습니다. EMR의 가장 큰 이점 중 하나는 데이터를 노드 자체가 아닌 S3에 저장하는 EMR 파일 시스템(EMRFS)을 사용한다는 것입니다.

우리가 발견한 문제는 EMR에 제한된 고가용성 옵션이 있어 단일 가용 영역에서 여러 기본 노드를 실행하거나 여러 가용 영역에서 하나의 기본 노드를 실행하도록 제한된다는 것입니다. 재해 복구를 위한 추가 내결함성과 컴퓨팅 기능에서 데이터 스토리지의 분리를 제공하므로 EMRFS를 활용하여 이 위험을 완화했습니다. EMR을 Hbase용 솔루션으로 사용함으로써 확장성과 장애 복구를 개선하고 클러스터를 유지 관리하는 데 필요한 수동 개입을 최소화할 수 있습니다. 궁극적으로 우리는 EMR이 우리의 요구 사항에 가장 적합하다고 결정했습니다.

마이그레이션 프로세스는 사전에 쉽게 테스트되고 실행되어 고객 가동 중지 시간 없이 수십억 개의 레코드를 새로운 EMR 클러스터로 마이그레이션했습니다. 새 클러스터는 성능이 향상되고 비용이 거의 40% 감소했습니다. EMR로의 전환이 인프라 비용을 절감하고 성능을 개선하는 데 어떻게 도움이 되었는지 자세히 알아보려면 Sprout Social의 AWS 사례 연구를 확인하십시오.

우리가 배운 것

이 프로젝트의 규모와 범위로 인해 인프라 데이터베이스 안정성 엔지니어링 팀은 여러 엔지니어링 팀과 교차 기능적으로 작업할 수 있는 기회를 얻었습니다. 도전적이었지만 협업 엔지니어링 조직인 Sprout에서 해결할 수 있는 대규모 프로젝트의 놀라운 예임이 입증되었습니다. 이 프로젝트를 통해 우리 인프라 팀은 Sprout의 데이터가 어떻게 사용, 저장 및 처리되는지 더 깊이 이해하게 되었고 향후 문제를 해결하는 데 더 많은 도움을 받을 수 있게 되었습니다. 우리는 차세대 고객 기능을 구축하는 데 도움이 될 수 있는 여러 팀 간에 공통 지식 기반을 만들었습니다.

우리가 구축하고 있는 것에 관심이 있다면 지금 우리 팀에 합류하여 개방형 엔지니어링 역할 중 하나에 지원하십시오.