SK플래닛의 Log Data Compliance

안녕하세요. Data Infrastructure팀(이하 DI팀)에서 Data Application을 개발하고 Data Compliance를 관리하는 신현주입니다.

이 글에서는 Data Compliance가 무엇이고, SK플래닛은 어떻게 대처하고 있는지 다음 6가지 주제를 통해 소개해 드리고자 합니다.

  • Data Compliance의 정의
  • SK플래닛 Data Infrastructure에서 다루는 데이터의 종류
  • SK플래닛의 Data Compliance 현황
  • 데이터 암호화를 중심으로 한 Data Compliance 실무 이해
  • SK플래닛의 데이터 지표 관리
  • 향후 과제

Data Compliance의 정의

Compliance는 법, 명령 등의 ‘준수’를 의미합니다. 그리고 Data Compliance는 ‘데이터에 대한 규제 준수’를 뜻합니다. 우리나라의 서비스 및 데이터 규제 기관으로는 금융위원회, 금융감독원, 미래창조과학부, 방송통신위원회, 행정자치부, 한국인터넷진흥원(KISA)이 있습니다. 규제 기관은 운영하는 서비스의 종류와 수집하고 적재하는 데이터의 종류에 따라 달라집니다. KISA-기술안내서 가이드를 통해 정보보호시스템과 개인정보보호에 관한 KISA의 법령 및 안내를 살펴보면 도움을 얻을 수 있습니다.

혹시, “어? 우리는 고객의 비밀번호도 없고, 바이오 정보도 없고, 휴대폰번호나 아이디 정도만 기록하고 있는데 암호화가 꼭 필요할까?” 라는 생각이 드신다면, <그림 1>을 살펴보시기 바랍니다.

1
<그림 1> KISA 암호화 담당자와의 대화

SK플래닛 Data Infrastructure에서 다루는 데이터의 종류

클러스터에 존재하는 데이터는 크게 원천(source) 데이터와 파생(product) 데이터로 이루어지고, 원천 데이터는 다시 적재 형태에 따라 끊임 없이 흘러 들어오는 데이터를 적재하는 Stream Data와 그때 그때의 현황을 사진 찍듯이(snapshot) 떠서 적재하는 Snapshot Data로 나뉩니다.

  • Stream Data는 실시간 적재하는 로그성 데이터로, 발생 지점에 따라 server-side log(서비스 서버 로그)와 client-side log(고객 단말 로그)로 두 가지 종류가 있습니다.
  • DB Data는 운영계 DB Table을 주기적으로 추출해 적재하는 데이터로, Stream Data에 비해 규모는 작으나 수는 훨씬 많습니다.

저마다 구분되는 형태와 특성, 즉 schema를 가진 각각의 원천 데이터를 Data Collection이라 부릅니다. Data Collection은 클러스터 내에서 입수 – 적재 – 처리 단계마다 존재 형태가 다르지만, 대체로는 Hive table 하나로 인식됩니다. 또한, 각 Data Collection은 그것을 발생시킨 서비스 또는 BM(Business Model)에 따라 Hive database로 묶어서 관리합니다. DI클러스터에는 2016년 11월 02일을 기준으로 총 847개의 DataCollection(143개 Stream Data + 704개 DB Data)이 있습니다. 2016년을 기준으로 SK플래닛의 대표적인 BM은 11st, Syrup, Gifticon, OKcashbag, Recopick이 있습니다.

SK플래닛의 Data Compliance 현황

SK플래닛의 Data Compliance는 정책은 사내 *CV추진팀(*CV: customer value; 고객정보보호팀)의 안내와 감독을 따릅니다. CV추진팀은 방송통신위원회와 한국인터넷진흥원 등 정부기관의 정책을 정리해 사내에 배포하고, 사내/외 변호사에게 자문을 구해 새로운 정책적 해석을 얻어내고 대처하는 역할을 합니다. 이 글에서 설명하는 많은 정책과 대응 방안 역시 CV추진팀의 의견이 곳곳에 녹아 있습니다.

