LINE DEVELOPER DAY 2021에서 이주홍 님이 발표하신 SHIELD: LINE Timeline을 어뷰저로부터 보호하기 세션 내용을 옮긴 글입니다. 참고로 LINE Timeline은 현재 LINE VOOM으로 이름이 변경됐습니다.들어가며안녕하세요. Shield Dev 팀 이주홍입니다. 이번 글에서는 어뷰저(abuser)로부터 LINE VOOM(구 Timeline)을 보호하고 있는 SHIELD를 소개하겠습니다. SHIELD는 어뷰징 검출과 NLP를 이용한 텍스트 필터링, 텍스트 필터 에이전트, 어뷰징 페널티 히스토리 관리 기능으로 구성된 솔루션으로 2019년 2월에 LINE VOOM에서 코멘트를 이용한 어뷰저를 막기 위해 개발하기 시작했습니다. 2019년 3월, LINE VOOM에 첫 번째 모델을 적용했고, 2020년에는 스토리와 생일 축하 카드에 모델을 추가해 다양한 형태의 어뷰저를 검출하고 있습니다. 앞으로도 LINE의 튼튼한 방패가 되기 위해 지속적으로 모델을 추가할 계획입니다.글은 어뷰징을 검출해야 하는 이유와 어뷰징 사례를 소개하고, SHIELD에서 어떻게 어뷰저를 찾고 있는지 설명한 뒤, SHIELD로 검출한 어뷰저 현황과 현재 진행하고 있는 사항을 공유하는 순서로 진행하겠습니다.어뷰징을 검출해야 하는 이유와 어뷰징 사례어뷰징을 왜 검출해야 할까요? 사용자는 자신이 보고 싶은 것만 보면서 편안하게 서비스를 사용하고 싶어 합니다. 무의미한 광고나 의미 없는 댓글, 욕설과 같이 자신을 불쾌하게 만드는 내용을 보고 싶어 하지 않습니다. 만약 LINE을 사용하면서 원치 않게 이런 내용을 접하고 부정적인 감정이 든다면 LINE 사용자가 줄어들 수 있겠죠. 따라서 서비스를 제공할 때 이런 내용을 제거해 사용자가 기분 좋은 감정을 유지할 수 있도록 만들어야 합니다.실제로 코멘트를 어뷰징에 이용한 사례를 살펴보겠습니다. 먼저 한 시간 동안 2,000번 이상의 코멘트를 생성한 사용자가 있었습니다. 아마 광고가 목적이었겠죠. 두 번째로 단순한 숫자 세기 코멘트를 짧은 시간 동안 여러 개 남긴 경우가 있었습니다. 예를 들어 1부터 100까지의 숫자를 코멘트로 하나씩 남기는 경우입니다. 의도는 알 수 없지만 생각보다 많이 발생하는 사례입니다. 세 번째로 내용을 전혀 알 수 없는 무의미한 문장을 짧은 시간 동안 아무렇게나 여러 개 남기는 경우입니다. 이 역시 의도는 알 수 없지만 어뷰징 사례라고 할 수 있습니다.SHIELD에서 어뷰저를 검출하는 방식그럼 SHIELD에서 어뷰저를 검출하기 위해 어떤 방법을 사용하고 있는지 소개하겠습니다.SHIELD의 목표 아키텍처아래는 현재 구축해 나가고 있는 SHIELD의 목표 아키텍처를 나타낸 그림입니다.가장 아래에 LINE에 쌓이는 여러 로그 데이터를 실시간으로 처리할 수 있는 레이어를 두고, 그 위에 중간 과정의 데이터를 쌓는 데이터 스토리지를 배치한 뒤, 그 위에 데이터 분석 레이어와 이상 검출(anomaly detection) 레이어를 올리는 것을 목표로 개발하고 있습니다. 현재 데이터 인프라와 규

