[TIL 66일자] 데브코스 데이터엔지니어링

송·2023년 7월 17일

TIL

데브코스

목록 보기

54/55

📚 오늘 공부한 내용

1. 구글이 데이터 분야에 끼친 영향

1) 구글의 검색 엔진 변화

그 전까지의 검색 엔진은 기본적으로 웹 페이지 상의 텍스트를 보고 랭킹을 결정했다.
1998 년 구글은 웹 페이지들간의 링크를 기반으로 중요한 페이지를 찾아서 검색 순위를 결정한다.
이 알고리즘을 래리 페이지 이름을 따서 페이지 랭크라고 부른다.
시작점을 만들고 그 웹 페이지에서 링크를 건 다른 웹 페이지에서 점수를 주고 이 방법을 반복하다 보면 어느 순간부터는 점수가 바뀌지 않게 된다.
2004 년 세계 최고의 검색 엔진으로 등장했다. 이 시점부터 검색 마케팅 플랫폼으로 확장하고, 안드로이드로 모바일 생태계를 지배하고 유튜브를 인수하면서 스트리밍 시장을 석권했다.
다양한 논문을 바탕으로 오픈 소스를 공유하며 개발자 생태계에도 영향을 미쳤다.
검색 엔진은 처음에는 배치 중심이었으나 사람들의 니즈에 따라 실시간 중심으로 바뀌게 되었다.

2) 페이지 랭크

두 가지 관찰을 기반으로 만들어진 알고리즘이다.
- 더 중요한 페이지일수록 더 많은 페이지로부터 링크를 받는다.
- 이 중요한 페이지가 링크를 건 다른 페이지들 역시 상대적으로 중요한 페이지이다.
분산 파일 시스템과 분산 처리 시스템이 존재하지 않으면 이 방식을 알아도 사용할 수 없다.
구글이 페이지 랭킹 이외에도 다른 검색 엔진 아키텍처 논문을 외부에 공개했다.
- 웹 페이지 본문 텍스트가 아닌 링크 텍스트도 중요
- 링크에 있는 원문 페이지의 중요도 역시 고려 필요

3) 빅데이터 시대 초래

빅데이터 처리를 구글이 어떻게 했는지 공개한 논문
- 2003 년 The Google File System
- 2004 년 MapReduce: Simplified Data Processing on Large Cluster
이를 바탕으로 하둡이라는 오픈 소스 프로젝트가 진행되었고, 이 기술이 빅데이터 처리를 가능하게 해 줌
또한 하둡을 시작으로 오픈 소스 활동이 활발해짐
머신러닝, 인공지능의 발전을 가속화함

4) 검색 기술, 마케팅 결합 - 구글 애드워즈

오버추어가 시작한 웹 검색 광고를 발전시켜 구글 애드워즈로 명명했다. -> 구글 애즈 (Ads)
구글과 오버추어의 검색 마케팅 방법의 차이
- 오버추어가 먼저 시작했지만 반드시 사람이 있어야만 했기 때문에 비효율적이었음 (검색어 경매 방식, 시간이 오래 걸림)
- 구글은 웹 기반 자동화를 염두에 두고 만들어 사람 개입 없이 검색어 경매와 광고 시스템을 구축함
- 검색어 광고의 성능에 따라 노출 빈도가 결정

2. 데이터 처리의 발전 단계

1) 데이터의 일반적 단계

데이터 수집 (Data Collection)
데이터 저장 (Data Storage)
데이터 처리 (Data Processing)

2) 데이터 저장 시스템의 변천

1980 년대 후반에는 데이터 웨어하우스가 주였고, 이 방식은 Top-down. 정말 필요한 것들만 저장하는 방식으로 데이터를 저장함.
2000 년대 후반에는 큰 데이터를 처리하고 이를 저장하는 스토리지는 비용이 많이 들지 않아 Data Lake 방식으로 바뀜. Bottom-up. 보통은 Data Lake와 Data Warehouse를 같이 사용함.
2010 년 중반부터는 Cloud Data Platform이 나오면서 이전에는 배치 중심이었지만 실시간 데이터 처리가 요구되면서 Kafka와 Kinesis 같은 Messaging Queue가 나오게 됨.
2021 년 이후 Data Mesh 형식으로 중앙 시스템 구조에서 분산 시스템으로 바뀌게 됨.

