Spreading the load: How Salesforce met Multi-AZ HA with SageMaker Inference Components

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Salesforce는 SageMaker Inference Components의 GPU 공유로 인프라 비용을 기존의 8분의 1로 줄이고, SchedulingConfig 기반 분산 배치로 모든 운영 모델의 2-AZ 지원 요건을 충족했다.

📌 핵심 요약

• Salesforce는 Agentforce의 다중 가용 영역 고가용성을 확보해야 했지만, 기존 IC 기본 배치는 작업별 인스턴스 분산만 고려해 모델별 AZ 균형을 보장하지 못했다.
• SchedulingConfig는 AvailabilityZoneBalance로 AZ 간 복제본 균형을 조정하고, PlacementStrategy의 SPREAD와 BINPACK으로 각 AZ 내부의 인스턴스 분산 또는 집약을 선택한다.
• Salesforce는 SPREAD를 선택했으며, 원문 예시는 2개 AZ의 4개 인스턴스에 복제본 4개를 분산하고, 복제본 2개인 경량 모델에는 MaxImbalance 0으로 AZ마다 1개씩 배치하도록 설정한다.
• 2-AZ 지원에는 CopyCount와 최소 인스턴스 수가 각각 2 이상 필요하며, CONSOLIDATION은 반복적인 확장·축소 이후에도 AZ 균형 제약을 지키며 복제본을 통합하고 유휴 인스턴스를 회수한다.
• 현재 유일한 EnforcementMode인 PERMISSIVE는 최선 노력 방식이므로 용량 부족 시 AZ 균형이 불완전할 수 있다. Salesforce는 AZ별 GPU 용량을 사전 예약했으며, 적용 결과 2-AZ 요건 충족과 비용 효율 유지, 확장·축소 및 모델 업데이트 중 다중 AZ 배치 유지를 보고했다.

🧩 주요 포인트

1. 기본 배치가 모델별 AZ 균형을 보장하지 못함 → 다중 AZ 엔드포인트 구성과 개별 모델의 장애 격리를 함께 다뤄야 함.
2. SPREAD와 AvailabilityZoneBalance가 서로 다른 배치 범위를 제어함 → 인스턴스 장애와 AZ 장애에 대한 복원력을 함께 확보하는 구조.
3. PERMISSIVE의 용량 제약과 작업별 SchedulingConfig 적용 → AZ별 GPU 용량 확보와 CONSOLIDATION을 통한 지속적인 배치 관리가 중요함.

🧠 상세 정리

1. 비용 절감 이후 드러난 모델별 가용성 문제

Salesforce는 에이전트를 위한 AI 기반인 Agentforce를 여러 가용 영역에 걸쳐 고가용성으로 운영하려 했으며, 모든 운영 모델에 2-AZ 지원을 요구하는 내부 기준을 가지고 있었다. SageMaker Inference Components는 여러 모델을 공유 GPU에 함께 배치해 인프라 비용을 기존의 8분의 1로 줄였지만, 기본 배치 방식만으로는 이 가용성 기준을 충족하지 못했다. 기존 알고리즘은 각 배포 작업을 독립적으로 최적화하면서 새 복제본을 인스턴스에 고르게 배치했으나, AZ 사이의 균형은 고려하지 않았다. 따라서 엔드포인트 자체가 여러 AZ에 걸쳐 있어도 특정 모델의 복제본은 한 인스턴스나 한 AZ에 몰릴 수 있었다. 원문은 이러한 배치가 단일 인스턴스 장애 또는 AZ 전체 장애로 모델을 완전히 사용할 수 없게 만드는 위험과 내부 규정 미충족 문제를 낳는다고 설명한다.

2. SchedulingConfig의 두 가지 배치 제어

새로운 IC 배치 기능은 CreateInferenceComponent API의 SchedulingConfig 매개변수를 통해 복제본의 인스턴스 및 AZ 배치를 제어한다. 이 가운데 AvailabilityZoneBalance는 AZ 간 복제본 분포를 조정하며, 허용할 복제본 수 차이를 설정해 균형 목표를 표현한다. PlacementStrategy는 각 AZ 내부의 배치를 담당하고, SPREAD는 가능한 한 많은 인스턴스로 복제본을 분산해 장애를 격리한다. 반대로 BINPACK은 복제본을 더 적은 인스턴스에 모아 GPU 활용 효율을 높이는 방식이며, Salesforce는 집약도보다 장애 격리를 우선해 SPREAD를 선택했다. 두 매개변수는 서로 다른 범위의 분산을 제어하므로, AZ 간 균형과 AZ 내부의 인스턴스 분산을 함께 설정하는 것이 이 해결책의 핵심이다.