딜리셔스는 광고를 집행하는 도매에게 광고 사용 현황과 통계 결과를 확인 할 수 있는 신상애드 서비스를 제공하고 있습니다. 여기서는 광고 상품별로 노출, 클릭, 찜, 매장 방문과 같은 유저의 행동 데이터와 광고 집행 비용에 대한 결과 메트릭을 광고주에게 제공함으로써 광고 집행의 효과를 쉽게 확인 할 수 있습니다. 행동 데이터 및 광고 집행 비용에 대한 데이터는 현재 딜리셔스의 DI(Data Integration) 파트에서 다루고 있으며, 이번 글에서는 데이터 서비스를 하기 위한 Non-Aggregation Real-time 분석시스템에 대해 설명하도록 하겠습니다. 도입 배경 도입 배경을 설명하기 위해 기존 데이터 처리 과정을 살펴 보겠습니다. 신상애드 메트릭 지표를 만들기 위해서는 고객의 행동 데이터와 RDB의 OLTP 데이터가 필요합니다. 고객의 행동 데이터는 JSON으로 들어오며, 정제하는 과정을 거쳐 Parquet 형식으로 S3에 보관되고 이 중 OLTP 데이터는 RDB로 저장됩니다. 이렇게 저장된 데이터는 Airlow 배치 스케줄러를 통해 ETL과정을 거친 후 데이터 마트로 생성됩니다. 기존 Airflow 배치의 가장 빠른 주기는 10분 단위로 실시간 집계는 아니었습니다. 딜리셔스의 광고는 RTB (Real Time Bidding) 형태로 제공하는데, 실시간으로 처리되는 광고와 다르게 신상애드의 데이터는 10분마다 갱신되고 있었기 때문에, 고객들은 물론 딜리셔스 내부에서도 실시간 데이터 처리에 대한 니즈는 점점 커져 실시간 집계라는 과제를 고민하게 되었습니다. 두번째 문제는 신상애드에서 제공되는 데이터가 데이터 마트라는 것이었습니다. 신상애드 메트릭 지표를 만들기 위해서는 고객의 행동 데이터와 OLTP데이터를 조합해야 합니다. 데이터 마트로 미리 필요한 데이터를 만들어 두지 않는 경우 OLTP DB의 특성상 대량의 데이터 집계시 속도가 나지 않아 채택한 방법이었지만, 새로운 광고 상품이 생성되거나 변경될때마다 데이터 마트 추가 작업이 필요한 문제가 있었고, 데이터 마트의 관리 포인트는 추가되는 데이터 마트의 수만큼 증가하는 것 또한 문제가 되었습니다. NARA 프로젝트 Nara 프로젝트는 Non-Aggregation된 데이터를 사용하여 실시간 집계 및 분석할 수 있는 시스템을 구축하는 목적으로 시작되었습니다. 데이터가 수집되는 즉시 Consume되어 Non-Aggregation DB로 적재되며 별도의 가공처리 없이 수집된 데이터 그대로를 사용하여 집계 및 분석을 할 수 있습니다. 신상애드 페이지에서 메트릭 데이터를 요청하면 Non-Aggregation DB에서 바로 쿼리해서 결과값을 내려주기 때문에 데이터 마트와 같은 별도의 집계가 필요없는 실시간성이 보장됩니다. NARA Architecture Kinesis로 수집된 고객 행동 데이터와 OLTP 데이터는 Clickhouse DB로 Migration되어 서비스단의 API와 분석을 위한 BI툴에서 사용됩니다. 그럼 NARA 시스템 구성의 주요 특징 4가지를 살펴보겠습니다. Kines

네이버의 콘텐츠 통계 서비스는 네이버의 콘텐츠를 사용자가 얼마나 소비했는지에 대한 통계를 콘텐츠 생산자에게 제공합니다. 예를 들어 블로그 관리자가 볼 수 있는 통계 메뉴의 방문자수 통계와 포스트 조회수 통계 등이 콘텐츠 통계 서비스가 블로그 콘텐츠 생산자에게 제공하는 정보입니다. 콘텐츠 통계 서비스를 제공하려면 빅데이터 분석이 필요합니다. 네이버는 Kudu를 백엔드 데이터베이스로 사용하는 빅데이터 다차원 분석 시스템을 개발해 2017년 5월부터 2018년 3월까지 운영하며 콘텐츠 통계 서비스 등에 사용했습니다. Kudu는 Cloudera에서 개발한 칼럼 기반 스토리지(columnar storage)입니다. 다른 많은 칼럼 기반 스토리지와 달리 primary key를 제공하기 때문에 밀리초(ms) 수준의 랜덤 액세스가 가능합니다. OLAP(online analytical processing) 성격의 질의와 OLTP(online transaction processing) 성격의 질의를 모두 지원하기 때문에 Kudu를 사용하면 빅데이터 분석 시스템의 구조를 단순하게 만들 수 있습니다. 이 글에서는 콘텐츠 통계 서비스에서 활용할 수 있는 빅데이터 다차원 분석 시스템을 Kudu를 사용해 개발한 경험을 소개합니다. 빅데이터 분석 시스템에서는 로그 수집, 저장, 집계, 질의 처리, 시각화, API 등이 필요하지만 이 글에서는 주로 저장과 질의 처리 기능을 중심으로 설명하겠습니다. 콘텐츠 통계 서비스와 KUDU 네이버 블로그의 방문자수 통계와 포스트 조회수 통계와 같이 네이버의 콘텐츠를 사용자가 얼마나 소비했는지에 대한 통계를 콘텐츠 생산자에게 제공하는 콘텐츠 통계 서비스는 빅데이터를 처리하기 위해 다양한 플랫폼을 사용한다. 2017년 5월에는 빅데이터 플랫폼인 Kudu를 사용한 빅데이터 다차원 분석 시스템을 개발해 콘텐츠 통계 서비스에 적용했다. Cloudera에서 개발한 칼럼 기반 스토리지인 Kudu는 Parquet의 파일 포맷처럼 OLAP 성격의 질의를 빠르게 처리한다. 또한 HBase가 row key를 제공하는 것과 비슷하게 primary key를 제공하기 때문에 밀리초 수준의 랜덤 액세스가 가능하다. OLAP 성격의 질의와 OLTP 성격의 질의를 모두 지원하는 Kudu를 사용하면 빅데이터 분석 시스템의 구조를 단순하게 만들 수 있다. > Kudu를 사용하기 전의 콘텐츠 통계 서비스에 관한 더 자세한 내용은 DEVIEW 2016의 "네이버 콘텐츠 통계서비스 소개 및 구현 경험 > 공유" 세션의 발표 내용을 참고한다. > - 세션 발표 자료: [215]네이버콘텐츠통계서비스소개 > - 세션 발표 영상: 네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유 KUDU의 특징 Kudu의 특징은 로그 수집, 저장, 집계, 질의 처리, 시각화, API 등의 측면에서 살펴볼 수 있지만, 이 글에서는 저장과 질의 처리 측면을 중심으로 살펴보겠다. Kudu에 관한 더 자세한 내용은 Kudu 웹 사이트와 "Kudu: Storage for Fast Analytics o

