Smart Talk 에피소드 7:관찰 가능성의 카디널리티, 제어 및 비용 탐색

우리는 이 시리즈에서 AIOps의 관찰 가능성과 보완 공간에 대해 몇 차례 논의했지만 이번에는 구매자의 사고방식을 이해하기 위해 주제에 대해 좀 더 실용적인 내용을 다룹니다. 조직의 CIO가 가시성 솔루션 시장에 진출할 때 무엇을 찾아야 합니까? Stratola의 수석 분석가이자 창립자인 Dinesh Chandrasekhar가 Kloudfuse의 CEO인 Krishna Yadappanavar와 대화하는 이번 에피소드에 참여하세요. Krishna는 카디널리티, 제어 및 비용이라는 세 가지 요소의 렌즈를 통해 관찰 가능성을 설명합니다.
이 3C는 계속 증가하는 관측 가능성 데이터를 이해하고 관리하는 데 핵심입니다. 이러한 요소는 데이터 관리뿐만 아니라 추가 분석을 위해 데이터 및 메타데이터를 활용하는 데에도 중요합니다.
관찰 가능성 분야의 새로운 발전은 모델 관찰 가능성, 특히 생성 AI를 구동하는 LLM입니다. 3C는 이 새로운 사용 사례에도 적용됩니다.

이번 Smart Talk 에피소드에서 다루는 주제는 다음과 같습니다:

• 관측 가능성 데이터의 잠재력
• 도구의 확산
• 단일화된 관측 가능성 데이터 극복
• 메타데이터 고려
• 비용에 대한 통찰력

게스트
Krishna Yadappanavar, Kloudfuse CEO
Krishna Yadappanavar는 통합 관측 플랫폼인 Kloudfuse의 공동 창립자이자 CEO입니다. 그는 이전에 SpringPath를 공동 창립하여 9,400만 달러의 자금을 확보하고 회사를 Cisco로부터 3억 2,000만 달러에 인수하도록 이끌었습니다. 20개 이상의 특허를 보유한 Krishna는 Veritas, Commvault, EMC, VMware 및 Cisco의 데이터, 가상화 및 스토리지 기술에 큰 영향을 미쳤습니다. 그는 VMware의 VMFS를 공동 작성하고 ESX Server용 스토리지 가상화 스택의 핵심 구성 요소를 설계했습니다. 또한 Krishna는 데이터, 가상화, 클라우드, 보안, AI/ML 전반에 걸쳐 신흥 스타트업에 조언하고 투자하여 비전, 제품 전략, 엔지니어링 및 시장 진출 노력에 기여하고 있습니다.

호스트:  Dinesh Chandrasekhar는 기술 전도사이자 사고의 리더이자 노련한 IT 산업 분석가입니다. 30년에 가까운 경험을 보유한 Dinesh는 복잡한 아키텍처를 가진 고객을 위해 정교한 솔루션을 제공하고 마케팅하는 SaaS 제품은 물론 B2B 엔터프라이즈 소프트웨어 분야에서 일해 왔습니다. 그는 또한 LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM 등과 같은 다양한 회사에서 여러 고성장 제품을 시장에 출시하기 위해 매우 성공적인 GTM 전략을 정의하고 실행했습니다. 그는 다작의 연설자이자 블로거이며 주말 코더입니다. Dinesh는 산타클라라 대학교에서 MBA 학위를, 마드라스 대학교에서 컴퓨터 응용 석사 학위를 취득했습니다. 현재 Dinesh는 고객 중심 비즈니스 전략 컨설팅 및 풀스택 마케팅 서비스 회사인 Stratola라는 회사를 직접 운영하고 있습니다.

리소스
Smart Talk 에피소드 6:AIOps와 IT 모니터링의 미래
Smart Talk 에피소드 5:관찰 가능성 스택의 분리
Smart Talk 에피소드 4:실시간 데이터 및 벡터 데이터베이스
Smart Talk 에피소드 3:최신 데이터 파이프라인 및 LLM
Smart Talk 에피소드 2:이동 중인 데이터를 갖춘 GenAI 애플리케이션의 부상
Smart Talk 에피소드 1:이동 중인 데이터 생태계 환경
여기에서 이동 중인 데이터 생태계 지도를 확인하세요.
여기에서 RTInsights의 이동 데이터에 대해 자세히 알아보세요.

