단계 7: A2A 통합 테스트

이 단계에서는 네트워크 문제를 시뮬레이션하고 collaborator 에이전트가 connectivity 및 performance 에이전트와 협력하여 문제를 해결하는 방법을 관찰하여 A2A 협업 시스템을 테스트합니다.

가상 환경 확인: 터미널에서 (.venv) 프롬프트가 보이는지 확인하세요. 보이지 않으면 다음을 실행하세요:

cd /workspace/workshop-module-3/agentcore-connectivity-agent && source .venv/bin/activate && cd /workspace/workshop-module-3/a2a/a2a-collaborator-agent

Route 53 Private Hosted Zone 설정: 테스트에서 dig 명령어로 도메인을 조회하려면, Route 53의 Private Hosted Zone(PHZ)에 VS Code 서버가 위치한 VPC가 연결되어 있어야 합니다. Route 53 콘솔에서 examplecorp.com PHZ를 선택한 후, **"Edit hosted zone"**에서 VS Code용 VPC를 추가하세요.

RDS 보안그룹 확인

AWS 콘솔에서 Amazon RDS 서비스로 이동합니다. RDS 인스턴스와 연결된 보안 그룹을 클릭합니다.

RDS 보안그룹

기본적으로 보안 그룹에는 Reporting VPC의 CIDR에서의 트래픽을 허용하는 규칙이 있어야 합니다.

정상 보안그룹 규칙

연결성 문제 시뮬레이션

아래 명령어를 실행하여 break 스크립트를 복사합니다:

curl https://ws-assets-prod-iad-r-iad-ed304a55c2ca1aee.s3.us-east-1.amazonaws.com/25286efc-5ab4-45b2-a654-bc31f00e0426/break-scripts/module-3-break-connectivity.py \
  --output module-3-break-connectivity.py && python3 module-3-break-connectivity.py

🔍 이 스크립트는 무엇을 하나요?

1. RDS 보안그룹에서 Reporting VPC CIDR 허용 규칙 제거 (Module 1과 유사)

2. TCP 재전송 문제를 유발하는 네트워크 설정 변경

3. 애플리케이션에 지원 티켓 자동 생성

4. Collaborator Agent가 Connectivity + Performance 에이전트에 위임하여 진단할 시나리오 생성

이전에 Reporting VPC의 CIDR 범위에서의 트래픽을 허용했던 인바운드 규칙이 제거되었는지 확인합니다.

제거된 보안그룹 규칙

ApplicationURL 조회

CLI 방법

aws cloudformation describe-stacks --stack-name sample-application \
  --query 'Stacks[0].Outputs[?OutputKey==`ApplicationURL`].OutputValue' --output text

콘솔 방법: AWS 콘솔에서 AWS CloudFormation으로 이동합니다. sample-application 스택에서 Outputs 탭의 ApplicationURL 값을 복사합니다.

CloudFormation ApplicationURL

노트북의 새 브라우저에서 ApplicationURL 값을 붙여넣습니다. Support Tickets를 선택하고 View Tickets 탭을 클릭합니다. 새로운 지원 티켓이 생성된 것을 확인할 수 있습니다.

지원 티켓

테스트 인증정보: [e-mail] / TestPassword123!

---

시나리오 1: 성능 문제 해결 (Part 1)

CloudWatch 확인

1. Amazon CloudWatch로 이동하여 Network Monitoring 아래의 Flow Monitors 선택:

Flow Monitors 목록

1. examplecorp-vpc-network-monitor 선택:

모니터 선택

1. Traffic Summary를 검토하고 Retransmission 그래프에서 현재 재전송 수준 확인:

재전송 메트릭 (수정 전)

Collaborator Agent 실행

cd /workspace/workshop-module-3/a2a/a2a-collaborator-agent
python3 test_a2a_m2m.py a2a_collaborator_agent_runtime \
  --prompt "안녕하세요" --interactive

영어: Hello

성능 문제 해결 요청

ExampleCorp Image Application의 재전송 문제를 해결해줘

영어: Fix retransmission issues for ExampleCorp Image Application

Collaborator Agent가 자동으로:

1. 요청을 분석하여 "성능 문제"로 분류

2. send_message_tool로 Performance Agent 호출

3. Performance Agent가 network-flow-monitor와 traffic-mirroring 도구 사용

4. 결과를 종합하여 사용자에게 보고

Collaborator 성능 수정

