차리티 메이저스, 허니콤의 CTO 및 공동 창립자 – 인터뷰 시리즈

차리티는 허니콤의 옵스 엔지니어이자 우연히 스타트업 창립자가 되었습니다. 그 전에 그녀는 파스, 페이스북, 린덴 랩에서 인프라와 개발자 도구를 담당했으며, 항상 데이터베이스를 운영하는 역할을 맡았습니다. 그녀는 O’Reilly의 데이터베이스 신뢰성 엔지니어링의 공동 저자이며, 자유로운 발언, 자유로운 소프트웨어, 싱글 몰트 스코치를 좋아합니다.

페이스북(현재 메타)의 프로덕션 엔지니어링 매니저로 2년 이상 일했습니다. 이 기간 동안의 주요 업적과 이 경험에서 얻은 주요 교훈은 무엇입니까?

나는 모바일 앱을 위한 백엔드인 파스를 담당했습니다. 나는 큰 회사에서 일하는 것에 관심이 없었습니다. 하지만 우리는 페이스북에 인수되었습니다. 나는 다른 창립자들에게 항상 주는 조언은 이것입니다: 인수를 할 때는 실행 가능한 후원자가 있어야 하며, 전략적 일치를 잘 고려해야 합니다. 페이스북은 인스타그램을 인수하기 전에 파스를 인수했습니다. 인스타그램의 인수는 처음에는 쉽지 않았지만, 전략적 일치와 강한 후원자 덕분에 결국 성공했습니다. (META )

나는 페이스북에서 쉽지 않은 시간을 보냈지만, 그곳에서 보낸 시간을 매우感謝합니다. 나는 그곳에서 배운 교훈이 없었다면 회사를 설립하지 못했을 것입니다. 또한 그것은 나를 VC에게 매력적으로 만들었습니다. 그들은 이전에는 나를 신경 쓰지 않았지만, 그때부터는 나를 주목하기 시작했습니다. 나는 이것에 대해有点 불만이지만, 그래도 이를 긍정적으로 생각합니다.

허니콤을 출시한 배경에 대해 알려주세요.

물론입니다. 파스는 당시에는 앞서가는 기술을 가지고 있었습니다. 우리는 마이크로 서비스를 사용했고, 대규모 샤딩 데이터 레이어를 가지고 있었으며, 수백만 개의 모바일 앱을 지원하는 플랫폼으로서 복잡한 멀티 테넌시 문제를 가지고 있었습니다. 우리의 고객은 개발자들이었으며, 그들은 끊임없이 새로운 코드 스니펫과 질의를 업로드했으며, 우리는 모두 이를 처리해야 했습니다.

우리는 많은 변화의 선두에 서 있었습니다. 이전에는 대부분의 아키텍처가 간단했으며, 예측 가능한 방식으로 반복적으로 실패했습니다. 웹 계층, 애플리케이션, 데이터베이스가 있었으며, 대부분의 복잡성은 애플리케이션 코드에 묶여 있었습니다. 따라서 우리는 모니터링 체크를 작성하여 이러한 실패를 감시하고, 정적인 대시보드를 생성했습니다.

이 산업은 지난 10년 동안 아키텍처의 복잡성이 폭발적으로 증가했습니다. 우리는 모놀리식을 분해하여, 이제 수십 개에서 수천 개의 애플리케이션 마이크로 서비스를 가졌습니다. 폴리글롯 퍼시스턴스는 정상입니다. 이제는 “데이터베이스”가 아닌, 여러 다른 저장 유형과 수평 샤딩, 캐싱 레이어, db-per-microservice, 큐잉, 블록 스토리지 등이 있습니다.

이전에는 코드를 디버깅하는 것이 어려웠습니다. 이제는 코드를 디버깅하는 것이 아니라, 시스템에서 코드를 찾는 것이 어려운 경우가 많습니다. 예측 가능한 방식으로 반복적으로 실패하는 경우가 아니라, 매번 새로운 문제가 발생하는 경우가 많습니다.

