Amazon Bedrock Agents와 AWS Support 자동화 워크플로우(SAW)를 통한 AWS 리소스 문제 해결 간소화

AWS 환경이 복잡해짐에 따라, 리소스 관련 문제를 해결하는 것은 어려운 작업이 될 수 있습니다. 특히 복잡한 시스템을 다룰 때 수동으로 문제를 조사하고 해결하는 것은 시간이 많이 소요되며 오류가 발생하기 쉽습니다. 다행히도 AWS에서는 AWS Systems Manager에서 사용자가 직접 실행할 수 있는 선별된 자동화된 런북 (self-service automation runbooks)의 모음인 AWS Support Automation Workflows라는 강력한 도구를 제공하고 있습니다. 이러한 런북들은 AWS Support Engineering 팀에서 고객 문제를 해결하며 수립한 모범 사례를 기반으로 생성되었습니다. 본 런북들은 AWS 고객들이 AWS 리소스에 발생하는 일반적인 문제를 해결, 진단 및 수정할 수 있도록 도울 수 있습니다.

Amazon Bedrock은 AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI 그리고 Amazon 같은 주요 AI 기업들의 고성능 파운데이션 모델 (Foundation Model, FM)들을 단일 API를 통해 제공하며, 보안, 프라이버시, 책임 있는 AI (Responsible AI)를 가진 생성형 AI 애플리케이션을 구축할 수 있는 광범위한 기능을 제공하는 완전 관리형 서비스입니다.
Amazon Bedrock을 사용하면 사용자의 사용 사례에 맞는 최상위 FM을 실험하고 평가할 수 있으며, 미세 조정 (Fine tuning) 및 검색 증강 생성 (Retrieval Augmented Generation, RAG)과 같은 기법을 사용하여 사용자의 데이터로 모델을 개인화할 수 있고, 사용자의 엔터프라이즈 시스템과 데이터 소스를 사용하여 작업을 실행하는 에이전트를 구축할 수 있습니다. Amazon Bedrock은 서버리스 서비스이므로 사용자가 인프라를 관리할 필요가 없으며, 사용자는 이미 익숙한 AWS의 서비스들을 사용하여 생성형 AI 기능을 사용자의 애플리케이션에 안전하게 통합하고 배포할 수 있습니다.

이 글에서는 Amazon Bedrock Agents와 AWS Support Automation Workflows를 활용하여 AWS 리소스의 문제를 해결할 수 있는 지능형 에이전트를 만드는 방법을 살펴보겠습니다.

솔루션 개요

이 솔루션은 다양한 AWS Support Automation Workflows에 적용할 수 있는 유연한 구조를 가지고 있지만, 이 글에서는 Amazon Elastic Kubernetes Service (Amazon EKS) 워커 노드가 클러스터 조인에 실패한 경우의 문제를 해결하는 예시에 초점을 맞추도록 하겠습니다. 다음 다이어그램은 Amazon Bedrock을 사용한 문제 해결 에이전트의 전반적인 개요를 보여줍니다.

본 솔루션은 원활하고 효율적인 문제 해결 경험을 제공하기 위해 다음과 같은 주요 구성 요소들로 이루어져 있습니다:

