Slack AI: The Path to Multi-Cloud
Author: Shaurya Kethireddy (Slack) | Source: Slack Engineering Blog | Published: 2026
한 줄 요약
Slack AI가 3년에 걸쳐 SageMaker → Bedrock(Provisioned) → Bedrock(On-Demand) → 멀티클라우드(AWS + GCP Vertex)로 진화하며, 추상화 레이어와 지능형 라우팅으로 best-of-breed 모델 접근과 provider 장애 격리를 확보.
핵심 주장/내용
- Phase 1 (SageMaker): escrow VPC로 zero-knowledge 보안 확보했으나 스케일 지연·GPU 희소성·over-provisioning + Bedrock 대비 feature lag(신모델이 Bedrock에 몇 주~몇 달 먼저)
- Phase 2 (Bedrock Provisioned): GPU 인스턴스 대신 Model Unit(MU) 추상화, 즉시 모델 접근. “측정 우선, 점진 마이그레이션, 지속 모니터링”으로 zero-incident 전환. 단 over-provisioning(글로벌 피크 기준) + 1~6개월 commitment lock-in
- Phase 3 (Bedrock On-Demand): idle 용량 문제 해결 + commitment 해제로 신모델 하루 만에 전환. Hybrid(PT for 지연 민감 + OD for bursty) + Spillover 패턴(예약 초과 시 OD로 자동 spill)
- Phase 4 (멀티클라우드): GCP Vertex 추가 — failover가 아닌 혁신 가속 엔진. model-to-feature 최적화로 복잡 추론 ~10% 품질↑, 저토큰 워크로드 ~67% 지연↓
- Intelligent Routing Layer: 메트릭 기반 모델 선택 + backup 모델, A/B 실험(릴리스 속도 주→일), Circuit Breaker(TTFT/5xx/p90 임계 초과 시 trip → partial-open으로 점진 복구). API Normalization 레이어로 provider별 에러/rate limit 통일
- 5대 교훈: XFN 정렬(legal/compliance), 추상화 레이어가 핵심, 아키텍처는 living document, 신뢰성엔 provider 비종속, “느린 LLM = 고장”(p90 spike를 soft failure로)
주요 수치 / 사실
- 멀티클라우드: 복잡 추론 ~10% 품질 개선, 저토큰 고속 워크로드 ~67% 지연 감소
- 일부 기능 피크/오프피크 10x 분산
- 트레이드오프: 운영 모니터링 복잡성, 비용 attribution 어려움, on-call provider-agnostic 역량 요구
관련 위키
Source: 원문 보기