Data Compliance 중에서 특히 Stream Data의 Compliance에 대한 이해를 위해, 먼저 <그림 2> 데이터의 상태 및 흐름을 살펴보겠습니다. Data Status는 화산의 상태에 빗댄 표현이며, Activity Data는 활화산의 용암 분출점에 빗댄 표현입니다. 화산의 상태에 따라 화산을 다루는 방식이 다르듯이 Compliance 이슈를 처리하는 방식이 다릅니다. 뜨겁게 흘러가는 용암을 다루는 방식과 시간이 지나 굳은 암석을 다루는 방식이 다르듯이 데이터의 상태에 따라 데이터의 처리 방법도 다를 수 밖에 없습니다.

데이터의 상태 및 흐름
<그림 2> 데이터의 상태 및 흐름

Active Data

의미

  • “Active Data”는 데이터가 끊임 없이 흘러 들어오고 있는 Data Collection을 의미합니다. Active Data는 그 발생 시간을 나타내는 필드(예를 들어, timestamp 필드)를 바탕으로 일정 구간마다 하나의 덩어리로 끊어서 적재하는데, 이를 Partition이라고 합니다. Partition을 나누는 단위는 Data Collection의 규모에 따라 일 단위 또는 시간 단위로 정합니다. 이상적이라면 현재 발생하는 데이터를 담을 Partition, 즉 가장 최신 Partition에만 데이터가 쌓여야 하지만, 데이터 입수 과정에서 불가피하게 일어나는 순서의 역전이나 지연, 장애 복구에 따른 재전송 등으로 인해 과거 Partition에도 데이터가 쌓일 수 있습니다. 이렇게 데이터가 추가적으로 쌓일 가능성이 있는 Partition을 “Hot-spot Partition”이라 부르고, 여기에 쌓인 데이터를 “Hot-spot Data”라고 합니다. 그리고 특정 시간이 지나 새로운 변화가 없는 Partition을 “Cold-spot Partition”이라 부르며, 여기에 쌓인 데이터를 “Cold-spot Data”라고 합니다.

암호화

  • 내용이 많아서 별도의 Section에 정리했습니다. 네 번째 주제인 ‘데이터 암호화를 중심으로 한 Data Compliance 실무 이해’ 를 봐주세요. 🙂

유효기간

  • 약관에 보관기간이 지정돼 있는 경우, 유효기간이 지난 데이터를 삭제하고 Partition도 삭제합니다.
  • 현재는 Continuous Integration 도구인 Jenkins를 이용해 주기적으로 데이터 및 Partition을 삭제하는 Shell Script를 실행합니다.

탈퇴회원

  • 각 Data Collection 내에서 탈퇴한 회원의 Log Data를 회사의 정책에 따라 적시에 삭제합니다. 이를 위해 탈퇴회원 목록을 DI클러스터로 입수한 후, Hive 상에서 Log Data와 탈퇴회원 정보를 outer join해서 삭제합니다.
  • 탈퇴회원의 Log Data를 비식별화 처리하면 개인정보로 취급하지 않기 때문에 이 방법이 더 낫다고 생각할 수도 있지만, 비식별화 처리를 할 경우에는 데이터에 왜곡이 발생할 수 있기 때문에 비식별화 처리하지 않습니다.
    탈퇴회원 Log Data 삭제 처리는 실시간성 작업이 아니라 주기적으로 돌아가는 일괄처리 작업(Batch Job)입니다. 따라서 개인정보 Key를 메시지 다이제스트 방식으로 변환하거나 문자열 일부를 Masking 하면 일괄처리 작업이 수행된 시점을 기준으로 데이터의 일관성이 깨집니다.
  • 예를 들어 MAU(월간 활성 사용자) 통계값을 구할 경우, <그림 3>와 같이 왜곡이 발생 할 수 있습니다.
    • 왜곡 1: 신현주와 신현진은 다른 사용자인데 Masking 작업 후에는 같은 사용자로 보입니다.
    • 왜곡 2: 통계값을 구하는 기간 내에 탈퇴회원 삭제 작업이 일어난다면 신현주와 신현*는 같은 사용자이지만 다른 사용자로 보입니다.
  • 이렇게 종, 횡 모두의 측면에서 데이터의 왜곡이 발생 합니다. 물론 Log Data를 모두 삭제하면 탈퇴한 사용자의 수나 행위의 수에 따라 데이터가 감소 할 수 있으나, 이는 탈퇴 사용자 삭제 작업에 대한 기록을 통해 오차범위를 줄일 수 있습니다.