Amazon Bedrock 에이전트 – Amazon Bedrock 에이전트는 사용자와 AWS Support Automation Workflows 사이의 지능형 인터페이스 역할을 합니다. 자연어 쿼리를 처리하여 문제의 맥락을 이해하고, 필요한 정보를 수집하기 위한 대화 흐름을 관리합니다. Anthropic 사의 Claude 3.5 Sonnet 모델을 활용해 고급 추론과 응답 생성을 수행하며, 문제 해결 과정 전반에 걸쳐 자연스러운 상호작용을 가능하게 합니다.
Amazon Bedrock 에이전트 작업 그룹 – 이 작업 그룹은 Amazon Bedrock 에이전트가 호출할 수 있는 구조화된 API 작업을 정의합니다. OpenAPI 명세를 사용하여 에이전트와 AWS Lambda 함수 간의 인터페이스를 정의하며, 사용 가능한 작업, 필요한 매개변수, 예상되는 응답을 지정 (specifying)합니다. 각 작업 그룹은 Lambda 함수와 상호작용할 때 에이전트가 요청을 적절하게 포맷하고 응답을 해석하는 방법을 알려주는 API 스키마를 포함합니다.
Lambda 함수 – Lambda 함수는 Amazon Bedrock 에이전트와 AWS Support Automation Workflows 사이의 통합 계층 역할을 합니다. 에이전트로부터 받은 입력 매개변수를 검증하고 적절한 Support Automation Workflow 런북 실행을 시작합니다. 기술적 출력을 구조화된 형식으로 처리하면서 자동화 진행 상황을 모니터링합니다. 런북 실행이 완료되면 사용자에게 보여줄 형식화된 결과를 에이전트에 반환합니다.
IAM 역할 – AWS Identity and Access Management (IAM) 역할은 Lambda 함수에 AWS Support Automation Workflows 런북을 실행하고 필요한 AWS 서비스와 상호작용하는 데 필요한 권한을 제공합니다. 이 역할은 보안 모범 사례를 유지하기 위해 최소 권한 원칙 (Principle of Least Privilege)을 따릅니다.
AWS Support Automation Workflows – AWS Support Engineering 팀에서 개발한 사전 구축된 진단 런북입니다. 이는 AWS 모범 사례를 기반으로 표준화되어 반복 가능한 방식으로 종합적인 시스템 점검을 실행합니다. AWS Support Engineering 팀의 문제 해결을 위한 전문 지식이 담겨 있으며 AWS 서비스와 일반적인 문제들을 광범위하게 다룰 수 있습니다.

다음 단계들은 본 솔루션의 작동 과정을 설명합니다:

사용자는 Amazon Bedrock 채팅 콘솔을 통해 사용자의 AWS 리소스 문제를 자연어로 설명하는 것으로 시작합니다. 예를 들어, “왜 내 EKS 워커 노드가 클러스터에 조인하지 않나요?”와 같은 방식으로 질문할 수 있습니다.
Lambda 함수는 검증된 요청을 받아 연관된 Support Automation Workflow 런북을 실행합니다. 이러한 런북에는 AWS Support Engineering 팀이 개발한 일반적인 문제와 그 근본 원인을 식별하기 위한 포괄적인 진단 검사가 포함되어 있습니다. 이러한 검사는 사용자의 개입 없이 자동으로 실행됩니다.
Support Automation Workflow 런북은 체계적으로 진단 검사를 실행하고 결과를 취합합니다. 식별된 문제점과 구성 문제를 포함한 이러한 결과는 JSON 형식으로 구조화되어 Lambda 함수로 반환됩니다.
Amazon Bedrock 에이전트는 ReAct 기법 (추론과 행동의 시너지를 활용하는 기법)을 기반으로 한 사고의 연쇄 (Chain of Thought, CoT) 추론을 사용하여 진단 결과를 처리합니다. 이를 통해 에이전트는 기술적 발견사항을 분석하고, 근본 원인을 식별하며, 명확한 설명을 생성하고, 단계별 문제 해결 가이드를 제공할 수 있습니다.

에이전트의 추론 단계 동안, 사용자는 추론 단계를 확인할 수 있습니다.

문제 해결 예시

앞서 언급한 일반적인 문제와 Amazon Bedrock 에이전트가 이를 해결하는 방법을 자세히 살펴보겠습니다.

EKS 워커 노드가 EKS 클러스터에 조인하지 못하는 문제

EKS 워커 노드가 EKS 클러스터에 조인하지 못할 때, Amazon Bedrock 에이전트는 클러스터 이름과 워커 노드 ID와 같은 연관 정보와 함께 호출될 수 있습니다. 에이전트는 연관된 AWS Support Automation Workflow를 실행하여 워커 노드의 IAM 역할 권한 확인과 필수 네트워크 연결 상태 확인과 같은 검사를 수행합니다.

AWS Support Automation Workflow가 모든 점검을 실행한 후, Amazon Bedrock 에이전트는 문제 해결 결과를 수집하고 사용자에게 문제의 근본 원인을 설명하며, AWSSupport-TroubleshootEKSWorkerNode 런북의 실행 결과를 기반으로 워커 노드의 IAM 역할 업데이트나 네트워크 구성 문제 해결과 같은 조치 단계를 제안합니다. 이를 통해 사용자는 문제 해결에 필요한 조치를 취할 수 있습니다.

OpenAPI 예시

Amazon Bedrock에서 작업 그룹을 생성할 때, 에이전트가 사용자로부터 호출해야 하는 매개변수들을 정의해야 합니다. 또한 에이전트가 이러한 매개변수들을 사용하여 호출할 수 있는 API 작업들도 정의할 수 있습니다. API 작업을 정의하기 위해 JSON 형식의 OpenAPI 스키마를 생성하겠습니다:

"Body_troubleshoot_eks_worker_node_troubleshoot_eks_worker_node_post": {
        "properties": {
          "cluster_name": {
            "type": "string",
            "title": "Cluster Name",
            "description": "The name of the EKS cluster"
          },
          "worker_id": {
            "type": "string",
            "title": "Worker Id",
            "description": "The ID of the worker node"
          }
        },
        "type": "object",
        "required": [
          "cluster_name",
          "worker_id"
        ],
        "title": "Body_troubleshoot_eks_worker_node_troubleshoot_eks_worker_node_post"
      }

이 스키마는 다음과 같은 구성 요소로 이루어져 있습니다:

Body_troubleshoot_eks_worker_node_troubleshoot_eks_worker_node_post – 이는 스키마의 이름으로, troubleshoot-eks-worker_node POST 엔드포인트의 요청 본문 (Request body)에 해당합니다.
Properties – 이 섹션은 스키마의 속성 (필드)들을 정의합니다:
- “cluster_name” – 이 속성은 EKS 클러스터의 이름을 나타냅니다. 문자열 유형이며 제목과 설명을 포함합니다.
- “worker_id” – 이 속성은 워커 노드의 ID를 나타냅니다. 이 역시 문자열 유형이며 제목과 설명을 포함합니다.
Type – 이 속성은 스키마가 키-값 쌍의 집합인 “객체 (object)” 유형임을 지정합니다.
Required – 이 속성은 스키마에 필수적인 필드들을 나열하며, 본 경우에는 “cluster_name”과 “worker_id”입니다. 이러한 필드들은 요청 본문에 반드시 포함되어야 합니다.
Title – 이 속성은 문서화 목적으로 사용될 수 있는 사람이 읽기 쉬운 스키마의 제목을 제공합니다.

OpenAPI 스키마는 요청 본문의 구조를 정의합니다. 보다 자세한 내용은 Amazon Bedrock에서 에이전트의 작업 그룹에 대한 OpenAPI 스키마 정의 와 OpenAPISpecification 문서를 참조해주세요.

Lambda 함수 코드

이제 Lambda 함수의 코드를 살펴보겠습니다:

@app.post("/troubleshoot-eks-worker-node")
@tracer.capture_method
def troubleshoot_eks_worker_node(
    cluster_name: Annotated[str, Body(description="The name of the EKS cluster")],
    worker_id: Annotated[str, Body(description="The ID of the worker node")]
) -> dict:
    """
    Troubleshoot EKS worker node that failed to join the cluster.

    Args:
        cluster_name (str): The name of the EKS cluster.
        worker_id (str): The ID of the worker node.

    Returns:
        dict: The output of the Automation execution.
    """
    return execute_automation(
        automation_name='AWSSupport-TroubleshootEKSWorkerNode',
        parameters={
            'ClusterName': [cluster_name],
            'WorkerID': [worker_id]
        },
        execution_mode='TroubleshootWorkerNode'
    )

이 코드는 다음과 같은 구성 요소들로 이루어져 있습니다:

app.post(“/troubleshoot-eks-worker-node”, description=”Troubleshoot EKS worker node failed to join the cluster”) – 이는 /troubleshoot-eks-worker-node 엔드포인트에 대한 POST 요청의 경로를 설정하는 데코레이터입니다. description 매개변수는 이 엔드포인트의 기능을 간단히 설명합니다.
@tracer.capture_method – 이는 애플리케이션 성능 모니터링 (Application Performance Monitoring, APM) 도구의 일부로 사용될 수 있는 추적 또는 모니터링 목적의 또 다른 데코레이터입니다. 함수 실행 시간, 오류 및 기타 지표와 같은 함수 실행에 관한 정보를 수집합니다.
cluster_name: str = Body(description=”The name of the EKS cluster”), – 이 매개변수는 문자열 유형의 cluster_name이 요청 본문을 통해 전달되어야 함을 명시합니다. Body 데코레이터는 이 매개변수가 요청 본문에서 추출되어야 함을 나타냅니다. description 매개변수는 이 매개변수가 의미하는 바를 간단히 설명합니다.
worker_id: str = Body(description=”The ID of the worker node”) – 이 매개변수는 문자열 유형의 worker_id가 요청 본문을 통해 전달되어야 함을 명시합니다.
→ Annotated[dict, Body(description=”The output of the Automation execution”)] – 이는 함수의 반환 유형으로, 딕셔너리 형태입니다. Annotated 유형은 반환값에 대한 추가 메타데이터를 제공하는 데 사용되며, 특히 응답 본문에 포함되어야 함을 나타냅니다. description 매개변수는 반환 값이 의미하는 바를 간단히 설명합니다.

Lambda 함수에 새로운 SAW 런북을 연결하려면 위와 동일한 템플릿을 따르면 됩니다.

사전 요구 사항

다음과 같은 사전 요구 사항이 갖춰져 있는지 확인하세요:

AWS 계정
Amazon Bedrock에서 Anthropic 사의 Claude 3.5 Sonnet 모델에 대한 접근 권한 활성화
자격 증명이 구성된 AWS Command Line Interface (AWS CLI)
Javascript 설치
143.0 버전 이상의 AWS Cloud Development Kit (AWS CDK)

솔루션 배포

다음 단계를 따라 솔루션을 배포하세요:

GitHub 리포지토리를 복제하고 다운로드한 리포지토리 폴더의 루트 경로로 이동합니다:
- ```
$ cd bedrock-agent-for-troubleshooting-aws-resources
```
로컬 종속성을 설치합니다:
- ```
$ npm install
```
자격 증명 파일을 구성하여 AWS CLI로 AWS 계정에 로그인합니다 (<PROFILE_NAME>을 배포할 AWS 계정의 프로파일 이름으로 교체하세요):
- ```
$ export AWS_PROFILE=PROFILE_NAME
```
AWS CDK 환경을 부트스트랩합니다 (1회성 작업이므로 AWS 계정이 이미 부트스트랩되어 있다면 필요하지 않습니다):
- ```
$ cdk bootstrap
```
스크립트를 실행하여 구성 파일의 AWS 계정과 AWS 리전에 대한 플레이스홀더를 교체합니다:
- ```
$ cdk deploy --all
```

Bedrock 에이전트 테스트

원하는 리전의 Amazon Bedrock Agents 콘솔로 이동하여 배포된 에이전트를 찾으세요. 에이전트 ID는 cdk deploy 명령어 출력 내용에서 확인할 수 있습니다.

이제 에이전트와 상호작용하면서 EKS 클러스터에 조인하지 못하는 워커 노드의 문제를 해결해볼 수 있습니다. 다음과 같은 예시 질문을 사용할 수 있습니다:

내 Amazon EKS 워커 노드가 클러스터에 조인하지 못하는 이유를 파악하고 싶습니다. 도와주실 수 있나요? (I want to troubleshoot why my Amazon EKS worker node is not joining the cluster. Can you help me?)
이 인스턴스 <instance_ID>가 EKS 클러스터 <Cluster_Name>에 조인하지 못하는 이유가 무엇인가요? (Why this instance <instance_ID> is not able to join the EKS cluster <Cluster_Name>?)

다음 스크린샷은 에이전트의 콘솔 화면을 보여줍니다.

에이전트가 질문을 이해하고 그 질문을 적절한 작업 그룹과 매핑했습니다. 또한 사용자 프롬프트에서 필요한 매개변수가 누락된 것을 발견했습니다. 이에 따라 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스 ID와 EKS 클러스터 이름을 요청하는 후속 질문을 했습니다.

추적 (Trace) 단계 1에서 에이전트의 사고 과정을 볼 수 있습니다. 에이전트는 적절한 Lambda 함수와 API 경로를 호출할 준비가 되었다고 판단했습니다.

런북으로부터 결과가 반환되면, 에이전트는 문제 해결 결과를 검토합니다. 정보를 분석한 후 사용자가 따를 수 있는 해결 방법에 대한 안내를 작성하기 시작합니다.

제공된 답변에서 에이전트는 모든 문제점을 파악하고 이를 해결 단계로 변환했습니다. 또한 에이전트가 IAM 정책이나 필요한 태그와 같은 적절한 정보를 언급하는 것을 확인할 수 있습니다.

자원 정리

Amazon Bedrock 에이전트를 구현할 때 리소스 구성에 대한 추가 비용은 발생하지 않습니다. 하지만 Amazon Bedrock에서 임베딩 모델과 텍스트 모델을 호출할 때는 사용된 각 FM의 가격을 기준으로 비용이 발생합니다. 본 사용 사례에서는 Lambda 호출에 대한 비용도 발생합니다.

향후 요금이 발생하는 것을 방지하려면 AWS CDK에 의해 생성된 리소스를 삭제하세요. 리포지토리 폴더의 루트 경로에서 다음 명령어를 실행하여 리소스를 삭제할 수 있습니다:

$ npm run cdk destroy --all

결론

Amazon Bedrock 에이전트와 AWS Support Automation Workflows를 결합하여 사용하면 AWS 리소스의 문제 해결 과정에 혁신을 일으킬 강력한 도구가 될 수 있습니다. 이 글에서는 AWS CDK로 구축한 서버리스 애플리케이션을 살펴보며, 어떻게 이러한 기술들을 통합하여 지능형 문제 해결 에이전트를 만들 수 있는 지 보여주었습니다. Amazon Bedrock 에이전트 내에서 작업 그룹을 정의하고 이를 특정 시나리오 및 Support Automation Workflow와 연결함으로써, Amazon EKS 워커 노드 장애와 같은 문제를 진단하고 해결하는 매우 효율적인 프로세스를 개발했습니다.

본 솔루션은 복잡한 문제 해결 작업을 자동화하여 시간을 절약하고 운영을 간소화할 수 있는 가능성을 보여줍니다. Anthropic 사의 Claude 3.5 Sonnet 모델을 기반으로 한 이 에이전트는 영어 외에도 한국어, 프랑스어, 일본어, 스페인어와 같은 다양한 언어에 대한 향상된 이해와 응답 능력을 보여주어 기술적 정확성과 효율성을 유지하면서도 글로벌 팀이 접근할 수 있게 되었습니다. 이 지능형 에이전트는 관련 AWS Support Automation Workflows를 자동으로 실행하여 신속하게 근본 원인을 식별하고 실현 가능한 인사이트를 제공합니다. 이러한 접근 방식은 다운타임을 최소화할 뿐만 아니라, 다양한 AWS 서비스와 사용 사례를 수용할 수 있도록 효과적으로 확장되어, AWS 인프라 관리를 개선하고자 하는 조직들에게 유용한 기반이 됩니다.

추가적인 사용 사례를 위해 AWS Support Automation Workflow를 살펴보고, 이 솔루션을 시작점으로 활용하여 조직의 요구에 맞춤화된 보다 포괄적인 문제 해결 에이전트를 구축하는 것을 고려해보세요. 워크플로우를 통합 관리 (Orchestrate)하는 에이전트 사용에 대해 자세히 알아보려면 AI 에이전트를 사용하여 애플리케이션에서 작업 자동화 문서를 참조하세요. 또한 생성형 AI 애플리케이션을 보호하기 위한 가드레일 사용에 대한 자세한 내용은 Amazon Bedrock Guardrails를 사용하여 모델의 유해한 콘텐츠 차단 문서를 참조하세요.

그럼, 즐거운 코딩 되시길 바랍니다!

AWS 기술 블로그