[데이터 관리정책] 데이터도 다이어트(Diet)가 필요하다!

최근 남녀노소를 불문하고 대분분의 사람들이 건강을 위해 다이어트를 합니다.

비만으로 신체기능의 이상이 발생하여 다양한 합병증을 불러오고 건강에 적신호가 발생할 수 있으며 고혈압, 고지혈등, 당뇨병, 지방간, 동맥경화, 위장장해등 대부분의 성인병의 원인이 되기도 합니다.

무리한 다이어트는 문제가 되지만 운동을 통한 적절한 다이어트는 생체리듬을 활성화 시켜주고 자신감도 키워줄 수 있습니다.

데이터도 우리 몸과 마찬가지로 다이어트가 필요합니다. 

데이터 다이어트(Diet)를 "데이터 슬림화" 라고 표현하기도 합니다. 

실제로 기업내의 데이터를 보관하고 조회하고 분석하기 위해서는 많은 Cost 즉 비용이 발생합니다. 예를들어 기간계에 불필요한(Gabage) 데이터가 있다고 할 때 이는 기간계만의 문제가 아니라 개발계, 테스트계, 교육용 서버, 백업 서버, ODS, EDW 등 수많은 DB에 중복으로 불필요한 데이터가 유지되고 이를 관리하기 위한 인프라 비용 및 추가적인 관리비용이 상상하는 이상으로 커질 수 있습니다. 

우리가 검강검진과 같은 정기적인 진단을 통하여 적절한 체중을 유지하도록 권고받고 적절한 건강상태를 유지하는 것과 마찬가지로 데이터도 적절한 Size(체중)를 유지하는 것이 필요하며 이를 위해 데이터의 증가량 및 업무적인 요구사항에 따라 장기적인 데이터 관리전략이 필요합니다.

이에 실제 Enterprise 환경에서 활용하는 데이터 슬림화란 무엇이고 슬림화 기준 및 효과, 절차 및 고려사항을 알아 보도록 하겠습니다.

1. 데이터 슬림화의 정의

데이터 수준에서 Business 요구사항에 맞는 적절한 용량으로 유지하기 위하여 데이터를 Cutting(데이터 축소)하여 적절한 DB 사이즈를 유지하는 협의의 데이터슬림화와 더불어 목적에 따라서 핵심영역과 비핵심영역으로 데이터를 분산 배치하여 핵심영역의 성능향상 및 유지보수를 용이하게 하고 비핵심 영역 데이터 비용을 절감하는 절차(데이터 분리)를 포괄적으로 정의하기도 합니다.

2. 데이터 슬림화 기준

 1) 데이터 축소(Cutting)

데이터 Cutting 하기위한 기준으로는 다양한 관점으로 정의할 수 있겠지만 데이터 집합 성격에 따른 분류를 통해 Master성, 이력성, 통계, 로그, 인터페이스등으로 데이터를 분류하고 이에따른 전사 슬림화 정책을 정의할 수 있습니다. 

예를들어 기간계의 경우 Master성 데이터의 경우  영구(또는 10년), 이력의 경우 5년, 통계는 2년, 로그는 1년, 인터페이스는 1년과 같이 정의하여 관리할 수 있습니다. 전사 기준으로 모두 동일하게 적용하면 좋겠지만 특정 업무를 위해 특정 테이블 이력의 경우 예외적으로 기간을 연장(예 회계 데이터 7년으로 연장)하고 이에대한 예외사유를 관리할 수 있겠습니다.

정보계의 경우 ODS, EDW 테이블의 전략을 기간계와 마찬가지로 엔터티(테이블)별 관리주기를 정의하여 관리하고 마트의 경우 일마트, 월마트에 따라 관리정책을 분리하여 관리합니다. 통신이나 금융계 시스템의 경우 수천만건을 고객으로 가지고 있는 상황에서 일단위로 마트로 Snapshot으로 관리하는 경우 데이터량이 기하급수적으로 증가(365일 * 1천만건 = 36억 5천만건)하여 시스템이 감담하지 못할 수 있으므로 적절한 관리 기간을 정책으로 정하여 관리할 필요성이 있습니다. 월마트는 3개월, 월마트 5년과 같이 대량의 데이터가 발생하는 데이터 집합에 대한 관리주기 정책을 가져가고 마찬가지로 특정 업무(예 채권업무의 경우 일마트 6개월)의 경우 예외사항적으로 기간을 초과하여 관리하고 이에대한 예외로그를 관리해야 합니다.

      

 2) 데이터 분리 