변경사항이 전파되는 데 5-10분이 소요됩니다. 시나리오 2를 진행한 후 나중에 검증하세요.

---

시나리오 2: 연결성 문제 해결

Collaborator Agent 채팅에서:

reporting.examplecorp.com과 database.examplecorp.com 사이 연결 상태를 확인해줘

영어: Can you check connectivity between reporting.examplecorp.com and database.examplecorp.com?

Collaborator Agent가 자동으로:

1. 요청을 분석하여 "연결성 문제"로 분류

2. send_message_tool로 Connectivity Agent 호출

3. Connectivity Agent가 dns-resolve와 connectivity 도구 사용

4. 보안 그룹 규칙 누락 발견

연결성 확인

수정 동의

사람의 동의 제공:

응 확인했어. 수정해줘

영어: Yes, I confirm. Please fix

연결성 수정

VPC Reachability Analyzer에서 분석 확인 - 연결이 복구된 것을 확인합니다.

VPC Reachability Analyzer

---

시나리오 1: 성능 수정 검증 (Part 2)

재전송 수정이 적용되었는지 확인합니다.

1. Amazon CloudWatch 콘솔로 돌아가서 Network Monitoring 아래의 Flow Monitors 선택:

Flow Monitors

1. examplecorp-vpc-network-monitor 모니터 선택:

모니터 선택

1. 업데이트된 Traffic Summary에서 재전송 합계 감소 확인. Retransmission 그래프에서 하락 추세 확인:

재전송 메트릭 (수정 후)

재전송 메트릭 (수정 후)

재전송 그래프에서 뚜렷한 감소가 나타나야 합니다. 이는 Performance Agent가 네트워크 성능 문제를 성공적으로 해결했음을 나타냅니다.

1. Collaborator Agent 채팅에서 exit를 입력하여 종료:

exit

1. 브라우저에서 ApplicationURL에 접속하여 View Tickets 탭을 확인합니다. 연결성 및 성능 관련 티켓이 closed 상태인지 확인:

티켓 종료 확인

---

선택 사항: 문제 해결 심층 분석

Network Flow Monitor 분석

1. Collaborator Agent를 interactive 모드로 시작:

cd /workspace/workshop-module-3/a2a/a2a-collaborator-agent
python3 test_a2a_m2m.py a2a_collaborator_agent_runtime \
  --prompt "안녕하세요" --interactive

1. Network Flow Monitor 분석 요청:

네트워크 플로우 모니터를 분석해줘

영어: Analyze network flow monitor

Network Flow Monitor 분석

Retransmissions와 Retransmission Timeouts가 0이 아닌 값으로 표시되어야 합니다.

Traffic Mirroring 로그 분석

Traffic Mirroring은 소스 인스턴스의 네트워크 트래픽을 복제하여 별도의 분석 인스턴스에서 패킷 캡처(PCAP)를 수행하는 AWS 기능입니다. PCAP 파일은 RDS에서 직접 생성되는 것이 아니라, ReportingServer ↔ Database 간 트래픽을 미러링하여 캡처합니다.

구성 요소	역할
ReportingServer	트래픽 미러링 소스 (ENI에서 패킷 복제)
TrafficMirroringTarget	복제된 패킷 수신 → tcpdump로 PCAP 캡처
S3 버킷	PCAP 파일 저장 (raw-captures/ 경로)
Performance Agent	S3에서 PCAP을 가져와 tshark로 분석 (SSM 경유)

1. Traffic Mirroring 로그 분석 요청:

트래픽 미러링 로그를 분석해줘

영어: Analyze traffic mirroring logs

Traffic Mirroring 분석

1. 채팅 출력에서 PCAP 파일 이름을 복사하고, S3 버킷 **traffic-mirroring-analysis-{AWS-ACCOUNT}**에서 검색합니다 ({AWS-ACCOUNT}를 실제 AWS 계정 ID로 대체). 파일의 전체 S3 URI를 복사합니다.

예시: 에이전트가 capture-20251028-110612.pcap을 언급한 경우:

s3://traffic-mirroring-analysis-123456789012/raw-captures/year=2025/month=11/day=2/instance-i-05f5a71fdcf005bd4/capture-20251028-110612.pcap

참고: S3 URI에는 실제 AWS 계정 ID와 캡처가 생성된 현재 날짜/시간이 포함됩니다.

S3 URI 확인

PCAP 파일 로컬 분석

