스마트 토크 에피소드 7: 옵저버빌리티에서 카디널리티, 통제, 비용 탐색하기

우리는 이 시리즈에서 옵저버빌리티와 AIOps의 보완적 공간을 몇 번 논의했지만, 이번에는 구매자의 심리를 이해하기 위해 이 주제에 더 실용적으로 접근합니다. 조직의 CIO가 옵저버빌리티 솔루션을 시장에서 찾을 때 무엇을 봐야 할까요? 스트라톨리(Stratola)의 수석 애널리스트이자 창업자인 디네시 챈드라세카가 클라우드퓨즈(Kloudfuse)의 CEO 크리슈나 야다파나바르와 이에 대해 이야기하는 이 에피소드에 참여하세요. 크리슈나는 옵저버빌리티를 세 가지 요소, 즉 카디널리티(Cardinality), 통제(Control), 비용(Costs)의 렌즈를 통해 설명합니다.
이 3C는 끊임없이 증가하는 옵저버빌리티 데이터를 이해하고 관리하는 데 핵심입니다. 이 요소들은 데이터를 관리하는 데만 중요한 것이 아니라, 추가 분석을 위해 데이터와 메타데이터를 활용하는 데도 중요합니다.
옵저버빌리티 분야의 새로운 발전은 모델 옵저버빌리티, 특히 생성형 AI를 주도하는 LLM들입니다. 3C는 이 새로운 사용 사례에도 적용됩니다.

이 스마트 토크 에피소드에서 다루는 주제들 중 일부는:

• 옵저버빌리티 데이터의 잠재력
• 도구 확산
• 사일로화된 옵저버빌리티 데이터 극복
• 메타데이터 고려
• 비용에 대한 인사이트

게스트
크리슈나 야다파나바르, 클라우드퓨즈 CEO
크리슈나 야다파나바르는 통합 옵저버빌리티 플랫폼인 클라우드퓨즈의 공동 창업자이자 CEO입니다. 그는 이전에 스프링패스(SpringPath)를 공동 창업하여 9,400만 달러의 자금을 확보하고 회사를 3억 2천만 달러에 시스코(Cisco)에 매각했습니다. 20개 이상의 특허를 가진 크리슈나는 베리타스(Veritas), 컴볼트(Commvault), EMC, VMware, 시스코에서 데이터, 가상화, 스토리지 기술에 상당한 영향을 미쳤습니다. 그는 VMware의 VMFS를 공동 저술했고 ESX 서버의 스토리지 가상화 스택의 핵심 구성 요소를 설계했습니다. 또한 크리슈나는 데이터, 가상화, 클라우드, 보안, AI/ML 전반의 신흥 스타트업들에 조언하고 투자하며, 비전, 제품 전략, 엔지니어링, 시장 진입 노력에 기여하고 있습니다.

호스트: 디네시 챈드라세카는 기술 에반젤리스트, 사고 리더, 베테랑 IT 업계 애널리스트입니다. 약 30년의 경험을 가진 디네시는 복잡한 아키텍처를 가진 고객을 위한 정교한 솔루션을 제공하고 마케팅하는 B2B 엔터프라이즈 소프트웨어 및 SaaS 제품에 종사해 왔습니다. 또한 로직모니터(LogicMonitor), 클라우데라(Cloudera), 호튼웍스(Hortonworks), CA 테크놀로지스(CA Technologies), 소프트웨어 AG(Software AG), IBM 등 다양한 회사에서 여러 고성장 제품을 시장에 출시하기 위한 매우 성공적인 GTM 전략을 정의하고 실행했습니다. 그는 다작의 연설가, 블로거, 주말 코더입니다. 디네시는 산타클라라 대학교에서 MBA 학위를, 마드라스 대학교에서 컴퓨터 응용 석사 학위를 받았습니다. 현재 디네시는 고객 중심의 비즈니스 전략 컨설팅 및 풀스택 마케팅 서비스 회사인 스트라톨리(Stratola)를 운영하고 있습니다.

리소스
스마트 토크 에피소드 6: AIOps와 IT 모니터링의 미래
스마트 토크 에피소드 5: 옵저버빌리티 스택의 분해
스마트 토크 에피소드 4: 실시간 데이터와 벡터 데이터베이스
스마트 토크 에피소드 3: 모던 데이터 파이프라인과 LLM
스마트 토크 에피소드 2: 데이터 인 모션을 통한 생성형 AI 애플리케이션의 부상
스마트 토크 에피소드 1: 데이터 인 모션 생태계 환경
데이터 인 모션 생태계 지도 여기 보기
RTInsights에서 데이터 인 모션에 대해 자세히 알아보기 여기

대본
디네시 챈드라세카

안녕하세요, 데이터 인 모션 리더십 시리즈인 스마트 토크의 이번 에피소드에 오신 것을 환영합니다. 그리고 이 에피소드에는 특별한 게스트, 크리슈나 야다파나바르가 함께합니다. 그는 클라우드퓨즈의 CEO입니다. 그는 스타트업 생태계에 낯설지 않습니다. 그는 연쇄 창업가입니다. 그는 이 전에 몇 개의 회사를 만들었고, 그래서 우리는 크리슈나를 따뜻하게 환영하며 옵저버빌리티에 대한 이 대화를 나누게 되었습니다. 이는 다시 이 시리즈에서 좋아하는 주제입니다.

크리슈나 야다파나바르

감사합니다.

디네시 챈드라세카

크리슈나, 자신을 소개하는 방식으로, 클라우드퓨즈와 회사를 설립하게 된 동기에 대해 말씀해 주시겠어요?

크리슈나 야다파나바르 (01:01):

좋습니다, 디네시. 따뜻한 소개 감사합니다. 여러분, 제 이름은 크리슈나입니다. 네, 저는 거의 20년 이상 밸리에서 살았고 여러 스타트업과 대기업들과 함께 일해왔습니다. 명성을 얻은 건 VMware가 초기 스타트업이었을 때였습니다. 합류했고 그것이 말 그대로 백만 ERR에서 640억 달러 회사로 성장하는 것을 보았습니다. 저는 파일 시스템 작성, 분산 시스템, 데이터베이스, OLAP, OLTP 등 다양한 데이터 관련 기술들과 연관되어 왔습니다. 좋아요, 이 여정 내내 제가 주목한 것은 데이터가 모든 인사이트의 비밀이라는 것입니다. 제품 분석 쪽이든 가상화나 백업, 재해 복구 같은 솔루션 제공이든 말이죠. 제 스타트업인 스프링패스를 했는데, 그건 하이퍼컨버전스 분야에서 스토리지, 네트워킹, 보안을 전부 한 박스에 모으려는 시도였고 시스코에 매각했습니다.

시스코에서 시간을 보낸 후, 다음에 올 큰 트렌드들이 무엇일지 생각했습니다. 이건 2020년 초반이었습니다. 개발자 데브옵스 또는 섹옵스에 관한 데이터가 기하급수적으로 증가하는 트렌드, 당시 초기 단계였던 머신러닝 AI와 LLM 모델의 새로운 트렌드가 시장을 어떻게 파괴할지, 그리고 인간 두뇌가 특정 사건에 대해 생각하고 반응하는 방식처럼 기계들도 비슷하게 행동하길 원한다는 문제들을 접했습니다. 이 세 가지의 교차점에서, 우리는 옵저버빌리티뿐만 아니라 데이터 위에 구축된 옵저버빌리티 플러스 분석과 자동화, 개발자와 데브옵스에 초점을 맞춘 문제 해결이 매우 중요하다는 것을 발견했습니다. 그것이 클라우드퓨즈의 시작으로 이어졌고, 하나에서 다른 것으로 이어져 이제 우리는 40명 이상의 팀입니다.

디네시 챈드라세카 (03:16):

