멀티 클라우드에 대한 제안은 항상 깔끔하게 들립니다. 벤더 종속성을 피하고, 특정 작업에 가장 저렴한 제공업체에서 워크로드를 실행하여 비용을 최적화하며, 독립적인 장애 도메인에 분산하여 복원력을 향상시킵니다. 이론적으로는 설득력 있는 주장입니다. 실제로는 멀티 클라우드 배포를 운영하는 팀들은 종종 그 반대에 가까운 것을 설명합니다. 운영 복잡성이 두 배가 되고, 관찰 가능성이 절반으로 줄어들며, 하나가 아닌 두 개의 클라우드가 존재하기 때문에 발생하는 신뢰성 문제의 범주입니다.제가 긴밀하게 협력했던 한 팀은 당시 더 나은 GPU 가용성과 가격 때문에 AWS로 멀티 클라우드 워크로드를 이전하고 GCP에서 ML 추론 파이프라인을 구축했습니다. 그리고 다음 8개월 동안 예상치 못한 유형의 사고에 대처해야 했습니다. 애플리케이션의 잘못도 아니고, 어느 클라우드 제공업체의 잘못도 아니지만, 그들 사이의 경계에 존재하는 장애였습니다. 로드 시에만 나타나는 데이터 전송 지연 시간 급증. 크로스 클라우드 호출 중에만 발생하는 인증 토큰 만료 엣지 케이스. 프로덕션 전 테스트는 모두 통과했지만 새벽 3시에 프로덕션에서 실패한 네트워크 정책 상호 작용. 개별적으로는 어려운 문제가 아니었습니다. 각 클라우드의 진단 도구가 내부를 가리키고 있었고, 장애는 어느 도구도 보고 있지 않은 공간에 존재했기 때문에 어려웠습니다.