1. 현재 터미널은 유지하고, 새 VS Code 터미널을 엽니다. 먼저 PCAP 분석 도구를 설치합니다:

sudo yum install -y wireshark-cli

새 터미널에서 **{REPLACE-WITH-PCAP-FILE-S3-URI}**를 복사한 S3 URI로 교체하여 실행합니다:

cd /workspace/workshop-module-3 && \
aws s3 cp {REPLACE-WITH-PCAP-FILE-S3-URI} ./capture.pcap && \
echo "Database IP: $(dig database.examplecorp.com +short | tail -1)" && \
echo "Reporting IP: $(dig reporting.examplecorp.com +short | tail -1)" && \
tshark -r capture.pcap -Y "(ip.addr == $(dig database.examplecorp.com +short | tail -1) and ip.addr == $(dig reporting.examplecorp.com +short | tail -1)) and tcp.analysis.retransmission" -T fields -e frame.time_epoch -e ip.src -e ip.dst -e tcp.seq 2>/dev/null

데이터베이스와 리포팅 서버 간의 재전송 로그가 표시되어야 합니다.

PCAP 분석 결과

코드 분석: A2A 메시지 흐름 추적

시나리오 2 메시지 흐름 상세

사용자: "Check connectivity between reporting and database"
    │
    ▼
[Collaborator Agent] LLM이 시스템 프롬프트 분석
    │ "connectivity" 키워드 → Connectivity_Troubleshooting_Agent로 라우팅
    │
    ▼
[send_message_tool] A2A SendMessageRequest 생성
    │ agent_name="Connectivity_Troubleshooting_Agent"
    │ task="Check connectivity between reporting.examplecorp.com and database.examplecorp.com"
    │
    ▼
[ALB] → [ECS Task] → [A2A Server] → [AgentExecutor]
    │
    ▼
[ConnectivityTroubleshootingAgentCoreExecutor]
    │ 1. OAuth 토큰 획득 (_bearer → get_token)
    │ 2. AgentCore Runtime URL 구성 (_build_agent_url)
    │ 3. HTTP POST로 Runtime 호출 (_invoke_json)
    │
    ▼
[AgentCore Runtime] → [TroubleshootingAgent]
    │ 1. dns-resolve("reporting.examplecorp.com") → i-xxx
    │ 2. dns-resolve("database.examplecorp.com") → 10.2.3.194
    │ 3. connectivity(source="i-xxx", dest="10.2.3.194", action="check")
    │
    ▼
[결과 반환] artifacts → TextPart → SendMessageResponse
    │
    ▼
[Collaborator Agent] 결과 종합 후 사용자에게 보고

A2A Executor 핵심 동작 (agent_executer.py)

class ConnectivityTroubleshootingAgentCoreExecutor(AgentExecutor):
    def _build_agent_url(self, qualifier="DEFAULT"):
        """AgentCore Runtime 호출 URL 구성"""
        endpoint = f"https://bedrock-agentcore.{region}.amazonaws.com"
        return f"{endpoint}/runtimes/{escaped_agent_arn}/invocations?qualifier={qualifier}"

    def _bearer(self):
        """OAuth 토큰 캐시 관리 (만료 30초 전 갱신)"""
        if self._token_cache.valid(now_ts):
            return self._token_cache.token
        tok = get_token(user_pool_id, client_id, client_secret, scope, discovery_url)
        self._token_cache.set(tok["access_token"], int(tok["expires_in"]), now_ts)

    async def execute(self, context, event_queue):
        """A2A 요청 처리"""
        # 1. TaskUpdater로 상태 관리 (submit → start_work → complete)
        # 2. HTTP POST로 AgentCore Runtime 호출
        # 3. 응답을 TextPart artifact로 변환

A2A 통신 경로: 사용자 → Collaborator(AgentCore) → ALB → ECS(A2A Server) → Executor → AgentCore Runtime → TroubleshootingAgent → Lambda 도구. 총 7단계를 거치지만, 사용자는 하나의 프롬프트만 입력하면 됩니다.

모듈 4 완료! Collaborator Agent가 전문 에이전트들을 조율하여 연결성과 성능 문제를 모두 해결했습니다. 요약 페이지로 이동하여 워크샵에서 배운 내용을 정리합니다.

참고: A2A 서버는 Amazon ECS 외에도 AgentCore Runtime에서 직접 호스팅할 수 있습니다.

이 모듈이 완료되었습니다. 다음 단계로 진행하세요.