가동 시간에서 경험으로: 현대 관측성의 AI 주도 전환

2001년, IBM은 자율 IT 선언문을 발표했습니다. 자율 컴퓨팅의 비전은 자체 관리(자체 최적화, 자체 치유, 자체 구성, 자체 보호)를 네 가지 기둥으로 나누었습니다. IBM이 이 IT 비전을 제시했을 때 저는 Microsoft에 있었습니다. 우리는 자율 데이터 센터와 같은 기술 아이디어를 제안했지만, 결국 그 비전은 시대를 앞선 꿈에 불과했습니다. 그 비전을 현실화할 실용적인 방법은 없었습니다.

Microsoft에 재직하던 시절, 저는 Clippy 팀에 있었습니다. 애니메이션 클립 보조 도우미가 악명 높게 방해가 되었음에도 그 아이디어는 타당했습니다: 컴퓨터는 인간이 업무를 수행하도록 적극적으로 도와야 합니다. 당시 우리는 이를 실현할 만큼의 계산 능력과 AI가 없었습니다. 25년이 지난 지금, 우리는 드디어 이를 구현했습니다.

서비스 수준에서 경험 수준으로

관측성 개념은 IT에서 시작된 것이 아닙니다. 1960년, 헝가리계 미국인 엔지니어이자 수학자인 Rudolf E. Kálmán 제시했다는 “관측성”이라는 용어를 시스템이 출력으로 얼마나 잘 측정될 수 있는지를 설명하기 위해 만들었습니다. 그리고 2013년에, Twitter는 그 용어를 채택했다는 일련의 블로그 게시물을 통해, 기존의 상용 도구들을 이용한 구식 모니터링은 다른 시대의 기술을 위해 설계된 것이며 마이크로서비스 규모 아키텍처에서는 작동하지 않는다고 효과적으로 말했습니다.

의사를 떠올려 보세요. 의사는 환자의 맥박을 확인하고, 혈압을 측정하며, 기타 외부 특징을 관찰함으로써 환자의 내부 건강 상태를 간접적으로 평가합니다. IT에서도 우리는 같은 방식을 적용해야 합니다. 환자의 맥박에 미세한 변동이 있을 때, 그것이 신장에 문제가 있는지 간에 문제가 있는지를 파악해야 합니다. Twitter가 20년 전에도 다루던 규모와 복잡성(당시 이 회사는 실시간 트윗과 피드로 1억 명의 사용자에게 서비스를 제공하고 있었습니다)에서는 관측성을 위해 다른 도구와 모니터링 접근 방식이 필요했습니다.

오늘날 시스템은 더욱 규모가 커지고 복잡해졌으며, 전 세계에 걸쳐 콘텐츠 전송 네트워크, 캐시 및 비트맵 배포, 폰트, JavaScript 파일 등에 의존하고 있습니다. 실제 애플리케이션의 성능을 진정으로 이해하는 일은 결코 쉬운 일이 아닙니다.

IT 팀이 새벽 4시에 페이지를 받으면, 누군가가 침대에서 일어나서 문제가 하드 드라이브의 불량 섹터 때문인지, 아니면 인프라를 침투해 혼란을 일으키려는 악의적인 행위자 때문인지 파악해야 합니다. 어느 쪽이든 결국 그들의 업무는 모든 시스템을 정상 가동 상태로 유지하는 것입니다. 다행히도 오늘날 애플리케이션 상태를 평가하기 위해서는 모든 가용 텔레메트리를 활용할 수 있습니다: 모든 네트워크 장치, 모든 애플리케이션, 수천 개의 기본 제공 통합, JIRA 또는 Atlassian을 통한 티켓 흐름, 그리고 수많은 다른 신호들.

여기서 경험 수준 목표(XLOs)가 등장합니다. 서비스 수준 계약(SLAs)과 서비스 수준 목표(SLOs)를 들어보셨을 것이지만, XLO는 고객과 직원이 원하는 경험 수준을 제공받고 있는지를 측정함으로써 한 단계 더 나아갑니다. 이는 가동 시간만이 아니라 품질에 관한 것입니다. 기술적인 관점에서 XLO를 달성하는 유일한 방법은 NIC부터 최종 사용자 장치까지의 가시성을 확보하는 것입니다.

