brunch

You can make anything
by writing

C.S.Lewis

by JSCODE 박재성 Jan 28. 2024

운영하는 서비스에서의 가용성 측정법

시스템이 정상적으로 운영될 확률을 수치적으로 계산해보자!

왜 가용성을 측정할 수 있어야 할까? 

서비스가 정상적으로 운영되지 않으면 사용자의 불편함, 브랜드 이미지, 사용자 이탈 등 여러가지의 손실이 발생한다. 그러다보니 서비스가 정상적으로 운영되어야 할 가용성을 수치적으로 표현함으로써 이러한 손실을 최소화할 수 있다. 



만약 가용성을 수치적으로 표현하지 않는다면 직원들은 생각보다 서비스의 가용성을 크게 고민하지 않을 것이다. 설령 가용성을 신경쓰는 직원이 있다고 하더라도 어느 정도로 안정성 있게 서비스를 구성해야 하는 지에 대한 감도 잡을 수 없다. 



이러한 이유들로 인해 가용성을 측정해서 관리하면 서비스의 품질을 꾸준히 높여나갈 수 있다. 



하지만 여기서 착각하면 안 되는 건 가용성 100%를 목표로 하는 게 좋은건 아니다. 이 링크에서 한 번 언급한 적이 있다. 구글도 절대 장애가 일어나지 않는 서비스를 구축하는 걸 목표로 삼고 있지 않다. 왜냐하면 신뢰성을 과도하게 향상시키려는 목표가 오히려 해가 되기도 하기 때문이다. 




운영하는 서비스에서의 가용성 측정법


대부분의 경우, 위험의 수용도를 표현하는 가장 직관적인 방법은 의도되지 않은 다운타임(서비스가 장애 등으로 인해 실행이 중단된 시간)을 어느 정도나 수용할 수 있는 지를 알아보는 것이다. 현재 동작 중인 시스템이라면 위험의 수용도는 시스템의 업타임 비율로 계산한다. 



가용성 = 업타임 / (업타임 + 다운타임)



이 공식을 1년에 걸쳐 적용해보면 목표 가용성 수치를 달성하기 위해 허용할 수 있는 다운타임이 몇 분인지를 계산할 수 있다. 예를 들어 가용성 목표치가 99.99%인 시스템의 경우, 허용 가능한 연간 다운타임은 52.56분이다. 



그러나 구글을 포함한 대규모 서비스를 운영하는 회사에서는 시간 기준의 가용성 지표는 그다지 의미가 없다. 왜냐면 분산된 형태로 서비스를 운영하기 때문에 전체 서비스가 중단되는 일이 드물다. 그럼 어떻게 가용성을 측정할까? 



요청 성공률(request success rate)에 기초한 가용성 계산 방법을 활용해 측정한다.



가용성 = 성공한 요청 수 / 전체 요청 수



예를 들어 하루에 250만 개의 요청을 처리하는 시스템의 경우 하루에 발생하는 에러가 250개 이내라면 일일 가용성 목표치 99.99%를 달성할 수 있다. 이 계산 방법은 나름대로 의도되지 않은 다운타임에 대한 적절한 추산이라고 볼 수 있다. 






작가의 이전글 로깅, 모니터링을 공부하기 위한 책 추천
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari