Databricks에서 AI를 사용하여 수천 개의 데이터베이스를 디버깅하는 방법

Databricks는 수동 데이터베이스 운영을 AI로 대체하여 디버깅에 소요되는 시간을 최대 90%까지 단축했습니다.

저희 AI 에이전트는 주요 메트릭과 logs를 검색하고 신호를 자동으로 연관시켜 해석, 실행, 디버깅을 수행합니다. 모든 주요 클라우드 와 거의 모든 클라우드 리전에 배포된 대규모 데이터베이스 전반에서 작동합니다.

이 새로운 에이전트 기능 덕분에 엔지니어는 스토리지 팀의 대기 엔지니어에게 연락할 필요 없이 서비스 상태 및 성능에 관한 질문에 자연어로 일상적으로 답변할 수 있게 되었습니다.

조사 워크플로를 간소화하기 위한 작은 해커톤 프로젝트로 시작된 것이 전사적으로 채택된 지능형 플랫폼으로 발전했습니다. 이것이 저희의 여정입니다.

AI 이전: 모든 것이 작동했지만, 서로 연동되지는 않았습니다.

일반적인 MySQL 인시던트 조사 중에 엔지니어는 종종

• Grafana에서 측정항목 확인
• 클라이언트 워크로드를 파악하기 위해 Databricks 대시보드로 전환합니다.
• CLI 명령어를 실행하여 InnoDB 상태, 즉 트랜잭션 기록, I/O 운영, 교착 상태 세부 정보와 같은 정보가 포함된 내부 MySQL 상태의 스냅샷을 검사
• 클라우드 콘솔에 로그인하여 느린 query logs를 download합니다.

각 도구는 개별적으로는 잘 작동했지만, 함께 사용했을 때 일관된 워크플로를 형성하거나 엔드투엔드 인사이트를 제공하지는 못했습니다. 숙련된 MySQL 엔지니어는 여러 탭과 명령어를 정확한 순서로 오가며 가설을 종합할 수 있었지만, 이 과정에서 소중한 SLO 예산과 시간이 소모되었습니다. 경험이 적은 엔지니어는 어디서부터 start해야 할지 모르는 경우가 많았습니다.

아이러니하게도 저희 내부 툴링의 파편화는 Databricks가 고객의 문제 해결을 돕는 바로 그 과제를 그대로 보여주었습니다.

Databricks 데이터 인텔리전스 플랫폼은 데이터 데이터 거버넌스, AI를 통합하여 승인된 사용자가 자신의 데이터를 이해하고 이를 활용할 수 있도록 합니다. 내부적으로 저희 엔지니어들도 인프라의 기반이 되는 데이터와 워크플로를 통합하는 통일된 플랫폼을 필요로 합니다. 이러한 기반을 바탕으로 AI를 사용하여 데이터를 해석하고 엔지니어에게 다음에 취해야 할 올바른 단계를 안내함으로써 인텔리전스를 적용할 수 있습니다.

저희의 여정: 해커톤에서 지능형 에이전트까지

저희는 크고 여러 분기에 걸친 이니셔티브로 시작하지 않았습니다. 대신 저희는 전사적 해커톤 기간 동안 이 아이디어를 테스트했습니다. 이틀 만에 몇 가지 핵심 데이터베이스 측정항목과 대시보드를 단일 보기로 통합하는 간단한 프로토타입을 만들었습니다. 완성도는 높지 않았지만 기본적인 조사 워크플로들를 즉시 개선했습니다. 이를 통해 저희의 기본 원칙이 정해졌습니다. 빠르게 움직이고 고객에 집착하기.

고객 중심주의로 플랫폼 구축하기

더 많은 코드를 작성하기 전에 저희는 디버깅의 어려움을 이해하기 위해 서비스 팀을 인터뷰했습니다. 공통된 의견은 일관적이었습니다. 주니어 엔지니어는 어디서부터 시작해야 할지 몰랐고, 시니어 엔지니어는 툴링이 단편적이고 번거롭다고 느꼈습니다.

어려움을 직접 확인하기 위해 저희는 온콜 세션에 참여하여 엔지니어들이 실시간으로 문제를 디버깅하는 것을 지켜보았습니다. 세 가지 패턴이 두드러졌습니다.

• 단편화된 툴링
  엔지니어들은 조사 및 재시작 또는 복원과 같은 운영 작업을 위해 여러 대시보드와 CLI, 수동 단계를 오가며 처리해야 했습니다. 각 도구는 독립적으로 작동했지만 통합이 부족하여 워크플로가 느려지고 오류가 발생하기 쉬웠습니다.