%e1%84%90%e1%85%a1%e1%86%af%e1%84%90%e1%85%ac%e1%84%92%e1%85%ac%e1%84%8b%e1%85%af%e1%86%ab
<그림 3> 비식별화 처리시 통계값 왜곡

Extinct Data

의미

  • “Extinct Data”는 서비스 종료나 신규 로그 개발 등의 이유로 인해 Data Collection 전체에서 더 이상 새로운 변화량이 생기지 않는 경우, 즉 데이터 입수가 중단 된 Data Collection을 의미합니다.

Extinct Data 인지 방법

  • 소극적인 방법으로는 데이터 소비자에게 Data Collection의 fade out 계획을 공유 받는 방법이 있습니다.
  • 적극적인 방법으로는 시스템을 통해 Extinct Data를 탐지하는 방법이 있습니다. DI팀에서는 *Insomnia로 데이터 입수량이 줄어들거나 사용량이 줄어든 상황을 자동으로 검출하고 있습니다.
    (*Insomnia: 데이터 입수 상태 및 저장된 데이터를 분석하여 이상 징후를 탐지하고, 이상 징후 발견 시 통지하는 시스템)

파기 (퇴역)

  • Data Collection이 더 이상 존재 의미가 없거나 존재하지 말아야 한다고 판단하면 데이터 파기를 진행합니다.
  • HDFS의 데이터와 Hive Table을 삭제합니다.

박제 (salt를 가미한 메시지 다이제스트)

  • 서비스 종료 등으로 데이터의 생성이 중단되고 더 이상 데이터가 적재되지 않는 서비스 중에서 향후 연구나 분석 가치가 있는 데이터에 한해 박제 처리 합니다. 박제 처리란 어떠한 경우에도 개인을 알아낼 수 없게 개인정보를 비식별화하는 작업을 의미합니다.
  • 다른 Data Collection과 연결 되지 않도록 salt 값을 넣어서 메시지 다이제스트를 하고, 보안을 위해 한 번 사용한 salt 값은 즉시 폐기합니다. 따라서 다른 Data Collection과 Join하여 사용하거나 개인 정보를 복호화하여 사용할 수 없습니다.

데이터 암호화를 중심으로 한 Data Compliance 실무 이해

암호화의 종류와 알고리즘

암호화는 그 용도와 처리 방식, 보안 수준에 따라 다양한 방식과 알고리즘이 존재합니다. <표1>에 간략히 정리해 놓았습니다.

key1

<표 1> 암호화의 종류와 알고리즘

SK플래닛 Log Data 암호화 방식

SK플래닛에서 채택한 암호화 방식을 이해하기 위해서는 <그림4> DI클러스터의 Stream Data Collection Pipeline에 대한 이해가 필요합니다. Log Collector를 중심으로 단계를 나눠 설명하겠습니다.

SK플래닛은 비밀키 암호화 방식과 공개키 암호화 방식을 병행 사용합니다.

Log Collector 이전 단계

  • 공개키 암호화 방식을 적용합니다.
  • Log Collector 이전 단계에서는 여러 BM의 서버 및 단말에서 Data를 수집하는데, 이 때는 공개키로 암호화 합니다. 복호화할 때와 다른 키를 사용하기 때문에 각 BM의 데이터 생성자와 개발자는 복호화가 불가능합니다.
  • 완벽한 통제가 불가능한 다수의 주체들에게 키를 배포해야 하는 상황이므로, 공개키 암호화 방식을 적용해 중요한 기밀인 복호화 키가 외부에 공개되는 상황을 방지합니다.

