데이터 엔지니어링 on Google Cloud (3/4)

제 3장. Google Cloud 기반의 복원력 있는 스트리밍 분석 시스템 구축

본 문서는 스트리밍 데이터 처리의 주요 개념, 과제, Google Cloud 서비스의 역할 및 활용 방안, 그리고 성능 최적화를 위한 고려 사항을 종합적으로 정리합니다.

1. 스트리밍 데이터 처리 소개 (M3_1_Introduction_KO.pdf)

• 스트리밍 데이터의 정의 및 과제: 스트리밍 데이터는 무한하고 지속적으로 생성되는 데이터 세트이며, 대용량(Volume), 빠른 속도(Velocity), 다양한 형태(Variety), 그리고 데이터의 불확실성(Veracity)이라는 4가지 주요 과제를 안고 있습니다.
• "스트리밍은 제한 없는 데이터를 대상으로 하는 데이터 처리 방법입니다."
• "스트리밍 애플리케이션과 관련된 과제는 4V, 즉 데이터의 다양성(Variety), 볼륨 (Volume), 속도(Velocity), 진실성(Veracity)입니다."
•  
• 스트리밍 데이터 처리의 필요성: 실시간 정보 획득 및 의사 결정 지원을 위해 스트리밍 데이터 처리가 중요합니다. NYC Cyber Command 사례는 Google Cloud 기반의 데이터 파이프라인을 통해 사이버 보안 위협을 실시간으로 감지하고 대응하는 성공적인 사례를 보여줍니다.
• "많은 조직이 내부 분석가에게 실시간 의사결정 역량을 제공하길 원하며, NYC3는 이 목표를 실현했습니다."
• NYC Cyber Command의 노암 도로고예르는 "사이버 보안 영역에서 비상 상황에 데이터가 늦게 들어오면 그 데이터는 더 이상 가치가 없습니다. 따라서 데이터 엔지니어링 관점에서 우리는 모든 단계에서 지연을 최소화하도록 파이프라인을 구축했습니다."라고 강조합니다.
•  
• Google Cloud 스트리밍 처리 아키텍처: 일반적인 아키텍처는 Pub/Sub를 통한 데이터 수집, Dataflow를 이용한 집계 및 변환, 그리고 BigQuery 또는 Bigtable을 활용한 데이터 저장 및 분석으로 구성됩니다.
• "일반적으로 데이터는 Pub/Sub를 통해 들어온 다음, Dataflow의 집계 및 변환을 거칩니다. 이후 사용자는 목표가 집계를 쓰는 것인지, 또는 스트리밍 소스에서 오는 개별 레코드를 쓰는 것인지에 따라 BigQuery 또는 Bigtable을 사용합니다."
•  
• 스트리밍 데이터 처리의 활용 분야: 실시간 데이터 웨어하우스 구축, 온라인 의사 결정 (실시간 추천, 사기 감지 등), 데이터 통합 등 다양한 분야에서 활용 가능합니다.
• "스트리밍을 사용하여 실시간 데이터 웨어하우스를 얻은 다음 실시간 정보 대시보드를 만들 수 있습니다."
•  
• Google Cloud 주요 제품: 스트리밍 데이터 처리 과제 해결을 위해 Pub/Sub (변동하는 데이터 볼륨 처리), Dataflow (낮은 지연 시간 데이터 처리), BigQuery (실시간 임시 분석)가 핵심적인 역할을 수행합니다.
• "여기서 살펴볼 세 가지 제품은 다음과 같습니다. Pub/Sub는 변화하는 데이터 볼륨을 처리할 수 있게 해줍니다. Dataflow는 지나친 지연 없이 데이터를 처리하는 데 도움이 될 수 있습니다. BigQuery는 스트리밍 데이터에 대한 임시 보고에 사용됩니다."
•  
• 일반적인 스트림 분석 단계: 데이터 수집 (앱, DB, IoT), Pub/Sub를 통한 배포 및 안정성 확보, Dataflow를 이용한 집계, 보강, 감지, 그리고 BigQuery/Bigtable 저장 또는 Vertex AI를 활용한 머신러닝 모델 학습 등으로 이루어집니다.

2. Pub/Sub를 사용한 서버리스 메시징

