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

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

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

 

 

구글의 SRE에서 유래된 SLO는 애플리케이션 성능 모니터링 및 로깅 툴 위에 위치하며, 이 텔레메트리 데이터를 고객 성과의 맥락에 집어넣는다. 즉, 이제 모니터링 시스템에 이상 현상이 감지될 때마다 공황 상태에 빠지지 않고 정해 놓은 서비스 상태 임계값 및 목표 맥락에서 공유된 데이터를 사용해 정보에 근거한 의사 결정을 내릴 수 있다. 

SLO는 안정성을 가장 중요한 고객 대면 클라우드 서비스의 중심에 두는 끊임없는 과정을 진행해 나가기 위한 수단이다. 로그, 메트릭, 트레이스 등 과거에 필요했던 모든 것이 여전히 필요하지만, SLO는 클라우드 서비스에 대해 기대되는 사용자 경험의 모델링 관점에서 이를 보강해준다. 

개발자, 운영자, 비즈니스 부서가 서비스의 안정성 저하가 실제로 문제가 되는 시점에서 파악해야 하는 맥락과 SLA(너무 구체적인), 모니터링 데이터(노이즈가 너무 많음) 사이에 존재하는 중대한 공백 문제를 SLO가 해결해준다.

SLO 시작하기 

기업 내에서 새로운 기술 프랙티스를 도입하는 것은 간단하지 않다. 물론 회의에서 논의하는 것만으로 되지도 않는다. SLO 도입을 촉진하기 위해 거버넌스 기반의 접근 방법을 채택한 조직도 있고 사회기술적 접근 방법을 통해 도입을 이끈 조직도 있다. 

어떻게 시작해야 할지 감이 잡히지 않을 수 있는데, 개발 및 운영팀과의 첫 SLO 설정 논의에 접근하는 방법은 다음과 같다. 

1. 사용자 스토리를 공유한다. 예를 들어 사용자가 장바구니에 상품을 추가하고 즉시 체크아웃할 수 있기를 기대하는 전자상거래 사용자 스토리가 있다고 가정해 보자. 이 사용자에게는 체크아웃 시 지연을 참는 임계치가 있으며, 체크아웃이 이 임계치보다 길어지는 경우 기분이 상해 장바구니를 버린다.

2. 이 고객 경험을 SLO로 더 정확하게 표현한다. 장바구니에 상품을 추가하고 X(시간) 이내에 체크아웃할 수 있는 사용자의 비율이 얼마나 되어야 하는가? 
 
3. 위험을 식별해 정량화한다. 고객이 이 시간 안에 체크아웃할 수 없다면 어떻게 되는가? SLO를 충족하지 못하는 경우 어떤 비용이 발생하는가? 
 
4. 위험 범주에 대해 브레인스토밍한다. SLO 미충족을 유발할 수 있는 상황은 무엇인가? 팀에서 다양한 위험에 대한 답이 나올 것이다. 예를 들어 “기반 인프라가 다운되는 경우”, “푸시한 업데이트에 버그가 있는 경우”, “그 정도의 동시 수요가 몰릴 것을 예상하지 못한 경우” 등의 답이 나온다. 
 
5. “그 위험을 낮추려면 어떻게 해야 하는가?”라고 묻는다. 위험을 낮추기 위해 필요한 자원 및 비용과 장애 발생 시 비용을 비교할 때 어떤 위험을 그냥 두고 어떤 위험에 사전에 대처하겠는가? 이 정보를 사용해서 SLO 충족 능력을 측정하고 추적하는 데 사용할 서비스 수준 지표(SLI)를 결정한다. 

언젠가 서비스 업체가 광고판에서 합리적인 SLO를 홍보하는 날이 오기를 바란다.

*Alex Nauda는 Nobl9의 CTO이다. editor@itworld.co.kr

원문보기:
https://www.ciokorea.com/news/207822#csidxfe8879f39c778bfb6e5bf0124ca069b