SRE 엔지니어링이란?
SRE(Site Reliability Engineering)는 소프트웨어 엔지니어링 기법을 활용하여 대규모 시스템과 서비스의 안정성, 성능, 확장성을 보장합니다. Google의 Ben Treynor Sloss가 처음 제안한 이 개념은 "운영 업무를 담당하는 소프트웨어 엔지니어가 하는 일"이라고 정의할 수 있습니다. 즉 운영도하고, 자동화를 위한 개발도 한다! 생각하면 쉽습니다.
SRE팀의 역할
자동화 중심 개발
SRE팀은 수동으로 수행되는 IT운영 작업을 소프트웨어 엔지니어링을 통해 자동화합니다. 예를들어 사용자가 몰려서 트래픽이 급증하여 서버 리소스 사용량이 올라가는 상황, 서버에 부하가 걸려서 장애가 생기는 상황, 새로운 기능을 출시해야하는 상황 이러한 상황 모두 사람이 관리하는데 이를 자동화하는 것을 목표로합니다.
서버 리소스 사용량이 올라가면 모니터링 도구를 통해 알람을 보내고, 장애가 발생하여 서버가 다운되면 자동으로 복구합니다. 새로운 기능을 출시할 때 원래는 사람이 배포했지만 CI/CD로 배포합니다.
또한 크리티컬한 장애가 발생해도 긴급대응 비상 대응책 절차를 미리 설계해 두는 것입니다. 예를들어서 정전이 발생했더라도 백업 발전기가 돌아가며 자동으로 전기를 공급하는 것처럼 소프트웨어를 사용하여 IT운영 작업을 전반적으로 자동화하는 것이 첫번째 목표입니다.
측정과 목표 설정
SLA(Service Level Agreement) 고객과의 약속을 의미합니다. 금전적 계약이 달린 문제라서 민감하고, 계약 그 자체라고 생각하면 됩니다. 예를들어 도미노 피자에서 15분이내로 배달을 오지 않으면 피자값을 받지 않는다는 정책이 SLA라고 생각하시면 쉽습니다.
SLO(Service Level Objective) 서비스 달성 목표를 의미합니다. 내부적으로 설정한 서비스 목표로써 위에서 말한 배달시간 15분을 지키기가 서비스 목표로 지정 될 수 있습니다. 서비스 가용성이 99% 달성 되어야 한다, 주문 트랜잭션은 99% 성공해야한다. 이러한 서비스 수준 목표를 의미합니다.
SLI(Service Level Indecator) 서비스 레벨 지표입니다. 그러니까 피자배달 평균 시간을 측정하여 얼마나 피자배달을 잘 하고 있나 측정하여 관리하는 지표라고 생각하면 쉽습니다. 서비스의 평균 응답 속도, 에러율 등이 이 서비스 레벨 지표에 해당합니다.
만약에 새로운 기능을 출시한다고 했을 때, 예를들어 SLI 지표에 평균적으로 피자를 만드는 시간이 8분인데 신메뉴 매운 소스 피자를 만드는데 15분이 걸렸다면 이는 SLI를 위반한 것이고, SLO를 지키지 못한 것이고 SLA에 따라서 고객에게 환불을 해줘야 할 수도 있습니다.
하지만 오류예산(Error Budget)을 고려해서 99.9%의 가용성 보장 한다면 한달(30일 = 720시간)동안 0.1%의 다운타임(43분)은 허용할 수 있습니다. 따라서 예정된 SLO를 초과하지 않으면서 오류예산을 활용하여 새로운 기능을 적극적으로 배포한다거나 성능을 개선하는 작업을 할 수 있습니다. 하지만 오류예산을 초과하면 서비스 안정성을 유지하기 위해 배포를 중단하고 신뢰성을 높이는 작업에 집중해야합니다.
위의 예시를 가지자면 신메뉴 매운 소스 피자를 한달동안 1000개를 만든다고 했을 때 99%를 10분이내로 제조해야하니까 한달동안 최대 10개의 피자는 10분을 초과해도 괜찮다는 것입니다. 하지만 11개가 넘어간다면 오류예산을 초과합니다.
정리하자면 SRE 엔지니어링 팀은 새로운 기능을 출시하기 전 SLI를 측정하고, SLO를 달성할 수 있는지 확인하여 SLA를 지킬 수 있도록 관리하고 평가하는 팀입니다.
속도의 안정성과 균형을 조절
너무 급하게 서비스를 배포하게 되면 장애가 발생할 확률이 높아집니다. 반대로 너무 안정성에만 신경 쓴다면 기능 개선이 느려서 경쟁력을 잃게 되겠죠.
이 사이에서 조절을 해야합니다. 빠르게 사용자에게 배포하는 대신 Blue/Green, 카나리 배포와 같은 점진적 배포를 통해 안정성을 검증하는 동시에 빠른 배포를 진행할 수 있습니다. 장애없이 서비스가 성공적으로 배포 됐다면 CI/CD 파이프라인을 통해 안전한 업데이트까지 지원합니다.
하지만 여기서 안정성을 더욱 확보하기 위해 SLO/SLI를 설정하여 안정성을 유지합니다. 이를 모니터링을 통해 이상 감지 및 자동 복구 시스템을 구축하고, 장애 대응 메뉴얼을 만들어서 비상 시 빠르게 복구하는 것을 목표로 합니다.
이렇게 새로운 기능과 출시와 서비스 안정성 사이에서 최적의 균형을 유지하는 엔지니어 팀이 SRE팀의 역할입니다.
SRE 팀의 문화
SRE팀의 시간관리
SRE팀은 기본적으로 서비스가 원활하게 진행될 수 있도록 해야하는 팀인데 운영 테스크(장애해결, 모니터링, 장애 대응훈련) 등을 하다보면 운영 자동화를 할 시간이 부족해질 수 있습니다. 이를 방지하기 위해 SRE팀은 운영 테스크에 50%의 시간만 할애하도록 문화가 잡혀있습니다. 쉽게 설명하자면 주방장이 요리하느라 바빠서 신메뉴 개발이나 주방 개선을 안 하고 있다는 것이죠.
SRE팀은 나머지 50%에는 토일 작업을 자동화 및 개발 해야합니다. 토일 작업이란 반복적이고, 자동화되지 않은 작업을 의미합니다. 서버 스케일 개선, 자동 서비스 복구, 새로운 CI/CD 구축 업무를 AI, 스크립트, Airflow와 같은 도구를 통해 자동화 시스템을 구축해야합니다.
만약에 운영 테스크의 업무가 너무 과도하다면 일부 업무를 외부 업체에 위임하거나 솔루션을 도입하여 시간을 확보한 후 토일 감소에 시간을 쏟아 서비스 안정성과 자동화 비율을 높여야합니다. 마치 주방 쉐프가 설거지 거리가 너무 많아서 주방보조를 고용하여 설거지를 위임하는 방식으로 이해하면 쉽습니다.
SRE와 DevOps의 관계
SRE와 DevOps는 밀접한 관련이 있지만 약간의 차이가 존재합니다. 데브옵스는 무엇을 해야하는지 초점을 맞춘다면 SRE는 어떻게 할 수 있는지를 중점을 둡니다.
데브옵스는 개발팀과 적극적으로 협업하여 소프트웨어 배포 속도를 증가시키고, 협업을 강화하는데 중점을 둡니다.
더불어 전체적인 CI/CD 프로세스를 자동화 시키고 최적화 시키는 역할을 합니다. 축구로 비유하자면 감독이고 팀이 빠르고 효과적으로 경기를 운영할 수 있도록 전술(배포전략)을 개발하는 역할입니다. 에자일 개발 팀과 유사하게 움직이며 지속적인 통합과 배포를 강조합니다.
SRE팀은 축구로 비유하자면 의무팀입니다. 선수(서비스)의 컨디션과 부상을 관리하는 팀이라고 생각하면 쉽습니다.
경기 중 부상방지(시스템 모니터링&장애대응), 운영 자동화, 장애복구&롤백, 시스템 부하 관리 등을 담당합니다.
SLA/SLO를 관리하고 자동화를 위한 개발을하는 포지션입니다. 개발과 운영 사이에 명확한 구분을 두며 시스템 안정성과 가용성을 책임집니다.
다시 정리하자면 데브옵스팀은 개발과 운영 협업 방식을 최적화하는 팀이고, SRE팀은 시스템 신뢰성과 안정성을 유지하는 운영 엔지니어링 팀입니다. DevOps는 축구감독으로서 팀 전략을 관리하고, SRE는 선수 컨디션을 관리합니다.
**참고자료**
https://www.redhat.com/ko/topics/devops/what-is-sre
https://www.ibm.com/kr-ko/topics/site-reliability-engineering
https://newdeal123.tistory.com/105
https://www.spaceone.megazone.io/blog/devops-vs-sre
