데이터의 중요성이 날로 커짐에 따라 데이터를 안전하게 보관하고 관리하는 일의 중요성 또한 강조되고 있습니다. 특히 GDPR과 같은 데이터 보호 법규를 준수하기 위해 많은 기업이 높은 비용을 지출하고 있는 상황에서, 관련 비용을 효율적으로 줄이는 방안이 한층 더 필요해지고 있습니다. 본 포스팅에서는 이러한 문제를 해결하기 위해 시도한 방법을 공유하고자 합니다.

GDPR은 General Data Protection Regulation의 약어로 유럽연합(EU)에서 제정한 데이터 보호 및 프라이버시 관련 법규이며 2018년 5월부터 시행되었습니다.

그림 1. GDPR

GDPR은 데이터를 수집/처리하는 기업들이 개인의 데이터 권리를 보호하며 투명하고 안전한 방식으로 데이터를 관리하도록 요구합니다. 위반할 경우 기업에 막대한 과징금이 부과될 수 있어 GDPR 준수는 선택이 아닌 필수 과제로 인식되고 있습니다. 또한 데이터의 양이 많아질수록 GDPR에 대응하는 비용도 비례해서 늘어나기 때문에 비용 효율적인 솔루션을 찾는 것이 더욱 중요합니다.

현재 서비스는 AWS EMR 환경에서 서버를 운용하며 Hadoop과 Hive를 활용하여 대규모 데이터를 수집 및 처리하고 있습니다. 저장된 데이터에 대해 매일 GDPR 대응(삭제권, 처리제한권, 이동권 등의 권리 대응)을 진행합니다. 그런데 서비스 확산에 따른 지속적인 데이터 증가로 GDPR 처리 비용과 시간이 증가하여 GDPR 대응 시한을 넘기지 않기 위한 효율적인 해결책이 필요했습니다. 사용자 권리 대응을 처리할 수 있는 다양한 솔루션을 검토하였으나 대용량 서비스 데이터를 옮기고 필요한 기능을 구성하는 데 많은 공수가 발생할 것으로 예상되었기 때문에 최소한의 수정으로 최대 효과를 낼 수 있는 방안이 필요했습니다.

그림 2. 다양한 솔루션들

다양한 실험을 통해 데이터 구조 개선 방안을 도출하였고, 이를 통해 많은 이슈를 개선할 수 있었습니다. GDPR 대응은 결국 이동권, 삭제권, 처리제한권 등을 요구하는 사용자를 찾아 권리 대응을 진행하는 것입니다. 따라서 권리를 요구하는 사용자 ID를 보다 효율적으로 탐색하면 시간과 비용을 줄일 수 있다고 판단되었습니다. 다양한 속성의 데이터가 존재했으며 데이터마다 다른 특성이 있었습니다. 특히 평균적으로 ID당 많은 로그를 가진 데이터가 GDPR 대응에 더 많은 시간이 소요됐고, 이 탐색 비용 문제를 해소한다면 큰 비용을 절감할 수 있을 것으로 기대되었습니다. 

그림 3. 데이터 구조 개선

그래서 여러 시도 중 채택한 방법은 탐색할 ID를 기준으로 필요 데이터를 List 형태로 만드는 방법입니다. 단순 ID만을 기준으로 List를 만들 경우 List 양이 거대해지는 이슈가 있었기 때문에, 변화량이 적은 컬럼들을 기준으로 변화량이 많은 컬럼들을 List로 만들기로 했습니다. 운영 중인 데이터 가운데 가장 큰 비중을 차지하는 데이터를 1차 변환 대상으로 선정하였습니다. 해당 데이터는 row가 약 10조 개로 처리 대상 사용자 데이터 탐색에 많은 시간이 소요되는 문제가 있었습니다. 따라서 test case를 정의하고 제한된 크기의 데이터를 바탕으로 사전 테스트를 진행했습니다.

그림 4. 테스트 결과