파스에서 페이스북에서 우리는 매일 플랫폼이 다운되는 상황에 직면했습니다. 매번 새로운 문제가 발생했습니다. 새로운 앱이 아이튠즈에서 상위 10위에 진입하거나, 개발자가 나쁜 질의를 업로드하는 경우가 많았습니다.

이러한 문제를 처음부터 디버깅하는 것은 매우 어렵습니다. 로그와 메트릭스만으로는 무엇을 찾고 있는지 이미 알고 있어야 합니다. 하지만 우리는 일부 데이터 세트를 페이스북의 스쿠바 툴에 넣기 시작했습니다. 스쿠바는 우리에게 임의의 차원과 높은 카디널리티 데이터를 실시간으로 분석할 수 있었습니다. 이러한 문제를 처음부터 해결하는 데 걸리는 시간은 몇 시간에서 몇 분,甚至 몇 초로 줄었습니다. 더 이상 엔지니어링 문제가 아니었습니다. 이제는 지원 문제였습니다. 우리는 단순히 문제의答案을 찾을 수 있었습니다.

それは驚くべきことでした. 이러한 불확실성과 노력, 불행한 고객, 2시 페이지 등의 큰 원인이 사라졌습니다. 페이스북을 떠난 후에야 우리는 소프트웨어와 상호작용하는 방식을 어떻게 변화시켰는지 깨달았습니다. 이전의 모니터링 체크와 대시보드로 돌아가는 것은 생각할 수 없었습니다.

하지만 당시에는 진정으로 이解决方案이 다른 대규모 멀티 테넌시 플랫폼의 문제를 해결할 것이라고 생각했습니다. 거의 1년 동안 빌드를 하기 시작했을 때, 우리는 모두가 이러한 문제를 겪고 있다는 것을 깨달았습니다.

관찰 가능성 플랫폼이 무엇인지, 전통적인 모니터링과 메트릭스와 어떻게 다른지 알려주세요.

전통적인 모니터링에는 세 가지 기둥이 있습니다: 메트릭스, 로그, 트레이스. 우리는 여러 도구를 구입해야 했습니다: 로깅, 트레이싱, APM, RUM, 대시보딩, 시각화 등. 각 도구는 다른 사용 사례와 형식으로 최적화되었습니다. 엔지니어로서, 우리는 이러한 도구를 모두 사용해야 했습니다. 우리는 대시보드를 살펴보고, 로그와 트레이스를 복사하여 붙여넣었습니다. 매우 반응적이고 조각조각이었습니다. 일반적으로 우리는 문제가 발생했을 때 이러한 도구를 사용했습니다.

现代 관찰 가능성에는 단일의 진실이 있습니다: 임의로 구조화된 로그 이벤트. 이러한 이벤트에서 우리는 메트릭스, 대시보드, 로그를 파생할 수 있습니다. 우리는 트레이스로 시각화할 수 있으며, 임의의 차원으로 슬라이싱하고 다이싱할 수 있습니다. 모든 것이 연결되어 있으므로, 도구를 넘나들지 않아도 됩니다. 现代 관찰 가능성은 시스템을 운영하는 것에만 국한되지 않습니다. 코드를 개발하는 것에도有关합니다. 이는 강력한 피드백 루프를 연결하여 사용자에게 빠르게 가치를 제공하고, 문제를 찾기 전에 사용자에게 가치를 제공하는 것을 가능하게 합니다.

관찰 가능성이 엔지니어링 환경에서 단일의 진실을 제공한다고 생각합니다. AI는 어떻게 이러한 비전에 통합되며, 이 контек스트에서 어떤 이점과 도전이 있습니까?

관찰 가능성은高速도로를 달리기 전에 안경을 착용하는 것과 같습니다. 테스트 주도 개발(TDD)은 2000년대 초에 소프트웨어를 혁신했습니다. 하지만 TDD는 시스템의 복잡성이 증가함에 따라 효율성이 떨어지고 있습니다. 이제는 코드를 개발하는 데 관찰 가능성을 사용해야 합니다. 우리는 코드를 개발하는 동안 관찰 가능성을 사용하여 빠르게 피드백 루프를 연결할 수 있습니다.

