3 posts tagged with "data-query"

운영 환경에서 로그는 장애를 진단하고 보안을 점검하는 기준 데이터입니다. 다만 로그를 저장해두는 것만으로는 충분하지 않습니다. 필요한 시점에 원하는 조건으로 빠르게 조회할 수 있어야 실제 운영 문제를 분석하고 원인을 파악하는 데 활용할 수 있습니다. 특히 감사와 진단에 반복적으로 활용되는 로그는, 처음부터 저장 위치와 파일 구조, 조회 방식을 함께 고려하는 것이 중요합니다.

이번에 추가된 두 개의 튜토리얼은 Object Storage에 저장된 운영 로그를 Data Catalog와 Data Query를 활용해 SQL로 조회하고 분석하는 방법을 다룹니다.

두 문서는 같은 데이터 분석 아키텍처를 사용하지만, 살펴보는 운영 관점은 조금 다릅니다. 하나는 사용자 활동과 리소스 변경 이력을 바탕으로 한 보안 감사와 변경 추적이고, 다른 하나는 VPC 내부의 DNS 질의 흐름을 바탕으로 한 네트워크 진단입니다. 이에 따라 분석 대상도 각각 Cloud Trail 로그와 DNS 리졸버 쿼리 로그가 됩니다.

운영 로그 저장 → Object Storage → Data Catalog → Data Query

즉, 분석 대상 로그는 서로 다르지만, Object Storage에 로그를 저장한 뒤 Data Catalog에서 테이블 메타데이터를 구성하고, Data Query에서 SQL로 조회하는 과정은 동일합니다.

이번 포스트에서는 각 로그가 어떤 운영 상황에서 유용한지 살펴보고, 운영 로그를 SQL 기반으로 분석하는 방법을 함께 알아보겠습니다.

Cloud Trail 로그: 리소스 변경 이력을 확인하는 기준 데이터​

Cloud Trail은 카카오클라우드에서 발생한 사용자 활동과 리소스 작업 이력을 이벤트 단위로 기록합니다. 예를 들어 특정 사용자가 언제 로그인했는지, 어떤 리소스를 생성하거나 수정했는지, 어떤 서비스에서 이벤트가 발생했는지 확인할 수 있습니다. 이 로그를 Data Query와 연동하면 보안 감사나 이력 추적 시 자주 마주치는 질문에 SQL로 답할 수 있습니다.

• 특정 날짜에 어떤 사용자가 어떤 리소스를 변경했는가?
• 특정 서비스나 IP 주소에서 수행된 작업 이력이 있는가?
• 특정 리소스에 대해 생성, 수정, 삭제 이벤트가 발생했는가?

Cloud Trail 로그를 Data Query를 통해 조회 튜토리얼에서는 Cloud Trail 로그를 Object Storage에 gz 형식으로 저장하고, project_event, domain_event 경로를 기준으로 Data Catalog와 Data Query 조회 환경을 구성하는 흐름을 안내합니다. 이때 date_id, hour_id 같은 파티션 컬럼을 조건으로 사용해 필요한 기간만 확인하는 방식이 중요합니다.

Cloud Trail 로그는 보안 감사나 변경 이력 추적에 활용되는 데이터이므로, 전체 로그를 한 번에 훑는 방식보다 언제, 어떤 서비스에서, 누가, 어떤 리소스에 대해라는 조건을 좁혀 조회하는 방식이 적합합니다.

DNS 리졸버 쿼리 로그: VPC 내부의 DNS 질의와 응답 확인​

DNS 리졸버 쿼리 로그는 VPC 내에서 발생한 DNS 질의와 응답 정보를 기록합니다. 애플리케이션이 어떤 도메인을 조회했는지, 응답 결과가 정상인지, 특정 시간대에 실패 응답이 집중되었는지 확인할 수 있습니다. 이 로그를 Data Query로 조회하면 다음과 같은 운영 질문을 다룰 수 있습니다.

• 특정 날짜에 가장 많이 조회된 도메인은 무엇인가?
• NOERROR가 아닌 응답이 어느 시간대에 집중되었는가?
• 특정 VPC에서 특정 도메인을 비정상적으로 많이 조회했는가?
• 응답 시간이 긴 DNS 질의가 반복되고 있는가?