스크립트
디네시 찬드라세카르

안녕하세요, Data in Motion 리더십 시리즈인 Smart Talk의 이번 에피소드에 오신 것을 환영합니다. 이번 에피소드에는 Krishna Yadappanavar라는 특별 게스트가 있습니다. 그는 Cloud Fuse의 CEO입니다. 그는 스타트업 생태계에 대해 전혀 낯선 사람이 아닙니다. 그는 연쇄 창업가입니다. 그는 이전에 몇 개의 회사를 설립했으므로 우리는 Krishna가 이 시리즈에서 가장 좋아하는 주제인 관찰 가능성에 대한 대화를 나누게 된 것을 진심으로 환영합니다. 

크리슈나 야다파나바르

감사합니다.

디네시 찬드라세카르

그럼 크리슈나 씨, 자기 소개로 Kloudfuse와 회사를 시작하게 된 계기에 대해 말씀해 주시면 어떨까요?

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

알았어, 물론이지. 고마워요, 디네쉬. 따뜻한 소개 감사드립니다. 안녕하세요 여러분, 제 이름은 크리슈나입니다. 네, 저는 거의 20년 넘게 밸리에 살면서 여러 스타트업 및 대기업과 협력해 왔습니다. 명성을 얻는 이름은 초기 스타트업 시절의 VM웨어와 같다. 저는 합류한 후 문자 그대로 백만 개에 가까운 ERR에서 640억 개의 회사로 성장하는 것을 보았습니다. 저는 파일 시스템, 분산 시스템, 데이터베이스, OLAP 또는 OLTP 작성 등 다양한 데이터 관련 기술과 관련되어 왔습니다. 좋습니다. 이 여정을 통해 제가 알아차린 것은 데이터가 제품 분석 측면이든, 가상화와 같은 솔루션을 제공하든, 백업이나 재해 복구와 같은 솔루션을 제공하든 상관없이 모든 통찰력의 비밀이라는 것입니다. 하이퍼컨버전스 시대에 있었던 Springpath라는 스타트업을 완료한 후 스토리지, 네트워킹, 보안의 융합을 하나의 상자에 담아 Cisco에 판매했습니다.

그리고 Cisco에서 시간을 보낸 후 앞으로 다가올 큰 트렌드는 무엇인지 생각했습니다. 이는 2020년 초로 거슬러 올라갑니다. 저는 개발자 DevOps 또는 SecOps와 관련된 데이터가 기하급수적으로 증가하는 방식과 관련된 일부 추세와 같은 몇 가지 추세를 발견했습니다. 기계 학습 AI 및 LLM 모델의 새로운 트렌드는 초기 단계에 있던 LLM 모델이 어떻게 시장을 혼란에 빠뜨릴까요? 그리고 인간의 두뇌가 특정 사건에 대해 생각하고 반응하기 시작하면 기계도 비슷한 방식으로 작동하기를 원합니다. 이것은 우리가 직면한 문제 중 일부였으며 세 가지 모두의 교차점에서 개발자와 DevOps에 초점을 맞춘 데이터 외에 관찰 가능성뿐만 아니라 분석 및 자동화에 더해 관찰 가능성의 문제를 해결하는 것이 매우 중요하다는 것을 발견했습니다. 이것이 Kloudfuse의 시작으로 이어졌습니다. 하나는 다른 하나를 낳았고 이제 우리는 약 40명 이상의 사람들로 구성된 팀이 되었습니다.

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