테스트 결과, 삭제권 및 이동권 데이터 처리에 필요한 자원의 양이 크게 감소하였습니다. 또한 수행 시간도 크게 감소하여 GDPR 대응 시 시간적 여유가 많이 생길 것으로 기대되었습니다. 설혹 제한된 크기 기반의 테스트 결과만큼 개선이 이루어지지 않더라도 기존 대비 큰 개선을 이룰 수 있겠다는 확신이 들었습니다. 실제로 ID당 log가 많은 특성을 갖는 데이터를 대상으로 데이터 구조 변경 작업을 진행했으며, 그 결과 운영 비용을 약 54% 절감하고 수행 시간을 약 50% 줄일 수 있었습니다. 

 

그림 5. EMR 구성

위 그림은 현재 서비스에서 사용 중인 AWS EMR Cluster의 구성입니다. EMR은 open source framework를 사용하는 빅데이터 처리 솔루션으로, primary, core, task node로 구성됩니다. primary node와 core node는 자원 할당이 보장되는 on-demand type이며, task node는 computing을 목적으로 하므로 필요시 자원을 할당하는 spot type을 사용합니다. on-demand는 항상 자원 할당이 보장되어 가격이 비싸지만 안정적이기에 core node로 활용하고 있습니다. 한편, task node는 상대적으로 가격이 저렴한 spot type을 사용해 필요시 필요한 양만큼 자원을 할당함으로써 비용효율적으로 구성하고 있습니다. spot type은 자원 할당이 해제될 수 있기 때문에 리스크가 어느 정도 존재하지만 computing의 경우 재할당 및 재수행을 통해 리스크에 대비할 수 있습니다.

그림 6. 개선 전 메모리 사용량

위 그림에서 분홍색은 할당된 노드 메모리 총량을, 회색은 실제 job에 할당된 메모리 총합을 나타냅니다. task node의 경우 필요시 할당하고 사용 후 해제하는 방법으로 비용을 아낄 수 있지만, 할당 및 해제하는 policy를 통해 작업이 이루어지므로 적당한 최적화가 필요합니다. 데이터 구조 개선 후 기존 policy를 따르고 있었기 때문에 실제 사용한 메모리와 할당된 메모리의 간극이 심해졌으며, 이 차이를 줄인다면 추가 비용 절감이 가능할 것으로 판단되었습니다. 

policy를 수정하기 위해서는 우선 모니터링 데이터가 필요합니다. 기본적으로 EMR scale out에서는 남은 메모리 비중과 pending 상태의 컨테이너 비율을 기준으로 scale in/out을 진행합니다.

그림 7. EMR 모니터링

개선 전 구조에 맞는 policy를 계속 사용했을 때 cluster scale in/out에 비효율이 발생했는데, 주요 Metric monitoring을 통해 policy를 fine tuning함으로써 cluster 사용률을 높일 수 있었습니다. 또한 데이터 개선 전에 비해 메모리 사용량이 크게 줄었기 때문에 노드 할당 최대치를 제한하는 방법으로 추가 개선을 진행했습니다. trade off로 시간 비용이 증가하지만 task node의 할당 최대치를 제한함으로써 메모리 사용 효율이 증가하는 것을 확인했습니다.

그림 8. 개선 후 메모리 사용량

위 그림은 서비스 데이터 및 작업 구성의 특성을 고려하여 auto scaling policy를 개선한 후 메모리 사용량 그래프입니다. 개선 전 그래프와 비교했을 때 최대 높이가 감소했으며 불필요한 메모리 할당이 크게 줄어들었습니다. policy의 경우 특정 조건이 일정 시간 동안 만족되면 node n개를 scale in, out하는 방식으로 설정합니다. 데이터 개선 전 policy를 customize하면서 자원 사용량을 모니터링하여 적정 조건과 값을 도출하였습니다. 이에 따라 별도 학습이나 프로그램 운영 없이 상당히 강력한 결과를 얻을 수 있었습니다.

서비스의 확장성과 영속성을 위해서는 GDPR과 같은 사용자 권리 대응의 요구사항을 충족하는 동시에 처리 비용을 최소화해야만 합니다. 저희는 데이터 구조와 cluster scaling을 개선함으로써 운영 비용을 약 75% 절감할 수 있었습니다. 이 같은 개선 사항을 대용량 데이터를 수집/활용하는 다른 서비스에도 적절히 적용하여 비용 절감 효과를 거둘 수 있을 것이라 생각됩니다.