[DRE] 로그 정합성 모니터링 고도화

📌 이 글의 핵심 요약 (Key Takeaways)

매일 수억 건이 발생하는 대규모 데이터 파이프라인에서 단순 건수 체크를 넘어선 '다차원 로그 정합성 모니터링 시스템(Airflow + Databricks + MySQL + Teams)'을 구축한 실무 사례입니다. 본 글에서는 특정 로그 타입 및 국가별 유실을 감지하는 세분화된 집계 로직, 알림 피로도(False Positive)를 줄이기 위한 임계치 설정 노하우, 그리고 대용량 집계 시 발생하는 비용 최적화(Cost Optimization) 전략을 집중적으로 다룹니다.

 

---

 

안녕하세요. 주형권입니다.

최근 방대한 로그들이 여기저기에서 들어오다 보니 로그가 정상적으로 들어오는지에 대해서 고민을 많이 하게 되었습니다. 그래서 데이터 엔지니어들의 영원한 숙제인 정합성 모니터링에 대해 깊은 고민을 하게 되었습니다.

 

현재 저희 팀에서는 매일 수천만~수억 건의 핵심 서비스 로그 데이터를 적재하고 있습니다. 그런데 시스템 규모가 커지다 보니, 전체 볼륨은 정상인데 특정 권역, 테이블, 로그타입, 국가등 로그가 정상적으로 들어오고 있는지에 대한 검증이 필요하다고 생각이 되었습니다. 

 

기존에는 단순하게 권역/테이블/일자 이렇게 3개로만 데이터를 체크 하였다면, 이제는 각 로그타입별 / 국가별로 로그 타입을 더욱 세분화하여 로그의 집계를 통해서 해당 로그에 이상이 있는지에 대해서 조금 더 세부적으로 보고 이를 발견할 수 있도록 해야겠다는 고민을 하게 되었습니다. 

 

단순히 "어제 1억 건 들어왔네, 정상!" 하고 넘어갈 수 없는 상황이 된 것이죠. 그래서 이번에 Airflow, MySQL, 그리고 Teams Adaptive Card를 엮어, 오탐(False Positive) 없이 정확하게 장애 차원을 집어내는 다차원 정합성 모니터링 및 데일리 리포트 시스템을 새롭게 구축했습니다.

 

그 과정에서 겪었던 쿼리 튜닝, DB 설계, 그리고 알림 피로도를 줄이기 위한 엔지니어링적 고민을 공유해 보고자 합니다.

 

---

1. 기존 로그 모니터링의 한계와 다차원 집계의 필요

앞서 말했듯이 정합성 모니터링이나 로그의 누락에 대해서 모니터링을 아예 안하진 않았습니다. 기존에는 단순히 오늘 몇 건이 들어왔으며, 어제와 비교해서 얼마 정도의 증가/하락정도를 권역별 테이블별로 보여줬습니다. 

 

 

이렇게 함으로써 데이터가 들어오지 않은 경우 다음날 바로 알고 조치가 가능 했습니다. (이 로그는 일 배 치입니다.) 그래서 데이터의 누락이 없이 꼼꼼하게 건수 체크를 함으로써 누락이 발생하지 않도록 최소한의 장치를 마련하였습니다. 이렇게 하면 적어도 데이터가 아예 안 들어온 경우는 잡을 수 있었습니다.

 

하지만 이렇게 될 경우 특정 로그나 또는 데이터가 유실되어 들어오는 경우는 알수가 없었습니다. 물론 증감/하락이 매우 뚜렷하면 알 수는 있지만 어디까지나 전날과 비교하므로, 무언가 잘못되었다고 알기는 쉽지 않았습니다. 그래서 조금 더 세부적으로 알고 싶다는 생각이 들었고, 내가 만든 건수 체크 모니터링이 정말 문제가 없나?라는 생각이 들었습니다. 

 

그래서 단순히 전날 -> 오늘 건수를 보여주고, 비교하는 로직을 벗어나서 몇가지 로직을 더 추가하였습니다. 

---

2. 기존보다 더욱 세분화 된 모니터링 

2.1. 모니터링의 세분화

일단 첫번째로 집계의 깊이( Depth)를 더욱 세분화하였습니다. 기존에는 권역 / 테이블 / 일자 이렇게 3개의 GROUP BY로 집계를 하였다면, 이번에는 로그타입 대분류 / 로그타입 소분류 / 국가까지 총 6개의 GROUP BY로 묶었습니다. 이렇게 되면 더욱 세분화하여 특정 로그타입과 특정 국가에서 로그가 유실되거나 로그의 문제를 감지 가능 합니다. 

 