축하드리고 이건 훌륭한 시작입니다. 그 여정에 행운을 빕니다. 옵저버빌리티에 대해 이야기해보자면, 이건 어제 갑자기 생겨난 게 아닙니다. 저도 꽤 오랫동안 그 분야에서 일했고 옵저버빌리티 개념은 수년에 걸쳐 진화했습니다. 그래서 원래 10, 12년 전에는 인프라 모니터링, 네트워크 모니터링 등에 대해 사람들이 들떠 있었고, 그러다 천천히 하나가 다른 것으로 이어지고 클라우드 모니터링과 컨테이너 모니터링 기능이 추가되었습니다. 그리고 오늘 우리는 꽤 인기 있는 옵저버빌리티라는 개념을 가지고 있습니다. 모니터링을 외치던 대부분의 회사들이 이제 옵저버빌리티 회사들입니다. 그리고 당신이 옵저버빌리티 공간에서 새로 시작하며 차이를 만들고 싶어했다는 걸 압니다. 이 진화를 어떻게 설명하시겠습니까? 이전과 비교하여 오늘 우리는 무엇을 가지고 있습니까? 이 진화를 어떻게 보셨습니까?

크리슈나 야다파나바르 (04:09):

네, 좋은 질문입니다 디네시. 저는 이걸 봤습니다, 제 말은 개발자로서 물리적 머신에서 돌아가는 모놀리식 애플리케이션을 작성하던 때부터입니다. 그런 다음 가상화의 출현을 보았습니다, VMware나 Hyper-V나 오픈소스 가상화 기술들이든 컨테이너화가 들어왔든. 옵저버빌리티를 위한 데이터의 핵심 문제를 보면, 이러한 진화들이 진화함에 따라, 우리는 데이터와 관련된 속성들이 계속 증가하는 것을 보았습니다. 그리고 그 속성들이 가질 수 있는 잠재적 값들의 카르테시안 곱을 취하면, 정말 커져서 수백만에서 수십억 단위가 됩니다. 그들이 카디널리티라고 부르는 것과 연관된 카디널리티는 데이터 양입니다. 데이터 양이 증가함에 따라, 사람들은 더 나은 분석을 위해 데이터 A를 데이터 B로 변환하고 싶어합니다. 그들은 데이터 위에 특정 워크플로를 자동화하고 싶어합니다. 그들은 데이터를 슬라이스 앤 다이스해서 더 나은 인사이트를 얻고 싶어합니다. 요약하자면, 데이터 양이 증가함에 따라, 헤이, 나는 소위 알려진 알려진 것들을 모니터링했어라는 전통적인 방식은 사라집니다, 그것이 전통적인 모니터링입니다. 그러면 당신은 알려진 알려지지 않은 것들을 보게 됩니다, 그것이 옵저버빌리티의 시작이고, 당신은 아무것도 모르고 멀티 테라바이트에서 페타바이트 분량의 데이터에 던져지는 완전한 알려지지 않은 알려지지 않은 것들이 있습니다. 그리고 당신은 그 데이터 내에서 더 나은 단어가 부족하여 문제가 정확히 어디인지, 그것이 사건과 어떻게 연관되는지, 근본 원인 분석이 무엇인지, 영향 분석이 무엇인지 해부해야 합니다. 개발자들이 코드를 작성하는 한, 이 복잡성과 더 많은 서비스들이 오고 있습니다. 이 복잡성은 점점 더 높아질 것이고 따라서 새로운 도전들이 등장하는 진화하는 공간으로 계속될 것입니다.

디네시 챈드라세카 (06:14):

환상적입니다. 옵저버빌리티는 분명히 해결하기 어려운 문제입니다. 왜 그런지 탐구하고 싶지만, 당신은 조금 전에 그것에 대해 언급하기도 했습니다. 하지만 또한 우리는 다임어더즌 공급업체들이 있는 붐비는 마켓플레이스를 가지고 있습니다, 우리가 옵저버빌리티의 이 부분과 저 부분을 해결한다고 말하는. 하지만 여전히 이상적인 솔루션을 찾는 탐색이 있습니다. 제가 이야기하는 모든 CIO는 항상 그들의 문제를 해결하는 마법의 총알 같은 이상적인 솔루션을 찾고 있습니다. 왜 그럴까요? 그것을 이해하기 위해 봐야 할 다른 렌즈가 있습니까?

크리슈나 야다파나바르 (07:04):