축하합니다. 좋은 시작이군요. 그럼 그 여행에 행운이 있기를 바랍니다. 관찰 가능성에 관해 이야기하자면, 이는 어제 갑자기 발생한 일이 아닙니다. 나는 상당한 시간 동안 그 공간에서 일했고 관찰 가능성의 개념은 수년에 걸쳐 발전해 왔습니다. 그래서 원래 10, 12년 전에 사람들은 인프라 모니터링, 네트워크 모니터링 등에 대해 이야기하는 것에 대해 과장된 이야기를 하다가 천천히 한 가지 일이 다른 일로 이어졌고 클라우드 모니터링과 컨테이너 모니터링 기능이 추가되었습니다. 그리고 오늘날 우리는 꽤 대중적인 관찰 가능성이라는 개념을 가지고 있습니다. 모니터링을 홍보했던 대부분의 회사는 이제 관찰 가능성 회사입니다. 그리고 나는 당신이 변화를 만들고 싶어 관찰 가능성 공간에서 새롭게 시작했다는 것을 알고 있습니다. 이 진화를 어떻게 설명하시겠습니까? 오늘날 우리가 가지고 있는 것과 비교하면 이전에는 어떠했습니까? 이러한 진화를 어떻게 보셨나요?

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

네, 좋은 질문이에요. 디네쉬. 나는 이것을 보았습니다. 즉, 물리적 시스템에서 실행되는 모놀리식 애플리케이션을 작성하는 개발자로서 말입니다. 그러다가 VMware, Hyper-V 또는 오픈 소스 가상화 기술과 같은 가상화의 출현을 보았고 컨테이너화가 등장했습니다. 따라서 관찰성에 대한 데이터의 핵심 문제를 살펴보면 이러한 평가가 발전함에 따라 데이터와 관련된 속성이 계속 증가하고 이러한 속성의 데카르트 곱을 취하면 수백만에서 수십억 단위로 정말 커집니다. 해당 카디널리티와 관련된 카디널리티라고 부르는 것은 데이터 볼륨입니다. 데이터 양이 증가함에 따라 사람들은 더 나은 분석을 위해 데이터 A를 데이터 B로 변환하고 싶어합니다. 그들은 데이터를 바탕으로 특정 워크플로를 자동화하려고 합니다.

그들은 더 나은 통찰력을 제공할 수 있도록 데이터를 분석하고 싶어합니다. 간단히 말해서, 데이터 양이 증가함에 따라 알려진 정보가 사라지는 소위 전통적인 모니터링 방식을 모니터링하고 있었습니다. 그런 다음 관측 가능성의 시작인 알려진 미지의 항목을 살펴봅니다. 아무것도 모르는 완전한 미지의 항목이 있으며 멀티 테라바이트에서 페타바이트 규모의 데이터에 던져지고 해당 데이터 내에서 분석해야 하며 정확히 문제가 어디에 있는지, 사건과 어떻게 연관되어 있는지, 근본 원인 분석은 무엇인지, 영향 분석은 무엇인지에 대해 더 나은 단어가 부족합니다. 따라서 개발자가 코드를 작성하는 한 이러한 복잡성과 점점 더 많은 서비스가 제공됩니다. 이러한 복잡성은 점점 더 높아질 것이며 따라서 새로운 과제가 등장하는 진화하는 공간이 계속될 것입니다.

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

환상적입니다. 따라서 관측 가능성은 분명히 해결하기 어려운 문제입니다. 왜 그런지 알아보고 싶습니다. 하지만 방금도 당신이 그것에 대해 조금 언급했다고 생각합니다. 하지만 우리는 관찰 가능성의 이 부분과 그런 종류의 관찰 가능성 등을 해결하지만 여전히 이상적인 솔루션을 찾고 있다고 말하는 수십 개의 공급업체가 있는 혼잡한 시장이 있습니다. 그래서 제가 대화하는 모든 CIO는 항상 자신의 문제를 해결할 수 있는 마법의 총알을 찾고 있습니다. 왜 그럴까요? 왜 이상적인 솔루션을 얻고자 하는 다른 충동이 있는지 이해하기 위해 이를 살펴봐야 하는 다른 관점이 있습니까?

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

