모든 블록체인에 전용 온콜 에이전트를 배치했습니다

Alchemy가 230개 이상의 에이전트로 노드 플릿 전체의 알림을 분류하고 수정하는 방법

Alchemy는 230개 이상의 블록체인 네트워크 인프라를 운영하며, 매년 1조 달러 이상의 거래를 처리하는 수천 대의 서버를 운영합니다. 모든 노드를 정상 상태로, 그리고 동기화된 상태로 유지해 이에 의존하는 애플리케이션이 계속 작동하도록 하는 것이 저희의 비즈니스입니다.

지난 4개월 동안 저희는 인시던트를 조사하고 해결하기 위해, 블록체인 네트워크마다 하나씩 230개 이상의 개별 에이전트를 관리하는 에이전트 팩토리를 구축했습니다. 알림 해결 시간 중앙값은 이제 8분으로, 사람이 처리하던 30분에서 줄었습니다. 에이전트는 알림의 약 73%를 사람의 개입 없이 해결하며, 매달 약 120시간의 엔지니어링 시간이 문제 진단과 수정 대신 더 생산적인 작업에 쓰이고 있습니다.

문제: 다양한 인프라 전반에서 주당 500건의 알림

저희 노드 플릿은 Node Ops 팀에 주당 500건 이상의 알림을 발생시킵니다. 다른 소프트웨어 엔지니어링 팀과 마찬가지로, 온콜 엔지니어는 모든 알림을 동일한 다섯 가지 질문으로 조사합니다.

1. 어떤 네트워크인가?
2. 고객이 영향을 받고 있는가?
3. 문제가 저희 플릿에 있는가, 아니면 네트워크 자체의 업스트림에 있는가? 배포 때문인가?
4. 이전에도 발생한 적이 있는가?
5. 다음에 무엇을 해야 하는가?

답은 대시보드, 요청 로그, 알림 시스템, 배포 기록, 과거 포스트모템에 흩어져 있습니다. 여기에 500건의 알림과 각 네트워크의 고유한 특성을 곱하면, 원인을 제거하는 대신 컨텍스트를 다시 구성하고 문제를 복구하는 데 상당한 시간이 듭니다.

설계 규칙: 결정에 최적화한다

모든 도구에 접근할 수 있는 에이전트는 그 모두를 읽으려 합니다. 그 결과 엔지니어가 여전히 파고들어야 하는 긴 보고서가 나옵니다. 엔지니어에게 필요한 것은 더 많은 데이터가 아닙니다. 필요한 것은 결정입니다. 이 알림에 사람이 필요한가, 그리고 얼마나 빨리 필요한가?

그래서 저희에게는 규칙이 하나 있습니다. 결정에 최적화한다.

작동 방식

1. 사람을 호출하기 전에 영향을 파악한다

저희 알림 시스템은 이미 주당 500회 이상 문제를 감지합니다. 에이전트가 이를 다시 감지할 필요는 없습니다. 에이전트의 역할은 누군가 신경 써야 하는지를 결정하는 것입니다.

발생한 알림이 자동으로 인시던트가 되지는 않습니다. 알림은 에이전트가 고객 대상 서버 오류, 지연 시간의 상당한 증가, 플릿 내 모든 노드 다운과 같은 실제 피해의 증거를 발견한 경우에만 인시던트가 됩니다.

피해를 발견하지 못하면 에이전트는 조사 결과를 별도의 "FYI" 채널에 게시합니다. 실제 인시던트만 온콜 채널에 전달됩니다.

2. 판정이 있는 조사

에이전트는 3~5개의 글머리 기호를 게시하며, 결론은 두 가지 중 하나입니다. 사람이 필요하지 않으면 에이전트가 알림을 직접 해결합니다. 사람이 필요하면 더 자세한 조사 결과를 온콜 채널에 게시합니다.

실제 사례 다섯 가지:

엔지니어는 결과를 먼저 읽고, 필요한 경우에만 증거를 읽습니다.

3. 코드가 강제하는 한도 내에서 조치한다

앞서 설명했듯이 해결은 사람 없이 이루어지는 경우가 많습니다. 저희는 에이전트에게 서비스를 복구하기 위해 비정상 노드를 재시작하는 기능과, 노드 설정이 예상과 더 이상 일치하지 않을 때 설정 드리프트를 표시하는 기능을 부여했습니다.

각 조치의 범위는 좁으며, 서버 코드가 이를 강제합니다. 에이전트는 다음을 할 수 있습니다.

• 네트워크당 한 번에 정확히 하나의 노드만 재시작합니다. 따라서 한 번에 너무 많은 용량을 제거할 수 없습니다.
• 데이터 손상을 방지하기 위해 자신의 네트워크에 대한 자동 재시작 시스템을 최대 24시간 동안 일시 중지합니다.
• 사람에게 요청합니다. 유지보수 플래그나 반복 재시작과 같은 위험도가 높은 변경에는 미리보기와 이후 사람의 새로운 확인이 필요합니다.