데이터 분리는 일반적으로 핵심업무용 현행 DB는 고사양/고성능으로 관리하고 저빈도 & 과거 데이터는 저사양/저성능의 DB에 보관하는 것이 일반적인 적용방법입니다. 데이터 분리 시 정책도 핵심DB에서 관리하지 않더라도 분리DB에서 관리하는 경우 이에대한 정책을 정의해야 합니다. 로그테이블이나 Cuttinge된 마스터성 데이터(해지고객 데이터 포함), Cutting된 이력데이터, 특정 기간 이후의 통계데이터등도 핵심 데이터 베이스에서 분리하여 관리하는 정책을 가져갈 수 있습니다. 해지고객 데이터 및 주민번호/연락처등의 개인정보 의 경우 개인정보보호법등에 영향을 받으므로 관리정책 적용 시 적절한 Compliance 기준을 고려해야 합니다. 최근에는 저사양 저빈도의 데이터에 대하여 분리 DB를 저가의 DB(또는 File)에 데이터를 저장하고 빅데이터 기술을 통하여 비용을 절감하는 방법도 기술적으로 논의/적용되고 있습니다. 

3. 데이터 슬림화 효과

 1) 불필요한 전체 Data 양 축소로 Storage 비용 절감

불필요한 데이터 양 축소로 데이터 및 인덱스 사이즈 감소에 따른 Storage 비용을 절감할 수 있습니다. 

 2) 유지보수 비용 절감

DB Back Up 및 Recovery 등의 유지보수 대상  Size 단축으로 인한  수행 시간 단축으로 유수보수 비용 절감할 있으며 단축된 시간을 DBA로 하여금 단순 작업이 아닌 전략적인 방안등에 적절하게 시간 활용을 할 수 있습니다.       

 3) 성능향상  

- 인덱스 Rebuild 비용 향상 : 데이터량이 축소되면 이에 비례하여 관련 Global Index Size 축소 이로 인한 Index depth 가 낮아져 성능이 향상됩니다. 데이터 입력 시 인덱스 Rebuild 비용이 감소합니다. 

- 파티션을 사용하는 경우 파티션 구간 축소로 인한 조회 성능이 향상될 수 있습니다.

- 업무 요구사항에 대한 조회범위 축소로 인한  성능 향상 : 시계열 조건(주, 일, 월등)의 데이터 축소로 인하여 성능 향상될 수 있습니다. 

      

 4) 기타 비용 개선(라이센스 비용) 

- DB License가 Volume Licence인 경우 데이터 Volume 축소로 License 비용 절감가능합니다.(DW 예. Sybase IQ, Vertica 등)

- 특정 Volume 한도내에서 다른 용도로 활용도 가능합니다.(예. 암호화 정책이 컬럼레벨이 아니고 테이블 스페이스 레벨로 적용하는 경우 해당 Storage를 테이블 스페이스 암호화 공간으로도 활용 가능 ) 

4. 데이터 슬림화 절차 

데이터 슬림화는 대상 선정, 리뷰/확정, 슬림화 수행의 세가지 단계를 통해 수행하는 것이 운영 시 안정적으로 적용할 수 있습니다.

 1) 슬림화 대상 선정 

운영중에 있는 데이터 중에서 어떤 데이터를 슬림화 대상으로 삼을 것인지를 결정합니다.

(1) 데이터 분석에 의한 슬림화 기준 적용 검토 대상 선정 - 데이터량 및 데이터 Size 기준으로 어떤 집합(테이블)을 슬림화 대상으로 정의할 기준 정의(예. 천만건 이상 이력 데이터  or 데이터 SIZE 10G 이상 데이터) 