Log Collector 이후 단계

  • 비밀키 암호화 방식을 적용합니다.
  • Log Collector에서는 공개키 암호화 알고리즘이 적용된 개인정보 컬럼을 개인키를 써서 모두 복호화 하고, 즉시 비밀키 암호화 방식으로 다시 암호화 합니다. 즉, 최종적으로 HDFS에 적재되는 Log Data는 높은 비도의 비밀키 암호화 방식으로 암호화돼 있습니다.

pipeline
<그림 4> DI클러스터의 Stream Data Collection Pipeline

왜 SK플래닛은 고객의 개인정보를 이런 방식으로 암호화하는 것일까?

모든 기술적 선택이 그렇듯이, 이 방식에도 장점과 단점이 있습니다.

먼저 단점은 다음과 같습니다.

  • DI클러스터에서는 복호화 + 재암호화 작업이 필요하기 때문에 암호화를 한번만 적용 했을 때에 비해 배 이상의 연산 자원을 사용합니다.

하지만, 다음과 같은 장점을 더 높이 평가했습니다.

  • 비밀키 암호화 방식이 공개키 암호화 방식보다 암호화 후 문자열 길이가 짧습니다. 즉, Provisioning Tool에서 Log를 조회 할 때 부담도 적고, 클러스터 내에서 용량도 적게 차지 합니다.
  • 더 중요한 점은, 어느 단계에서도 고객의 개인정보가 평문으로 존재해서는 안 된다는 요건을 충족시킬 수 있습니다. 비밀키만 사용할 경우에는 키의 광범위한 배포 및 그에 따른 보안 관리상의 문제로 인해 이 요건을 충족시키기 어렵습니다. 따라서, 연산자원이 더 들고 방식이 복잡해지더라도 이 방식을 채택할 수 밖에 없었습니다.

물론, 중간에 Log Collector에서 공개키를 풀어서 개인키로 재암호화하는 대신, 원래의 공개키 암호화를 유지한 채 적재할 수도 있습니다. 하지만 공개키 암호화 방식이 소요 시간과 결과 데이터의 문자열 길이에서 개인키 방식에 비해 현저히 불리하기 때문에, 중간에 한 번 변환하는 편이 더 낫다는 판단입니다.

암호화 적용 과정

기 입수 Data Collection의 암호화 과정

  • 암호화 대상 필드 확인
    • ‘암호화 대상 필드 가이드’를 참고하여 암호화 대상 필드를 체크합니다. 가이드 문서의 형식은 <그림 5>를 참고해 주세요. 사내의 민감한 정책 해석과 밀접한 관련이 있으므로, 로그 발생 시각 필드를 제외하고 공개할 수 없는 점을 양해해 주시기 바랍니다.
  • 각 Data Collection의 소유권자와 소비자 사이의 암호화 일정 조율
  • 과거 데이터와 Collector 암호화 적용 및 검증

신규 입수 Data Collection의 암호화 과정

  • 암호화 대상 필드 확인
    • 데이터 소유권자가 *Sentinel을 통해 데이터 입수 요청을 할 때, CV추진팀과 협의 후 직접 암호화 대상 필드를 표기합니다. (*Sentinel:  로그 데이터의 정의 및 그에 따른 Formatting Library 생성, 생성된 로그의 QA 및 시나리오 테스트, 리포팅을 제공하는 Data Schema 관리 도구)
    • 이 때 표기된 암호화 대상 필드는 데이터 입수 시에 자동으로 공개키 암호화를 적용합니다.
  • Collector 암호화 적용 및 검증

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2016-11-03-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-5-1<그림 5> 암호화 대상 필드 가이드 일부 캡쳐

Terminator

Terminator는 HDFS에 적재된 데이터에 대해 암호화 등의 데이터 변경을 할 수 있도록 만든 DI팀 자체 개발 도구 입니다. Hocon 형태의 Property만 정의해 주면 MapReduce 혹은 Spark에서 간단한 ETL작업을 해줍니다. 주로 Data Compliance 이슈를 해결할 때 사용하고, 잘못된 로그가 입수됐거나 로그 재정의 등으로 인해 신규 schema에 맞춰 과거 데이터를 migration할 때도 요긴하게 사용합니다. 특히 한번에 몇 년치의 대규모 데이터를 변경할 때 유용합니다.