• 컨텍스트를 파악하는 데 낭비되는 시간
  대부분의 작업은 무엇이 변경되었는지, '정상' 상태가 어떤 모습인지, 그리고 누가 도움을 줄 수 있는 적절한 컨텍스트를 가지고 있는지 파악하는 것이었고, 실제로 인시던트를 완화하는 것은 아니었습니다.
• 안전한 완화 조치에 대한 불분명한 가이드
  인시던트 발생 시 엔지니어들은 어떤 조치가 안전하고 효과적인지 확신하지 못하는 경우가 많았습니다. 명확한 런북이나 자동화가 없어 기본적으로 장시간 조사를 하거나 전문가를 기다려야 했습니다.

돌이켜보면 사후 분석에서는 이러한 격차를 거의 드러내지 못했습니다. 즉, 팀에는 데이터나 도구가 부족하지 않았고, 쏟아지는 신호를 해석하고 안전하고 효과적인 조치로 안내할 지능형 디버깅 이 부족했습니다.

지능을 향한 반복

데이터베이스 조사를 첫 번째 사용 사례로 삼아 작게 시작했습니다. 저희의 버전 1은 디버깅 SOP를 따르는 정적 에이전트 워크플로였지만 효과적이지 않았습니다. 엔지니어들은 수동 체크리스트가 아닌 즉각적인 인사이트를 제공하는 진단 보고서를 원했습니다.

저희는 올바른 데이터를 확보하고 그 위에 인텔리전스를 더하는 것으로 초점을 옮겼습니다. 이 전략은 이상 탐지로 이어졌고, 이를 통해 올바른 이상을 발견할 수는 있었지만 명확한 다음 단계를 제공하지는 못했습니다.

디버깅 지식을 체계화하고, 후속 질문에 답하며, 조사를 대화형 프로세스로 전환하는 채팅 어시스턴트가 등장하면서 진정한 돌파구가 마련되었습니다. 이것은 엔지니어들이 엔드투엔드로 인시던트를 디버깅하는 방식을 바꾸어 놓았습니다.

기반: 추상화와 중앙화

한 걸음 물러서서 생각해보니, 기존 프레임워크가 단일 인터페이스에서 워크플로와 데이터를 통합할 수는 있었지만, 저희의 생태계는 AI가 운영 환경에 대해 추론하도록 구축되지 않았다는 것을 깨달았습니다. 모든 에이전트는 리전 및 클라우드별 로직을 처리해야 합니다. 그리고 중앙 집중식 액세스 제어가 없으면 너무 제한적이어서 유용하지 않거나 너무 허용적이어서 안전하지 않게 될 것입니다.

Databricks는 수백 개의 리전, 8개의 규제 도메인, 3개의 클라우드에 걸쳐 수천 개의 데이터베이스 인스턴스를 운영하기 때문에 이러한 문제를 해결하기가 특히 어렵습니다. 클라우드 및 규제 차이를 추상화하는 견고한 기반이 없다면 AI 통합은 다음과 같은 피할 수 없는 장애물에 부딪히게 될 것입니다.

• 컨텍스트 파편화: 디버깅 데이터가 여러 곳에 분산되어 있어 에이전트가 일관된 그림을 구성하기 어려웠습니다.
• 불분명한 거버넌스 경계: 중앙 집중식 승인 및 정책 시행이 없으면 에이전트(및 엔지니어)가 올바른 권한 내에서 작동하도록 보장하기가 어려워집니다.
• 느린 반복 루프: 일관성 없는 추상화는 AI 행동을 테스트하고 발전시키기 어렵게 만들며, 시간이 지남에 따라 반복 속도를 심각하게 저하시킵니다.

AI 개발을 안전하고 확장 가능하게 만들기 위해 저희는 세 가지 원칙을 중심으로 플랫폼의 기반을 강화하는 데 집중했습니다.

• 중앙 우선 샤딩 아키텍처 는 글로벌 Storex 인스턴스가 지역별 샤드를 조정하여 단일 인터페이스를 제공하고, 민감한 데이터는 로컬에 보관하여 규정을 준수하도록 합니다.
• 팀, 리소스, RPC 수준에서 적용되는 세분화된 액세스 제어 를 통해 엔지니어와 에이전트는 올바른 권한 내에서 안전하게 작동할 수 있습니다.
• 통합 오케스트레이션, 저희 플랫폼이 기존 인프라 서비스를 통합하여 클라우드와 리전에 걸쳐 일관된 추상화를 가능하게 합니다.

데이터와 컨텍스트가 한곳에 집중되자 다음 단계가 명확해졌습니다. 어떻게 하면 플랫폼을 통합하는 데 그치지 않고 지능적으로 만들 수 있을까요?

가시성에서 인텔리전스로

통합된 기반이 마련되자 데이터베이스 스키마, 측정항목 또는 느린 쿼리 로그를 검색하는 것과 같은 기능을 구현하여 AI 에이전트에 노출하는 것이 간단해졌습니다. 몇 주 안에 저희는 기본 데이터베이스 정보를 집계하고, 추론하며, 사용자에게 다시 제시할 수 있는 에이전트를 구축했습니다.

이제 어려운 부분은 에이전트를 신뢰할 수 있도록 만드는 것이었습니다. LLM은 비결정적이기 때문에 액세스 권한이 있는 도구, 데이터, 프롬프트에 어떻게 응답할지 알 수 없었습니다. 이를 제대로 구현하기 위해서는 어떤 도구가 효과적인지, 그리고 프롬프트에 어떤 컨텍스트를 포함(또는 제외)해야 하는지 파악하기 위해 많은 실험이 필요했습니다.

이처럼 빠른 반복 작업을 지원하기 위해, 저희는 MLflow의 프롬프트 최적화 기술에서 영감을 얻어 프롬프팅을 도구 구현과 분리하는 DsPy를 활용하는 경량 프레임워크를 구축했습니다. 엔지니어는 일반적인 Scala 클래스와 함수 시그니처로 도구를 정의하고, 도구를 설명하는 짧은 docstring만 추가하면 됩니다. 이를 통해 LLM은 도구의 입력 형식, 출력 구조, 결과 해석 방법을 추론할 수 있습니다. 이러한 디커플링 덕분에 파싱, LLM 연결, 대화 상태를 처리하는 기본 인프라를 계속 변경하지 않고도 프롬프트를 반복하거나 에이전트에서 도구를 교체하는 등 신속하게 움직일 수 있습니다.

반복 작업을 진행하면서 회귀를 유발하지 않고 에이전트가 개선되고 있다는 것을 어떻게 증명할 수 있을까요? 이 문제를 해결하기 위해 저희는 검증 프레임워크를 만들었습니다. 이 프레임워크는 프로덕션 상태의 스냅샷을 캡처하고 에이전트를 통해 재생하며, 프롬프트와 도구를 수정하는 과정에서 별도의 “판단” LLM 을 사용해 응답의 정확성과 유용성을 평가합니다.

이 프레임워크를 사용하면 빠르게 반복 작업을 할 수 있으므로, 시스템 및 데이터베이스 문제, 클라이언트 측 트래픽 패턴 등 다양한 도메인에 특화된 에이전트를 쉽게 만들 수 있습니다. 이러한 분해를 통해 각 에이전트는 자신의 영역에서 깊은 전문성을 쌓는 동시에 다른 에이전트와 협력하여 더 완전한 근본 원인 분석을 제공할 수 있습니다. 또한 데이터베이스를 넘어 AI 에이전트를 인프라의 다른 부분에 통합할 수 있는 기반을 마련합니다.

전문가의 지식과 운영 컨텍스트가 추론 과정에 코드화되어 있어 저희 에이전트는 의미 있는 인사이트를 추출하고 조사 과정에서 엔지니어를 적극적으로 안내할 수 있습니다. 몇 분 안에 엔지니어가 검토할 생각도 못 했을 관련 logs와 메트릭을 표시합니다. 예상치 못한 부하를 유발하는 workspace를 식별하고 IOPS 급증을 최근 스키마 마이그레이션과 연관 짓는 등 여러 계층에 걸쳐 증상을 연결합니다. 근본적인 원인과 결과까지 설명하고 완화를 위한 다음 단계를 권장합니다.

이 모든 요소가 함께 가시성에서 인텔리전스로의 전환을 의미합니다. 저희는 도구와 메트릭이 제공하는 가시성을 넘어, 시스템을 이해하고 전문가 지식을 적용하며 엔지니어가 안전하고 효과적인 완화 조치를 취하도록 안내하는 추론 레이어로 발전했습니다. 이는 데이터베이스는 물론, 인프라 전체 운영 방식에 있어서도 저희가 계속해서 발전시켜 나갈 수 있는 토대가 됩니다.

영향: 대규모 구축 및 운영 방식의 재정의