DNS 리졸버 쿼리 로그를 Data Query 서비스를 통해 조회 튜토리얼에서는 DNS 리졸버 쿼리 로그가 Object Storage의 KCLogs/{region-name}/{year=yyyy/month=mm/day=dd} 구조로 저장되는 점을 기준으로 테이블을 구성합니다. 이후 Data Query에서 year, month, day 파티션을 동기화하고, 도메인별 질의 수나 실패 응답 수를 집계하는 예시를 제공합니다.

DNS 로그는 네트워크 장애 분석뿐 아니라 내부 서비스의 외부 의존성, 예상하지 못한 도메인 질의, 반복적인 실패 응답을 확인하는 데도 유용합니다. Cloud Trail이 사용자와 리소스 작업의 이력을 보여준다면, DNS 리졸버 쿼리 로그는 VPC 내부에서 애플리케이션이 어떤 이름 해석 흐름을 만들고 있는지 보여주는 데이터라고 볼 수 있습니다.

두 튜토리얼이 같은 패턴을 사용하는 이유​

앞에서 설명한 것처럼 Cloud Trail 로그와 DNS 리졸버 쿼리 로그는 성격이 다르지만, 운영자가 두 로그를 다루는 방식에는 공통점이 있습니다.

먼저 로그가 Object Storage에 저장됩니다. 그다음 파일 경로와 파티션 구조를 기준으로 Data Catalog에 메타데이터를 구성합니다. 마지막으로 Data Query에서 SQL을 사용해 특정 기간, 서비스, 사용자, 도메인, 응답 코드 같은 조건으로 조회합니다.

이 공통 패턴을 만들어두면 분석 대상이 바뀌더라도 저장 위치, 메타데이터 구성, SQL 조회라는 흐름을 그대로 가져갈 수 있습니다.

이 구조는 운영 로그 분석을 일관된 방식으로 관리하는 데 도움이 됩니다. 별도 도구마다 다른 조회 언어와 저장 구조를 학습하기보다, Object Storage와 Data Catalog, Data Query를 기준으로 조회 흐름을 표준화할 수 있기 때문입니다.

운영 로그 분석을 시작하는 방법​

운영 로그를 장기간 보관하고 필요한 시점에 조회해야 한다면, 두 튜토리얼을 함께 살펴보는 것이 좋습니다. 예를 들어 특정 시간대에 장애가 발생했을 때 Cloud Trail 로그로 리소스 변경 이력을 확인하고, DNS 리졸버 쿼리 로그로 같은 시간대의 도메인 질의 실패나 응답 지연을 함께 볼 수 있습니다. 서로 다른 성격의 로그를 같은 방식으로 조회할 수 있으면, 개별 이벤트를 더 넓은 운영 맥락에서 해석하는 데 도움이 됩니다.

카카오클라우드 기술문서에서는 실제 운영 상황을 가정한 다양한 튜토리얼을 제공합니다. 아래 문서에서 운영 로그를 저장하고, 조회 가능한 형태로 구성한 뒤, 필요한 조건으로 분석하는 과정을 단계별로 확인할 수 있습니다.

👉 Cloud Trail 로그를 Data Query를 통해 조회
👉 DNS 리졸버 쿼리 로그를 Data Query 서비스를 통해 조회

Logs, user events, and transaction information generated by services. Storing this data is important, but it becomes a truly "meaningful flow" only when it can be analyzed quickly.

The Kafka-based real-time data pipeline tutorial series introduced here is a hands-on tutorial that lets you directly follow how to implement this "flow of data" on KakaoCloud.

This series consists of three parts and guides you step by step through the entire process, from receiving real-time messages to storage and analysis. It is designed so that you can connect Kafka, Object Storage, Data Catalog, and Data Query, understand the overall structure through which data flows, and implement it directly.

Architecture for building a real-time data pipeline

Part 1: Build a structure for receiving Kafka messages​

In the first tutorial, you create a Kafka cluster and configure an environment for sending and receiving messages through topics. You create Kafka topics, configure producers and consumers, and send and receive messages to establish the foundation for real-time data collection. This process focuses on understanding the basic structure of an event-driven system and creating the starting point of message flow.

👉 View the message processing through Kafka tutorial