3. 복제본 수에 따른 배치 설정 예시

원문의 기본 시나리오는 2개 AZ에 인스턴스가 각각 2개씩 있는 엔드포인트에 모델 복제본 4개를 배포하는 구성이다. 예시에서는 SPREAD와 PERMISSIVE를 사용하고 MaxImbalance를 1로 설정하며, 설명된 배치 결과는 인스턴스마다 복제본 1개, AZ마다 복제본 2개다. MaxImbalance 1은 두 AZ 사이에 복제본 수가 최대 1개 차이 나도록 허용 범위를 설정한다는 의미다. 복제본 2개만 필요한 경량 모델은 MaxImbalance 0으로 각 AZ에 정확히 1개씩 배치하는 균형을 목표로 하며, 이는 뒤에 등장하는 IC3 예시에도 적용된다. 원문은 복제본 하나가 가속기 4개처럼 여러 GPU를 요구하는 모델에도 같은 배치 논리가 적용되며, SPREAD가 복제본별 인스턴스 분산을 돕고 AZ 균형 설정이 영역 간 분산을 담당한다고 설명한다.

4. 확장·축소와 지속적인 재배치의 구분

SageMaker는 복제본을 늘릴 때 SchedulingConfig에 따라 AZ 분포를 고르게 유지하도록 새 복제본을 배치하고, 줄일 때는 AZ 간에 대칭적으로 복제본을 제거한다. 원문의 확장 예시는 CopyCount를 8로 변경해 각 AZ에 복제본 4개를 배치하는 형태이며, 고가용성이 중요한 모델에는 CopyCount를 1로 설정하지 말라고 명시한다. 복제본 하나는 한 AZ에만 존재할 수 있으므로, 단일 복제본 구성은 2-AZ 지원 요건을 즉시 깨뜨린다. 다만 SchedulingConfig는 개별 확장·축소 작업의 배치 계획을 제어하며, 반복 작업 이후 장기적인 통합과 재균형을 위해서는 엔드포인트의 ScaleInPolicy에 CONSOLIDATION을 설정한다. 이 구성에서는 백그라운드 작업이 AZ 균형 제약을 지키면서 복제본을 주기적으로 통합하고 유휴 인스턴스를 회수하며, 예시의 관리형 인스턴스 확장 범위는 최소 2개에서 최대 8개다.

5. 알고리즘 개선과 여러 모델의 배치

새 배치 알고리즘의 첫 번째 개선은 당장 추가할 복제본의 배치만 보는 대신 최종 분포의 균형을 고려한다는 점이다. 두 번째는 AZ 사이에 최선 노력 방식으로 복제본을 고르게 분산하고, 엔드포인트와 IC 업데이트에서도 다중 AZ 배치를 유지하도록 한다는 점이다. 세 번째는 각 AZ 내부에서 SPREAD 또는 BINPACK을 적용해 장애 격리와 GPU 활용 효율 중 우선할 방향을 선택하게 한다는 점이다. 원문은 같은 엔드포인트에 IC1의 복제본 4개, IC2의 복제본 2개, IC3의 복제본 2개를 서로 다른 작업으로 배포하는 상황을 통해 기존 방식과 새 방식의 차이를 설명한다. 이 중 IC3는 SPREAD와 MaxImbalance 0을 사용해 AZ마다 복제본 1개를 목표로 하며, 전체 AZ 하나가 장애를 겪더라도 다른 AZ의 복제본으로 모델 가용성을 유지하도록 구성한다.

6. 용량 예약과 최선 노력 방식의 한계

원문은 AZ별 용량 확보가 어려운 리전에서 온디맨드 용량 예약인 ODCR을 사용할 것을 강하게 권고하며, Salesforce는 대상 AZ마다 예약 GPU 용량을 미리 확보했다. 예약이 없으면 수요가 높은 리전의 온디맨드 용량 제약으로 인해 원하는 복제본 분포를 만들기 어려울 수 있다. 배치 알고리즘은 부분 배포를 지원하므로, 완전한 AZ 균형을 달성할 용량이 없더라도 전체 작업을 실패시키는 대신 사용 가능한 인스턴스에 복제본을 배치한다. 현재 유일한 EnforcementMode인 PERMISSIVE도 이러한 최선 노력 방식을 사용하므로, MaxImbalance를 설정했다는 사실만으로 실제 배포에서 항상 균형이 보장되는 것은 아니다. 따라서 이 기능은 ODCR 없이도 사용할 수 있지만 분포가 최적이 아닐 수 있으며, 설정한 균형 목표와 실제 확보된 AZ별 용량을 구분해서 이해해야 한다.

