마이크로소프트가 Copilot Studio Redis 비용을 72% 줄였다

마이크로소프트는 Copilot Studio의 에이전트 플로우와 Power Automate 워크플로를 지원하는 공유 서비스의 Redis를 Azure Cache for Redis (Classic)에서 Azure Managed Redis(AMR)로 이전했다. 이전에 불필요한 Redis 작업과 연결 복구 문제를 줄였으며, AMR 교체 비용까지 포함한 지속 운영 비용은 이전 기준보다 약 72% 낮아졌다.

이 공유 서비스는 에이전트 플로우의 생성·관리·공유를 담당하며, 여러 서비스 애플리케이션이 커넥터 메타데이터, 환경 정보, 접근 결과, 권한 정보, 만료되는 조정 상태를 함께 캐시한다. 각 지역의 주·보조 서비스 배포는 각자 Redis 캐시를 두며, 아래 트래픽은 두 배포의 합계다. 수치는 2026년 9월 6일부터 12일까지 7일간 성공한 Redis 클라이언트 작업을 집계했다.

유럽의 평균 읽기·쓰기 요청은 초당 각각 10,922건과 4,010건이었고, 미국은 각각 10,263건과 3,678건이었다. 하루 평균 읽기·쓰기 횟수는 유럽이 9억 4,370만 건과 3억 4,650만 건, 미국이 8억 8,670만 건과 3억 1,780만 건이었다. 마이크로소프트는 데이터를 서비스마다 나누면 중복 저장과 갱신 작업이 늘고 무효화·배포 설계가 필요해진다며, 같은 데이터와 조정 상태를 사용하는 서비스의 지역별 공유 구조를 유지했다. 데이터·보안·가용성 요구가 다르면 캐시를 분리할 수 있다고 설명했다.

이전 작업은 캐시를 바꾸기 전에 불필요한 호출을 줄이는 데서 시작했다. 서유럽의 24시간 기준으로 환경 매핑 캐시는 Redis 쓰기를 약 2억 9,000만 건 발생시켰다. 이는 해당 지역 서비스 Redis 작업의 약 16%였지만 이에 상응하는 읽기는 거의 없었다. 먼저 서비스 인스턴스 메모리의 1차 캐시(L1)는 유지하면서 해당 쓰기를 막았고, 이후 분산 캐시 경로를 완전히 제거했다.

또한 L1 캐시를 확인하기 전에 Redis GET을 실행하던 읽기 경로를 고쳤다. L1 적중률이 95% 이상인 상황에서, 적중 여부를 먼저 확인해 Redis 호출을 피하도록 바꿨다. 일부 플로 접근 및 결제 문맥 조회에는 1분 수명의 로컬 캐시와 명시적 무효화를 적용했고, 삭제된 워크플로가 백엔드 작업을 계속 유발하지 않도록 확인된 ‘찾을 수 없음’ 결과도 캐시했다. 마이크로소프트의 7월 업데이트에 따르면 이런 변경 뒤 명령 처리 중 서버가 바쁜 시간 비율은 유럽 사례에서 약 75%에서 15%로, 미국 사례에서 75~95%에서 약 40%로 내려갔다. 미국과 유럽의 측정 구간은 서로 다르다.

클라이언트의 연결 안정성도 개선했다. StackExchange.Redis 2.13.17은 쓰기 실패 뒤 연결을 닫아 요청·응답 대기열이 어긋나지 않도록 했고, 다른 연결 안정성 수정도 포함했다. StackExchange.Redis 3.0은 입출력 처리 경로를 바꾸고 DOM 기반 응답 파서를 리더 기반 구현으로 대체했다. 목표는 특히 크거나 복잡한 응답의 처리 부담을 줄이고 입출력 경계와 스레딩을 더 세밀하게 제어하는 것이었다. 마이크로소프트는 공개된 StackExchange.Redis 벤치마크를 업그레이드 판단에 참고했으며, 이를 자사 서비스의 성능 향상을 입증하는 자료로 제시하지는 않았다.

서비스는 연결을 오래 유지하고 재연결 시도를 직렬화해 속도를 조절했으며, 연결 핸드셰이크 대기 시간에도 상한을 뒀다. 이를 통해 실패한 요청마다 새 연결이 생기는 상황을 막으면서 복구 과정의 경합을 줄였다. 복구 절차는 토큰 갱신과 신원 제공자의 지연도 처리해야 했다.

