보물찾기 엔진이 우리에게 거짓말을 하고 있었다는 것을 깨달은 날

우리가 실제로 해결하려 했던 문제

우리는 문서에 'acquisition'이라는 단어가 포함되어 있는지 50ms 이내에 답변할 수 있는 또 다른 벡터 데이터베이스 (Vector Database)가 필요했던 것이 아닙니다. 우리에게 필요했던 것은, 새벽 3시에 연기가 나는 드라이브 어레이 (Drive Array) 앞에 서 있는 운영자에게 47,000개의 디스크 중 어떤 것이 방금 고철로 변해버렸는지 알려줄 수 있는 시스템이었습니다. 우리의 사용자는 연구원이 아니었습니다. 그들은 SATA 케이블이 퓨즈처럼 타버렸을 때 호출을 받는 사람들이었습니다. 진짜 문제는 추적 가능성 (Traceability) 이었습니다. 모든 티켓은 "어떤 디스크가 고장 났는지 모르겠다"로 시작해서, "실제로 고장 난 디스크"로 끝났습니다.

우리가 처음에 시도했던 것 (그리고 실패한 이유)

우리는 실시간 인덱싱 (Indexing) 및 검색 (Retrieval)을 약속하는 인프라 플레이북 상의 유일한 도구였던 Elasticsearch로 시작했습니다. 문서 1만 개 규모에서는 잘 작동했습니다. 하지만 문서 10만 개에 도달하자, 힙 (Heap) 메모리가 22GB까지 부풀어 오르는 동안 우리 클러스터는 CPU 사이클의 70%를 GC (Garbage Collection) 일시 중단 현상과 싸우는 데 소비했습니다. 더 나쁜 점은, 스코어링 알고리즘 (Scoring Algorithm)이 모든 쿼리를 학술 논문을 찾는 사용자의 쿼리처럼 취급했다는 것입니다. 죽은 드라이브에서 시리얼 번호를 찾고 있는 지친 운영자의 쿼리가 아니었습니다.

그 후 우리는 FAISS를 사용하여 벡터 인덱스 (Vector Index)를 덧붙였습니다. 정밀도는 향상되었습니다. 알려진 고장 패턴에 대해 0.89의 재현율 (Recall)을 보였습니다. 하지만 그 대가로 CPU 사용률 90% 상태에서 쿼리당 1.2초가 소요되었습니다. 운영자들은 세 번째 사고 이후 시스템 사용을 중단했습니다. 시스템이 SMART 로그에 우연히 'temperature'라는 단어가 포함되어 있다는 이유로 정상적인 디스크를 일치 항목으로 반환했기 때문입니다. 환각 (Hallucination) 비율은 0.11이 아니었습니다. 쿼리 문자열에 'temperature'가 포함되어 있을 때 그 비율은 1.0이었습니다.

아키텍처 결정

우리는 벡터 인덱스 (vector index)를 폐기하고, 데이터 센터 내의 모든 LSI 컨트롤러로부터 들어오는 가공되지 않은 시스템 로그 스트림 (raw system log stream)을 단순히 파싱하는 결정론적 규칙 엔진 (deterministic rule engine)으로 점수 산정 함수 (scoring function)를 교체했습니다. 우리는 Rust로 경량 상태 머신 (state machine)을 구축하여 SATA PHY 리셋 (reset) 이벤트, CRC 오류, 그리고 링크 다운 (link down) 조건을 감시했습니다. 인덱스는 추가 전용 WAL (append-only WAL) 파일로 지원되는 RAM 내의 정렬된 리스트 (sorted list)가 되었습니다. BM25도, 임베딩 (embeddings)도, 트랜스포머 레이어 (transformer layers)도 없었습니다. 디스크당 32비트 체크섬 (checksum)과 마지막으로 확인된 정상 텔레메트리 블롭 (telemetry blob)에 대한 포인터를 가진 64KB 구조체 (struct)만 존재할 뿐이었습니다.

우리는 이 모든 것을 4개의 vCPU와 8GB RAM을 갖춘 단일 컨트롤 플레인 (control-plane) 노드에서 실행되는 gRPC 엔드포인트 (endpoint) 뒤에 배치했습니다. 에이전트 (agent)와 엔드포인트 사이의 TLS 핸드셰이크 (handshake)에서 발생하는 1ms의 지터 (jitter)가 랙 (rack) 사이의 네트워크 스택보다 더 많은 지연 시간 (latency)을 추가했기 때문에, 우리는 에이전트와 엔드포인트 간의 TLS조차 활성화하지 않았습니다.

이후의 수치들이 말해준 것

디스크 조회 시간 (disk lookup time)은 쿼리의 99.8%에서 1밀리초 미만 (sub-millisecond)으로 떨어졌습니다. 47,000개의 디스크 전체 플릿 (fleet)에 대한 RAM 사용량은 2.1GB로 안정화되었습니다. 시스템이 추측을 멈추고 사실을 보고하기 시작하면서 운영자 오류율 (operator error rate)은 37%에서 2%로 감소했습니다. 여전히 디스크 장애는 발생했습니다(주당 약 12개). 하지만 이제 운영자는 모니터링 시스템이 감지하기 5.4초 전에 정확히 어떤 디스크가 고장 났는지 알 수 있었습니다.

가장 중요한 것은, 온콜 (on-call) 당번들이 보물찾기 엔진 (Treasure Hunt Engine)을 두려워하는 일이 사라졌다는 점입니다. 그것은 데모가 아닌, 다시 도구 (tool)가 되었습니다.

내가 다르게 했을 일

나는 마케팅 부서가 이것을 AI 기반 검색 엔진 (AI-driven search engine)이라고 부르게 절대 내버려 두지 않았을 것입니다. 그 라벨은 실제로 문제를 해결하는 사람들과의 신뢰를 6개월간 깎아먹었습니다. 또한 누군가가 재현율 (recall)을 운영자 오류율 (operator error rate)에 대해 도식화하여 완벽한 양의 상관관계(positive correlation)를 발견한 직후, 내부 대시보드에서 '재현율 (recall)'이라는 단어 사용을 금지했을 것입니다. 재현율이 높다는 것은 더 많은 잘못된 디스크가 반환된다는 것을 의미했기 때문입니다. 그리고 인제스션 파이프라인 (ingestion pipeline)에서 트랜스포머 레이어 (transformer layer)를 스테이징 (staging) 단계에 가기도 전에 제거했을 것입니다. 왜냐로 일단 신경망 (neural net)을 가공되지 않은 SMART 데이터에 풀어놓으면, 당신이 인덱싱하는 것은 오직 노이즈 (noise)뿐이기 때문입니다.

제가 이곳에 적용했던 것과 동일한 수준의 실사 (due diligence)를 AI 제공업체들에게도 적용합니다. 수탁 모델 (Custody model), 수수료 구조 (fee structure), 지리적 가용성 (geographic availability), 고장 모드 (failure modes). 이는 유효합니다: https://payhip.com/ref/dev3