애플리케이션에 제한된 AI 요청 추가하기

소개

문서 요약 명령은 AI 의존성에 예측 가능한 한도가 필요합니다. 제공된 애플리케이션에 제한된 Bedrock 클라이언트를 추가하고, 너무 긴 입력을 추론 전에 거부하며, 서비스 장애나 느린 응답을 원본 예외 노출 없이 처리합니다.

Python 기초와 이전 랩의 구조화 출력 검증을 알아야 합니다. 인터페이스와 파서는 제공되므로 요청 경계에 집중할 수 있습니다. 새 VM은 자체 문서, 설정된 ID, 추론 한도를 갖습니다.

자격증 관련성

제한된 Bedrock 클라이언트 연결하기

이 단계에서는 명령의 클라이언트를 구현하고 실제 구조화 요약을 생성합니다.

작업 공간에서 시작합니다:

cd /home/labex/project

원본 문서와 명령 옵션을 읽습니다:

cat incident.txt

/opt/labex/aws/venv/bin/python application.py --help

사고는 INC-204입니다. application.py는 문서를 읽고 JSON을 출력합니다. client.request_summary를 호출하며, 제공된 response_parser.py는 종료 이유와 이전에 배운 세 문자열 필드를 확인합니다. 초기 client.py는 미완성 작업을 보고하고 요청을 보내지 않습니다.

입력 한도는 추론 한도 소비 전에 애플리케이션을 보호합니다. 이 예제는 비어 있지 않은 1–1000자를 받고 출력을 768 토큰으로 제한하며 명확한 SDK 연결 및 읽기 타임아웃을 사용합니다. total_max_attempts: 1은 첫 요청 한 번이고 자동 재시도가 없다는 뜻입니다. 읽기 타임아웃은 연결에서의 대기를 제한하며 모든 작업이 정확히 그 시각에 끝난다는 약속은 아닙니다.

초기 클라이언트를 이 구현으로 바꿉니다. ClientError는 서비스 오류 응답이고 ReadTimeoutError는 읽기 대기 만료입니다. 둘 다 짧은 진단 JSON으로 바뀝니다. 원본 예외, 요청 헤더, 자격 증명은 결과에 포함하지 않습니다:

cat > client.py <<'EOF'
import boto3
from botocore.config import Config
from botocore.exceptions import BotoCoreError, ClientError, ReadTimeoutError
from response_parser import summarize_response


def request_summary(document, endpoint_url, read_timeout):
    if not document.strip() or len(document) > 1000:
        return {'status': 'rejected', 'reason': 'input_limit'}
    client = boto3.client('bedrock-runtime', endpoint_url=endpoint_url,
        config=Config(proxies={}, connect_timeout=3, read_timeout=read_timeout,
                      retries={'total_max_attempts': 1}))
    try:
        response = client.converse(
            modelId='labex.text-v1:0',
            system=[{'text': 'Summarize only facts supplied in the incident document. Return exactly one JSON object with string fields incident_id, impact and next_action. No Markdown fences, extra keys or surrounding prose. Do not turn planned work into completed work.'}],
            messages=[{'role': 'user', 'content': [{'text': document}]}],
            inferenceConfig={'maxTokens': 768, 'temperature': 0})
    except ReadTimeoutError:
        return {'status': 'unavailable', 'reason': 'read_timeout'}
    except ClientError as error:
        code = error.response.get('Error', {}).get('Code')
        reason = 'busy' if code == 'ThrottlingException' else 'service_unavailable'
        return {'status': 'unavailable', 'reason': reason}
    except BotoCoreError:
        return {'status': 'unavailable', 'reason': 'connection_failed'}
    return summarize_response(response)
EOF

정상 설정된 Bedrock 엔드포인트로 실행합니다. > accepted.json은 출력 결과를 저장합니다:

/opt/labex/aws/venv/bin/python application.py > accepted.json

읽습니다:

cat accepted.json

status: ok와 세 요약 필드를 기대합니다. 문서와 의미를 비교하세요. AWS View에서 실제 완료 요청을 펼쳐 텍스트를 비교합니다. 출력 한도는 생성 토큰을 제한하며 입력 문자 한도는 별도 정책입니다. 캐시 응답은 실제 모델 출력을 추가 credits 소비 없이 재사용할 수 있습니다.