지난 10월, AWS US‑EAST‑1 중단되었습니다. Catchpoint는 Amazon이 공식적으로 인지하기 16분 전에 문제를 감지했습니다. 해당 가시성을 가진 고객들은 사용자들이 장애의 영향을 체감하기 전에 대응할 수 있었습니다.

관측성의 약속은 스모키 베어와 같습니다: 불이 나기 전에 연기가 있는 곳을 감지합니다. 제대로 구현하면 관측성은 캘리포니아 파리세이즈의 팔리세이즈를 집어삼킬 정도의 대형 화재가 되기 전에 초원 불꽃을 끌 수 있게 해줍니다. 스모키는 AWS 문제이든, Oracle 문제이든, GCP 문제이든, Microsoft Azure 문제이든, 인프라의 어떤 이상이든 관계없이 작은 연기 냄새를 감지할 수 있는 조기 경보 시스템입니다.

AI가 보안 시스템을 확장한다

오늘날의 인프라 시스템을 인간 운영자가 모두 파악하기는 불가능합니다. 페타바이트 규모의 로그 데이터와 하루 수조 건의 메트릭을 수집해 대규모로 시스템을 모니터링하는 유일한 방법은 AI를 활용하는 것입니다.

예를 들어 디스크의 읽기/쓰기 성능이나 네트워크 환경 내 입력/출력 혹은 패킷 버퍼 오버런을 추적하고 싶다고 가정해 보세요. 동적 임계값을 사용해 정상적인 모습을 정의하거나, 지난 주, 월, 연도 혹은 원하는 기간의 시계열 데이터를 분석해 정상 성능 임계값을 설정할 수 있습니다. 이러한 통계 분석을 수행하면 평균으로부터 두 표준편차 범위 수준을 설정할 수 있어, 해당 범위를 벗어나는 상황이 발생하면 성능이 비정상일 가능성이 있다는 알림을 받게 됩니다.

하지만 매우 복잡한 시스템은 하루에 수천 개의 알림을 받을 수 있습니다. 대시보드가 깜빡이고, 사람들에게 페이지가 전송됩니다. 이러한 모든 알림을 일일이 검토하는 것은 인간의 시간을 효율적으로 활용하는 방법이 아닙니다. 실제로 Vectra는 추정한다는 바에 따르면 조직은 하루 평균 2,992개의 보안 알림을 받으며, 그 중 63%가 처리되지 않은 채 남아 있습니다.

AI 도구는 하루에 수천 건의 알림을 단 몇 십 개로 줄일 수 있습니다. 저는 한 번, 단일 머신의 단일 NIC에서 발생한 하나의 문제가 2,000개의 하위 알림을 일으킨 사례를 기억합니다. AI 덕분에 고객은 알림 상관관계를 수행하고 훨씬 빠른 근본 원인 분석을 할 수 있었으며, 그 결과 특정 시점의 하나의 문제가 회사 전체 대시보드가 빨갛게 표시되는 원인이라는 결론에 이르렀습니다.

AI가 IT를 다시 흥미롭게 만들다

2023년 Cisco가 Splunk를 인수한 후 잠시 쉬었습니다. 그 후 2년 동안, 친구들과 전 동료들이 5년 전에는 불가능했던 방식으로 AI를 활용하는 회사를 설립하는 모습을 지켜보았습니다. (ChatGPT를 인간 아이에 비유한다면, 현재 3세 정도가 된다고 기억하세요).

IT 팀은 경보가 울리기 전에 연기를 감지할 수 있는 도움이 필요할 뿐, 바라볼 대시보드를 더 늘릴 필요는 없습니다. 그들. 어느 정도 이 문제는 IBM, Twitter, 그리고 Clippy를 가진 Microsoft까지도 해결하려고 노력해 온 문제와 동일합니다.

이것이 제가 다시 뛰어들기로 결심한 이유입니다. 기술이 마침내 관측성 및 자율 IT라는 원래 약속을 실현할 수 있는 단계에 이르렀습니다.