기존에는 하나의 테이블 단위로만 로그를 감지 하였다면 이번에는 로그타입과 세부타입 그리고 국가까지 볼 수 있습니다. 이렇게 됨으로써 사용자는 자신에 맞게 필요한 로그의 정합성을 더욱 쉽게 알 수 있습니다.

 

2.2. 로그의 추세 모니터링

앞서 말한것과 같이 전날 -> 오늘 이렇게 두 개의 날짜만 비교하다 보니 추세를 각 개인이 봐야 했습니다. 기존에는 이렇게 추세를 볼 수 있는 모니터링 대시보드는 제가 만들어서 제공하고 있었습니다.

 

하지만 본인이 보는 로그가 굉장히 중요하다면 일일이 들어가서 확인 하겠지만 모두 본업이 있고, 매일 들어가서 보는 것은 생각보다 쉽지 않습니다. 개인이 하나씩 챙겨 보기는 생각보다 어렵다 보니 알림을 주는 형태로 가는 게 맞다고 판단하였습니다. 그래서 일주일치의 로그의 평균을 내고 거기에서 너무 심한 등락이 있는 경우를 추적하는 것으로 만들면 좋겠다고 생각하였습니다. 

---

3. Airflow & Databricks 기반 로그 정합성 모니터링 아키텍처

 

막상 그리고보니 엄청 대단한 아키텍처는 아닌데, 간단하게 그리면 위와 같이 만들었습니다.

각 Databricks에서 api/2.0/sql/statements를 통해서 각 테이블을 조회합니다. 집계 SQL의 경우 각각의 테이블이 다르고 칼럼명이 다르기 때문에 각각 폴더를 만들어서 파라미터 형태로 불러오도록 SQL 파일로 저장하여 사용하였습니다. 

 

 

각각의 형식에 맞게 저장 된 SQL을 통해서 api를 이용해서 Databricks에서 테이블을 조회하여 각각 테이블의 세부적인 적재 현황을 집계하여 RDS에 적재합니다. 적재된 내역을 이용해서 Role 기반으로 정합모니터링을 하고, 기본적인 건수 체크 로직을 합니다. 여기에서 발생된 내역을 Teams 알림을 통해서 발송합니다. 필요하면 각 담당자를 호출할 수도 있지만 대개 많은 회사에서 그렇듯이 1차 담당자 (데이터 적재 담당자)가 확인합니다. 

 

추가적으로 세부적인 내역을 확인하기 위해서 Databricks의 Redash를 이용해서 지표화를 하였습니다. 이후에 설명 하겠지만 Teams 알림으로는 세부내역을 볼 수 없습니다. Teams의 경우는 알림의 용도가 크기 때문에 리포팅을 할 경우 payload의 글자수 제한으로 일부밖에 보낼 수 없습니다. 그렇기에 심각도에 따라서 순위를 주어서 잘라서 일부만 보내도록 하였습니다. 

 

아래와 같이 일부의 내역만 우선 Teams 메시지에서 노출하고 혹시라도 본인이 보는 로그에 이상이 있는 경우에 Databricks의 Redash를 통해서 보도록 유도 하였습니다. (아래쪽에 하이퍼링크 링크를 걸었습니다.)

 

그리고 아래와 같이 더욱 세부적으로 보기를 유도하여 대시보드에서 각각의 로그의 세부 항목과 국가까지 보도록 만들었습니다. 물론 심각한 로그의 경우는 알림에서 보여지도록 만들었습니다.

---

4. 대용량 로그 집계 시 트러블슈팅: 비용 최적화와 알림 피로도 해결

4.1. 집계 비용

처음에 든 생각으로는 단순히 GROUP BY 집계에 칼럼 몇 개 추가라고 생각했습니다. 그런 게 놓친 게 있습니다. 로그의 적재 건수가 너무나도 많았고 (수십억 건) 이를 집계하는 것도 자원이 필요하였습니다. 그리고 모니터링을 위해서 비용을 너무 많이 쓴다면 배보다 배꼽이 더 큰 상황이었습니다. 

 