그럼 앞서 언급했듯이 조금 뒤로 물러서겠습니다. 그렇죠? 고객이 이상적인 관찰 솔루션을 생각할 때 무엇을 보고 있습니까? 문제부터 시작해 보겠습니다. 나는 이 문제를 카디널리티(Cardinality), 제어(Control), 비용(Cost)이라는 세 가지 C로 분류합니다. 다음 단계의 세부정보를 살펴보겠습니다. 이 세 가지 C는 무엇을 의미합니까? 카디널리티는 까다로운 측정 지점, 로그라인, 이벤트, 추적, 배포자 추적에서 나오는 범위, 지속적인 프로필의 프로필 등 특정 데이터를 보유하는 방식에 관한 모든 것입니다. 더 나은 단어, 라벨 또는 태그가 부족하여 추가로 첨부됩니다. 해당 레이블이 취할 수 있는 잠재적 가치의 데카르트 곱을 취하면 정말 매우 높아질 것입니다. 이제 모든 데이터 포인트가 태그와 연결되어야 합니다.

태그를 메타데이터라고 부르겠습니다. 그리고 데이터가 있습니다. 다른 계획에는 다른 문제가 있습니다. 일부는 메타데이터가 무겁습니다. 매트릭스 사이트에 가면 분산 추적과 같은 로그와 스팬을 보면 마치 데이터처럼 무겁지만 실제로는 카디널리티로 인해 가시성 데이터의 양이 엄청나게 증가한 것입니다. 요즘은 반대 추세를 보았습니다. 내 말은, 사람들이 '내 데이터를 SaaS 포털로 보내면 SaaS 공급업체가 해당 데이터를 모두 관리할 것'이라고 생각했던 시절을 의미합니다. 하지만 CTO, CIO, 엔지니어링 책임자, 개발자, 설계자, 심지어 CFO와 이야기를 나누면 그들은 '내 데이터를 통제할 수 있게 해주세요'라고 생각합니다. 그게 무슨 뜻인가요? 위험 비용의 유출, 보안 측면, 데이터 자체의 양 등 다양한 이유로 데이터가 너무 많아지는 역 추세가 진행되고 있습니다.

그들은 해당 데이터를 VPC 외부로 보내기를 원하지 않으며 또 다른 각도가 있습니다. 그들은 대시보드, 경고, SLO 또는 전통적인 SQL이나 GraphQL로 작성될 수 있는 분석 기능 생성과 같은 전통적인 관찰 종류의 인터페이스를 위한 것인지, 관찰 가능성이 기본 기둥이 되었기 때문에 관찰 가능성 데이터를 기반으로 일부 분석을 실행하는 Spark 작업과 같은 고급 기능을 위한 것인지 생각할 수 있는 가능한 모든 인터페이스를 가져오고 싶어합니다. 이는 그들이 데이터를 소유해야 함을 의미합니다. 데이터가 VPC를 벗어나면 안 됩니다. 데이터, 수집되는 데이터, 쿼리되는 데이터, 분석되는 데이터를 말하면 마지막으로 중요한 것은 비용입니다. 전통적인 SaaS 상용 공급업체든 오픈 소스 구성 요소든 관계없이 어떤 공급업체에든 가면 거기에는 수많은 오픈 소스 솔루션이 있습니다. 인프라 비용, 공급업체의 비용은 데이터 양, 쿼리 수, 사용자 수에 정비례합니다. 이 세 가지는 이상적인 솔루션, 이상적인 관찰 솔루션을 찾고 있는 전통적인 조직이 찾고 있는 문제입니다.

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

