블로그

NetOps는 가용성 실현을 위해 MTTR에 초점을 맞춘 SRE를 주목합니다.

로리 맥비티 썸네일
로리 맥비티
2018년 5월 14일 게시

사이트 안정성 엔지니어(SRE)는 비교적 새로운 역할로, 주로 엔지니어링이나 운영 분야에서 담당하며, 놀랍지 않게도 사이트 안정성을 유지하는 데 중점을 둡니다. 일반적으로 이는 애플리케이션의 가용성을 의미하지만, 성능도 포함됩니다. 이는 대부분의 최종 사용자가 반응하지 않는 앱을 사용할 수 없다고 생각하기 때문에 당연한 일입니다.

Catchpoint의 2018년 SRE 보고서를 살펴보면서 서비스 수준 지표와 SRE 측정항목을 비교한 차트가 눈에 띄었습니다. 일반적으로 "가용성"을 최상위 서비스 수준 지표로 볼 때 "가동 시간" 또는 "가동 중지 시간"도 측정 항목으로 봅니다. 이 설문조사에 따르면 SRE는 그렇지 않았습니다. 

서비스에 가장 중요한 서비스 수준 지표가 무엇인지 물었을 때, 압도적으로 많은 84%가 "최종 사용자 가용성"을 1위로 꼽았습니다. 지연 시간은 61%로 2위를 차지했고 오류율은 60%로 3위를 차지했습니다. 성능(보고서에서는 최종 사용자 응답 시간으로 설명)이 무려 58%의 답변을 차지했습니다.

이제 성공을 정의하는 데 사용된 척도를 살펴보겠습니다. 인프라와 운영 분야에서는 '가동 시간'과 '5.9'와 같은 매력적인 문구와 같은 지표를 보는 데 더 익숙합니다.

대신 SRE는 사고율과 MTTR을 기준으로 성공을 평가하는 경향이 있습니다. 같은 보고서에서 SRE의 41%가 SRE가 되기 전에 "DevOps 엔지니어" 역할을 했다고 언급했기 때문에 이는 놀라운 일이 아닙니다. DevOps 자체는 가동 시간을 계산하는 것보다 MTTR에 더 관심이 있습니다. 왜냐하면 가동 중지 시간이 발생할 것이라고 가정하기 때문입니다. 중요한 것은 문제를 피하려고 시간을 낭비하는 것이 아니라 문제를 신속하게 해결하여 최소화하는 것입니다.

하지만, 눈치 빠른 독자라면 MTTR을 최소화하면 가동 중지 시간도 최소화된다는 것을 알아차릴 것입니다. 해결 속도가 빨라지고 다운타임이 줄어듭니다.

둘 사이의 미묘한 차이점은 인간은 측정되는 것을 최적화하려는 경향이 있다는 것입니다. 코드 줄 수로 평가받는다면, 필요 여부와 관계없이 많은 줄의 코드를 작성하게 될 것입니다. 보안 사고로 인해 측정을 받는다면 모든 것을 잠그고 침해를 조장할 수 있는 모든 변경 사항에 대해 NO라고 외칠 것입니다. 가동 시간에 따라 사람들을 측정한다면 운영은 시스템을 가동하고 사용 가능한 상태로 유지하는 데 중점을 두게 되지만 MTTR을 감소시키는 시스템과 애플리케이션을 설계하고 계측하는 데는 중점을 두지 않게 됩니다.

이는 DevOps의 '문화적' 측면 중 하나이며, NetOps로 이어져야 하는 운영 접근 방식의 변화입니다. 가동 시간을 계속해서 최적화하다 보면 문제 해결에 걸리는 평균 시간을 줄이고 가동 중지 시간을 최소화한다는 목표를 달성하는 데 필요한 알림 및 관찰 기능(모니터링 및 견고한 로깅 등)을 구현할 기회를 놓치게 됩니다.

로그를 파헤치는 것은 - 중앙 집중화된 로그라 할지라도 - 문제의 핵심을 파악하고 이를 해결하는 효율적인 수단이 아닙니다. 용량, 연결성, 성능 등 가용성에 영향을 미치는 주요 변수에 대한 실시간 모니터링 및 경고를 전체 데이터 경로(네트워크, 인프라, 애플리케이션)에서 수행하면 저하되거나 갑자기 실패한 시스템이나 서비스를 알고 있는 경우 문제를 해결하는 데 걸리는 시간이 변함없이 줄어듭니다.

NetOps는 불가피한 실패를 처리하는 데 전반적으로 더 나은 접근 방식 이고 DevOps 대응 방식과 일치하기 때문에 프로덕션 파이프라인의 안정성 측면에서 이 접근 방식을 채택해야 합니다. 결국, 우리가 5.999까지만 도달한 데에는 이유가 있지 않나요? 아무리 노력해도 실패는 일어날 수 있고, 완벽함은 불가능하다는 것을 깨달았기 때문입니다.

성공의 척도를 가동 시간/가동 중지 시간에서 MTTR로 전환하면 전체 프로덕션 파이프라인에서 팀 간 협업과 관찰 도구 사용이 촉진됩니다. 설문조사에서 SRE가 꼭 갖춰야 할 도구로 모니터링 및 알림 도구가 가장 위에 오른 데에는 이유가 있습니다. 관찰성(오류/사고 발생 시 경고 목표)과 협업은 모든 사람(NetOps, DevOps, 앱 개발자 포함)이 앱을 빠르고 가용성 있게 유지한다는 목표를 달성할 수 있도록 보장하는 더 나은 방법입니다.