개발자

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

Alex Nauda | InfoWorld 2021.09.14


구글의 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

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.