2021년이 가르쳐준 클라우드 SLA 핵심 교훈과 모범 사례

클라우드 SLA에 관해서는 디테일에 악마가 숨어 있습니다. 어떤 지표를 추적해야 할지, 그 지표가 수익에 어떤 금전적 영향을 미치는지 평가하는 것이 필수적입니다.

미 국회의사당 공격 여파로 Amazon Web Services가 Twitter 대안인 우파 마이크로블로깅 Parler 호스팅을 중단했습니다. Amazon에 따르면 Parler는 불법, 유해, 공격적인 콘텐츠를 다루기 위한 적절한 조정 시스템을 갖추지 못해 양방향 서비스 수준 계약(SLA)을 위반했습니다. AWS가 Parler를 클라우드 서비스에서 그렇게 빨리 제거할 수 있었다는 사실은 2021년 그들이 호스팅하는 콘텐츠에 대해 클라우드 제공업체가 휘두르는 엄청난 힘에 주목을 끌었습니다. 이 케이스는 많은 서비스 제공업체가 클라우드 SLA를 통해 가진 힘뿐만 아니라, 디테일에 주의를 기울이고 클라우드 제공업체와 좋은 업무 관계를 유지할 필요성을 강조합니다.

적절한 실사 없이 클라우드 SLA에 서두르지 마십시오

클라우드 SLA는 서비스 제공업체가 특정 서비스 제공에 대해 책임을 지거나 지지 않는 상황을 상세히 기술합니다. 이 계약들은 많은 다른 조항을 가진 살아있는 문서입니다. 중요하게, SLA는 서비스 제공업체 책임뿐만 아니라 고객 책임, 계약 위반에 대한 벌칙, 응답 시간 및 해결 시간 같은 성과 지표도 다룹니다. 조직의 법률 고문이 문서의 세부 사항에 익숙한 것이 중요합니다. 고객도 벤더도 나중에 당혹스러워하지 않아야 합니다. 우선, SLA가 클라우드 제공업체의 보안 표준을 상세히 나열하는지 확인하십시오. 예를 들어, 클라우드 제공업체가 법으로 반드시 의무화되지 않더라도, 고객은 제공업체가 HIPAA 표준을 준하하길 원할 수 있습니다. 그렇다면 그 조건들을 미리 합의해야 합니다. 또한 계약은 고객 조직이 저장된 데이터의 소유권을 유지함을 확인해야 합니다. 마지막으로, 고객 조직이 향후 서비스 제공업체 준수를 감사할 권리를 유지하는지 확인하는 것이 현명합니다.

참고: 멀티클라우드 계획, 코로나 안개로 어려움 겪다

양 당사자가 같은 페이지에 있는지 확인하십시오

클라우드 SLA는 일반적으로 양방향입니다. 즉, 고객과 벤더 모두에 대해 (바라건대 명확한) 기대가 있습니다. 각 당사자는 각자의 책임에 대해 인식해야 합니다. 최소한 허용 가능한 성과 매개변수, 위반 시 벌칙, 구제책, 서비스 크레딧이 무엇인지 아는 것이 포함됩니다. 양 당사자는 성과 데이터 지표, 책임, 기대, 프라임 타임과 논프라임 타임 동안 예상 서비스 수준에 대해 같은 페이지에 있어야 합니다. 예방적 유지보수의 정확한 일정이 있어야 하고, 일이 잘못될 경우 분쟁 해결 프로세스가 마련되어 있어야 합니다.

다운타임, 지연 시간, 사고 대응에 대한 최대 허용 수준 결정

