One post tagged with "dns"

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

이번에 추가된 두 개의 튜토리얼은 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로 조회하는 구조는 동일합니다.

이번 포스트에서는 각 로그가 어떤 운영 상황에서 유용한지 살펴보고, 이러한 공통 흐름이 로그 분석 방식에서 어떤 의미를 가지는지 정리해 보겠습니다.

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 서비스를 통해 조회