제가 앞서 암시했듯이 조금 뒤로 물러나 봅시다, 맞죠? 고객이 이상적인 옵저버빌리티 솔루션을 생각할 때 무엇을 찾습니까? 문제에서 시작해봅시다. 저는 이 문제를 세 가지 C, 즉 카디널리티, 통제, 비용으로 분류합니다. 다음 레벨의 디테일로 들어가 봅시다. 이 세 가지 C가 무엇을 의미합니까? 카디널리티, 그것은 우리가 특정 데이터를 가지고 있는 것에 관한 것입니다, 그것이 까다로운 메트릭 포인트이든 로그 라인이든 이벤트이든 분산 추적에서 오는 트레이스나 스팬이든 지속적 프로파일의 프로파일이든, 그것은 추가적인, 더 나은 단어가 부족하여 레이블이나 태그들과 함께 붙습니다. 당신이 그 레이블들이 가질 수 있는 잠재적 값들의 카르테시안 곱을 취하면, 정말 정말 높게 성장합니다. 그래서 이제 모든 데이터 포인트는 그것의 태그들과 연관되어야 합니다.

태그들을 메타데이터라고 부르자. 그리고 데이터가 있습니다. 다른 스키마들은 다른 문제들을 가집니다. 어떤 것들은 메타데이터가 무겁습니다. 메트릭 사이트에 갈 때, 로그와 스팬처럼 분산 추적에서는 데이터가 무겁습니다. 하지만 효과적으로, 그것은 카디널리티 때문에 옵저버빌리티 데이터의 양이 엄청나게 증가하는 것입니다. 요즘 저는 역트렌드를 보았습니다. 옛날에는 사람들이 헤이, 내 데이터를 SaaS 포털로 보내고 SaaS 공급업체가 그 모든 데이터를 관리하게 하자라고 생각했습니다. 하지만 제가 CTO나 CIO나 엔지니어링 헤드나 개발자나 아키텍처 심지어 CFO와 이야기할 때, 그들은 내 데이터를 통제하게 해달라고 생각합니다. 그게 무슨 뜻일까요? 여러 이유로 역트렌드가 진행 중입니다, 이그레스 비용 위험, 그것의 보안 측면, 또는 데이터 양 자체 때문이든.

그들은 그 데이터를 그들의 VPC 밖으로 보내고 싶지 않습니다. 또 다른 각도도 있습니다. 그들은 그들이 생각할 수 있는 모든 가능한 인터페이스를 가져오고 싶어합니다, 전통적인 옵저버빌리티 종류의 인터페이스처럼 대시보드 생성, 알림, SLO, 또는 전통적인 SQL이나 GraphQL로 작성될 수 있는 분석 기능이든, 또는 옵저버빌리티 데이터 위에 일부 분석을 실행하기 위한 스파크 잡 같은 고급 것이든. 옵저버빌리티가 그 근본적인 기둥이 되었기 때문입니다. 그것은 그들이 데이터를 소유해야 함을 의미합니다. 데이터는 VPC를 떠나지 않아야 합니다. 내가 데이터라고 말할 때, 수집되는 데이터, 쿼리되는 데이터, 분석되는 데이터, 그리고 마지막으로 비용입니다. 당신이 밖에 있는 어떤 공급업체에게 가든, 전통적인 SaaS 상업 공급업체이든 오픈소스 구성요소이든, 많은 오픈소스 솔루션들이 있습니다. 인프라 비용, 공급업체의 비용은 데이터 양에 정비례하고, 쿼리 수에 정비례하고, 사용자 수에 정비례합니다. 그 세 가지가 이상적인 솔루션, 이상적인 옵저버빌리티 솔루션을 찾는 전통적인 조직이 찾는 문제들입니다.

디네시 챈드라세카 (10:24):