• Pub/Sub 소개: Pub/Sub는 완전 관리형의 확장 가능하고 안정적인 메시지 배포 서비스로, 느슨하게 결합된 시스템 구축을 용이하게 합니다. Google Cloud뿐만 아니라 온프레미스 또는 다른 클라우드 환경과도 통합 가능합니다.
• "Pub/Sub는 완전 관리형 데이터 배포와 전송 시스템을 제공하며 여러 용도로 사용할 수 있습니다. 가장 일반적인 용도는 시스템의 각 부분을 느슨하게 결합하는 것입니다."
• Pub/Sub는 가용성, 내구성 (기본 7일 메시지 저장), 확장성이 뛰어납니다. Google은 전체 인프라에서 초당 약 1억 개의 메시지를 처리합니다.
•  
• Pub/Sub의 핵심 개념: 주제(Topic)는 메시지가 게시되는 채널이며, 구독(Subscription)은 주제로부터 메시지를 수신하는 메커니즘입니다. 게시자(Publisher)는 주제에 메시지를 보내고, 구독자(Subscriber)는 구독을 통해 메시지를 소비합니다. 하나의 주제에 여러 구독이 있을 수 있으며, 하나의 구독에 여러 구독자가 연결될 수 있습니다.
• "Pub/Sub는 주제와 구독이라는 두 가지 데이터 구조로 이루어집니다."
• "주제에 게시된 메시지를 받으려면 해당 주제에 대한 구독을 생성해야 합니다."
•  
• 푸시(Push) 및 풀(Pull) 구독: Pub/Sub는 두 가지 메시지 전송 모델을 제공합니다. 푸시 모델은 Pub/Sub가 구독자의 엔드포인트로 메시지를 전송하는 방식이며, 풀 모델은 구독자가 Pub/Sub로부터 메시지를 명시적으로 가져오는 방식입니다.
• "Pub/Sub는 푸시와 풀 전송을 모두 허용합니다."
• 풀 모델은 메시지 처리 완료 후 확인(ACK) 단계를 거쳐 안정성을 높입니다. 푸시 모델은 HTTP 응답 코드를 통해 메시지 전송 성공 여부를 확인하고, 성공 응답 속도를 기반으로 자체 속도 조절을 수행합니다.
•  
• 메시지 필터링: 구독 시 메시지 속성을 기반으로 필터를 설정하여 특정 조건에 맞는 메시지만 수신할 수 있습니다.
• "필터를 사용하여 구독에서 메시지를 수신할 때는 필터와 일치하는 메시지만 수신됩니다."
•  
• 메시지 확인(ACK) 및 재생: Pub/Sub는 각 메시지가 최소 한 번 전송되도록 보장합니다. 메시지 확인 기한을 설정할 수 있으며, 메시지 보관 기능을 통해 이전 시점의 메시지를 재생할 수 있습니다 (최대 7일).
• "확인은 각 메시지가 최소 한 번 전송되도록 보장하는 작업입니다."
• "메시지 보관으로 주제를 구성하면 더 많은 유연성을 제공하여 주제에 연결된 모든 구독을 이전 시간에서 찾고 이전에 확인한 메시지를 재생할 수 있습니다."
•  
• 메시지 순서 지정: 동일한 순서 키를 가진 메시지가 동일한 리전에 있는 경우 메시지 순서 지정을 활성화하여 메시지를 게시된 순서대로 수신할 수 있습니다. 하지만 순서 지정은 지연 시간을 증가시킬 수 있으며, 완전한 순서 보장은 아닙니다.
• "메시지에 동일한 순서 키가 있고 메시지가 동일한 리전에 있다면 메시지 순서 지정을 사용 설정하고 Pub/Sub 서비스에서 메시지를 수신하는 순서대로 메시지를 수신할 수 있습니다."
•  
• 스트리밍 복원력: Pub/Sub는 메시지 버퍼링을 통해 트래픽 급증 시에도 시스템 과부하를 방지하고, 다운스트림 애플리케이션이 처리 가능한 속도로 데이터를 소비하도록 지원합니다.
• "Pub/Sub는 스트리밍 복원력, 즉 버퍼링에도 도움이 됩니다."
•  
• 데드 레터 큐(Dead Letter Queue): 처리 실패한 메시지를 별도의 큐로 이동시켜 데이터 손실을 방지하고 문제 해결을 용이하게 합니다. Dataflow와 함께 사용하여 오류 레코드를 격리할 수 있습니다.
•  
• 지수 백오프(Exponential Backoff): 메시지 전송 실패 시 재시도 간격을 점진적으로 늘려 시스템 부하를 줄이고 전송 성공률을 높입니다.
•  
• 보안, 모니터링, 로깅: Pub/Sub는 Cloud 감사 로그, Cloud Logging 측정항목, IAM 기반의 액세스 제어, 전송 중 및 저장 시 암호화를 제공하여 보안을 강화하고 시스템 운영 상황을 모니터링할 수 있도록 지원합니다.

