7일 전

칼럼 | 데브옵스팀이 SLA를 없애고 SLO를 선택해야 하는 이유 

Alex Nauda | InfoWorld
SLA(Service Level Agreement)는 1980년대 유선전화 통신사 사이에서 인기를 얻기 시작했다. 지난 20년 동안 미국 주요 도시의 도로 곳곳에 9x5(99.999%)를 홍보하는 광고판이 걸렸다. 그러나 지금 시점에서 SLA에 포함된 9의 수가 통신사 내에서, 그리고 외부적으로 고객에게 안정성을 전달하는 지표로서 적절할까? 
 
ⓒ Getty Images Bank

SLA가 존재하는 이유가 있다. 바로 변호사이다. 누구나 서비스 계약을 맺을 때는 서비스 업체의 수행 능력이 떨어지는 경우 계약을 파기하고 나올 길이 필요하다. 

계약에서 SLA와 관련해 발생하는 줄다리기는 익숙한 풍경이다. 고객의 법무팀(구매팀과 함께)은 보장되는 9의 개수를 최대화하고자 하고, 서비스 업체의 운영팀은 약속하는 9의 개수를 최대한 줄이고자 한다. 보통 고객은 SLA 미충족분에 대해 요금을 환급받거나 크레딧을 받는 정도로 협상을 한다. 

서비스 업체는 고객이 서비스에 온전히 만족하지 않더라도 약속한 9의 개수를 달성하면 약정한 가격을 모두 받는다. 약간 미달하면 고객이 예를 들어 비용의 10%를 환급받고 SLA에 크게 미달할 경우에는 고객은 50%를 돌려받거나 계약을 파기하고 다른 서비스 업체를 찾아 나설 수 있다. 대체로 고객은 서비스 업체가 SLA를 충족하는 편을 선호해왔다. 

이런 계약상의 SLA 의무는 서비스 업체 조직 내에서 성능, 안정성, 가동시간 및 응답성 목표로 이어진다. 또한 그 결과로 안정성에 관한 사고 프로세스가 극히 방어적으로 고착되면서, 절대적인 다운타임 방지와 무조건 최대한 빠른 사고 해결에 과도하게 초점을 두는 척도(평균 장애 간격, 평균 해결 시간)가 가장 널리 사용되는 상황에 이르렀다. 

SLA로는 ‘어느 지점이 되면 고객이 실제로 만족하고, 따라서 SLA 초과 달성 노력을 멈출 수 있는가?’라는 질문에 답하지 못한다. 즉 SLA로는 사용자의 만족도를 모델링할 수 없다.

클라우드 서비스에는 안성맞춤인 지점이 있다. 기존 사용자를 만족시키는 서비스의 안정성을 유지하면서 새로운 기능(사용자를 유인하고 기쁘게 하는)을 신속하게 제공할 수 있는 균형점이다. 하지만 SLA로는 이 지점을 찾을 수 없다. 

비현실적으로 많은 9의 개수로 포장되는 완벽한 SLA에 지나치게 집중할 경우, 시간이나 비용, 엔지니어링 번아웃 측면에서 여파가 크다. 완벽해지기 위해 노력하는 데는 많은 비용이 든다! 지나친 안정성은 사용자에게 해가 될 수 있다. 사용자가 원하는 기능을 추가하는 속도가 그만큼 느려지기 때문이다. 이는 고객 이탈로 이어질 수 있다. 

반대로 새로운 기능을 너무 빠르게 추가하면 소프트웨어에 버그가 많아진다. SLA의 목표치는 유지할지 몰라도, 놓친 0.001%가 하필 가장 중요한 고객에게 영향을 미칠 수 있다. 서비스가 다운되었다는 사실은 단순한 척도지만, SLA는 그 중단이 실제로 사용자에게 어떻게 영향을 미쳤는지는 알려주지 않는다. 

또한 SLA는 복잡한 워크플로우에 걸쳐 사용자 성공을 정의하기가 훨씬 더 까다로운 지금의 분산 시스템과 잘 맞지 않는다. 암호 재설정과 같은 일상적인 작업도 웹 애플리케이션, API, 서드파티 이메일 서비스 업체, 공용 인터넷, 그리고 사용자의 컴퓨터를 거치면서 이뤄진다. 많은 시스템이 올바르게 작동해야 할 뿐만 아니라 사용자가 여러 단계를 완료해야만 한다. SLA는 이런 유형의 통합 시스템과 복잡한 워크플로우(암호 재설정은 단순한 예)에 대한 성공률을 모델링할 방법을 제공하지 않는다. 
 

SLO를 사용한 더 세분화된 안정성 척도 

SLO(Service level objectives, 서비스 수준 목표)는 개발자가 클라우드 서비스에 대한 더 세부적인 안정성 목표를 모델링할 수 있게 해주는 수학 기반의 원칙이다. 애플리케이션 소유자에게 클라우드 서비스에서 기대되는 항목을 가져오고 결과를 측정(서비스 수준 지표를 통해)하고 장기적으로 튜닝이 가능하도록 코드화할 수단을 제공한다. 

SLO는 엔지니어링 팀에 안정성 목표에서 어느 정도의 재량을 주는 오류 예산에 반영된다. 이는 개발자와 비즈니스 부서에 안정성 저하가 사용자의 만족에 실제로 어떻게 영향을 미치는지 보기 위한 공통된 기반, 그리고 개발 속도와 안정성 아이의 균형점을 찾기 위한 더 많은 선택지를 제공한다. 