카디널리티, 제어 및 비용. 나는 그것을 좋아한다고 생각합니다. 세 가지 C는 관찰 가능성 공간과 실제 사용자에게 중요한 것이 무엇인지 추론하는 방법 등을 살펴보는 좋은 방법입니다. 비용 이야기를 하다가 이 부분도 물어보고 싶습니다. 내 개인적인 경험에 따르면, 관찰 가능성 솔루션을 찾고 있는 고객과 이야기를 나누었을 때 고객이 자주 불평하는 내용은 다음과 같습니다. 각 부서에는 최소 8~10개의 도구가 있습니다. 저는 현재 조직 전반에 걸쳐 30~40개의 도구를 살펴보고 있습니다. 나는 이미 해마다 이러한 라이센스에 대해 많은 비용을 지불하고 있습니다. “관측성 솔루션을 하나 더 원하는 이유는 무엇입니까?”라고 제가 자주 받았던 반발이었죠. 그렇죠? 비용 측면을 다루었으니 이제 동일한 질문을 드리고자 합니다. CIO와 함께 이 질문에 어떻게 접근하고 CIO를 설득하거나 이것이 30~40개의 다른 도구를 보유하는 것보다 나은 이유를 설명하려면 어떻게 해야 합니까?

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

좋습니다. 좋은 질문입니다. 따라서 해당 질문에 답하기 위해 도구가 급증하는 이유에 대한 문제부터 시작해 보겠습니다. 따라서 전체 생태계, 전통적으로 일부 벤더를 살펴보면 상업용 벤더를 선택하면 특정 스트림에서 꽤 좋았습니다. 로그에 가면 Splunk를 떠올릴 수 있습니다. 측정항목을 생각하면 Datadog이 떠오릅니다. 그런 다음 Google과 전 세계의 모든 FANG 내부에서. 이러한 오픈 소스의 모든 움직임은 특히 Kubernetes의 출현과 함께 시작된 다음 Prometheus, OpenTelemetry 등과 같은 것들이 등장했습니다.

그리고 오픈 소스 기반 솔루션을 향해 나아가고 있는 전체적인 변화가 있습니다. 그것은 무엇을 의미합니까? 이는 개발자, 설계자, DevOps 직원이 관찰 가능성 데이터를 개방형 형식으로 수집하기를 원한다는 것을 의미합니다. 즉, 코드를 계측하기 위해 계측기를 선택하거나 데이터를 수집하기 위해 에이전트를 배치하더라도 100% 오픈 소스와 호환되어야 한다는 의미입니다. 그렇기 때문에 상업용 공급업체도 에이전트를 오픈 소스에 배치하기 시작했을 때 쿼리 측면에서는 전체 시각화, 대시보드, 경고 등 이러한 모든 기능을 오픈 소스 쿼리 언어로 구동하기를 원했습니다. 이것이 PromQL, LockQL, TraceQL, OpenTelemetry의 출현으로 이제 또 다른 오픈 소스 쿼리 언어를 시도하는 이유입니다.

 이제 당신은 많은 선택권이 있는 세상에 있습니다. 고객은 이미 특정 스트림, 특정 공급업체를 선택했습니다.

그런 다음 오픈 소스 움직임이 있고 다른 팀이 다른 인프라를 사용하고 있습니다. 일부는 Kubernetes를 기반으로 하고 일부는 서버리스를 기반으로 하며 일부는 ECS, Fargate 등을 기반으로 합니다. 따라서 이는 또 다른 차원을 추가하고 전체 제품 제공의 속도와 민첩성을 확보하기 위해 CI/CD가 이러한 교차점에서 발전하여 문제를 매우 신속하게 해결합니다. 그들은 뾰족한 해결책을 찾으려고 노력하고 결국 매우 뾰족한 해결책을 선택하게 됩니다. 그때 우리는 이상적인 관측 가능성 솔루션으로서 회사를 위한 관측 가능성 스택을 시작하려면 한 걸음 물러서서 MTTR 및 MTTD를 줄이려면 관측 가능성 데이터의 모든 최종 스트림을 수집해야 한다고 생각합니다. n 에 가나요? 여러 공급업체를 선택하고 n 선택 아니면 모든 스트림을 함께 모아서 이상값 감지, 이상치, 인과관계 등의 고급 기능을 상대적으로 쉽게 분석할 수 있는 관측 가능성 데이터 레이크로 이동해야 합니까? 이는 사내 데이터를 보존할 수 있는 데이터 레이크에 모든 것을 통합할 수 있는 이상적인 솔루션이 될 것입니다.

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