그래서 첫번쨰 아이디어를 낸 게 Databricks에 Delta Table로 데이터를 저장하기 전에 "원천 데이터 파일을 읽어서 데이터를 검증하고 이걸 넣자"로 생각해냈습니다. 제가 만든 적재 파이프라인의 경우 (적재도 제가 만들었기에 가능한 이야기) 로그 자체를 필터 하진 않습니다. 원천 자체가 parquet라서 csv , text 같은 파일이 아니므로, 일단 깨지지 않았고, (파일이 깨지면 아예 그 파일이 문제지...) 100% 모두 넣는 것을 원칙으로 만들었기에 오히려 이게 가능했습니다. 

 

만약에 적재 과정에서 데이터 클렌징과 필터 작업이 있다면, 당연히 적재 이후에 집계를 해야 합니다. 저 같은 경우 적재가 N -> N으로 그대로 가기 때문에 이 방법은 고안 하였습니다. 그리고 현재 저희 데이터의 특성상 일자별로 파티션이 아니고 월자별 파티션이라서 이 방법이 최선이라고 생각했습니다.

 

4.2. 너무 세분화된 데이터의 잘못된 알림 

앞서 말한 대로 세분화하여 집계를 하다 보니 허점이 생겼습니다. 예를 들어서 A 타입의 로그가 전날 2건이 들어왔는데 오늘 0건이면 이건 과연 유실인가? 였습니다. 로그의 특성이 모두 다르고 패턴이 다른데 이렇게 로그의 발생 건수가 너무도 낮은 경우 자칫 사용자들에게 너무 많은 알림으로 인해서 알림 피로가 발생할 것 같았습니다. 

 

그래서 과감하게 로그 건수 1,000건 이하의 로그는 집계는 하지만 알림에서 제외하였습니다. 1,000건 이하의 경우 아직 테스트 단계의 로그일수도 있고 빈도수가 매우 적어서 이것이 대시보드나 다른 AX 관점에서 활용될 가치가 적을 수 있다고 판단하여, 알림에서는 과감하게 제외 하였습니다. (어디까지나 저의 생각입니다.)

 

그리고 이렇게 작은 건수 이외에도 로그의 타입에 따라서 등록이 너무 심각하게 많은 경우가 있을 수 있어서 등락 조정이 조금 어려웠습니다. 저의 경우 로그에서 50% 이상 상승/하락인 경우 알림 대상으로 고정하였습니다. 이 정도면 꽤나 많은 유실이나 중복일 수 있으므로 충분히 검토가 필요하다고 판단하였습니다. 

 

4.3. 더욱 세분화 및 맞춤의 한계

위의 내용을 모두 메타 테이블을 만들거나 yaml 파일을 만들어서 각각 체계적으로 관리를 하고 싶었지만 앞서 말한 대로 너무나도 세부적인 집계의 경우 비용의 한계가 분명히 있었습니다. 또한 현재 로그의 종류가 수천 개가 넘어가는데, 이 모든 로그의 생성자가 다르고, 역사가 있는데 모든 것을 혼자 감당하기는 어렵다고 판단하였습니다. 

 

제가 데이터 신뢰성 엔지니어만 하는 직군이거나 아니면 담당자라면 더욱 세분화하여 할 수 있었을 것 같기도 합니다. 하지만 시간/비용적 이슈로 인해서 어느 정도까지만 세분화가 가능한 것은 분명한 한계였습니다. 

 

---

5. 앞으로 개선하고자 하는 것은?

5.1. Databricks Lakebase 교체

개선점은 굉장히 명확합니다. 우선 AWS RDS의 경우 한계점이 많이 있습니다. 우선 성능상 문제입니다. 모니터링을 위해서 좋은 스펙을 쓰기도 굉장히 애매하고 집계 및 조회등에 한계가 있으므로, Databricks에서 제공하는 Lakebase로 교체를 하고자 합니다. 이렇게 되면 플랫폼 자체가 통일되기 때문에 네트워크를 이용할 필요도 없고 안정성 측면에서도 굉장히 많은 이점이 있으며, 관리 포인트도 많이 줄어든다고 생각합니다.

 

5.2. Meta Table 개발 

Meta Table 또는 yaml 파일을 이용해서 단순히 정해진 Role이 아니고, 세부적으로 각 로그마다 특성에 맞게 데이터를 저장하여 감지하도록 할 수 있습니다. 예를 들면 A 로그의 경우 굉장히 민감한 장애 코드 로그라서 잘 발생하지 않지만 발생한다면 매우 중요하므로 알림을 받고 싶다고 하는 사람이 나타나면 이것을 Meta에 저장하고 알림을 받도록 할 수 있습니다. 또한 앞서 말한 등락이 심한 로그도 특정 요일 특정 일 특정 달 같은 부분을 Meta에 저장하고 각각의 상황에서 맞게 관리가 가능합니다. 

 