카디널리티, 통제, 비용. 저는 그게 좋습니다. 세 가지 C는 옵저버빌리티 공간을 바라보고 실제 사용자들에게 무엇이 중요한지 추론하는 훌륭한 방법입니다. 비용에 대해 이야기했으니, 이 질문도 물어보고 싶습니다. 제 개인적 경험에서, 옵저버빌리티 솔루션을 찾는 고객들과 이야기했을 때, 그들이 종종 불평하는 것은 헤이, 저는 최소 8개에서 10개의 다른 도구들을 각 부서에 가지고 있습니다. 조직 전체에서 아마도 30개에서 40개 도구들을 보고 있습니다. 저는 이미 이 라이선스들에 대해 해마다 많은 비용을 지불하고 있습니다. "왜 제가 옵저버빌리티 솔루션을 하나 더 원하죠?"라는 반박을 받곤 했죠. 그래서 제가 이제 그 질문을 당신에게 던집니다. 당신이 비용 측면을 언급했으니까요. CIO에게 그 질문에 어떻게 접근하고, 왜 이게 30개나 40개 다른 도구들을 갖는 것보다 나은지 설득하거나 말해주나요?

크리슈나 야다파나바르 (11:23):

좋습니다, 훌륭한 질문. 그 질문에 답하기 위해, 왜 도구 확산이 있는지 그 문제에서 시작해봅시다. 전체 생태계를 보면, 전통적으로 일부 공급업체들, 상업적 공급업체들을 가져가면, 그들은 특정 스트림에서 꽤 좋았습니다. 로그에 가면 스플렁크(Splunk)를 생각할 수 있습니다. 메트릭을 생각하면 데이터독(Datadog)을 생각합니다. 그러면 구글과 세상의 모든 팡(FANG)들 내부에서. 이 전체 오픈소스 운동이 시작되었습니다, 특히 쿠버네티스의 출현과 함께, 그리고 프로메테우스(Prometheus), 오픈텔레메트리(OpenTelemetry) 같은 것들이 왔습니다.

그리고 오픈소스 기반 솔루션으로 이동하고 있는 이 전체 변화가 있습니다. 그게 무슨 뜻일까요? 개발자들, 아키텍처들, 데브옵스들이 그들의 옵저버빌리티 데이터를 오픈 포맷으로 수집하기를 원한다는 뜻입니다. 의미는, 내가 내 코드를 계측하기 위해 어떤 계측을 선택하든, 내 데이터를 수집하기 위해 어떤 에이전트를 두든, 그것은 100% 오픈소스 호환이어야 합니다. 그래서 상업적 공급업체들도 그들의 에이전트를 오픈소스에 넣기 시작했을 때, 쿼리 쪽에서, 그들은 시각화, 대시보딩, 알림—이 모든 역량들이 오픈소스 쿼리 언어들에 의해 주도되기를 원합니다. 그래서 PromQL, LogQL, TraceQL, 오픈텔레메트리의 등장이 있었고, 그들은 이제 또 다른 오픈소스 쿼리 언어를 시도하고 있습니다.

그래서 이제 당신은 많은 옵션들이 있는 이 세계에 있습니다. 고객들은 이미 특정 스트림에 특정 공급업체들을 선택했습니다.

그러면 오픈소스 운동이 있고 다른 팀들이 다른 인프라들을 사용합니다. 일부는 쿠버네티스 기반이고, 일부는 서버리스 기반이고, 일부는 ECS, 파게이트(Fargate) 등등 기반입니다. 그래서 그게 또 다른 차원을 더하고 전체 제품 전달의 속도와 민첩성에 도달하기 위해, CI/CD가 이 교차점에서 문제들을 매우 빠르게 해결하기 위해 진화했습니다. 그들은 포인트 솔루션을 찾으려 하고 따라서 매우 포인트 솔루션을 선택하게 됩니다. 그게 우리가 이상적인 옵저버빌리티 솔루션으로서, 만약 내 회사의 옵저버빌리티 스택을 시작한다면, 저는 한 발 물러서서 헤이, 내 MTTR과 MTTD를 줄이고 싶다면, 나는 옵저버빌리티 데이터의 모든 엔드 스트림들을 수집해야 해. 내가 n개의 다른 공급업체들에 가서 n개의 다른 스트림들을 고를까, 아니면 내가 모든 스트림들을 함께 넣을 수 있는 옵저버빌리티 데이터 레이크로 갈까? 그래서 상관관계, 아웃라이어 탐지, 이상 징후, 인과관계 같은 고급 기능들이 상대적으로 더 쉬워지는? 그게 당신의 데이터를 당신의 구내에 보존할 수 있는 데이터 레이크에서 모든 것을 통합할 수 있는 이상적인 솔루션이 될 것입니다.