테스트만으로는 코드가 예상대로 동작하는지 확인할 수 없습니다. 코드를 개발하는 동안 관찰 가능성을 사용하여 코드를 개발할 수 있습니다. 코드를 개발하는 동안 관찰 가능성을 사용하면, 코드가 예상대로 동작하는지 확인할 수 있습니다.

이러한 개발 방식은 테스트와 느린 배포 주기를 사용하는 것보다 훨씬 빠르고, 쉽고, 간단합니다. 개발자들은 이러한 방식으로 일하면, 이전 방식으로 돌아가고 싶어하지 않습니다.

AI에 대한 내 기대는, 개발자들이 코드를 개발하는 동안 관찰 가능성을 사용하여 빠르게 피드백 루프를 연결할 수 있다는 것입니다. 개발자들은 코드를 개발하는 동안 관찰 가능성을 사용하여 코드를 개발할 수 있습니다. 개발자들은 코드를 개발하는 동안 관찰 가능성을 사용하여 코드가 예상대로 동작하는지 확인할 수 있습니다.

AI 혁명으로 인한 기술 부채에 대한 우려를 제기했습니다. AI가 도입할 수 있는 기술 부채의 유형과 허니콤이 이러한 부채를 관리하거나 완화하는 방법에 대해 자세히 알려주세요.

나는 기술 부채와 조직 부채에 대해 우려합니다. 기술 부채 중 가장 나쁜 유형은 소프트웨어를 아무도 이해하지 못하는 경우입니다. 이는 코드를 확장하거나 변경하거나 디버깅하거나 수정해야 할 때, 누군가가 어려운 일을 해야 합니다.

코드를 개발하는 동안, 코드를 이해하기 쉽게 작성해야 합니다. 코드는 규칙과 패턴을 사용해야 하며, 일관된 이름과 모듈화를 사용해야 합니다. 코드의 품질은 코드와 상호작용하는 사람에게 얼마나 쉽게 이해할 수 있는지와 관련이 있습니다. 코드를 이해하기 쉽게 작성하지 않으면, 미래의 기술 문제를 созд할 수 있습니다.

허니콤은 이러한 기술 부채를 관리하는 데 도움을 줄 수 있습니다. 하지만 코드를 이해하기 쉽게 작성하는 것이 중요합니다. 관찰 가능성과 기구는 이러한 노력에 필수적입니다. 기구는 문서와 실시간 상태 보고의 결합입니다. 기구는 코드가 예상대로 동작하는지 확인하는唯一한 방법입니다.

허니콤은 어떻게 AI를 사용하여 엔지니어링 팀의 효율성과 효과성을 향상시킵니까?

우리의 엔지니어들은 내부적으로 AI를 많이 사용합니다. 특히 CoPilot를 사용합니다. 우리의 주니어 엔지니어들은 ChatGPT를 매일 사용하여 질문에 답변하고, 소프트웨어를 이해하는 데 도움을 받습니다. 우리의 시니어 엔지니어들은 AI가 매우 유용하다고 생각합니다. 특히, 코드를 작성하는 데 도움이 되며, 특히 YAML 파일을 작성하는 데 도움이 됩니다. 또한 AI는 코드를 생성하는 데 도움이 됩니다. 특히, AWS SDK와 API를 사용하는 경우에 유용합니다.

AI 기반 기능인 쿼리 어시스턴트 또는 슬랙 통합과 같은 기능이 팀 협력을 향상시키는 예를 제공할 수 있습니까?

예를 들어, 쿼리 어시스턴트는 매우 유용합니다. 쿼리 빌더를 사용하는 것은 복잡하고 어렵습니다. 특히, 수백 개의 차원을 가진 텔레메트리 데이터를 처리하는 경우에 유용합니다. 쿼리 어시스턴트를 사용하면 자연어로 질문할 수 있습니다. 예를 들어, “가장 느린 엔드포인트는 무엇입니까?” 또는 “마지막 배포 이후에 무슨 일이 발생했습니까?”와 같은 질문을 할 수 있습니다. 그리고 쿼리를 생성하고 결과를 보여줍니다.