Part 2: Store received messages in Object Storage​

The second tutorial covers the flow of periodically collecting messages received through Kafka and storing them in Object Storage. Messages are collected at regular intervals and stored as a single file, and the stored files are used later as data sources for analysis. In this process, you can also consider the boundary between streaming and batch and how file formats and structures should be designed.

👉 View the tutorial for loading Kafka data into Object Storage

Part 3: Real-time analysis with Data Catalog and Data Query​

The final tutorial configures an environment where data stored in Object Storage is registered in Data Catalog and SQL-based analysis can be performed through Data Query. Tables registered in the catalog are managed by partition, and new data can be automatically reflected through periodic synchronization settings. The most important part of this stage is converting real-time data collected through Kafka into a structure that can be analyzed immediately without a separate complex pipeline.

👉 View the tutorial for analyzing Kafka messages using Data Catalog and Data Query

This real-time data pipeline tutorial series is not a simple code example. It is written based on architecture and settings that can be used as-is in operating environments. By directly following the entire process of receiving Kafka messages, storing them in Object Storage, and connecting them to analysis with Data Catalog and Data Query, you can quickly build practical intuition for designing real-time services, monitoring systems, and event-based statistics pipelines.

If you are designing a Kafka-based real-time data pipeline for the first time or want to expand an existing pipeline on KakaoCloud, this tutorial will be a good reference.

🖥️ Try it now!
View the Kafka-based real-time data pipeline tutorial series at a glance

KakaoCloud's serverless interactive query service, Data Query, has finally been officially released as GA (General Availability). This GA version can be seen as a release in which features, performance, and the pricing system have been refined overall through numerous customer cases during internal beta testing and preview stages, so it can be used reliably in real customer environments.

Data Query is a serverless query engine that lets users query data stored in Object Storage directly using SQL without managing separate infrastructure. Users can explore large-scale data with a single query without building a data warehouse themselves or worrying about complex cluster operations.

Simpler and more transparent pricing​

In the GA version, a data-scan-based pay-as-you-go pricing model is applied. Fees are charged at KRW 5,850 per TiB based on the amount of data scanned when a query is executed, and no cost is incurred for metadata queries or DDL statements (CREATE, DROP, SHOW TABLE).

A particularly notable change in this version is that the billing policy for failed and canceled queries has been clarified. If a user cancels a query directly, only the data scanned up to the cancellation point is charged. If a system timeout occurs, fees are charged based on the scanned amount immediately before the timeout. This pricing policy helps ensure that unnecessary charges do not occur from an actual operator's perspective, and allows users to safely try experimental queries or large-scale exploration tasks.

Data Query is also most efficient when used together with Object Storage. Because data can be queried as-is without separate replication or movement, no additional overhead occurs beyond standard Object Storage pricing. As a result, operators can secure flexibility in data analytics while reducing unnecessary costs.

Real example: log analysis based on a data lake​

Data Query works closely with Object Storage and enables analysis in the same way even as data scale grows. One of the most frequently mentioned cases during the beta service stage was service log analysis. One customer stored tens of TB of service logs in Object Storage and used Data Query to explore abnormal traffic patterns in near real time. With the existing approach, logs had to be collected, loaded, and then ingested into a separate analysis system. With the GA version of Data Query, however, results can be checked directly with SQL queries without separate ETL.

For example, users can quickly check the distribution of error codes concentrated during a specific time period or instantly analyze API response times by user segment. This usage clearly shows the value of a serverless query service in a data lake architecture.

Data analysis closer to real operations​

The GA release of Data Query is an important starting point for KakaoCloud's expansion into the data platform area. You can now explore data stored in Object Storage directly without separately building or managing a query-only cluster. In particular, by providing a predictable cost model rather than a complex billing structure, it can improve stability and efficiency in actual service operations. After this GA release, support for various additional data sources will continue to expand, and additional features such as IAM Role integration and more sophisticated query optimization will be provided sequentially.

Data analysis is no longer the role of only dedicated teams. An environment has been prepared where various users, including operators, developers, and planners, can immediately explore the data they need through Data Query and make decisions quickly.
Try the GA version of Data Query now and experience the changed data analytics experience directly.

Want to learn more about Data Query?
👉 View Data Query documentation