환상적입니다. 그리고 도구 확산에 드는 비용도 추가하고 싶습니다. 개발자가 자신만의 것을 구축하기를 원하고 많은 오픈 소스 도구도 혼합에 추가했지만 이는 부서 수준 구매이기도 하기 때문에 크게 동의합니다. 따라서 IT 부서에서는 반창고 솔루션을 구하고 이 도구를 기성품으로 구입하여 사용할 수 있기 때문에 이 문제를 해결할 수 있다고 생각합니다. 그리고 시간이 지나면서 그들은 무기고에 도구를 하나 더 추가했다는 사실을 깨달았고, 나무보다는 숲을 바라보고 있다는 사실을 깨닫지 못했습니다. 따라서 CIO 대화는 항상 흥미롭고 기업 전체에 걸쳐 보유하고 있는 도구 수를 압축하거나 줄이는 방법과 부서 전체, 애플리케이션, 인프라 컨테이너 등을 살펴보는 하나의 관찰 플랫폼을 갖는 방법에 대한 것입니다. 

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

물론입니다. 그래서 저는 이제 회사의 다른 페르소나도 동일한 데이터를 보고 있다는 점을 덧붙이려고 합니다. DevOps 개발자와 마찬가지로 설계자는 모두 인프라, 컨테이너화 애플리케이션 등과 관련된 관측 가능성 데이터를 살펴봅니다. 동일한 로그를 사용합니다. SecOps 직원은 보안과 위협을 찾기 위해 데이터를 분석하려고 합니다. 로그나 추적에서 나오는 유사한 데이터를 살펴봅니다. DataOps 담당자도 '이봐요, 내 데이터 작업이 얼마나 잘 되나요?'라고 말합니다. 이제 LLM의 출현으로 LLM Ops 직원도 비슷한 데이터를 보고 분석을 수행하고 있습니다. 따라서 또 다른 통합이 이루어져야 합니다. 이것이 제가 이상적인 관측 솔루션에서 찾는 것 중 하나입니다. 소위 동일한 데이터 레이크의 데이터를 활용할 수 있도록 조직의 다양한 페르소나를 어떻게 모두 불러올 수 있습니까?

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

우리 모두가 노력해 왔던 속담의 단일 유리창입니다. 그래서 그것은 좋은 일입니다. 그래서 MTTR 감소에 대한 이전 답변을 설명하실 때 간략하게 언급하신 내용을 하나 더 말씀드리고 싶습니다. 따라서 관찰 가능성의 주요 핵심은 문제 해결뿐만 아니라 MTTR을 줄여 경고 소음과 이러한 종류의 측정 항목도 줄이는 것입니다. 따라서 SRE와 IT Ops가 머리를 쪼개어 문제가 어디에 있는지 파악해야 하는 수고를 덜고 이 모든 것이 이 문제를 해결하기 위한 핵심 기본 요구 사항입니다. 발생하는 실시간 이벤트에 액세스해야 합니다. 특정 애플리케이션이나 특정 서버에 악의적인 활동이나 이와 유사한 로그가 입력된 경우 해당 이벤트에 즉시 액세스하여 해당 이상이 어디에 있는지, 인프라 전체에 무슨 일이 일어나고 있는지, 특정 메모리 스레드에서 이러한 특정 급증이 발생하는 이유 등을 이해할 수 있어야 합니다.