디네시 챈드라세카 (14:18):

환상적입니다. 그리고 저는 도구 확산의 비용에 대해서도 덧붙이고 싶습니다, 저는 개발자들이 그들 자신의 것을 만들고 싶어하고 많은 오픈소스 툴링도 믹스에 추가했기 때문에 크게 동의하지만, 부서 수준 구매이기도 합니다. 그래서 IT 부서는 이 문제를 해결할 수 있다고 느낍니다, 반창고 솔루션을 받자, 선반에서 이 도구를 사서 쓰자. 그리고 시간이 지나면서 그들은 무의식적으로 무기고에 도구를 하나 더 추가했다는 걸 깨닫습니다, 숲을 나무들로 보지 않고. 그래서 CIO 대화들은 항상 흥미롭습니다, 어떻게 당신이 기업 전체에 걸쳐 도구 수를 압축하거나 줄이고 부서들, 애플리케이션들, 인프라 컨테이너들 등을 전반적으로 보는 하나의 옵저버빌리티 플랫폼을 가질 수 있는지.

크리슈나 야다파나바르 (15:08):

전적으로 그렇습니다. 그래서 이제 회사의 다른 페르소나들도 같은 데이터를 보고 있습니다. 데브옵스 개발자들, 아키텍처들은 인프라, 컨테이너화 애플리케이션 등에 관한 옵저버빌리티 데이터를 보고 있습니다. 같은 로그들을 사용해서. 섹옵스들은 데이터의 보안과 위협을 찾으려고 데이터를 해부하려 합니다. 로그나 트레이스에서 오는 비슷한 데이터를 보고. 심지어 데이터옵스들도 헤이, 내 데이터 운영이 얼마나 좋은가? 보고. 그리고 이제 LLM의 출현으로, 심지어 LLM옵스들도 비슷한 데이터를 보고 그들 종류의 분석을 합니다. 그래서 또 다른 통합이 일어나야 합니다. 그게 제가 이상적인 옵저버빌리티 솔루션에서 볼 한 가지입니다. 조직의 모든 다른 페르소나들을 어떻게 가져와서 그들이 소위 데이터 레이크에서 같은 데이터를 활용할 수 있게 할 것인가.

디네시 챈드라세카 (16:05):

진정한 단일 창구(single pane of glass)라는 속담 같은 것, 우리가 모두 노력해온 것. 그래서 좋은 일이네요. 그래서 제가 당신이 이전 응답을 설명하면서 잠시 언급한 한 가지 다른 것에 닿고 싶은데, 그건 MTTR 감소에 관한 것이었습니다. 옵저버빌리티의 주된 핵심으로서, 그것은 트러블슈팅뿐만 아니라 MTTR 감소, 알림 소음 감소 그리고 그런 종류의 메트릭들에 관한 것이기도 합니다. 그래서 그것은 분명히 SRE들과 IT 옵스들이 트러블이 어디 있는지 헤매고 갈라내지 않아도 되게 하는 핵심적인 근본 요구사항으로 저장합니다. 실시간 이벤트들에 접근할 필요가 있습니다. 특정 애플리케이션이나 특정 서버에 악의적 활동 같은 것에 대한 로그가 입력되었다면, 당신은 그 이벤트에 즉시 접근할 필요가 있습니다, 그러면 당신이 그 이상 징후가 어디인지, 당신의 인프라 전반에서 무슨 일이 일어나고 있는지, 왜 이 특정 메모리 스레드나 뭐 그런 것에서 특정 스파이크가 있는지 이해할 수 있습니다.

그래서 당신은 그것을 파악해야 하고, 그러기 위해서는 이 모든 것을 실시간으로 수집할 능력도 필요합니다. 데이터 즉시성, 내가 지난 해 가장 좋아했던 용어이고 데이터 신선함이 여기서 일종의 최우선 중요성입니다. 이건 우리가 옵저버빌리티, 특히 수백 수천 개의 서버들을 모니터링하고 그런 모든 것들에 대해 이야기할 때, 데이터가 가능한 한 신선한지 아닌지에 대해 어디서 문제가 있는지 정확히 지목하는 것과 관련하여 우리가 이야기하는 것입니다. 그것은 주로 수집 메커니즘에 크게 의존합니까? 당신이 TEL과 다른 유형의 계측 기술들에 대해 말했기 때문에. 당신은 그것에 대해 어떻게 달리 생각하거나 이 관점에서, 얼마나 빨리 실시간 데이터에 접근할 수 있는지 바라볼까요?

