새벽 3시입니다. 데이터베이스 연결 풀이 고갈됩니다. 사이트가 다운됩니다. PagerDuty가 당직 근무자에게 알람을 보냅니다.

그들은 Slack 화상 회의에 참여하고, CloudWatch 로그를 뒤지다가 무한 재시도 루프에 빠진 Lambda 함수를 발견합니다. 누군가가 AWS CLI를 사용해 이 함수의 동시성(concurrency) 제한을 0으로 설정합니다. 데이터베이스가 복구됩니다. 그들은 Lambda의 동시성을 다시 늘리고 잠자리에 듭니다.

사건은 끝났습니다. 진짜 고통은 48시간 후에 찾아옵니다. 엔지니어링 리더십이 RCA(Root Cause Analysis, 근본 원인 분석)와 업데이트된 런북(runbook)을 요청할 때, 아무도 새벽 3시에 실행했던 정확한 명령어 순서를 기억하지 못하기 때문입니다. 사후 검토 보고서는 모호하고, 런북은 절반만 완성되었으며, 6개월 후 다른 당직 엔지니어가 동일한 장애를 처음부터 해결해야 합니다.

모든 엔지니어링 조직이 이 문제의 어떤 버전을 가지고 있습니다. 해결책이 2일 후에 자신의 기억을 재구성하려는 지친 인간에게 의존할 필요는 없습니다. 여러분의 인프라는 이미 무슨 일이 일어났는지 지켜봤습니다. 단지 그것을 기록만 할 필요가 있습니다.

AWS Systems Manager, CloudTrail, Amazon Bedrock, 그리고 Amazon Q Business를 사용하여 이를 구축하는 방법입니다.

파이프라인

아이디어는 인간의 기억에 의존하는 것을 멈추고, 대신 AWS 자체 감사 추적(audit trail)에서 무엇이 고장 났고 어떻게 수정되었는지 채굴하는 것입니다.

SSM Incident Manager는 알람이 발생한 순간부터 사건을 추적하여 깨끗한 시작 및 종료 타임스탬프를 제공합니다. 이 시간 창(time window)을 중심으로 모든 것이 구축됩니다.

한편, AWS는 이미 그 시간 창 안에서 발생하는 모든 것을 기록하고 있습니다. CloudWatch는 애초에 알람을 유발했던 오류 추적(error traces)과 지연 시간 급증(latency spikes)을 포착합니다. CloudTrail은 당직 엔지니어들이 문제를 해결하는 동안 실행하는 모든 API 호출을 기록합니다. 누군가가 Lambda의 동시성을 제한하면, CloudTrail은 해당 IAM 사용자와 연결된 PutFunctionConcurrency 이벤트를 기록합니다.

SSM에서 사고가 해결(resolved)으로 표시되면, EventBridge로 이벤트를 발생시키고, 이것이 RCA 파이프라인을 자동으로 시작합니다. 람다 함수는 CloudWatch 오류 로그와 필터링된 CloudTrail 이벤트를 가져와 Bedrock의 Claude 3.5 Sonnet에 전달하며, 프롬프트는 대략 다음과 같습니다:

"당신은 Principal SRE입니다. 이 CloudWatch 오류 로그를 분석하여 근본 원인을 찾아주세요. 그런 다음 엔지니어들이 장애를 중단시키기 위해 실행한 CloudTrail API 호출 순서를 살펴보세요. 무엇이 고장 났는지 설명하고, 다시 발생했을 때 수정하기 위한 단계별 runbook을 작성하는 비난 없는(blameless) RCA 보고서를 작성해 주세요."

두 번째 람다는 이 출력을 받아 Markdown 형식으로 포맷한 다음, docs: DB 연결 풀 고갈에 대한 Runbook 추가와 같은 이름으로 인프라 레포지토리에 풀 리퀘스트를 열어줍니다. 이것이 병합되면 Amazon Q Business가 새로운 runbook을 RAG 설정에 색인화합니다. 다음에 동일한 경보가 발생하면, Q는 사고 채널로

CloudTrail은 데이터가 너무 많습니다. 바쁜 AWS 계정은 분당 수천 개의 이벤트를 발생시키며, 이를 모두 LLM에 전달할 수는 없습니다. 데이터를 수집하는 Lambda 함수는 readOnly: false 이벤트만 필터링하고, 실제로 페이지 알림을 받은 IAM 사용자에게 범위를 한정해야 합니다. 그렇지 않으면 정상적인 백그라운드 API 트래픽 속에 중요한 신호가 묻혀버립니다.

CloudTrail은 제어 평면(control plane)만 볼 수 있습니다. AWS API 호출(DynamoDB 테이블 확장, ECS 태스크 재시작 등)은 기록하지만, 데이터 평면(data plane)은 기록하지 않습니다. 즉, 엔지니어가 손상된 행을 수정하기 위해 SQL 셸에 입력한 내용은 알 수 없습니다. 만약 팀이 인스턴스 접속을 위해 SSM Session Manager를 사용한다면, 터미널 입/출력을 CloudWatch로 스트리밍하도록 구성할 수 있습니다. 이렇게 하면 최소한 엔지니어가 실제로 실행했던 bash 및 SQL 명령어를 얻을 수 있습니다.

AI의 출력물은 완성된 문서가 아니라 초안입니다. AI는 엔지니어가 특정 조치를 취한 이유를 오해할 수 있으므로, 파이프라인은 main 브랜치에 바로 커밋하는 대신 풀 리퀘스트(pull request)를 열어야 합니다. 결국 사람이 다음 날 아침에 검토하고 몇 문장을 수정하여 병합합니다. 모델이 대부분의 초안 작성을 담당하지만, 최종 승인은 여전히 사람의 몫입니다.

핵심은 이것입니다

우리는 생성형 AI(generative AI)를 코딩 도우미나 지원 티켓 봇으로 생각하는 경향이 있으며, 운영(operations) 분야에서 할 수 있는 일은 대부분 무시합니다. Bedrock을 AWS 자체 감사 로그에 연결하면, 인프라가 엔지니어가 무엇을 하는지 감시하고 기록하는 시스템으로 변모하며, 이 역할을 완전히 누가 새벽 3시에 깨어있느냐에게 맡기지 않아도 됩니다.

오늘 팀은 근본 원인 분석(RCA)과 runbook을 어떻게 처리하고 있나요? 혹시 이런 것을 시도해 본 분이 있다면 궁금합니다. 댓글로 알려주세요.