초기 Job을 구동할 때 드는 시간을 단축하기 위해 한 번에 많은 양의 Partition을 읽어 Data Processing 작업을 하고 Partition을 재분배 합니다. Terminator Property의 예제는 다음과 같습니다.

 

reorder {
    priority=7,
    conditionFieldName="token",
    conditionEqStr="e58d66ab2f9cff89ef9124f11675cc981c3388",
    newOrder=[14,1,2,3,4,5,6,7,8,9,10,11,12,13,0]
}

filter {
    priority=6,
    info= [{"field":"device_model","filter_string":"SHV-E330K","filter_type":"in"}]
}

insert {
    priority=4,
    info=[
	{"field":"new","insert_value":"###"},
        {"field":"new1","insert_field":"local_time"},
	]
}

concat {
    priority=4,
    info=[
        {"field":"local_time","value":"###"},
        {"field":"device_id","conditionFieldName":"base_time","conditionEqStr":"20150101010046626","value":"concat@@"}
    ]
}

SK플래닛의 원천 데이터 지표 관리

DI팀에서는 Data Collection과 관련한 지표를 관리하기 위해 자체적으로 Overwatch라는 시스템을 개발했습니다. Overwatch는 Data Collection의 관리 수준을 질적, 양적으로 측정해 현황과 추세를 파악하는 목적으로 개발했고, 부가적으로 데이터 소유자들로 하여금 자발적으로 데이터의 품질을 제고하도록 유인하는 효과도 기대하고 있습니다. Overwatch는 데이터의 수명 주기를 생성, 보관, 활용, 퇴역의 4단계로 나눠, 각 단계별로 몇 가지 관리 항목을 두고, 이 항목들에 대한 달성 수준에 따라 채점한 후 이를 현황판에 게시합니다.

세부적으로는 DI팀 입수시스템 사용 여부, 정제 작업, 입수 모니터링, 암호화 여부, 용량 관리 여부, 탈퇴 및 휴면처리 여부 등의 13가지 Data Collection 관리 항목이 있습니다. 관리 항목의 세부 내용은 <표 2>을 참고 하세요.

key2<표 2> Data Collection 관리 지표

<그림 6>는 Overwatch의 메인 페이지 입니다. 전체 Data Collection의 점수 추이를 확인 할 수 있습니다.

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2016-11-02-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-4-04-38<그림 6> Overwatch

Overwatch에서는 <그림 7>과 같이 Data Collection 마다 항목 정보와 관리 점수를 볼 수 있습니다. 관리 점수에 따른 정렬과 특정 문자열에 대해 필터링이 가능합니다.

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2016-11-02-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-5-43-19<그림 7> Overwatch Data Collection 별 상세정보

Overwatch의 관리 항목 수치 대부분은 Sentinel, Medic, Insomnia API에서 연동해 가져 오고 있습니다. 하지만 API에 정보가 없는 퇴역과 보관 단계의 관리 항목은 아직까지 임의 확인 및 수기 작성이 불가피해 Data Collection 별로 수동 입력하고 있습니다.

하지만, Overwatch의 관리 및 운영 수고를 줄이고 신뢰도를 높이려면, 보관 단계 역시 수동 입력이 아닌 시스템화를 통해 자동 산출 및 기입이 필요합니다. Overwatch의 편집 화면은 <그림 8>을 참고하세요.

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2016-11-24-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-3-50-08<그림 8> Overwatch Data Collection 편집 Page

향후 과제

  • Compliance 이슈에 대한 지속적인 Follow-up
  • 보관주기 관리 시스템화
  • Overwatch 수동 입력 관리 항목 자동화

마지막으로 DI팀 블로그 포스팅 시리즈에 많은 지원을 해주시고, 꼼꼼히 교정해주신 송재하 팀장님과 언제나 큰 힘이 되어주시는 엄태욱 매니저님께 깊은 감사의 말씀을 드립니다.

신현주 Data Infrastructure팀

Data Infrastructure팀 Data Application Developer

Facebook 

공유하기