7일 전

칼럼 | 데브옵스팀이 SLA를 없애고 SLO를 선택해야 하는 이유 

Alex Nauda | InfoWorld
SLA(Service Level Agreement)는 1980년대 유선전화 통신사 사이에서 인기를 얻기 시작했다. 지난 20년 동안 미국 주요 도시의 도로 곳곳에 9x5(99.999%)를 홍보하는 광고판이 걸렸다. 그러나 지금 시점에서 SLA에 포함된 9의 수가 통신사 내에서, 그리고 외부적으로 고객에게 안정성을 전달하는 지표로서 적절할까? 
 
ⓒ Getty Images Bank

SLA가 존재하는 이유가 있다. 바로 변호사이다. 누구나 서비스 계약을 맺을 때는 서비스 업체의 수행 능력이 떨어지는 경우 계약을 파기하고 나올 길이 필요하다. 

계약에서 SLA와 관련해 발생하는 줄다리기는 익숙한 풍경이다. 고객의 법무팀(구매팀과 함께)은 보장되는 9의 개수를 최대화하고자 하고, 서비스 업체의 운영팀은 약속하는 9의 개수를 최대한 줄이고자 한다. 보통 고객은 SLA 미충족분에 대해 요금을 환급받거나 크레딧을 받는 정도로 협상을 한다. 

서비스 업체는 고객이 서비스에 온전히 만족하지 않더라도 약속한 9의 개수를 달성하면 약정한 가격을 모두 받는다. 약간 미달하면 고객이 예를 들어 비용의 10%를 환급받고 SLA에 크게 미달할 경우에는 고객은 50%를 돌려받거나 계약을 파기하고 다른 서비스 업체를 찾아 나설 수 있다. 대체로 고객은 서비스 업체가 SLA를 충족하는 편을 선호해왔다. 

이런 계약상의 SLA 의무는 서비스 업체 조직 내에서 성능, 안정성, 가동시간 및 응답성 목표로 이어진다. 또한 그 결과로 안정성에 관한 사고 프로세스가 극히 방어적으로 고착되면서, 절대적인 다운타임 방지와 무조건 최대한 빠른 사고 해결에 과도하게 초점을 두는 척도(평균 장애 간격, 평균 해결 시간)가 가장 널리 사용되는 상황에 이르렀다. 

SLA로는 ‘어느 지점이 되면 고객이 실제로 만족하고, 따라서 SLA 초과 달성 노력을 멈출 수 있는가?’라는 질문에 답하지 못한다. 즉 SLA로는 사용자의 만족도를 모델링할 수 없다.

클라우드 서비스에는 안성맞춤인 지점이 있다. 기존 사용자를 만족시키는 서비스의 안정성을 유지하면서 새로운 기능(사용자를 유인하고 기쁘게 하는)을 신속하게 제공할 수 있는 균형점이다. 하지만 SLA로는 이 지점을 찾을 수 없다. 

비현실적으로 많은 9의 개수로 포장되는 완벽한 SLA에 지나치게 집중할 경우, 시간이나 비용, 엔지니어링 번아웃 측면에서 여파가 크다. 완벽해지기 위해 노력하는 데는 많은 비용이 든다! 지나친 안정성은 사용자에게 해가 될 수 있다. 사용자가 원하는 기능을 추가하는 속도가 그만큼 느려지기 때문이다. 이는 고객 이탈로 이어질 수 있다. 

반대로 새로운 기능을 너무 빠르게 추가하면 소프트웨어에 버그가 많아진다. SLA의 목표치는 유지할지 몰라도, 놓친 0.001%가 하필 가장 중요한 고객에게 영향을 미칠 수 있다. 서비스가 다운되었다는 사실은 단순한 척도지만, SLA는 그 중단이 실제로 사용자에게 어떻게 영향을 미쳤는지는 알려주지 않는다. 

또한 SLA는 복잡한 워크플로우에 걸쳐 사용자 성공을 정의하기가 훨씬 더 까다로운 지금의 분산 시스템과 잘 맞지 않는다. 암호 재설정과 같은 일상적인 작업도 웹 애플리케이션, API, 서드파티 이메일 서비스 업체, 공용 인터넷, 그리고 사용자의 컴퓨터를 거치면서 이뤄진다. 많은 시스템이 올바르게 작동해야 할 뿐만 아니라 사용자가 여러 단계를 완료해야만 한다. SLA는 이런 유형의 통합 시스템과 복잡한 워크플로우(암호 재설정은 단순한 예)에 대한 성공률을 모델링할 방법을 제공하지 않는다. 
 

SLO를 사용한 더 세분화된 안정성 척도 

SLO(Service level objectives, 서비스 수준 목표)는 개발자가 클라우드 서비스에 대한 더 세부적인 안정성 목표를 모델링할 수 있게 해주는 수학 기반의 원칙이다. 애플리케이션 소유자에게 클라우드 서비스에서 기대되는 항목을 가져오고 결과를 측정(서비스 수준 지표를 통해)하고 장기적으로 튜닝이 가능하도록 코드화할 수단을 제공한다. 

SLO는 엔지니어링 팀에 안정성 목표에서 어느 정도의 재량을 주는 오류 예산에 반영된다. 이는 개발자와 비즈니스 부서에 안정성 저하가 사용자의 만족에 실제로 어떻게 영향을 미치는지 보기 위한 공통된 기반, 그리고 개발 속도와 안정성 아이의 균형점을 찾기 위한 더 많은 선택지를 제공한다. 


X