OpsNow의 AWS 빌링 데이터 처리 시스템 개발기

제가 처음 OpsNow에 합류하고 받은 업무 중에 하나는 데이터 레이크 구축이었습니다. 모든 데이터를 한 곳에 모아놓고 분석할 수 있는 시스템과 그 데이터들을 종합하여 다양한 서비스를 제공하고자 하는 원대한 포부가 있었습니다. 물론 해당 프로젝트는 여전히 진행중이지만, 순차적으로 내부 시스템 개편을 위해 진행했던 세부 프로젝트중에 하나가 바로 AWS의 빌링 데이터 처리 시스템 개편이었습니다.

머나먼 과거에는…

모든 프로젝트는 초기 의도와는 다르게 항상 변화하기 마련입니다. 저도 신규 처리 시스템을 개발하면서 팀이 여러 차례 변경되었고, 그 과정에서 기존 시스템의 운영도 함께 진행하게 되었는데, 기존 시스템은 빌링 데이터를 수집 즉시 처리하여 Amazon RDS에 적재하고 있었습니다. 데이터 처리는 EC2 위에 구축된 스파크 클러스터가 사용되고 있었습니다.

이 당시에는 대부분의 지급인 계정 (Payer Account)들이 지금은 서비스가 중단된 DBR (Detailed Billing Reports) 방식의 빌링 데이터로 설정되어 있었습니다. 그 후에 CUR (Cost and Usage Reports) 방식의 상세한 빌링 데이터가 새로 등장하면서 더 많은 빌링 정보와 인사이트를 제공할 방법들이 보이기 시작했고, 이 때문에 이미 가공되어 대부분의 컬럼이 버려진 데이터가 아닌 CUR 그대로의 데이터가 필요했습니다.

AWS CUR은 가장 포괄적인 정보 소스를 제공합니다. 개별 비용을 심층적으로 이해하고 더 자세히 분석할 수 있습니다. 이는 엔터프라이즈급 규모에서 특히 유용합니다. AWS CUR은 전용 쿼리 또는 분석 기반 시스템을 사용하는 고객 등 복잡한 비용 관리가 필요한 고객에게 가장 적합합니다. AWS CUR은 특히 분할 상환 요금을 보려는 경우 예약 인스턴스(RI) 정보를 위한 최상의 소스입니다.

– 포괄적인 예약 정보
– 온디맨드 요금 가용성
– 세분화된 할인 분석
– 자동화된 대규모 데이터 수집
– 교차 제품 통합

AWS CUR의 이점 비교

일단, 보다 많은 지급인 계정들이 CUR 데이터를 이용할 수 있도록 변환을 유도하였습니다. 변환이 진행될 수록 데이터 처리 과정에서 유의미한 정보들을 별도로 추출하여 제공할 수 있게 되었습니다. 그러나, 데이터의 크기가 커진 만큼 기존 처리 방식때문에 데이터 처리 시간이 기하급수적으로 증가하기 시작했습니다. 스파크가 분산 처리에 특화되어 있기는 하지만, 보다 효율적으로 쓰는 방법을 몰랐기 때문입니다.

이를 해결하기 위해서 스파크 클러스터를 Amazon EMR (Elastic Map Reduce)로 이전하고, 배치 작업시에만 클러스터를 배포하도록 하였습니다. 여기에 스팟 인스턴스 (Spot Instance)를 사용함으로써 리소스를 확정하더라도 적은 비용을 낼 수 있게 되었습니다. 비용은 잡았는데, 여전히 시간이 문제였습니다. 이 부분은 스파크 작업의 병렬 처리 글을 통해서 따로 언급하겠습니다만, 결과적으로 효율적인 처리 방법을 통해서 처리 시간을 80% 이상 단축할 수 있었습니다.

데이터 수집과 처리, 저장의 분리

데이터의 처리 시간을 단축하고, 그 이후에 진행한 작업은 바로 데이터의 처리와 저장을 분리한 것입니다. EMR을 사용하면 EMR 내부의 하둡 (Hadoop)을 사용할 수도 있지만, 클라우드 특성상 비용 절감을 위해서는 S3가 훨씬 유리합니다. 왜냐하면, 하둡을 사용하게 되는 순간 EMR을 종료할 수 없고, 이를 유지하기 위한 비용은 상당하기 때문입니다. 또한 불의의 사고가 발생하더라도 데이터는 유지되어야 하는데 EMR이 종료되면 데이터의 안정성을 보장할 수 없기 때문에 데이터의 처리와 저장을 우선 분리하게 되었습니다. 이제 EMR은 데이터의 처리를, S3는 데이터의 저장을 전담하게 되었습니다.