이 플랫폼은 Databricks 엔지니어들이 인프라와 상호작용하는 방식을 바꾸었습니다. 이전에는 대시보드, CLI, SOP 간의 전환이 필요했던 개별 단계들을 이제 채팅 어시스턴트를 통해 쉽게 해결할 수 있어 소요 시간이 최대 90%까지 단축되었습니다.

신입 엔지니어들의 인프라 학습 곡선 또한 급격하게 낮아졌습니다. 아무런 컨텍스트가 없는 신입 사원도 이제 5분 이내에 데이터베이스 조사를 시작할 수 있게 되었는데, 이는 이전에는 거의 불가능했던 일입니다. 그리고 이 플랫폼 출시 이후 훌륭한 피드백을 받았습니다.

데이터베이스 어시스턴트 덕분에 모든 쿼리 대시보드가 어디 있는지 기억할 필요가 없어서 시간이 정말 많이 절약돼요. 어느 워크스페이스에서 부하가 발생하는지 그냥 물어보기만 하면 돼요. 역대 최고의 툴이에요!— Yuchen Huo, Staff Engineer

저는 이 기능의 헤비 유저인데, 이게 없었을 때 어떻게 지냈는지 상상이 안 가네요. 완성도와 유틸리티가 정말 인상적입니다. 팀에게 감사합니다. 개발자 경험에 획기적인 변화를 가져왔네요.— Dmitriy Kunitskiy, Staff Engineer

특히 AI 기반 인사이트를 인프라 문제 디버깅에 활용하는 방식이 정말 마음에 듭니다. 팀에서 이러한 점을 염두에 두고 콘솔을 처음부터 미래지향적으로 설계한 점이 정말 인상 깊습니다.— Ankit Mathur, Senior Staff Engineer

아키텍처 측면에서 이 플랫폼은 다음 진화, 즉 AI 지원 프로덕션 운영을 위한 기반을 마련합니다. 데이터, 컨텍스트, 안전장치가 통합됨에 따라 이제 에이전트가 복원, 프로덕션 query, 구성 업데이트에 어떻게 도움을 줄 수 있는지 탐색할 수 있습니다. 이는 AI 지원 운영 워크플로를 향한 다음 단계입니다.

그러나 가장 의미 있는 영향은 단순히 반복 작업 감소나 더 빠른 온보딩이 아니었습니다. 바로 사고방식의 전환이었습니다. 저희의 초점은 기술 아키텍처에서 엔지니어가 저희 시스템을 경험하는 방식을 정의하는 CUJ(핵심 사용자 여정)로 옮겨졌습니다. 이러한 사용자 우선 접근 방식 덕분에 저희 인프라 팀은 엔지니어들이 업계를 선도하는 제품을 만들 수 있는 플랫폼을 구축할 수 있습니다.

핵심 요약

결론적으로 저희의 여정은 세 가지 핵심 교훈으로 요약할 수 있습니다.

• 에이전트 개발에는 빠른 반복이 필수적입니다. 에이전트는 빠른 실험, 검증, 개선을 통해 발전합니다. 저희의 DsPy 기반 프레임워크는 프롬프트와 도구를 빠르게 발전시킬 수 있게 하여 이를 가능하게 했습니다.
• 반복 속도는 그 기반에 의해 제한됩니다. 통합된 데이터, 일관된 추상화, 세분화된 액세스 제어를 통해 가장 큰 병목 현상을 제거하여 플랫폼을 신뢰할 수 있고 확장 가능하며 AI에 적합하게 만들었습니다.
• 속도는 올바른 방향일 때만 의미가 있습니다. 저희는 에이전트 플랫폼을 구축하려고 시작한 것이 아닙니다. 각 반복은 단지 사용자 피드백을 따랐고 엔지니어들이 필요로 하는 솔루션에 더 가까이 다가갈 수 있게 했습니다.

내부 플랫폼을 구축하는 것은 보기보다 어렵습니다. 같은 회사 내에서도 제품 팀과 플랫폼 팀은 매우 다른 제약 조건 하에서 운영됩니다. Databricks에서는 고객 중심주의로 구축하고, 추상화를 통해 단순화하며, 인텔리전스로 향상시킴으로써 그 격차를 해소하고 있습니다. 외부 고객에게 제공하는 것과 동일한 관심과 엄격함으로 내부 고객을 대합니다.

가입하세요.

앞으로 AI가 어떻게 프로덕션 시스템을 구축하고 복잡한 인프라를 손쉽게 만들 수 있는지, 그 한계를 계속해서 넓혀나가는 과정이 기대됩니다. 차세대 AI 기반 내부 플랫폼 구축에 열정이 있다면 저희와 함께하세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)