아마존 베드록 에이전트코어 런타임 버전 2 공개, 스냅샷 복원으로 2초대 세션 시작 지원

스냅샷 기반 세션 시작 전환

아마존웹서비스는 아마존 베드록 에이전트코어 런타임에 플랫폼 버전 2를 적용해 세션 초기화 방식을 개편했다. 기존 버전은 세션이 열릴 때마다 컨테이너 이미지를 내려받고 초기화 코드를 실행했으나 새 버전은 배포 시점에 환경을 한 번 준비해 스냅샷으로 저장한 뒤 이를 복원한다. 이를 통해 새로운 세션 시작 속도가 약 2초 수준으로 단축되고 일관성이 높아졌으며 사용하지 않는 메모리를 회수해 실제 자원 사용량에 맞게 비용이 청구된다.

콜드 스타트 한계와 스냅샷 동작

대화형 에이전트와 장시간 동작하는 자동화 도구가 늘어나면서 사용자가 첫 응답을 기다리는 지연 시간을 줄이는 작업이 핵심 과제로 떠올랐다. 기존 1 버전 환경에서는 컨테이너 이미지 크기가 커질수록 레지스트리에서 이미지를 가져오는 시간이 늘어나 초기 구동 지연인 콜드 스타트가 심화되는 구조적 한계가 있었다. 새 버전은 이러한 병목을 해소하기 위해 컨테이너 초기화 과정을 배포 시점으로 옮겨 런타임 생성이나 업데이트 단계에서 단 한 번만 실행하도록 재설계했다.

런타임 생성 또는 갱신 시 에이전트코어는 독립된 마이크로 가상머신에서 컨테이너를 구동하고 120초 이내에 정상 핑 신호가 도착할 때까지 대기한다. 정상 신호가 확인되면 스냅샷 크기를 줄이기 위해 운영체제의 파일 캐시를 비운 뒤 메모리와 디스크 상태를 고정해 스냅샷으로 보관한다. 이후 새 세션 요청이 들어오면 해당 스냅샷을 새 가상머신에 즉시 복원하므로 가져온 라이브러리와 객체 및 클라이언트는 메모리 속도로 복원되지만 파일 읽기 캐시는 비워진 상태이므로 이미지 파일은 실제 읽기가 발생할 때 블록 단위로 지연 로드된다.

빌드 훅과 초기화 최적화 기법

개발자는 정적 라이브러리 가져오기와 클라이언트 생성 및 정적 데이터 적재를 초기화 단계에 집중시켜 핸들러의 실행 부담을 덜어내야 한다. 별도 프로세스로 동작하는 도구나 브라우저처럼 프로세스 메모리에 상주하기 어려운 자원은 새로 지원되는 빌드 훅 기능을 활용해 사전 적재할 수 있다. 빌드 훅은 컨테이너에 설정한 웹 엔드포인트로 120초의 제한 시간을 공유하는 메모리 단계와 디스크 검증 단계를 차례로 호출하며 8000번에서 12000번 사이의 비예약 포트를 지정해 연동한다.

런타임 성능은 클라우드 감시 서비스의 지표로 세분화해 점검할 수 있으며 첫 바이트 도달 시간인 전체 지연 시간에서 가상머신 기동과 스냅샷 복원을 나타내는 오버헤드 지연 시간을 빼면 순수 코드 실행 시간을 분리해 측정할 수 있다. 이미 실행 중인 세션은 약 200밀리초 안에 응답하므로 음성이나 채팅 서비스에서 1초 미만의 응답이 필요하다면 사용자가 채팅창을 여는 시점에 백엔드에서 미리 고유 세션 식별자를 생성해 백그라운드 호출로 세션을 가동하는 예열 방식을 적용한다.

동적 데이터 처리와 적용 제약

스냅샷에 포함된 상태는 다음 배포 전까지 모든 세션에 동일하게 공유되므로 보안과 데이터 정합성을 위한 엄격한 분리가 요구된다. 난수 생성기, 일회용 보안값, 고유 식별자, 인증 토큰은 스냅샷 시점에 고정되면 심각한 보안 문제가 발생하므로 반드시 요청을 처리하는 핸들러 내부에서 운영체제 엔트로피를 통해 생성해야 한다. 또한 변경 가능한 도구 목록이나 기능 플래그는 세션 내부에서 벽시계 시간을 기준으로 만료 시간을 두어 캐시해야 하며 단조 시계는 스냅샷 보관 기간을 반영하지 못하므로 경과 시간 측정 시 주의해야 한다.

에이전트코어 런타임의 세션 수명은 최소 60초에서 최대 8시간까지 지정할 수 있는 유휴 시간 제한에 의해 관리되며 기본값은 15분으로 설정되어 있고 전체 세션의 최대 존속 시간은 8시간으로 제한된다. 또한 초기화 시점에 많은 객체를 메모리에 유지하면 핸들러 속도는 개선되지만 스냅샷 크기가 커지고 매 세션마다 점유 메모리 비용을 부담해야 하는 상충 관계가 존재한다. 배포 시점마다 스냅샷을 생성하는 수 분의 빌드 시간이 추가되며 네트워크 소켓은 복원 후 유효하지 않으므로 초기화 시점에 연결을 닫거나 재연결 로직을 확인해야 한다.