크리슈나 야다파나바르 (18:03):

좋습니다, 옵저버 팀의 또 다른 훌륭한 측면, 당신은 절대적으로 맞습니다, 다네시. 옵저버티브 데이터가 소비되는 핵심 차원은, 데이터가 데이터 소스를 떠난 순간부터 얼마나 빨리 데이터를 가질 수 있는가입니다, 그것이 당신의 애플리케이션이든 인프라 구성요소든 오픈소스 구성요소 같은 플랫폼이든. 그래서 그것을 위해, 산업이 지난 5년에서 10년 동안 어떻게 진화했는지 보면, 실시간 스트리밍 서비스들, 실시간 데이터베이스들이 등장했습니다. 전통적인 옵저버 솔루션들을 보면, 제 말은 그들이 그 기능을 활용할 수 없었다는 것입니다, 기술이 상대적으로 더 오래되었기 때문에. 그래서 실시간 스트리밍과 실시간 데이터베이스의 출현으로, 당신은 가능한 한 빨리 데이터에 접근할 수 있습니다. 그래서 그것이 데이터가 애플리케이션을 떠난 순간부터 쿼리 가능하게 될 때까지의 신선함이라고 불리는 것의 척도입니다, 그게 전부입니다.

그런 다음 헤이, 나는 모든 데이터를 가지고 있어. 내가 그 데이터를 어떻게 구획화할까? 내가 근본 원인에 도달하기 위해 필요한 관련 패턴들을 어떻게 찾을 수 있을까, 그것은 다음 문제들의 세트입니다. 그래서 나는 한 데이터에서 다른 데이터로 변환할 수 있어야 합니다. 헤이, 나는 로그 시리즈를 얻고 있어. 내가 로그에서 메트릭을 빨리 볼 수 있을까? 나는 스팬 시리즈를 얻고 있어. 나는 그 스팬이나 트레이스 내의 일부 속성을 보고 그 데이터를 분석할 수 있을까? 왜냐하면 이 속성들은 일반적으로 연관되어 있고 그게 디버깅이 일어나는 방식이기 때문입니다. 그래서 그게 다음 차원입니다. 그리고 세 번째 차원은 고급 분석입니다. 그 데이터 위에, 내가 흥미로운 통계적 또는 대규모 언어 모델들을 가져와서 데이터를 분석하여 내 시스템에서 아웃라이어라고 불리는 것을 찾을 수 있을까?

내 시스템에서 이상 징후를 찾을 수 있을까? 좋아, 내 데이터의 계절성 측면을 볼 수 있을까? 내가 과거에서 본 것을 기반으로 내 데이터를 예측할 수 있을까? 데이터의 계절적 측면? 그래서 이 모든 게 내가 고급 분석 패키지라고 부르는 것입니다. 그래서 당신이 신선함의 데이터가 해결된 후 전체 솔루션을 생각하면, 당신은 데이터를 벽돌의 단위로 생각하고 각 벽돌이 어떻게 조정될 수 있는지, 그리고 분석 기능의 세트. 그리고 우리가 필요로 할 자연스러운 것은, 헤이, 내가 이걸 한 번 분석했어, 내가 이것을 자동화할 수 있을까? 그게 전체 것에 대한 자연스러운 확장이 됩니다. 그래서 세 가지 C 문제와 함께, 우리는 고객들이 내 옵저버빌리티 데이터를 어떻게 관찰, 분석, 자동화할 수 있는지 묻는 것을 보았습니다.

디네시 챈드라세카 (20:57):