99.9% 가동 시간 보장은 적절해 보일 수 있지만, 이는 연간 약 9시간 다운타임, 월 43분으로 분해됩니다. 글로벌 이커머스 기업들이 일반적으로 서비스 제공업체로부터 99.999% 가동 시간을 요구하는 것은 당연합니다. 지연 시간과 사고 대응도 중요한 지표입니다. 최소한 주어진 사고에 대응하는 데 얼마나 걸리는지 추적하는 것이 필수적입니다. 또한 조직은 어떤 지연 시간 수준이 허용 가능한지 알아야 합니다. 보통 밀리초로 측정되는 지연 시간(네트워크 내 연결 품질)은 경과한 시간입니다. 지연 시간에는 정보 처리, 요청 처리, 주어진 작업 단위 완료 시간이 포함될 수 있습니다. 명확성을 위해 기업들은 종종 지연 시간 지표를 백분위수로 그룹화합니다. 예를 들어 "중앙값 지연 시간" 또는 50번째 백분위수 지연 시간은 가장 빠른 50% 요청의 최대 지연 시간을 설명합니다. 또 다른 인기 지표인 99번째 백분위수 지연 시간은 가장 빠른 99% 모든 요청의 최대 지연 시간을 가리킵니다. 가능할 때마다 지연 시간의 비즈니스 영향을 정량화해야 합니다. 조직은 다운타임, 지연 시간, 데이터 손실의 영향을 측정하는 명확한 KPI를 항상 가져야 합니다.

지표를 신중하게 정의하십시오

조직이 집중할 올바른 지표를 선택했으면, 그 지표들을 클라우드 SLA 내에서 적절히 정의하는 것이 중요합니다. 가동 시간 비율, 평균 해결 시간(MTTR), 사고 대응 시간 같은 지표들은 절대적으로 신중하게 정의되어야 합니다. 빠른 예로, SLA의 문구에 따라 자동 이메일 응답이 클라우드 서비스 제공업체의 사고 대응 시간 지표 충족으로 잠재적으로 자격이 될 수 있습니다. 모든 가능성에서 이메일은 당면 문제를 적절히 해결하지 못할 것입니다. 따라서 세부 사항을 파고들어 지표가 정확히 어떻게 정의되는지 평가하는 것이 필수적입니다. 또한 가능할 때마다 자동으로 모니터링되어 경고를 트리거할 수 있는 지표를 사용해야 합니다. 예를 들어 지연 시간 경고가 트리거되면 IT 담당자가 경고되어 당면 네트워크 문제를 트러블슈팅할 수 있습니다. 일반적으로 말하면, 더 많은 자동화가 마련되어 있을수록 더 좋습니다.

클라우드 제공업체와 좋은 관계 유지

합의된 서비스 수준이 충족되지 않으면 고객은 구제 서비스와 서비스 크레딧을 받을 가능성이 높습니다. 서비스 크레딧은 고객 청구서에서 공제되는 금전적 크레딧입니다. 서비스 제공업체를 정직하게 유지하기 위해 SLA에 서비스 벌칙을 두는 것이 중요하지만, 많은 고객은 좋은 서비스에 대한 보상으로 클라우드 서비스 제공업체에 금전적 보너스를 제공하는 것을 고려합니다. 또한 적립 환급 조항도 제공업체로부터 호의를 이끌어낼 수 있습니다. 적립 환급은 서비스 제공업체가 주어진 기간 동안 효과적으로 수행하면 서비스 레벨 크레딧을 되찾는 SLA 조항입니다. 또한 앞서 언급했듯 SLA는 살아있는 문서입니다. 특히 회사가 빠르게 성장한다면 주기적으로 재협상하는 것이 중요합니다. 하지만 그런 협상은 격렬할 수 있으므로, 이 재협상을 연 1~2회로 제한하는 것이 현명합니다.

간단히 말해, 클라우드 SLA에 관해서는 디테일에 악마가 숨어 있습니다. 어떤 지표를 추적해야 할지(예: 중앙값 지연 시간, 가동 시간 비율, 사고 대응 시간, MTTR)를 아는 것이 필수적이며, 그 지표들이 수익에 정확히 어떤 금전적 영향을 미치는지 평가해야 합니다. 또한 클라우드 제공업체와 좋은 관계를 유지하는 것이 핵심입니다. 결국 클라우드 SLA는 양 당사자에게 이익이 되는 공생 관계를 조성해야 합니다.