3. Dataflow 스트리밍 기능 (M3_3_Dataflow_Streaming_Features_KO.pdf)

• Dataflow 소개: Dataflow는 확장 가능하고 낮은 지연 시간으로 스트리밍 및 일괄 데이터 처리를 위한 서버리스 서비스를 제공합니다.
• "이미 알아본 바와 같이 Dataflow는 일괄 처리와 데이터 스트리밍을 위한 서버리스 서비스를 제공합니다. 확장 가능하며 스트리밍의 경우 수신 메시지에서 파이프라인을 처리할 때 지연 시간이 짧습니다."
•  
• 스트리밍 데이터 처리 관련 과제: 확장성 유지, 내결함성 확보, 스트리밍/반복 일괄 처리 모델 선택, 그리고 늦게 도착하는 데이터 처리 등이 주요 과제입니다.
• "스트리밍 데이터 처리와 관련된 과제는 무엇이 있을까요? 첫째, 확장성입니다. 즉, 더 자주, 더 크게 증가하는 데이터 볼륨을 처리할 수 있어야 합니다. 둘째, 내결함성입니다. 더 많은 데이터를 받다 보면 더 민감하게 반응하여 예기치 않게 중단될 수 있습니다."
•  
• 제한 없는(Unbounded) PCollection 처리: Dataflow는 스트리밍 작업을 통해 실시간으로 수신되는 제한 없는 데이터 컬렉션을 처리할 수 있습니다.
•  
• 윈도잉(Windowing): 제한 없는 데이터 스트림을 시간 기반의 유한한 기간으로 나누어 집계 및 분석을 가능하게 합니다. 고정(텀블링), 슬라이딩(홉핑), 세션 윈도우 등 다양한 유형을 지원합니다.
• "따라서 스트리밍 시나리오에서는 시간을 기간으로 나누어 특정 기간의 평균을 구해야 합니다."
• "Dataflow에서는 고정, 슬라이딩, 세션이라는 세 가지 유형의 기간이 지원됩니다."
•  
• 워터마크(Watermark): Dataflow는 워터마크를 통해 데이터의 예상되는 완료 시간을 추적하여 지연된 데이터를 처리하는 데 도움을 줍니다.
• "워터마크라는 기능으로, Dataflow는 워터마크를 자동으로 추적합니다. 기본적으로 지연 시간을 추적합니다."
•  
• 트리거(Trigger): 윈도우의 결과를 언제, 얼마나 자주 내보낼지를 결정하는 메커니즘입니다. 이벤트 시간 기반, 처리 시간 기반, 데이터 기반 트리거 및 복합 트리거를 지원하여 다양한 처리 요구 사항을 충족할 수 있습니다.
• "기본 동작은 워터마크에서 트리거하는 것입니다. 따라서 트리거를 지정하지 않으면 'AfterWatermark' 트리거를 사용하게 됩니다."
•  
• 지연 데이터 처리: Dataflow는 워터마크를 사용하여 지연 데이터를 식별하고, 트리거와 축적(Accumulation) 기능을 통해 지연 데이터를 처리하거나 폐기하는 정책을 정의할 수 있습니다.
•  
• 데드 레터 싱크(Dead-Letter Sink) 및 오류 로깅: Dataflow 파이프라인에서 오류가 발생한 레코드를 별도의 싱크로 보내거나 로깅하여 데이터 무결성을 유지하고 문제 해결을 용이하게 합니다.

4. 높은 처리량의 BigQuery 및 Bigtable 스트리밍 기능 