클라우드Martin Heller이 글은 IDG의 아티클을 전재하여 제공합니다.[원문보기] : https://www.itworld.co.kr/insider/엔터프라이즈 데이터 웨어하우스(EDW)는 전사적으로 모든 역사적 데이터를 저장하는 통합 데이터베이스로 분석에 최적화돼 있다. 최근, 데이터 웨어하우스를 구축하는 기업은 온프레미스보다 클라우드에 데이터 웨어하우스를 구축하는 경우가 많다. 또한, 전통적인 데이터 웨어하우스 대신 쿼리를 지원하는 데이터 레이크를 활용한다. 이밖에 역사적 데이터와 스트리밍 라이브 데이터의 결합 여부도 EDW 프로젝트에서 중요한 결정 사항이다.ⓒ Getty Images Bank데이터 웨어하우스(Data warehouse)는 일반적으로 역사적 데이터를 저장하기 위해 2개 이상의 데이터 소스로 만든 분석(관계형) 데이터베이스다. 페타바이트급까지 크기가 커지기도 한다. 데이터 웨어하우스는 복잡한 쿼리를 실행시키고 보고서를 생성하는 상당한 컴퓨팅 및 메모리 리소스를 갖춘 경우가 많으며, 종종 비즈니스 인텔리전스(BI) 시스템과 머신러닝의 데이터 소스 기능을 한다.트랜잭션 운영 데이터베이스의 쓰기 처리량 요건은 생성할 수 있는 인덱스의 종류와 수를 제한한다(인덱스가 많을 수록 추가되는 레코드당 쓰기와 업데이트가 많아지며 경합이 증가할 수 있음). 이로 인해 운영 데이터베이스에 대한 분석 쿼리가 느려진다. 데이터를 데이터 웨어하우스로 내보낸 후, 별개 OLTP(Online Transaction Processing) 데이터베이스의 쓰기 성능에 영향을 주지 않고 상당히 좋은 분석 쿼리 성능으로 데이터 웨어하우스에서 필요한 모든 것을 인덱스 처리할 수 있다.데이터 마트에는 특정 비즈니스 라인을 대상으로 한 데이터가 포함돼 있다. 데이터 마트는 데이터 웨어하우스에 종속적일 수도, (운영 데이터베이스나 외부 소스에서 가져오는 형태로) 독립적일 수도 있다. 또는 둘이 혼합될 수도 있다.자체 형식으로 데이터 파일을 저장하는 데이터 레이크는 ‘읽기 스키마(Schema on read)’다. 레이크에서 데이터를 읽는 애플리케이션은 데이터에 독자적인 유형과 관계를 적용해야 한다는 의미이다. 반면 전통적인 데이터 웨어하우스는 ‘쓰기 스키마(Schema on write)’다. 데이터 유형과 인덱스, 관계가 데이터 웨어하우스에 저장된 대로 데이터에 적용된다.현대적인 데이터 웨어하우스는 구조화된 데이터, 반구조화 된 데이터를 처리하고 동시에 쿼리할 수 있는 경우가 많다. 또한, 역사적 데이터와 스트리밍 된 최근 데이터를 동시에 쿼리할 수 있다.클라우드 데이터 웨어하우스 vs. 온프레미스 데이터 웨어하우스기업은 온프레미스, 클라우드, 또는 하이브리드로 데이터 웨어하우스를 구현할 수 있다. 과거 데이터 웨어하우스는 항상 온프레미스였다. 그러나 온프레미스 서버의 확장성 부족과 자본 비용이 문제가 되자, 관련 업체가 데이터 웨어하우스 어플라이언스를 제공하기 시작하면서 온프레미스 EDW 도입이 늘어났다. 다시 지금은 데이터 웨어하우스의 일부나 전부를 클라우드