매우 멋집니다. 매우 멋집니다. 그리고 당신의 응답의 일부로서, 당신은 또한 마법의 단어 LLM, 대규모 언어 모델들을 언급했습니다. 제 말은 요즘 GenAI LLM들에 대해 이야기하지 않고 대화를 가질 수 없다는 것입니다. 그래서 당신이 그것을 언급해서 기쁩니다. 왜냐하면 제가 확실히 그것에 대해 물어볼 수 있기 때문입니다, LLM 옵저버빌리티. LLM들이 곳곳에 확산되면서 사람들이 그들이 어떻게 수행되는지 이해하는 데 어려움을 겪고 있는 것처럼 갑자기 떠오르는 공간 같습니다. 그래서 그것에 대해 말해주세요. 클라우드퓨즈도 그 전선에서 무언가를 만들고 있는 것 같네요, 맞죠? 그래서 그것에 대해 더 말해주세요.

크리슈나 야다파나바르 (21:32):

제 말은, 네. 근본적으로 전체 LLM 모델들이 다양한 사용 사례들에 배포되고 있습니다, 더 나은 단어가 부족하여. 옵저버빌리티 세계에서 특히 데이터의 역동성이 변합니다. 올바른 LLM 모델을 구축하여 특정 작업을 수행하는 것은 항상 어렵습니다. 그래서 우리는 두 가지 방식으로 문제를 보았습니다. 내가 기존 옵저버빌리티 데이터 위에 특정 LLM 모델들을 어떻게 활용할 수 있을까, 그것은 내가 말한 모든 다른 페르소나들에 의해 소비되고 있습니다, 데브옵스나 섹옵스나 데이터옵스들이나 LLM옵스들이든. 그게 그것의 한 측면입니다. 그리고 다른 측면은, 헤이, 나는 LLM이 매우 매우 중요한 구성요소인 애플리케이션을 개발하고 있어. 내가 데이터를 생성하는 애플리케이션의 완전한 옵저버빌리티를 어떻게 볼 수 있을까, 그 데이터가 LLM에 공급되고, 그 LLM 모델들로부터 데이터를 소비하는 많은 컨슈머들이 있어.

그래서 우리는 사실상 LLM 모델들을 사용하여 개발된 모든 애플리케이션에 대한 진정한 엔드투엔드 옵저버빌리티가 무엇인지 생각한 첫 번째 사람들이라고 말할 수 있습니다. 왜냐하면 저는 모델 옵저버빌리티만 보는 많은 솔루션들을 접해왔습니다, 드리프트 같은 것들. 하지만 우리는 엔드투엔드를 보고 있습니다. 그건 매우 흥미로운 측면입니다. 왜냐하면 많은 인프라 애플리케이션 옵저버빌리티가 모델 옵저버빌리티와 나머지 것들과 함께 가기 때문입니다. 그리고 마지막이지만 가장 중요한 건, 당신이 어떤 CIO나 CFO에게 가서 물어보면, LLM의 비용, 현재 솔루션들처럼, 비용은 또 다른 핵심 차원입니다. 그 비용을 어떻게 유지하거나 심지어 LLM 모델들 자체의 비용 메트릭에 대한 분석을 제공할 수 있을까는 그것의 또 다른 측면입니다. 그래서 당신은 모든 것을 봐야 합니다: 성능, 부족한 것, LLM 애플리케이션을 위한 APM이라고 부르자, 그리고 비용. 그래서 이것들이 당신이 그것을 볼 전형적인 차원들입니다.

디네시 챈드라세카

매우 멋지고, 흥미로운 공간이고 저는 앞으로 몇 달 안에 그 공간에서 무엇이 올지 배우는 것에 확실히 흥분됩니다. 정말 감사합니다, 크리슈나. 이건 매우 매우 훌륭한 대화였습니다. 당신을 우리 쇼에 모시게 되어 기뻤습니다. 옵저버빌리티에 대해 이야기하는 걸 좋아했습니다. 당신의 세 가지 C를 기억할게요: 카디널리티, 통제, 비용. 저는 그게 옵저버빌리티를 바라보는 훌륭한 방식, 훌륭한 만트라라고 생각합니다. 모든 인사이트에 감사드립니다. 여기 와주셔서 고맙습니다. 감사합니다.

크리슈나 야다파나바르

정말 감사합니다, 디네시. 당신의 웹 채팅에 저를 초대해 주셔서 감사합니다.