굿닥에서 지속 가능한 데이터 분석하기. (2)
굿닥은 데이터 중심과 데이터 기반의 플랫폼을 구축 중입니다.
지속 가능한 데이터 분석을 위해서는 데이터 플랫폼의 운영과 관리를 위한 지속적인 비용과 관리 리소스의 투입이 꾸준하게 발생됩니다.
플랫폼이건 서비스이건 한번 만들어 놓으면 알아서 동작하는 시스템이라는 것은 애초에 존재를 하지 않죠.
대표적인 것은 각종 DB 연결과의 이슈, 로그정보나 행위정보들의 데이터의 인입 시에 발생하는 문제, 사용자 서비스의 변경을 통해서 만들어지는 변경 이슈 등을 시작으로 하여, 각 데이터들이 모여지고 관리되고 분산되고 동작되는 서비스들의 트러블, 어느 정도 시스템으로 운영되고 확장되고 내부적인 데이터 속성들의 관리의 문제는 매우 지속적으로 발생되는 문제입니다.
가장 기본적인 것을 몇 개 나열하면 도대체 이런 데이터를 모으기 위한 서비스의 최대 호출 빈도와 실행에 걸리는 시간, 어느 정도 DB나 시스템과 연결되어야 하는지에 대해서 지속적으로 체크해야 합니다.
안타깝지만, 어느 정도 규모 이상을 넘어서고, 기업이 이익을 보는 정도라면 해당 시스템을 운영하는 것은 기존 고객 서비스의 규모를 커버하는 것 이상의 노력과 시간이 투여됩니다.
더군다나, 조금 잘못 디자인되면 AWS의 비용은 기하급수적으로 늘어나기 때문에 지속 가능한 데이터 분석 플랫폼의 가장 기초 단계를 다지는 단계에서 매우 귀찮고, 복잡하고, 단순한 노가다성 작업들을 지속적으로 하게 됩니다.
보통 여기서 나가떨어지거나, 포기하거나, 미래의 가치를 내던져 버리는 경우도 많이 보게 됩니다.
AWS의 경우 네트워크 PUT비용만 조금 잘못 계산해도 이슈가 커지게 되니까요. 데이터 가공을 위해서 작은 파일로 나누고 합치는 과정들도 조회 시의 이슈가 되는 상황까지... 플랫폼을 유지 관리하는 아주 기본적인 형태에 대해서 매우 큰 업무가 지속적으로 발생합니다.
아이러니하지만, 지속 가능한 데이터 분석 플랫폼을 유지하려면, 어떻게든 이 지속 가능한 데이터 분석 플랫폼을 회사나 조직의 규모와 업무의 형태에 맞추어서 적절하게 디자인되어야 합니다.
AWS의 Glue를 사용하면 클라우드의 데이터의 추출, 변환 및 로드(ETL)등을 매우 손쉽게 관리하고, 통합된 데이터 카탈로그 등, 각종 언어에 필요한 적절한 툴킷까지 매우 효과적으로 사용이 가능합니다.
어느 정도 비용 부담과 내부 인력들의 성장을 위해서라면 AWS의 적절한 서비스들을 혼용하여 구축하는 것도 매우 바람직합니다. 개인적으로 그것을 권하는 경우도 많고요.
단! 개발팀 이외의 데이터팀에 데이터 플랫폼 인프라를 지속적으로 관리할 수 있는 인력의 배분이 가능한 경우에만 그렇게 권합니다. 2~3명 정도가 지속적으로 데이터 플랫폼 인프라를 관리할 수 있고, 해당 인프라를 지속적으로 관리해야 하는 이유가 명확한 경우에는 이 방법도 좋습니다.
( Amazon EMR [ 관리형 클러스트 플랫폼], Kinesis [실시간 데이터 처리기], Glue [데이터 카탈로그/통합 보기], S3 [클라우드 스토리지], Radshift [비용 효율적인 데이터 웨어 하우스] 등의 세트를 활용하여 데이터 플랫폼을 구축하는데 매우 요긴합니다. )
데이터 분석 조회 기능의 효과적인 배분을 위해서 RedShift의 JSON파일들을 단순하게 만들고, Glue의 ETL작업을 통해서 이를 지속적으로 정리 정돈해야 하는 작업은 매우 빈번하고 반복적으로 발생됩니다.
여기서 제가 TD를 선택한 이유는 해당 작업을 위해서 인력 리소스를 굳이 더 추가할 필요 없이 ETL, Glus, RedShift를 혼용하고 ETL작업등을 매우 손쉽게 다룰 수 있는 TD를 사용하면서 이 작업은 더욱더 단순해집니다.
배치작업과 관련된 스크립트까지 적절하게 구사할 수 있는 TD를 사용하면서, 초기 비용은 분명 들어가지만, 보다 분명하게 데이터 수집과 마트를 구축하는 업무를 1명의 개발자로 인프라 유지보수 관리에 대해서 투입 없이 효과적으로 서비스를 몇 개월 만에 진행하게 되었으니까요.
내부적으로 지속적인 데이터 인프라 팀의 능력을 성장시키고, 이를 기반으로 보다 복잡한 서비스들을 유지 관리해야 하는 계획이 있고, 데이터 인프라팀에 5~6명, 데이터 팀과 분석/관리/예측에 10명 이상의 팀이 꾸려지고, ML과 실 서비스 연계에 30명 이상의 개발팀에 세팅이 된다면, 뭐.. 굳이 TD를 사용할 필요는 없습니다.
그만큼 복잡한 업무를 위해서 인력을 세팅하려는 개발 총괄 책임자의 큰 그림이 있을 것입니다.
하지만, 일단. 데이터팀을 최소화하고, 미래를 위한 데이터 인프라를 구축하고, 빠르게 고객 개인화된 타기팅이나 데이터 마트를 다루기 위한 업무를 수행한다면, 현재 선택할 수 있는 최고의 솔루션은 TD 아닌가 합니다.
의지가 있는 데이터 엔지니어 1명만 있어도, 상당한 규모의 데이터 마트와 관련 인프라를 손쉽게 구축 가능할 수 있으니까요.
.
.
.
계속 지속적으로 이어집니다.