7. 권장 구성과 실제 배치 상태 관측

원문의 권장 구성은 SPREAD, PERMISSIVE, MaxImbalance 0 또는 1이며, 2-AZ 지원을 위해 CopyCount와 ManagedInstanceScaling.MinInstanceCount를 각각 2 이상으로 설정한다. 모델 아티팩트 캐싱을 활성화하는 DataCacheConfig.EnableCaching은 확장 속도를 높이고, RoutingConfig의 LEAST_OUTSTANDING_REQUESTS는 AZ 간 자동 장애 조치 라우팅을 지원하는 보완 기능으로 제시된다. 다만 캐싱과 라우팅은 SchedulingConfig 배치 기능 자체에 속하지 않는 일반 엔드포인트 또는 IC 설정이다. 상세 관측을 활성화한 SageMaker AI Insights에서는 AZ 불균형 비율, IC별 AZ 복제본 수, 재균형 발생 시점과 소요 시간을 확인할 수 있다. 또한 AZ 및 인스턴스 유형별 용량 부족 오류인 ICE 횟수로 예약 용량 조정 필요성을 판단할 수 있으며, 이러한 지표는 SageMaker AI Insights와 Amazon CloudWatch에서 접근할 수 있다.

8. Salesforce가 보고한 적용 결과

원문은 IC 배치 기능을 적용한 결과 Salesforce의 모든 모델 배포가 내부 2-AZ 지원 요건을 충족했다고 보고한다. 또한 단일 인스턴스나 단일 AZ 장애가 특정 모델 전체를 중단시키는 단일 장애 지점을 제거했다고 설명한다. 여러 모델을 함께 호스팅하는 비용 절감 구조는 유지하면서 SPREAD를 통해 인스턴스 사이의 장애 격리를 강화한 것이 비용과 가용성 측면의 결과다. 확장·축소 과정에서도 다중 AZ 분포를 유지하고, 모델 업데이트로 AZ 균형이 깨질 위험을 해소한 점 역시 성과로 제시된다. 이러한 결과는 Salesforce의 적용 사례로 읽어야 하며, 기능 자체가 PERMISSIVE 방식으로 동작하고 용량 부족 시 불균형 배치를 허용한다는 앞선 구현 제약과 함께 해석해야 한다.

🧾 핵심 주장 / 시사점

• 다중 AZ 엔드포인트를 마련하는 것과 각 모델의 복제본을 여러 AZ에 배치하는 것은 별개의 조건이며, 모델 단위의 분포가 실제 장애 격리에 중요하다.
• 공유 GPU를 통한 비용 절감과 SPREAD를 통한 장애 격리는 함께 적용할 수 있으며, Salesforce 사례는 기존 비용 효율을 유지하면서 배치 방식을 개선한 사례다.
• 배치 설정, AZ별 용량 확보, 지속적인 재균형, 실제 분포 관측이 함께 작동해야 최선 노력 방식의 한계를 파악하고 고가용성 상태를 관리할 수 있다.

✅ 액션 아이템

• 운영 모델별 2-AZ 지원 여부와 SPREAD 및 AvailabilityZoneBalance 설정 확인.
• 확장·축소 시 CopyCount와 최소 인스턴스 수를 각각 2 이상으로 유지하고 CONSOLIDATION 적용 여부 검토.
• PERMISSIVE의 용량 제약을 고려해 AZ별 GPU 용량 확보 상태와 실제 복제본 분포 확인.

❓ 열린 질문

• 모든 운영 모델의 복제본이 실제로 2-AZ에 분산되어 있는가?
• 확장·축소 이후에도 CopyCount와 최소 인스턴스 수가 각각 2 이상으로 유지되고 CONSOLIDATION이 적용되는가?
• PERMISSIVE에서 AZ 균형이 불완전해질 수 있는 용량 제약에 대비해 AZ별 GPU 용량을 충분히 확보했는가?