5.3. Role & AI를 이용한 이상 탐지

현재는 단순하게 정해진 Role에만 의존한다면 AI를 이용해서 AI가 판단해서 할 수도 있습니다. 기존에 만들었던 개인정보 모니터링의 경우도 AI를 활용하여하였듯이 AI를 활용하여 각각의 로그를 판단하여 검증이 가능합니다. 위의 Meta에 해당 정보를 넣고 Role 기반으로 1차 체크 후 2차로 AI를 통한 체크도 가능 합니다. 

 

5.4. 알림 개별화

위의 모든 부분을 충족하면 개발적 알림 메시지도 가능할 것으로 보입니다. 각각의 요구 사항을 받아서 Meta에 미리 넣어두면 각각의 알림 대상자에게 어느 상황에 알림을 발송할지 AI가 판단하고 알림의 개별화가 가능합니다. 이렇게 되면 단순히 A 로그가 들어오지 않았다. A로그가 적게 들어왔다. 이런 단순한 알림을 넘어서 A로그가 이번 달에 적게 무슨 이유로 적게 들어왔다. 등의 내용도 알 수 있습니다. 

---

6. 추가적으로 개발해야 하는 것들

지금까지 위의 모든 내용의 경우 로그가 잘 들어왔냐의 초점을 맞춥니다. 조금 더 상세하게 말하면 그 로그가 100건인데, 100건이 그대로 우리에게 왔는가? 에 포커스를 맞췄습니다. 하지만 이것은 너무나 초기적인 모니터링입니다. 

 

저는 앞으로 더욱 나아가서 해당 칼럼마다의 NULL의 비율이나 해당 일자로 데이터가 정확하게 들어왔는가? 추가적으로 값에는 이상이 없는지가 중요한 포커스라고 봅니다. 

 

데이터가 들어온 건 알겠는데 정확히 들어왔어?

 

제가 앞으로 해보고 싶은 것은 위에 대한 질문에 대한 대답입니다. 지금까지는 단순히 건수에 집중하는 건수의 세분화된 로그 탐지였다면, 이제는 그 로그의 내용을 보는 모니터링을 만들고자 합니다. 하지만 이 역시 앞서 말한 한계점으로 비용의 문제가 가장 큰 거 같습니다. 집계된 로그를 보고 AI를 통한 검증의 경우 집계를 하였으므로 몇백 ~ 몇천 건으로 끝날 수 있습니다.

 

하지만 각 Row를 검증하는 것은 이야기가 다르다고 생각합니다. 모든 Row를 AI로 검증하면 너무나도 편하겠지만 이건 어디까지만 꿈의 이야기 같습니다. 저 같은 경우 추후에 앞서 말한 Meta Table을 이용해서 Role기반으로 한번 검증 이후에 나오는 데이터를 AI를 통해서 재검증하는 시스템으로 진화하고자 합니다. 

 

지금 현재는 집계된 데이터를 검증이었다면 이후에는 집계되지 않은 데이터를 검증하여 데이터 신뢰성을 더욱더 높이고자 합니다. 이렇게 되면 AX에서 사용될 데이터를 더욱 신뢰하며 사용이 가능할 것으로 보입니다. 

 

---

마치며

바야흐로 AX의 시대인 거 같습니다. AX를 안 하면 죽는 것 같이 모두들 말합니다. 하지만 저는 AX가 잘 작동하려면 데이터가 그만큼 잘 적재되고 그만큼 신뢰가 가야 한다고 봅니다. 그렇기에 데이터엔지니어가 AI를 통해서 AX를 못하면 큰일 난다가 아니고 데이터 엔지니어가 이제는 더욱 세분화되어서 업무를 하는 형태로 진화할 것으로 보입니다.

 

그래서 계속해서 데이터 신뢰성에 대해서 공부하고자 하며, 이러한 작업 중에 일부가 이번 글의 핵심이라고 생각됩니다. AI는 내부의 데이터를 이용해서 의사 결정을 해야 하는데, 내부의 데이터가 잘못되었거나 들어오지 않았다면, 판단은 당연히 잘못될 수밖에 없습니다. 

 

앞으로도 더욱 많은 데이터 신뢰성 관련 글을 작성하도록 하겠습니다. 긴 글 읽어 주셔서 감사합니다.