(2) 슬림화 방안 수립 : 테이블 슬림화 ,레코드 슬림화, 컬럼 슬림화, 데이터 모델 개선 및 재적재 계획등 슬림화 방안을 수립합니다. 

 2) 담당자 리뷰 및 대상 확정

대상 확정 후 사용자(현업) 및 운영자(IT 담당자)의 인터뷰를 통해 슬림화 대상에 대한 리뷰 및 검토를 진행합니다. 리뷰 진행 시 시스템 영향도 분석 및 적용 방안을 수립하여 기간계 프로그램 영향도, 배치 프로그램 영향도, 정보계의 사용자 SQL 영향도, OLAP App 영향도를 고려하여 적용합니다.

  

 3) 데이터 슬림화 수행 

실제 데이터 슬림화(테이블 Drop, 컬럼 삭제) 수행합니다. 운영 환경에서 슬림화 방안별로 적용 시 단계별로 쉽게 확인할 수 있는 미사용 테이블 삭제, 보관기간 이전 데이터 삭제, 보관기간 변경등을 기준 및 확정 시 우선 적용하고 영향도가 높은 미사용 컬럼 삭제, 데이터 구조 변경, 데이터 이관, 보안항목 삭제 및 이관등은 리뷰 및 영향도 검토가 완료된 이후에 순차적으로 적용하면 영향도를 최소화 할 수 있습니다.    

5. 데이터 슬림화 시 고려사항

 1) 전사 데이터 관리정책 마련 후 합의 

데이터 슬림화를 진행하려면 전사 데이터 관리정책을 먼저 마련하고 이에대한 합의 및 의사결정을 먼저 받는 것이 필요합니다. 실제로 필자가 슬림화 정책 적용을 위해 현업 인터뷰 시 대부분 모든 데이터를 남겨달라고 하고 본인의 업무 데이터중 삭제를 원하는 담당자는 거의 없었습니다. 하지만 전체 관리정책에 의하여 기준을 정하고 (예 이력은 5년, 일마트는 3개월, 월마트는 5개월로 정의) 예외적인 경우 반드시 사용업무 및 사용 프로그램(SQL) 검토를 통해 예외사항을 정의하면 특정한 경우를 제외하고는 전체 정책에 맞추도록 유도할 수 있습니다.  

 2) 프로그램 변경 영향도 최소화

차세대 시스템 구축과 같이 신규 시스템 구축시 데이터 Sizing을 통한 슬림화를 수행하는 것이 가장 효율적인 방법이지만 운영중에 데이터 슬림화를 진행하려면 운영계 프로그램 및 배치프로그램 영향도, DW 의 경우 현업 사용자가 사용하는  SQL 영향도, OLAP등 App영향도등을 고려해야 합니다. 실제 기간계 화면에서 조회기간에 대한 제약이 발생할 수 있으며 프로그램 및 현업에서 사용하는 SQL이 수정될 수 있으므로 이를 최소화 하기위한 방안을 마련하고 적절한 가이드가 필요한 경우 가이드 및 교육을 진행하여 업무에 미치는 영향도를 최소화하기 위한 작업을 병행하는 것이 좋습니다.

살을 너무 많아도 문제지만 너무 많이 빼서 건강에 적신호가 오는 경우도 있는 것처럼 데이터도 적절한 장기적인 정책에 의하여 관리 비용, 분석 요구사항, 기술추세를 접목하여 적절한 데이터 슬림화 정책을 적용하는 것이 필요할 것입니다. 

데이터 슬림화가 데이터를 운영하는데 크게 다른 작업이 아니라 전사적인 관리체계하에서 데이터 관리 기준을 정의하고 해당 기준을 계속적으로 유지하고자 하는 노력의 결과로서 데이터 슬림화를 지속적으로 유지할 수 있습니다.  

기업의 데이터아키텍쳐(DA)는 전사적인 데이터 전략에 맞게 데이터 슬림화 관리 정책을 마련하고 계속적으로 유지하기 위하여 끊임없이 노력해야 합니다.