이러한 경로 외에는 에이전트가 범위가 지정된 지식 베이스와 플레이북에서 데이터를 읽기만 합니다. 에이전트가 운영 중인 프로덕션 인프라와 상호작용하게 할 때는 에이전트의 접근 범위를 제한하는 것이 핵심입니다.

4. "업스트림 문제"를 가장 내리기 어려운 결론으로 만든다

블록체인 노드 운영의 재미있는 점(적어도 저희는 재미있다고 생각합니다)은 노드가 본질적으로 불안정하다는 것입니다. 클라이언트에는 문제가 생길 수 있고, 모든 네트워크가 다양한 워크로드에서 같은 방식으로 동작하지는 않으며, 업스트림 네트워크 운영자(검증자, 시퀀서 등)가 저희 인프라의 정지나 장애를 일으킬 수 있습니다. 그래서 모든 에이전트에는 네트워크별 메모리와 지침이 필요하며, 이는 "우리 문제인가, 저쪽 문제인가?"라는 하나의 질문에 답하기 위한 것입니다.

에이전트가 "업스트림"이라고 판단하려면 네 가지 조건을 충족해야 합니다.

1. 오류율과 지연 시간 관점에서 저희 노드가 정상이어야 합니다.
2. 업스트림 오류(예: 네트워크 "정지")가 저희가 운영하는 모든 리전에서 동일하게 나타나야 합니다.
3. 독립적인 프로바이더가 이를 확인해야 하며, 그 외에는 고객 요청이 정상으로 보여야 합니다.
4. 일부 리전에서만 발생한 정지는 절대 업스트림이 아닙니다.

이 규칙은 양방향으로 작동합니다. 한 알림에서는 노드 6개가 비정상이었지만 네트워크는 여전히 새 블록을 생성하고 있었습니다. 에이전트는 이를 업스트림 정지가 아니라 저희 서빙 측 문제로 판단했습니다.

결과: 더 높은 안정성, 더 빠른 해결

이러한 투자 덕분에 엔지니어링 시간은 의미 있는 작업에 쓰이고, 고객은 어떤 네트워크에서 개발하든 문제를 더 빠르게 해결받습니다.

• 알림이 거의 4배 빠르게 해결됩니다. 해결 시간 중앙값은 30분에서 8분으로 줄었습니다.
• 대부분의 알림에는 엔지니어가 필요하지 않습니다. 에이전트는 알림의 약 73%를 스스로 해결하며, 이는 6월의 0%에서 증가한 수치입니다.
• 팀은 매달 약 120시간을 되찾았습니다. 알림에 쓰는 엔지니어링 시간은 월 약 150시간에서 약 30시간으로 80% 줄었습니다. 이는 매달 약 3엔지니어-주에 해당하며, 이 시간은 이제 컨텍스트 재구성 대신 원인 제거에 쓰입니다.
• 에이전트는 처음부터 정확합니다. 지난 한 달간 200건 이상의 조사에서 첫 시도 근본 원인 정확도는 약 98%였습니다.

자체 온콜 에이전트를 구축하는 팀에게 드리는 조언

1. 성과를 측정하세요. 온콜 에이전트는 해결 시간, 정확도, 절약한 엔지니어링 시간으로 평가하세요.
2. 판정을 요구하세요. 한 페이지 분량의 조사 결과를 돌려주는 에이전트는 작업을 옮겼을 뿐 없앤 것이 아닙니다. 결정을 먼저 제시하도록 요구하세요. 해결하거나, 사람을 호출하고 얼마나 긴급한지 알리는 것입니다.
3. 범위가 고정된 명명된 조치를 부여하세요. 24시간 상한이 있는 단일 노드 재시작이 원시 셸 접근보다 안전합니다.
4. 각 에이전트에 좁은 담당 범위와 긴 메모리를 주세요. 해당 네트워크의 런북, 특성, 인시던트 기록을 가진 네트워크당 하나의 에이전트는 알림마다 시스템을 다시 파악할 필요가 없습니다. 오늘 이것이 일곱 번째 정지라는 것을 이미 알고 있습니다.

하지만 가장 중요한 것은 문제 조사에서 멈추지 않는 것입니다. 문제가 사람에게 도달하기 전에 이를 방지할 수 있는 에이전트는 고객 가치에 쏟는 엔지니어링 노력을 누적시킵니다.

응용 AI와 인프라가 만나는 이런 주제에 관심이 있으신가요?

• @onewaysidewalks를 팔로우하고 Alchemy의 AI 관련 최신 소식을 받아보세요.
• 팀에 합류하세요. 채용 중입니다!