따라서 이를 파악해야 하며, 이를 위해서는 이 모든 것을 실시간으로 수집할 수 있는 능력도 필요합니다. 작년에 제가 가장 좋아하는 용어인 데이터 즉시성에 대해 이야기했는데, 여기서는 데이터 최신성이 가장 중요합니다. 이것이 바로 우리가 말하는 것입니다. 데이터가 얼마나 최신인지는 특정 문제를 얼마나 빨리 해결할 수 있는지 또는 관찰 가능성이라는 특정 맥락에서 발생하려고 하는 일을 피할 수 있는지 여부입니다. 특히 모니터링 중인 서버의 수백, 수천 개에 대해 이야기할 때, 또는 데이터를 가능한 한 최신 상태로 유지하는 데 문제가 있는 부분이 어디인지 정확히 알 수 있습니까? 섭취 메커니즘에 크게 의존합니까? 당신이 TEL과 다른 유형의 계측 기술 등에 대해 이야기했기 때문입니다. 그렇다면 실시간 데이터에 얼마나 빨리 액세스할 수 있는지에 대한 관점에서 다른 어떻게 생각하거나 살펴보시겠습니까?

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

좋습니다. 관찰팀의 또 다른 훌륭한 측면은 Danesh님의 말씀이 절대적으로 옳다는 것입니다. 따라서 관찰 데이터가 소비되는 핵심 차원은 데이터를 얼마나 빨리 가질 수 있는지, 데이터가 데이터 소스에서 떠나는 순간, 애플리케이션이든 인프라 구성 요소든 오픈 소스 구성 요소와 같은 플랫폼이든 상관없습니다. 이를 위해 지난 5~10년 동안 업계가 어떻게 발전했는지 살펴보면 실시간 스트리밍 서비스, 실시간 데이터베이스가 등장했습니다. 기존의 관측 솔루션을 살펴보면 기술이 상대적으로 오래되었기 때문에 이러한 기능을 활용할 수 없었다는 의미입니다. 따라서 실시간 스트리밍과 실시간 데이터베이스의 출현으로 가능한 한 빨리 데이터에 액세스할 수 있습니다. 따라서 이는 애플리케이션을 떠난 순간부터 쉽게 쿼리할 수 있을 때까지 데이터의 최신성을 측정하는 것입니다. 그게 모두 중요합니다.

그런 다음 '이봐, 내가 모든 데이터를 가지고 있어'라는 측면이 있습니다. 해당 데이터를 어떻게 분류합니까? 근본 원인을 파악하는 데 필요한 관련 패턴을 찾는 방법은 다음 문제 세트입니다. 즉, 데이터를 한 데이터에서 다른 데이터로 변환할 수 있어야 한다는 의미입니다. 안녕하세요, 일련의 로그를 받고 있습니다. 로그에서 측정항목을 빠르게 확인할 수 있나요? 일련의 범위를 얻고 있습니다. 해당 데이터를 분석하기 위해 해당 범위 또는 추적 내의 일부 속성을 볼 수 있습니까? 이러한 속성은 일반적으로 상호 연관되어 있으며 이것이 디버깅이 발생하는 방식이기 때문입니다. 이것이 바로 다음 차원입니다. 그리고 세 번째 차원은 고급 분석입니다. 해당 데이터 외에 흥미로운 통계 모델이나 대규모 언어 모델을 가져와 데이터를 분석하여 내 시스템에서 이상치라고 불리는 것을 찾아낼 수 있나요?

내 시스템에서 이상 징후를 찾을 수 있나요? 좋습니다. 데이터의 계절성 측면을 조사해도 될까요? 과거에 본 내용을 바탕으로 데이터를 예측할 수 있나요? 데이터의 계절적 측면? 그래서 이 모든 것이 제가 고급 분석 패키지라고 부르는 것입니다. 따라서 데이터의 신선함이 해결된 후 전체 솔루션을 생각할 때 데이터를 브릭 단위로 생각한 다음 각 브릭을 어떻게 조정하고 분석 기능을 설정할 수 있는지 생각해야 합니다. 그러면 우리가 해야 할 자연스러운 일은 '이봐, 내가 이것을 한 번 분석했는데 자동화할 수 있을까?'입니다. 그것은 전체에 대한 자연스러운 확장이 됩니다. 그래서 3C 문제와 함께 관찰 데이터를 어떻게 관찰, 분석, 자동화할 수 있는지 묻는 고객을 본 적이 있습니다.

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