• BigQuery 스트리밍: 스트리밍 삽입을 통해 데이터를 BigQuery 테이블에 실시간으로 추가하고 즉시 쿼리할 수 있습니다. 실시간에 가까운 통계 분석 및 대시보드 구축에 유용합니다. 하지만 일괄 로드와 달리 스트리밍 삽입에는 비용이 발생하며 할당량 제한이 있습니다. Storage Write API를 통해 높은 처리량의 스트리밍을 지원합니다.
• "스트리밍 데이터는 로드 작업을 통해 BigQuery에 추가되지 않습니다. '스트리밍 삽입'이라는 별도의 BigQuery 메서드가 있습니다."
• "정답은 솔루션에서 즉각적인 데이터 가용성을 필요로 하는 경우입니다. 왜냐하면 대부분의 경우 일괄 데이터를 로드하는 데는 비용이 청구되지 않지만 스트리밍 데이터를 로드하는 데는 비용이 청구되기 때문입니다."
•  
• Looker Studio 연동: BigQuery에 스트리밍되는 데이터를 Looker Studio와 연동하여 실시간 대시보드를 구축하고 시각화 분석을 수행할 수 있습니다.
•  
• BigQuery BI Engine: 고속 인메모리 분석 서비스로, BigQuery에 내장되어 Looker Studio 등 BI 도구의 대시보드 성능을 향상시킵니다.
•  
• Bigtable 스트리밍: 매우 높은 처리량과 낮은 지연 시간을 요구하는 NoSQL 워크로드에 적합합니다. 특히 1TB 이상의 대규모 데이터, 시계열 데이터, 실시간 처리 등에 강점을 가집니다. Bigtable은 '단순함으로 속도 향상'이라는 설계 원칙하에 row key 기반의 빠른 스캔, 정렬, 검색을 지원합니다.
• "Bigtable은 각각의 값이 보통 10MB를 넘지 않는 구조화되지 않은 키-값 데이터를 위해 매우 높은 처리량과 확장성이 필요한 애플리케이션에 적합합니다."
• "Bigtable은 높은 처리량이 반드시 필요한 애플리케이션의 실시간 조회 기능에 가장 자주 사용됩니다."
•  
• Bigtable 설계 원칙: 효율적인 데이터 액세스를 위해 적절한 row key 설계가 매우 중요합니다. row key는 데이터의 논리적 순서를 반영하고, 자주 사용되는 쿼리를 효율적인 스캔 작업으로 만들 수 있도록 설계해야 합니다.
•  
• Bigtable 성능 최적화: 스키마 설계 (데이터 편향 최소화), 충분한 데이터 볼륨 및 테스트 기간 확보, 클러스터 노드 수 조정, 클라이언트와 Bigtable의 동일 영역 배치, SSD 디스크 사용 등이 성능에 영향을 미칩니다. Bigtable은 액세스 패턴을 학습하여 자동으로 데이터 재조정 및 로드 균형 조정을 수행합니다.
•  
• Key Visualizer: Bigtable 사용 패턴을 시각적으로 분석하여 핫스팟을 찾고 스키마 설계를 개선하는 데 도움을 주는 도구입니다.
•  
• Bigtable 복제: 읽기 워크로드 분리, 가용성 향상, 실시간 백업 제공, 글로벌 데이터 배치를 위해 Bigtable 복제를 구성할 수 있습니다.

5. 고급 BigQuery 기능 및 성능

