(1) 데이터 파이프라인 구성방안
요즘은 사내에서 데이터 파이프라인을 구성을 한다. 큰 회사는 플랫폼이라고 하며, 기본 아키텍처의 구성을 어떻게 해야되는지에 대한 고려가 필요하다.
(1) 회사내의 데이터적 요구사항(User Case)에 대한 빠른 대응
초기에는 데이터로 요구사항을 해결하는 기간적 사이클이 컸다.
하지만 요즘에는 데이터의 중요성이 커지고 있으며, 요구사항도 많이지기 때문에, 그 날 요청한 것이 그 날의 데이터 중에서 해결할 수 있는 것이면, 그 날 대응해주는 것이 좋다. (1-2일 이내에 대응)
(2) 지속적이고 에러가 없어야 한다.
데이터 중심의 회사라면 아침에 데이터를 중심으로 회의가 진행하는 경우가 있기 때문에 기본적으로 데이터를 처리해주는 데이터 파이프라인에 에러가 없어야 한다.
(3) 시스템적으로 발생하는 문제에 대해서 유연한 Scability가 있어야 한다.
(4) Sclae up과 Scale Out이 자유로워야 한다.
(5) 이벤트성 데이터 부하에도 문제없이 처리가 가능해야 한다.
마케팅 이벤트, 푸시 발송, 서비스 오픈 데이터에서 이슈가 가장 많이 발생한다. 푸시 발송은 일괄적으로 발송이 되기 때문에, 복합적으로 다양한 이벤트들이 발생할 때 부하이슈가 발생하여, 수집하는 데이터에서 이슈가 발생하는 경우가 생긴다. 따라서 수집하는 서버에서의 문제에 문제가 없도록 해야하며, 부하처리를 쉽게 핸들링할 수 있도록 해야한다.
(6) 데이터 쌓이는 공간에 문제가 없어야 한다.
초기에는 온프레미스 형태로, RDBMS에 데이터를 저장해서 사용하는 형태로 많이 사용되었다.
최근에는 빅데이터 수집을 해서 처리를 하는 경우가 생기는데,
Disk공간이 full이 되는 경우, 그 원인을 찾기가 어렵다. 따라서 디스크 공간에 문제가 없도록 해야한다.
그 해결방법으로는 Object storage를 잘 활용해야서 분석/저장측면에서 다양한 아키텍처를 구현할 수 있도록 해야한다.
AWS의 S3에는 쌓는 공간이 무제한이다. 따라서 S3에서의 데이터를 백업정책(Achieving)을 통해 내부 데이터를 잘 관리해야한다. (Data lifecycle 설정 / data보관 기한 설정)
(7) 수집데이터(저장 데이터)의 유연성이 있어야 한다.
데이터를 분석하는데 있어, 수집에 대한 요구사항 다양하다.
그래서 필요에 따라 parameter를 넣고 빼는 경우가 많다.
과거에는 column 베이스로, 요구사항에서의 변경사항이 생겼을때, 그것을 변경을 하는데 있어, 많은 코스트 발생하였다.
(8) 쉬운 분석 데이터 Format
쌓여있는 데이터를 쉽게 읽어서 분석할 수 있는 포멧이어야 한다.
XML 포멧을 데이터를 활용하기 어려운 포멧이다. 최근 들어서는 유연성을 가미할 수 있는 JSON 포멧을 많이 활용하고 있으며, KEY, VALUE 형태로 구성이 되어있기 때문에 데이터를 쉽게 참조할 수 있고, 값을 넣었다가 안들어갔더라도 에러없이 지속적으로 데이터를 분석할 수 있다.
초기라면, JSON형태로 데이터를 저장하는 것이 좋으며, 단점이라면 Key값이 들어가있기 때문에 용량이 크다.