아주 멋지다. 아주 멋지다. 그리고 응답의 일부로 마법의 단어인 LLM(대규모 언어 모델)에 대해서도 언급하셨습니다. 요즘에는 GenAI LLM에 관해 이야기하지 않고는 대화를 나눌 수 없다는 뜻입니다. LLM 관찰 가능성에 대해 확실히 물어볼 수 있기 때문에 언급해주셔서 기쁩니다. 어디에서나 LLM이 확산되고 사람들이 자신의 성과 등을 이해하는 데 어려움을 겪고 있다는 점을 감안할 때 갑자기 떠오르는 공간인 것 같습니다. 그것에 대해 알려주십시오. 클루퓨즈도 그 정면에 뭔가를 만들고 있는 것 같죠? 자세한 내용을 알려주세요.

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

내 말은, 네. 근본적으로 LLM 모델이 다양한 사용 사례에 배포되고 있다는 뜻이죠? 더 나은 단어가 부족합니다. 데이터 변화의 역동성은 특히 관찰 가능성의 세계에서 매우 역동적입니다. 특정 작업을 수행하는 데 적합한 LLM 모델을 구축하는 것은 항상 어렵습니다. 그래서 우리는 두 가지 측면에서 문제를 살펴보았습니다. DevOps, SecOps, DataOps 담당자 또는 LLMOps 담당자 등 제가 언급한 다양한 페르소나에 의해 소비되고 있는 기존 관찰 가능성 데이터 위에 특정 LLM 모델을 어떻게 활용할 수 있습니까? 그것이 그것의 한 측면입니다. 그리고 LLM이 매우 중요한 구성 요소인 응용 프로그램을 개발 중이라는 또 다른 측면이 있습니다. LLM에 공급되는 데이터를 생성하고 해당 LLM 모델에서 해당 데이터를 소비하는 많은 소비자가 있는 애플리케이션의 완전한 관찰 가능성을 어떻게 볼 수 있습니까?

그래서 우리는 실제로 LLM 모델을 사용하여 개발된 모든 애플리케이션에 대한 진정한 관찰 가능성이 무엇인지 생각해 본 최초의 사람이라고 말할 수 있습니다. 드리프트와 같은 모델 관측 가능성을 살펴보는 것만으로도 많은 솔루션을 발견했기 때문입니다. 그러나 우리는 끝에서 끝까지 찾고 있습니다. 많은 인프라 애플리케이션 관찰 가능성이 모델 관찰 가능성 및 기타 사항과 함께 진행되기 때문에 이는 매우 흥미로운 측면입니다. 그리고 마지막으로, CIO나 CFO에게 가서 현재 솔루션과 마찬가지로 LLM 비용을 물어보면 비용이 또 다른 핵심 차원입니다. 해당 비용을 유지하는 방법이나 LLM 모델 자체의 비용 측정 항목에 대한 분석을 제공하는 방법도 또 다른 측면입니다. 따라서 성능, 부족함, LLM 지원을 위한 APM, 그리고 비용 등 모든 것을 조사해야 합니다. 이것이 여러분이 볼 수 있는 일반적인 치수입니다.

디네시 찬드라세카르

매우 멋지고 흥미진진한 공간이며 앞으로 몇 달 안에 그 공간에서 어떤 일이 일어날지 배울 수 있어 정말 기대됩니다. 정말 고마워요, 크리슈나. 이것은 매우 매우 훌륭한 대화였습니다. 우리 쇼에 당신을 초대해서 좋았습니다. 관찰 가능성에 대해 이야기하는 것을 좋아합니다. 세 가지 C인 카디널리티, 제어, 비용을 기억하겠습니다. 저는 이것이 관찰 가능성을 살펴보는 좋은 방법이자 훌륭한 진언이라고 생각합니다. 모든 통찰력에 감사드립니다. 당신이 여기 있어주셔서 감사합니다. 감사합니다.

크리슈나 야다파나바르

고마워요, 디네쉬. 웹 채팅에 초대해 주셔서 감사합니다.