3) 데이터 처리의 고도화

처음에는 배치로 시작. 이 경우 처리할 수 있는 데이터의 양이 중요하다.
서비스가 고도화되며 점점 더 실시간 처리 요구가 생기기 시작했다.
배치이긴 한데 주기가 작거나 한 번에 처리하는 데이터의 양이 작은 배치 처리를 Near Realtime, Semi Realtime이라고 한다.

3. 실시간 데이터 처리

1) 처리량 (Throughput) vs 지연 시간 (Latency)

처리량은 주어진 단위 시간 동안 처리할 수 있는 데이터 양을 말한다. 이는 배치 시스템에서 중요하다.
지연 시간은 데이터를 처리하는 데 걸리는 시간이 얼마나 되는가를 말한다. 작을수록 응답이 빠름을 의미하며 Production 프로그램과 같은 실시간 시스템에서 매우 중요해진다.
대역폭 (Bandwidth) = Throughput * Latency

2) SLA (Service Level Agreement)

서비스를 제공하는 업체와 고객 간의 계약 또는 합의를 말한다.
서비스 제공 업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술한다.
사내 시스템들 간에도 SLA를 정의하기도 한다.
이 경우 지연 시간이나 업타임 등이 보통 SLA로 사용된다. (필요에 따라 구체적으로 정의되는 경우도 존재함)
- 예를 들어 업타임이 99.9 % = 8 시간 45.6 분
- API라면 평균 응답 시간 혹은 99 % 이상 0.5 초 전에 응답이 되어야 함
데이터 시스템이라면 데이터의 시의성(Freshness)도 중요한 포인트가 된다.

3) 배치 처리

주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리하는 것을 말한다.
보통 여기서 말하는 주기는 daily, hourly가 일반적이며 더 짧아진다면 5 분, 10 분 역시 배치로 볼 수 있다.
ETL로 관리되는 것이 일반적이다.
분 단위보다 짧아진다면 airflow로 돌리기 애매해지고 spark 등으로 프로세싱을 한다는 게 불가능하기 때문에 데이터 처리가 부적합해지기 때문에 실시간 프레임워크가 필요해진다.
처리량(Throughput)이 중요하다.
처리 시스템 구조
- 분산 파일 시스템 (HDFS, S3)
- 분산 처리 시스템 (MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
- 처리 작업 스케줄링에 보통 Airflow 사용

4) 실시간 처리

연속적인 데이터 처리를 말하며 배치 처리 다음의 고도화 단계이다.
시스템 관리의 복잡도가 증가한다. 데이터가 발생하는 족족 들어오는 것이기 때문에 발생하는 데이터가 유실될 가능성이 높아진다.
초 단위의 계속적인 데이터를 처리한다.
이때 계속적인 데이터를 Event라고 부르며 이 데이터는 한 번 생성되면 바뀌지 않는 데이터(Immutable) 데이터이다.
계속해서 발생하는 Event들을 저장하는 곳을 Event Stream 혹은 Message Queue이라고 부른다. (Kafka에서는 이를 Topic이라고 부름)
이 경우 다수의 Consumer가 있어서 Queue로부터 데이터를 읽어서 처리한다. 또한 Consumer마다 별도의 포인터를 유지하지만 다수의 Consumer(Consumer Group)가 데이터 읽기를 공동으로 수행하기도 한다.
실시간 처리만을 위한 다른 형태의 서비스들이 필요해지기 시작했다.
- 이벤트 데이터 저장하기 위한 메시지 큐: Kafka, Kinesis, Pub/Sub 등
- 이벤트 처리를 위한 처리 시스템: Spark Streaming, Samza, Flink 등
- 이런 형태의 데이터 분석을 위한 애널리틱스/대시보드: Druid 등

