Site Reliability Engineering이란 소프트웨어 시스템의 안정성과 신뢰성을 유지하고 향상시키는 분야를 뜻한다.
구글에서 사용하기 시작하여 전파된 용어로 최근 여러 스타트업의 채용 공고에서 심심치 않게 확인할 수 있다. 그런데 사실 이런 정의는 어디서나 볼 수 있는 두루 뭉술한 정의이다. 이것이 나온 배경을 공부해보면서 좀 더 구체적으로 이게 어떤 분야인지 알아보자.
일반적으로 소프트웨어로 서비스를 고객에게 공급하고 있다면 소프트웨어 엔지니어 그룹은 크게 2가지로 개발팀과 운영팀으로 나뉠 수 있다.
개발팀은 말그대로 고객의 니즈를 반영하여 새로운 기능과 로직을 개선하는 엔지니어로 구성된 팀이다. 반면 운영팀은 기존에 문제없이 운영되는 서비스를 그대로 문제없이 지속적으로 운영하는 책임을 맡는 팀이다.
새로운 서비스의 배포 및 기능 추가되는 과정에는 많은 리스크가 있을 수 있다. 대표적으로는 개발 환경에서는 잘 되던 코드가 프로덕션 환경에서 여러 이유로 작동하지 않을 수 있고... 그렇게 되면 고객에게 제공되는 서비스의 장애가 발생하여 궁극적으로 비즈니스에 심각한 타격을 입힌다.
개발과 운영팀 모두 각자의 조직 목표가 있지만 최상위적인 목표는 고객의 니즈를 빠르게, 그리고 원활하게 반영하는 것이다. 그래서 많은 회사들이 서비스 관리에 있어서 개발과 운영 조직간의 간극을 메워주는 방법을 궁리했고 대표적인 방법론이 DevOps 였다.
또한 전통적인 개발-운영 팀의 구조에서는 서비스 규모가 커지게 되면 팀의 일이 더 많아지게 되고 그에 따라 더 많은 사람이 필요해지는 구조였다.
세계 최고의 소프트웨어 회사 구글이라고 이런 문제에서 자유로울 수 없었다. 이를 해결하기 위해 기존의 소프트웨어 엔지니어 중 일부가 차출되어 운영팀을 만들게 되었고 그게 SRE팀이 된 것이다. 기존의 개발-운영 구조에서 개발-SRE팀 으로 바뀌게 된 것이다.
구글은 SRE 엔지니어의 특성으로 2가지를 제시하고 있다.
1. 수동으로 진행되는 작업에 쉽게 지루해지는 사람
2. 기존에 수동으로 이루어지던 작업을 개선할 수 있는 skill들을 가진 사람
한 마디로 사내에서 시스템화, 자동화할 수 있는 부분들을 캐치할 줄 알고 그것을 직접 자동화할 수 있는 사람이어야 한다는 것이다!
구글은 또한 SRE 엔지니어는 운영 작업에 50%의 태스크 한도를 설정한다고 한다. 그러니까 SRE의 업무는 개발과 운영을 50:50 으로 가져가는 것이다!
서비스의 안정적 운영을 위한 업데이트, 비용검토 등의 업무는 많아야 50%를 투자하고 나머지 50% 이상은 기존 시스템을 자동화하는 소프트웨어를 개발하거나 실제 서비스 개발에 투입되는 것이다.
SRE팀은 일반적으로 서비스의 가용성, Latency, 효율성, 긴급 대응 및 용량 증설 계획을 담당한다. 이러한 요인들은 고객이 서비스를 사용할 때 얼마나 신뢰할 수 있는지 평가하는 지표가 된다.
여기서 중요한 것은 신뢰성 평가의 관점은 고객이라는 것이다. 예를 들어, 사이트의 latency를 0.001ms 증가시켰다고 해도 고객이 이를 크게 체감하지 못한다면 이득이 없는 것으로 간주한다.
구글에서는 운영팀 대신 SRE를 만들게 되면서 비용이 줄어들었다고 한다. 왜냐면 운영팀보다 적은 인력이 필요하기 때문이다. (팀의 역할이 서비스 개발, 시스템 자동화, 운영 모두를 담당하니까 당연할지도..)
또한 SRE는 개발과 운영 지식을 모두 갖추고 있기 때문에 개발자들과 교류하며 다른 개발자들의 역량 향상에도 도움이 되었다고 한다.