그 다음에는 데이터의 수집을 분리하는 것이었습니다. 저장 공간이 분리되었기 때문에 굳이 스파크에서 수집을 할 필요가 없습니다. CUR은 대략 100MB 단위로 파일이 나뉘어 있기 때문에, 병렬로 파일을 일괄 수집할 수 있는 시스템을 구축하면 수집 시간을 매우 단축시킬 수 있습니다. 그렇게 선택했던 것이 Ni-Fi 였습니다.

프로세서 그룹 안에는 별처럼 많은 프로세서들이 연결되어 있습니다.

Apache Ni-Fi는 Web UI를 통해서 사전에 저장된 혹은 사용자가 추가한 단위 프로세서를 이용하여 데이터 워크플로우를 작성할 수 있는 오픈 소스 툴입니다. 다양한 수집 프로세스를 통합 관리할 목적으로 도입했는데, Ni-Fi 클러스터를 유지하기 위한 인프라 비용의 과도한 증가로 인하여 결국 빠르게 손절하였습니다.

이후에 Serverless 플랫폼을 이용하여 빌링 데이터 수집 애플리케이션을 개발하게 되었습니다. 앞서 AWS SAM으로 개발하기 글을 올렸었는데, 신규 빌링 데이터 수집부도 이렇게 새로 개발된 것입니다. 이 부분에 대해서도 Serverless 플랫폼을 이용한 AWS 빌링 데이터 수집 글에서 자세하게 설명하도록 하겠습니다.

데이터 분석 플랫폼

그렇다면, S3에 저장된 데이터를 어떻게 접근하고 분석할 것인가가 숙제로 남았습니다. 데이터 분석 플랫폼은 수시로 켜지고 꺼지는 스파크 클러스터와는 별개로 항상 동작해야 합니다. 그래서 데이터 분석을 위한 프레스토 (Presto) 클러스터를 별도로 만들고, 스파크와 프레스토가 함께 바라볼 하이브 (Hive) 외부 메타 스토어를 RDS에 구축하였습니다.

스파크는 작업을 모두 처리하면 하이브 외부 테이블을 생성하고, 이런 테이블 정보는 메타 스토어에 저장되며 프레스토에서도 동일한 메타 스토어를 통해서 테이블에 쿼리할 수 있는 구조입니다. 데이터는 S3에 있으므로 스파크가 작업을 끝내고 클러스터가 지워져도 프레스토는 아무런 영향을 받지 않습니다.

그러나, 데이터 분석 플랫폼을 이용하는 사용자에 비해서 역시나 과도한 유지비는 부담이 되었고, 결국 AWS 네이티브 서비스로 모두 이전하게 되었습니다. 우리가 사용하던 서비스들에 대응하는 AWS Managed 서비스를 이용함으로써 엄청난 비용 절감을 이룰 수 있었습니다.

  • 하이브 외부 메타 스토어 -> 글루 (AWS Glue)의 데이터 카탈로그
  • 프레스토 클러스터 -> 아테나 (Amazon Athena)
수 많은 테이블들. 모든 이력을 쌓아서 간혹 AWS가 제공한 틀린 데이터도 발견하고는 합니다.

유지 비용을 없애고 온디맨드 사용 비용으로 전환하여 쿼리로 스캔한 데이터 비용만큼만 지불함으로써 적은 사용자에게 알맞은 데이터 분석 플랫폼이 구축되었습니다. 권한 관리를 위한 IAM 설정에 대해서는 AWS Athena의 권한 관리와 클라이언트 접속 글에서 살펴보실 수 있습니다.

To-Do

단순히 필요한 데이터만 처리하던 시스템이 이제는 수집과 처리, 저장을 분리하여 데이터의 초기 형태와 편집된 형태를 모두 보관하고 데이터 분석 플랫폼을 제공함으로써 개발자와 분석가 모두가 더 많은 데이터를 통해서 추가 기능과 데이터 통계에 따른 분석, 그리고 비용 절감 인사이트를 보다 쉽게 제공할 수 있게 되었습니다.

앞으로 시스템을 더욱 발전시켜 나가기 위해서는 어떤 부분의 개선이 필요할까 고민이 많습니다. 지금까지 언급한 이런 변화들은 화면에서 직접적으로 느끼기 어려운 부분들이기 때문입니다. 저는 앞으로 두 가지 부분을 더욱 개선함으로써 고객분들이 OpsNow의 이런 시스템의 변화를 더욱 잘 느낄 수 있도록 하고자 합니다.

  • 다양한 정보를 제공할 수 있도록 화면용 데이터 웨어하우스를 구축하는 것
  • 많은 데이터를 제공할 수 있도록 리포트용 데이터의 소스를 데이터 분석 플랫폼으로 연동하는 것

그 밖의 개선할 점들은 역시 고객분들의 의견을 통해서 이루어질 것입니다. 보다 나은 서비스가 구축될 수 있도록 많은 의견을 보내주시면 더욱 노력하도록 하겠습니다.

Leave a Reply

Your email address will not be published. Required fields are marked *