5) 람다 아키텍처 (Lambda Architecture)

배치 레이어와 실시간 레이어 두 개를 별도로 운영된다.

초기 람다 아키텍처이다.
데이터가 생성이 되면 분산 파일 시스템에 저장을 하고 주기적으로 Batch Layer에서 데이터를 업데이트하고 이 정리된 데이터를 어딘가에 저장해 둔다. Speed Layer에서는 실시간 데이터를 배치 데이터의 주기 사이 갭을 줄여 주는 용도로 최근 데이터만 빠르게 처리해 저장해 준다.
최근 더 많이 쓰이는 아키텍처이다.
데이터 수집 자체를 별도로 하지 않고 streaming message queue로 한 번에 처리한다.
저장된 데이터를 일부는 배치, 일부는 realtime으로 프로세싱 한다.

4. 실시간 데이터 처리 챌린지

1) 실시간 데이터 처리 단계

이벤트 데이터 모델을 어떻게 정의할 것인지에 대한 결정 (만약 문제가 생기면 alert을 보내고, 데이터가 제대로 원하는 방향으로 들어오는지도 확인 필요)
이벤트 모델에 맞추어 데이터를 생성한 뒤 이 데이터를 어떻게 잘 수집하고 저장할 것인가 (데이터 프로듀서가 작업)
kafka를 누가 운영하고 관리할 것인가 (일반적으로 DevOps)
이벤트 데이터 처리
이벤트 데이터와 관련된 kafka 자체의 모니터링, 데이터 시의성이 깨지는지 아닌지 등의 데이터 이슈를 확인하는 모니터링 및 해결

2) 이벤트 데이터 모델 결정

최소 Primary Key와 Timestamp는 필요하다.
사용자 정보가 필요할 수 있다.
해당 이벤트 자체에 대한 세부 정보가 필요하다.

3) 이벤트 데이터 모델 전송 및 저장

Point To Point
- Producer와 Consumer가 바로 연결된다.
- 즉, Latency가 존재하지 않는다.
- Producer가 데이터를 생성하는 비율보다 Consumer가 데이터를 소비하는 비율이 더 느리면 데이터가 쌓이게 되고, 데이터가 밀리고 유실될 가능성이 있다. -> Back pressure
Messaging Queue
- 중간에 데이터 저장소를 두고 Producer가 만든 데이터가 Consumer에게 바로 가는 것이 아니라 필요할 때 데이터 저장소에서 데이터를 가지고 갈 수 있다.
- Consumer가 기간 내 데이터를 조회하지 않는 경우 기간이 지나 데이터가 사라질 수도 있지만 Back pressure를 완화할 수 있다.
- Producer와 Consumer가 일대일로 연결하지 않아도 돼서 더 scalable하다.

🔎 어려웠던 내용 & 새로 알게 된 내용

📌 Realtime vs Semi Realtime

Realtime

짧은 Latency

연속적인 데이터 스트림

특정 event에 의해 데이터 처리가 트리거 되는 구조로 처리가 이루어진다. 즉, 이벤트 중심의 아키텍처이다.

Semi Realtime

합리적인 Latency

배치와 유사한 처리

처리 용량과 리소스 활용도를 높이기 위해 일부 즉각성을 희생하기도 한다. 즉, 이벤트에 의해 반응하는 것이 아닌 주기적인 업데이트가 발생한다.

📌 Backpressure

스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성하게 되는데 가끔 트래픽이 몰리면 데이터 생성이 폭발적으로 일어날 수 있다. 그러면 훨씬 더 많은 데이터가 생성이 될 거고 그게 모두 소비가 되어야만 뒤에 있는 데이터들이 모두 처리가 될 수 있다.

그래서 데이터가 들어오는 속도를 따라잡지 못해 데이터가 쌓이면서 메모리 사용량이 증가하고 이로 인해 잠재적인 시스템 장애를 초래할 수 있다.

Backpressure는 Point-to-Point 단계에서 심화되며 Messaging Queue로 완화할 수는 있지만 완전히 해결은 불가능하다.