AMR 이전은 제한된 배포 그룹부터 진행했다. 마이크로소프트는 용량, 인증, 호환성을 먼저 점검하고, 일부 공유 메타데이터를 일정 기간 양쪽 캐시에 쓰되 읽기는 Classic에서 유지해 새 캐시를 예열했다. 이는 전체 데이터 복제가 아니었다. 다른 조회 데이터는 원천 서비스에서 다시 채웠고, 만료되는 조정 상태에는 이 방식을 그대로 적용할 수 없었다. 새 캐시가 채워질 때 하위 서비스 부하도 살폈다.

각 그룹은 오류, 캐시 미스, 꼬리 지연 시간, 하위 서비스 부하를 기준으로 전환 여부를 판단했다. 라우팅 결정은 프로세스별로 캐시되므로 계획된 재시작으로 목적지를 바꿨다. 연결 설정이 없으면 잘못된 캐시를 읽는 대신 오류가 드러나도록 했으며, 문제가 지속되면 확장을 멈추거나 Classic으로 되돌렸다.

• 준비: 대상 범위의 용량, 인증, 클라이언트 호환성을 확인하고, 연결 성공 여부뿐 아니라 전체 클라이언트 설정을 검증했다.
• 선택 데이터 예열: 일부 공유 메타데이터를 양쪽 캐시에 쓰면서 읽기는 Classic에서 처리했다. 전체 복제가 아니며, 만료되는 조정 상태는 별도로 고려해야 했다.
• 전환 및 재시작: 라우팅을 변경하고 계획된 재시작으로 연결을 새로 만들었다.
• 관찰: 오류, 캐시 미스, 꼬리 지연 시간, 하위 서비스 부하를 살폈다. Classic이 남아 있는 동안 문제가 지속되면 확장을 멈추거나 되돌렸다.
• 폐기: 임시 중복 쓰기와 배포 의존성을 제거한 뒤, 실행 중인 서비스나 향후 배포가 기존 캐시를 더는 필요로 하지 않는다는 근거를 충분히 확인하고 Classic 용량을 폐기했다.

유럽 지역 전환에서는 예상하지 못한 연결 한도가 드러났다. 인증 설정에 상속된 유지 관리 리스너가 서비스에서 사용하지 않는 Redis의 SUBSCRIBE 명령을 실행했고, 이 구독이 AMR의 백엔드 연결 공유를 방해했다. 지역 운영 규모에서 연결 수요가 가용 백엔드 연결을 소진하면서 고객은 플로를 만들고 저장하고 활성화할 때 오류와 시간 초과를 겪었다.

마이크로소프트는 영향을 받은 배포를 Classic으로 되돌리고 애플리케이션 인스턴스를 단계적으로 재시작해 연결을 다시 만들었다. 영구 수정에서는 신원 인증, 토큰 갱신, 일반 캐시 작업은 유지하면서 AMR에서 사용하지 않는 구독 동작을 비활성화했다. 기본 읽기·쓰기 성공뿐 아니라 인증 어댑터와 연결 기본값이 추가하는 동작도 운영 규모에서 확인해야 한다는 점을 얻었다고 설명했다.

전환 뒤에는 임시 중복 쓰기를 제거하고 Classic 리소스 생성을 막았으며, 기존 캐시의 출력값을 참조하는 구성 요소도 정리했다. 실행 중인 서비스뿐 아니라 앞으로의 배포도 삭제된 캐시의 설정이나 자격 증명을 찾지 않는지 확인했다. 캐시가 유휴 상태라는 사실만으로는 충분하지 않아, 남은 연결과 리소스 식별자를 점검하고 기존 캐시가 더는 필요하지 않다는 근거를 지속적으로 확인했다. 폐기가 끝나면 캐시를 다시 만들고 채워야 하므로 간단한 롤백 경로도 사라진다. 이번 이전 대상 밖의 주권 클라우드 지역 워크로드는 계속 Classic Redis를 사용한다. 현재 클라우드 제공 범위는 AMR 계획 FAQ에서 확인할 수 있다.

비용 비교는 이전 배포의 기준 비용을 100%로 두고 AMR 교체 비용을 포함했다. 비율은 반올림했으며 고객 가격을 뜻하지 않는다. Standard 및 Basic 계층은 제외했다.

마이크로소프트는 이번 작업이 단순한 캐시 주소 변경이 아니라 요청 경로를 살펴 불필요한 트래픽을 줄이고, 클라이언트와 복구 동작을 개선하며, 이전과 폐기를 단계적으로 관리한 결과라고 밝혔다. 회사는 이 변화가 Copilot Studio 에이전트 플로와 Power Automate 워크플로를 위한 운영 여유를 늘리고 지속 인프라 비용을 낮췄다고 설명했다.