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

Databricks에서는 수동 데이터베이스 작업을 AI로 대체하여 디버깅에 소요되는 시간을 최대 90%까지 줄였습니다.

당사의 AI 에이전트는 주요 메트릭과 로그를 검색하고 신호를 자동으로 상관시켜 해석, 실행 및 디버깅합니다. 이 에이전트는 모든 주요 클라우드 및 거의 모든 클라우드 리전에 배포된 데이터베이스 클러스터에서 작동합니다.

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

조사 워크플로를 단순화하기 위한 작은 해커톤 프로젝트로 시작된 것이 이제는 회사 전체에서 채택된 지능형 플랫폼으로 발전했습니다. 이것이 우리의 여정입니다.

AI 이전: 모든 것이 작동했지만 아무것도 함께 작동하지 않았습니다

일반적인 MySQL 인시던트 조사 중에 엔지니어는 종종 다음과 같은 작업을 수행했습니다.

• Grafana에서 메트릭 확인
• 클라이언트 워크로드를 이해하기 위해 Databricks 대시보드로 전환
• CLI 명령을 실행하여 트랜잭션 기록, I/O 작업 및 교착 상태 세부 정보와 같은 정보를 포함하는 내부 MySQL 상태의 스냅샷인 InnoDB 상태 검사
• 느린 쿼리 로그를 다운로드하기 위해 클라우드 콘솔에 로그인

각 도구는 자체적으로는 잘 작동했지만, 함께 사용하면 통합된 워크플로를 형성하거나 엔드투엔드 통찰력을 제공하지 못했습니다. 숙련된 MySQL 엔지니어는 올바른 순서로 탭과 명령을 넘나들며 가설을 세울 수 있었지만, 이 과정에서 귀중한 SLO 예산과 시간을 소모했습니다. 신입 엔지니어는 종종 어디서부터 시작해야 할지 몰랐습니다.

아이러니하게도 내부 도구의 이러한 단편화는 Databricks가 고객이 극복하도록 돕는 과제와 정확히 일치했습니다.

Databricks 데이터 인텔리전스 플랫폼은 데이터, 거버넌스 및 AI를 통합하여 권한 있는 사용자가 데이터를 이해하고 조치할 수 있도록 합니다. 내부적으로 엔지니어들도 마찬가지로 인프라를 뒷받침하는 데이터와 워크플로를 통합하는 통합 플랫폼이 필요합니다. 이러한 기반을 통해 AI를 사용하여 데이터를 해석하고 엔지니어를 다음 올바른 단계로 안내함으로써 지능을 적용할 수 있습니다.

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

우리는 대규모의 여러 분기 동안 진행되는 이니셔티브로 시작하지 않았습니다. 대신, 회사 전체 해커톤 동안 아이디어를 테스트했습니다. 이틀 만에 몇 가지 핵심 데이터베이스 메트릭과 대시보드를 단일 보기로 통합하는 간단한 프로토타입을 구축했습니다. 세련되지는 않았지만 즉시 기본적인 조사 워크플로를 개선했습니다. 그것이 우리의 지침 원칙인 빠르게 움직이고 고객 중심을 유지하라는 것을 설정했습니다.

고객 중심의 플랫폼 구축

더 많은 코드를 작성하기 전에 서비스 팀과 인터뷰하여 디버깅의 고충점을 이해했습니다. 주제는 일관적이었습니다. 주니어 엔지니어는 어디서부터 시작해야 할지 몰랐고, 시니어 엔지니어는 도구가 파편화되고 번거롭다고 느꼈습니다.

직접 고충을 보기 위해 담당자 세션에 참여하여 엔지니어들이 실시간으로 문제를 디버깅하는 것을 지켜보았습니다. 세 가지 패턴이 두드러졌습니다.

• 파편화된 도구
  엔지니어들은 조사 및 재시작 또는 복원과 같은 작업을 위해 대시보드, CLI 및 수동 단계를 번갈아 사용했습니다. 각 도구는 독립적으로 작동했지만 통합 부족으로 인해 워크플로가 느리고 오류가 발생하기 쉬웠습니다.
• 컨텍스트 수집에 낭비되는 시간
  대부분의 작업은 무엇이 변경되었는지, “정상”이 무엇인지, 누가 도움을 줄 수 있는 올바른 컨텍스트를 가지고 있는지 파악하는 것이었지, 실제로 인시던트를 완화하는 것은 아니었습니다.
• 안전한 완화에 대한 불분명한 지침
  인시던트 중 엔지니어는 종종 어떤 조치가 안전하거나 효과적인지 확신하지 못했습니다. 명확한 실행서나 자동화 없이는 장기간의 조사에 의존하거나 전문가를 기다렸습니다.

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

지능을 향한 반복

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

우리는 올바른 데이터를 얻고 그 위에 지능을 계층화하는 데 초점을 전환했습니다. 이 전략은 올바른 이상 징후를 보여주는 이상 징후 감지로 이어졌지만, 여전히 명확한 다음 단계를 제공하지는 못했습니다.

진정한 돌파구는 디버깅 지식을 코드화하고, 후속 질문에 답변하며, 조사를 대화형 프로세스로 전환하는 채팅 어시스턴트와 함께 찾아왔습니다. 이것은 엔지니어들이 인시던트를 엔드투엔드로 디버깅하는 방식을 변화시켰습니다.