추론 전에 너무 긴 입력 거부하기

이 단계에서는 입력 예산을 넘는 문서가 거부되는지 확인합니다.

제공된 oversized.txt는 1000자를 넘습니다. wc -m은 문자 수를 셉니다:

wc -m oversized.txt

같은 애플리케이션으로 파일을 처리합니다:

/opt/labex/aws/venv/bin/python application.py --document oversized.txt > too-long.json

의도된 거부는 종료 코드 2입니다. echo $?는 앞 명령의 종료 코드를 출력합니다:

echo $?

안전한 결과를 읽습니다:

cat too-long.json

status: rejected와 reason: input_limit을 기대합니다. 클라이언트는 요청 구성 전에 검사하므로 AWS View에는 이전 완료 요청 하나만 남아야 합니다. 입력 거부는 새 소비를 막지만 결과 파일 삭제는 이전 소비를 취소하지 않습니다.

서비스 장애와 읽기 타임아웃 처리하기

이 단계에서는 명시된 두 로컬 통신 테스트 서비스로 오류 경계를 확인합니다.

아래 엔드포인트는 의도적으로 오류를 반환하거나 응답을 지연합니다. 모델 요청이나 credits 소비가 없습니다. 테스트 의존성이지 성공 추론의 대체 제공자가 아닙니다.

포트 5001의 서비스 이용 불가 테스트를 사용합니다:

/opt/labex/aws/venv/bin/python application.py --endpoint-url http://127.0.0.1:5001 > unavailable.json

예상 실패는 종료 코드 3입니다. 진단 결과를 확인합니다:

cat unavailable.json

status: unavailable과 reason: service_unavailable을 기대하며, 스택 추적이나 SDK 예외 텍스트, 자격 증명이 없어야 합니다.

포트 5002는 3초 기다립니다. 이 테스트에서 읽기 타임아웃을 1초로 바꿉니다:

/opt/labex/aws/venv/bin/python application.py --endpoint-url http://127.0.0.1:5002 --read-timeout 1 > timed-out.json

결과를 읽습니다:

cat timed-out.json

status: unavailable과 reason: read_timeout을 기대합니다. SDK는 한 번만 시도합니다. 타임아웃은 상위 모델 요청이 취소되었거나 무료였다는 증거가 아닙니다. 실제 상위 서비스는 클라이언트가 기다리지 않은 뒤에도 끝날 수 있습니다. 재시도 전에 대기 중이거나 실패한 요청과 한도를 확인하고 무조건 재시도 루프를 추가하지 마세요.

AWS View에는 여전히 단계 1의 실제 요청만 있어야 합니다. 정상 명령의 150초 읽기 대기는 이 연습의 유한한 선택입니다. 실제 애플리케이션은 지연 예산에 따라 타임아웃, 재시도 정책, 사용자 피드백을 정해야 합니다. 공식 Config 참조는 연결, 읽기, 시도 횟수의 별도 제어를 설명합니다.

테스트 출력 삭제하고 작동하는 애플리케이션 보존하기

이 단계에서는 작동하는 클라이언트와 애플리케이션을 보존하고 네 로컬 결과를 삭제합니다.

정리 전에 기능 및 실패 확인을 통과해야 합니다. 지정한 출력만 삭제합니다:

rm accepted.json too-long.json unavailable.json timed-out.json

남은 파일을 나열합니다:

ls

application.py, client.py, response_parser.py, 문서와 사례를 보존합니다. Converse는 영구 워크로드를 만들지 않았으며 출력 삭제로 credits는 돌아오지 않습니다. 소스는 VM이 끝날 때까지 추가 연습에 사용할 수 있습니다.

요약

실제 Bedrock 요청을 요약 명령에 연결하고 입출력을 제한했으며, 자동 재시도를 끄고 유한한 연결 및 읽기 대기를 설정했습니다. 미리 정한 성공으로 추론을 대체하지 않고 장애와 타임아웃을 테스트했으며, 안전한 진단을 반환하고 로컬 출력만 삭제했습니다.