AgentCore의 멀티 에이전트

세션 노트

과제

장애 발생 시 기존 워크플로

• 클라우드 리소스 상태 확인
• 장애 발생
• 인시던트 기록 보기
• 구성 확인
• 알림 확인
• 작업 지시 할당
• 로그 분석
• 근본 원인 가설 수립
• 해결책 검색
• 메트릭 확인
• 종속성 분석
• 최근 업데이트 보기
• 호출 체인 검색
• 운영 및 유지보수 매뉴얼 보기
• 서비스 대시보드 조회
• 완화 조치 실행
• 동료에게 알림
• 이상 메트릭 조회
• 매뉴얼 읽기
• 복구 상태 모니터링 핵심 과제
• 적시 손실 완화
• 장애 격리
• 허용 가능한 시간 내에 문제 해결
• 장애를 격리 경계 내로 제한하여 다른 서비스로의 연쇄 효과를 방지함으로써 장애 영향 범위 축소
• 서비스가 사용자 기대와 SLA를 충족하도록 보장

솔루션의 발전

• 단일 에이전트에서 멀티 에이전트 솔루션으로 발전 이상적인 솔루션 시스템 알림 및 경보
• 경보 메트릭: 5xx 비율 30% 초과
• 경보 상세: 서비스, 엔드포인트, 트리거 시간 보충 근본 원인 분석 주요 결과: API 오류율 100%, DB 오류 없음, S3 버킷 정책이 업데이트됨.
• 즉각 조치: S3 버킷 정책의 Deny 확인
• 신뢰도: 90% 자동 운영 확인
• 메시지: 시스템 복구 완료(원문: System Revered).
• RCA: S3 버킷 정책이 Deny로 설정됨
• MTTR: 5분
• 장애 복구 시간을 몇 시간에서 몇 분으로 단축 SRE 전문가 작업 범위
• 지난 한 시간 동안 내 User Service 오류율이 5%에 도달한 이유는 무엇입니까?
• 지난 한 시간 동안 RDS MySQL 인스턴스에서 연결 한도 초과 문제가 12회 발생했기 때문입니다
• 현재 시스템 파악
• 서비스 상관관계 찾기
• 로그 분석
• 감사 로그 분석
• 구성 분석
• 메트릭 분석 두 가지 질문 고려

1. 시스템 복잡도가 높고 문제 해결 워크플로가 길며 로그 양이 많다면 단일 에이전트가 원활하게 작동할 수 있을까요?

2. SRE 전문가의 경험을 에이전트에 복제하여 Q&A 방식을 대체하고, 에이전트가 자율적으로 의사 결정하고 행동하게 할 수 있을까요?

멀티 에이전트 아키텍처 설계

• "Planner"는 워크플로를 생성
• "Executor"는 할당된 작업 실행을 담당
• "Evaluator"는 각 단계의 결과가 유익한지 평가하고 후속 계획을 위해 "Planner"로 돌려보내는 역할을 담당
• 결과도 반환하기 전에 "Evaluator"의 검토가 필요
• "Planner"는 "Evaluator"의 피드백을 바탕으로 프로세스를 조정할 수 있음 멀티 에이전트 vs 단일 에이전트

1. 더 복잡한 작업에 적합

2. 더 명확한 책임 및 권한 경계

3. 더 쉬운 컨텍스트 엔지니어링

4. 더 편리한 확장 AgentCore 모범 사례 에이전트 전용 런타임 환경 소개

• "시험"에서 "구현"까지의 과제
• PoC에서 프로덕션 환경 구현까지의 과제
• 성능
• 탄력성
• 보안
• 비즈니스 가치 창출
• 규정 준수

에이전트 런타임 환경 v1.0

• 인터페이스 및 프로토콜(MCP/A2A)
• 에이전트 배포
• 에이전트 프레임워크
• 대규모 언어 모델
• 메모리
• 프롬프트
• 도구/리소스
• 가드레일
• 관찰 가능성
• 평가 에이전트 런타임 환경 v2.0
• 인터페이스 및 프로토콜(MCP/A2A)
• 에이전트 배포
• Amazon Bedrock
• AgentCore
• 에이전트 프레임워크
• 대규모 언어 모델 런타임
• 메모리
• 프롬프트
• 도구/리소스
• 자격 증명 도구
• 가드레일
• 게이트웨이
• 관찰 가능성
• 평가 특화형
• Amazon Q Agents 완전 관리형
• Amazon Bedrock Agents DIY
• OSS 프레임워크, Strands Agents SDK