기반: 추상화 및 중앙 집중화

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

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

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

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

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

데이터와 컨텍스트가 중앙 집중화됨에 따라 다음 단계가 명확해졌습니다. 플랫폼을 단순히 통합하는 것이 아니라 지능적으로 만드는 방법은 무엇일까요?

가시성에서 지능으로

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

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

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

반복하는 동안 회귀를 도입하지 않고 에이전트가 개선되고 있음을 어떻게 증명할 수 있을까요? 이를 해결하기 위해 저희는 프로덕션 상태의 스냅샷을 캡처하고 에이전트를 통해 다시 실행하는 검증 프레임워크를 만들었습니다. 별도의 “judge” LLM을 사용하여 프롬프트와 도구를 수정하면서 응답의 정확성과 유용성을 평가합니다.

이 프레임워크를 통해 빠르게 반복할 수 있기 때문에 다양한 도메인에 특화된 에이전트를 쉽게 생성할 수 있습니다. 하나는 시스템 및 데이터베이스 문제에 집중하고, 다른 하나는 클라이언트 측 트래픽 패턴에 집중하는 식입니다. 이러한 분해를 통해 각 에이전트는 해당 영역에서 깊은 전문성을 구축하는 동시에 다른 에이전트와 협력하여 보다 완전한 근본 원인 분석을 제공할 수 있습니다. 또한 데이터베이스를 넘어 AI 에이전트를 다른 인프라 부분에 통합할 수 있는 길을 열어줍니다.

전문 지식과 운영 컨텍스트가 모두 에이전트의 추론에 코드화되어 있어, 에이전트는 의미 있는 통찰력을 추출하고 엔지니어가 조사를 통해 적극적으로 안내할 수 있습니다. 몇 분 안에 엔지니어가 검토하지 않았을 수도 있는 관련 로그와 메트릭을 찾아냅니다. 또한 작업 공간이 예상치 못한 로드를 유발하는 것을 식별하고 IOPS 급증을 최근 스키마 마이그레이션과 상관시키는 등 계층 간의 증상을 연결합니다. 또한 근본적인 원인과 결과를 설명하고 완화를 위한 다음 단계를 권장합니다.

이러한 요소들이 함께 모여 저희의 초점이 가시성에서 지능으로 전환되었음을 보여줍니다. 저희는 도구와 메트릭에서 얻는 가시성을 넘어 시스템을 이해하고, 전문 지식을 적용하며, 엔지니어가 안전하고 효과적인 완화 조치를 취하도록 안내하는 추론 계층으로 나아갔습니다. 이는 데이터베이스뿐만 아니라 전반적인 인프라 운영 방식을 개선하는 데 계속 구축할 수 있는 기반입니다.

영향: 규모에 맞는 구축 및 운영 방식 재정의

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

신규 엔지니어의 인프라 학습 곡선도 가파르게 완만해졌습니다. 컨텍스트가 전혀 없는 신규 입사자도 5분 이내에 데이터베이스 조사를 시작할 수 있게 되었는데, 이는 이전에는 거의 불가능했던 일입니다. 그리고 이 플랫폼 출시 이후 훌륭한 피드백을 받았습니다.

데이터베이스 도우미가 정말 많은 시간을 절약해 주어 모든 쿼리 대시보드가 어디에 있는지 기억할 필요가 없습니다. 어떤 워크스페이스가 로드를 생성하는지 물어보기만 하면 됩니다. 최고의 도구입니다!— Yuchen Huo, 수석 엔지니어

저는 이 도구를 많이 사용하며, 이 도구가 없던 시절에 어떻게 살았는지 믿을 수 없습니다. 완성도와 유용성이 매우 인상적입니다. 팀에게 감사합니다. 개발자 경험의 획기적인 발전입니다.— Dmitriy Kunitskiy, 수석 엔지니어

특히 AI 기반 통찰력을 인프라 문제 디버깅에 적용하는 방식이 마음에 듭니다. 이 콘솔을 처음부터 염두에 두고 설계한 팀의 미래 지향적인 사고방식에 감사합니다.— Ankit Mathur, 선임 수석 엔지니어

아키텍처 측면에서 이 플랫폼은 다음 진화 단계인 AI 지원 프로덕션 운영을 위한 기반을 마련합니다. 데이터, 컨텍스트 및 가드레일을 통합함으로써 이제 에이전트가 복원, 프로덕션 쿼리 및 구성 업데이트를 어떻게 도울 수 있는지 탐색할 수 있습니다. 이는 AI 지원 운영 워크플로를 향한 다음 단계입니다.

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

핵심 요약

결론적으로 저희의 여정은 세 가지 핵심 요약으로 귀결되었습니다.

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

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

함께하세요

앞으로 저희는 AI가 프로덕션 시스템을 어떻게 형성하고 복잡한 인프라를 쉽게 느끼게 할 수 있는지에 대한 경계를 계속 넓혀갈 것입니다. AI 기반 차세대 내부 플랫폼 구축에 열정을 가지고 있다면 저희와 함께하세요!

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