• 분석 윈도우 함수: 데이터의 파티션 및 순서를 정의하고, 각 파티션 내에서 행과 관련된 계산을 수행하는 함수입니다 (RANK, CUME_DIST, DENSE_RANK, ROW_NUMBER, PERCENT_RANK 등).
• "분석 윈도우 함수는 특정 행과 관련된 계산을 수행합니다."
• "먼저 행을 부서별로 분할하고 시작 날짜에 따라 정렬한 다음 최종적으로 순위를 매겼습니다."
•  
• WITH 절: 복잡한 SQL 쿼리를 여러 개의 명명된 서브 쿼리 (공통 테이블 표현식)로 분할하여 가독성과 유지보수성을 높입니다.
• "WITH는 명명된 서브 쿼리 (또는 공통 테이블 표현식)임. 임시 테이블 역할, 복잡한 쿼리 분할."
• GIS (Geographic Information System) 함수: BigQuery 내에서 지리 공간 데이터를 분석하고 처리할 수 있는 내장 함수 (ST_MakePoint, ST_Distance, ST_Within, ST_MakeLine, ST_MakePolygon, ST_DWithin, ST_Intersects, ST_Contains, ST_CoveredBy 등)를 제공합니다.
• "BigQuery에는 GIS 기능이 내장되어 있습니다."
•  
• BigQuery 성능 고려 사항: 효율적인 쿼리 작성, 데이터 파악, 스키마 및 데이터 재검토, 조기에 끝낼 수 있는 작업 관리, I/O 및 셔플 최소화, 적절한 집계 함수 사용, 파티션 테이블 활용 등이 중요합니다.
• "BigQuery의 성능 최적화를 위한 핵심 영역 5개는 다음과 같습니다. 입력 및 출력 - 디스크에서 읽은 바이트 수, 셔플 - 다음 쿼리 처리 단계로 전달된 바이트 수, 그룹화 - 각 그룹에 전달된 바이트 수, 구체화 - 디스크에 영구적으로 기록된 바이트 수, 함수 및 UDF - 쿼리 계산에 사용되는 CPU 사용량."
• "필요한 것보다 더 많은 데이터 열을 선택하지 않습니다. 다시 말해서 가능하다면 어떤 경우에도 SELECT *를 사용하지 않습니다."
•  
• 쿼리 최적화: SELECT 구체화, WHERE 절을 이용한 조기 필터링, JOIN 순서, GROUP BY 최적화, 근사치 집계 함수 활용, ORDER BY 사용 최소화, 파티션 테이블 활용 등 다양한 방법을 통해 쿼리 성능을 향상시킬 수 있습니다.
• 중간 테이블 구체화: 대규모 다단계 쿼리의 성능 향상을 위해 중간 결과를 테이블에 저장하여 후속 쿼리에서 읽는 데이터 양을 줄입니다.
•  
• BigQuery 요금제 및 최적화: BigQuery 버전 (Standard, Enterprise, Enterprise Plus)을 활용하여 비용 대비 성능을 최적화하고, 자동 확장 기능을 통해 사용한 만큼만 비용을 지불합니다. 압축 스토리지를 사용하여 스토리지 비용을 절감할 수 있습니다.
•  
• 슬롯(Slot): BigQuery 쿼리 실행 시 소비되는 컴퓨팅 리소스 단위입니다. 슬롯 사용량을 모니터링하고 워크로드에 맞게 슬롯 할당을 예측하는 것이 중요합니다. BigQuery는 공정한 스케줄러를 통해 동시 실행되는 쿼리 간에 슬롯을 공정하게 배분하며, 계층적 예약을 통해 프로젝트의 우선순위를 설정할 수 있습니다.
•  
• Cloud Monitoring: BigQuery 작업의 성능 (슬롯 사용률, 진행 중인 쿼리, 업로드/저장된 바이트 등)을 모니터링하고 분석하는 데 유용한 도구를 제공합니다.
•  

본 과정에서는 복원력 있는 스트리밍 분석 시스템 구축을 위해 스트리밍 데이터의 개념과 과제, Pub/Sub를 이용한 데이터 수집, Dataflow를 통한 실시간 처리, BigQuery 및 Bigtable을 활용한 데이터 저장 및 분석 방법을 학습했습니다.

BigQuery의 고급 분석 기능 (윈도우 함수, GIS 함수) 및 쿼리 성능 최적화 기법을 살펴보았습니다. Google Cloud를 사용하여 스트리밍되는 데이터에서 실시간으로 유용한 정보를 추출하고, 변화하는 데이터 볼륨과 지연 시간을 효과적으로 관리하며, 안정적이고 확장 가능한 분석 시스템을 구축할 수 있습니다. Pub/Sub, Dataflow, BigQuery, Bigtable은 각기 고유한 장점을 가지고 있으며, 함께 사용하여 복원력 있고 효율적인 스트리밍 분석 시스템을 구축할 수 있습니다. 시스템 설계 시 데이터의 특성, 처리 요구 사항, 성능 및 비용 고려 사항을 종합적으로 고려하는 것이 중요합니다.