Azure Logic Apps Consumption Integration Accounts는 이전 런타임에서 실행되는 약 60,000개의 Azure Functions 앱으로 구동되었습니다. 팀은 고객의 별도 조치 없이 이 모든 애플리케이션을 최신 Functions v4 런타임으로 성공적으로 마이그레이션했습니다. 이는 호환성을 보장하고 중단을 최소화하도록 설계된 세심한 다단계 접근 방식을 통해 달성되었습니다.핵심 전략은 실제 프로덕션 트래픽을 이전 런타임과 새 런타임 모두에 동시에 라우팅하는 섀도잉을 포함했습니다. 이를 통해 검증되지 않은 경로가 고객에게 영향을 미치지 않으면서 모든 결과를 직접 비교할 수 있었습니다. 핵심적인 측면은 강력한 패리티 바를 설정하여 적격 트래픽의 100%를 분석하여 실제 버그와 본질적으로 비결정적인 워크로드를 구별하도록 하는 것이었습니다.감지된 실제 차이점은 트래픽이 이동되기 전에 세심하게 수정되었습니다. 롤아웃은 점진적이고 되돌릴 수 있었으며, 이는 트래픽 해싱을 기반으로 지역별로 점진적으로 트래픽이 이동되었음을 의미합니다. 중요한 기능은 간단한 구성 변경을 통해 전체 마이그레이션을 몇 분 안에 적용할 수 있도록 되돌릴 수 있다는 것이었습니다.이전 애플리케이션의 사용 중단은 극도로 신중하게 처리되었습니다. 이전 앱이 먼저 중지되었고, 영구 삭제 전에 상당한 관찰 기간이 있었습니다. 이 단계적 접근 방식은 예상치 못한 문제가 고객에게 영향을 미치지 않도록 보장했습니다.이 복잡한 마이그레이션은 Microsoft가 기본 컴퓨팅 인프라를 소유하고 운영했기 때문에 가능했습니다. 계약 및 스키마와 같은 영구적인 고객 데이터는 그대로 유지되었으며 수행된 작업은 순수한 변환이었습니다. 이 제어 평면은 두 런타임의 병렬 실행 및 비교를 가능하게 했습니다.주요 과제는 새 런타임 자체가 아니라 기존 고객 워크로드와의 호환성을 입증하는 것이었습니다. 레거시 런타임은 지원 종료 시점이 다가오고 있어 위험이 증가하고 있었습니다. 격리된 워커 모델을 갖춘 Azure Functions v4로의 전환은 중요한 아키텍처 변경을 나타냈습니다.호스트 모델 변경과 60,000개 애플리케이션에 걸친 운영 규모로 인해 인플레이스 업그레이드 또는 간단한 배포 슬롯과 같은 표준 경량 마이그레이션 옵션은 불충분한 것으로 간주되었습니다. 마이그레이션은 고객에게 보이는 중단이 없도록 했지만, 소수의 고객이 롤백이 시작되기 전에 과도한 부하 상태에서 짧은 엣지 케이스를 경험했습니다. 팀은 고객에게 원활한 경험을 제공하기 위해 복잡성을 흡수했습니다.