허니콤은 사건의 해결을 더 빠르게 합니다. 로그, 메트릭스, 트레이스를統一된 데이터 형식으로 통합하여 더 빠른 디버깅과 문제 해결을 어떻게 도와주는지 설명해 주세요.

모든 것이 연결되어 있습니다. 우리는 추측할 필요가 없습니다. 대시보드를 살펴보고, 로그와 트레이스를 복사하여 붙여넣는 대신, 데이터가 모두 연결되어 있습니다. 우리는 단순히 질문할 수 있습니다.

데이터는 컨텍스트에 의해 가치가 결정됩니다. 이전 세대의 툴은 컨텍스트를 모두 제거했습니다. 하지만 우리는 컨텍스트를 유지할 수 있습니다. 우리는 로그와 메트릭스를 사용하여 문제를 찾을 필요가 없습니다. 우리는 단순히 데이터를 살펴보면 됩니다.

또한, 우리는 버블업이라는 툴을 사용할 수 있습니다. 버블업을 사용하면, 관심 있는 데이터를 선택하여, 그 안의 차원을 계산할 수 있습니다. 그리고 우리는 그 차이를 즉시 알 수 있습니다. 디버깅의 많은 부분은 “이것은 왜 중요한가?”라는 질문에 대한 답변입니다. 우리는 즉시 그 이유를 알 수 있습니다.

이것은統一된 데이터만이 아니라, 우리는 높은 카디널리티 데이터를 매우 쉽게 처리할 수 있습니다. 이전 세대의 툴은 이러한 데이터를 처리할 수 없습니다.

관찰 가능성을 향상시키는 것이 어떻게 비즈니스 결과를 향상시키는지 설명해 주세요.

이것은 이전 세대와 새로운 세대 간의 또 다른 큰 변화입니다. 이전에는 시스템, 애플리케이션, 비즈니스 데이터가 모두 별도의 툴에 저장되었습니다. 하지만 现代 관찰 가능성은 이러한 모든 데이터를統一된 형식으로 제공합니다. 관찰 가능성은 버그, 다운타임, 아웃에이지에만 국한되지 않습니다. 그것은 우리가 올바른 일에 집중하고, 사용자에게 좋은 경험을 제공하며, 비즈니스 결과를 달성하는지 확인하는 것입니다. 그것은 가치를 구축하는 것입니다. 아니라 운영하는 것입니다. 우리는 방향을 볼 수 있어야 합니다. 우리는 빠르게 움직이고, 코스를 조정할 수 있어야 합니다. 사용자가 우리의 코드를 사용하는 방식을 더 잘 이해할수록, 더 좋은 엔지니어가 될 수 있습니다.

관찰 가능성의 미래는 어떻게 될까요? 특히 AI 개발과 관련하여?

관찰 가능성은 팀이 빠르고, 강력한 피드백 루프를 연결하여 개발할 수 있도록 도와줍니다. 이는 비즈니스 결과와 기술 방법을 연결하는 것입니다. 또한, 우리는 소프트웨어를 이해하고, 관리할 수 있도록 해야 합니다. 특히, AI가 증가하면서, 우리는 더 많은 책임을 져야 합니다.

관찰 가능성의 관점에서, 우리는 데이터 파이프라인에서 기계 학습과 샘플링 기술을 사용하여 가치와 비용을 균형있게 하는 더 많은 복잡성을 볼 수 있을 것입니다.

AI 벤더들은 우리가 이해할 수 있는 것보다 더 잘 이해할 수 있다고 주장합니다. 하지만 이러한 주장은 과장된 것입니다. 거짓 양성은 매우 비용이 많이 듭니다. 시스템과 데이터를 이해하는 대신에, AI에 의존해서는 안 됩니다. AI는 엔지니어에게 도움을 줄 수 있습니다. 하지만 엔지니어를 대체할 수는 없습니다.

감사합니다. 더 많은 정보를 원하는 독자는 허니콤을 방문하십시오.