SRE - Site Reliability Engineering

Contents

Site Reliability Engineering(이하 사이트 신뢰성 엔지니어링 혹은 SRE로 표기한다.)는 소프트웨어 엔지니어링 기술들을 인프라 및 운영에 적용하는 것을 의미한다. SRE 팀을 이끌고 있는 Google의 Ben Trenor에 따르면, SRE는 "소프트웨어 엔지니어가 이전에는 작업이라고 불렀던 일을 처리 할 때 어떤 일이 일어날지"에 대한 것이라고 설명했다.

Ben Treynor이 7명의 소프트웨어 엔지니어로 구성된 팀을 이끌면서 프러덕션 운영 환경을 개선하기 위한 프로젝트를 진행했다. 이 프로젝트의 결과물이 SRE다. 이 팀은 구글 사이트가 안정적이고 효율적으로 운영하기 위한 방법을 찾아야 했다.

초기에 Google은 대규모 시스템을 운영하면서, 기존에 접하지 못했던 거대한 시스템을 관리하기 위한 새로운 환경을 제공해야 했다. 구글의 시스템은 거대할 뿐만 아니라 동시에 새로운 기능을 지속적으로 도입해야했기에, 변화를 수용하면서 동시에 우수한 품질을 최종 사용자에게 제공해야 했다.

구글은 지금 1500 명 이상의 엔지니어들이 SRE 업무를 수행하고 있다. 많은 제품에 SRE를 서비스를 제공하는 중소 규모의 SRE팀을 가지고 있다. 수년 동안 갈고 닦은 SRE 프로세스는 이제 다른 대규모의 기업에서 사용되고 있다. Zero, Intuit, ServiceNow, Microsoft, Apple, Twitter, Facebook, Dropbox, Amazon, Target, Dell Technologies, IBM, Xero, Oracle, Zalando, Acquia, VMWare, GitHub, Waze, Home Depot, Capital One, OVH, Ticketmaster 등 많은 대규모 기업에서 SRE 팀을 운영하고 있다.

SRE 엔지니어는 "운영(ops)" 관련된 작업을 수행하는데 최대 50%의 시간을 소비한다. SRE가 관리하는 소프트웨어 시스템은 고도로 자동화 되어있으며, 자가치유 기능을 가져야 하므로 이러한 시스템의 자동화와 기능 개발 작업에 50%의 시간을 소비해야 한다. 이상적인 SRE 후보자는 시스템관리 경험을 가진 소프트웨어 엔지니어 혹은 코딩 및 자동화에 대한 지식이 있는 숙련된 시스템관리자들이다.

2008년경 시작된 DevOps는 사일로화된(분업화 되면서 해체된) 팀을 연결해서, 효율적인 조직을 만들기 위한 문화적 움직임이다. 수동 작업의 자동화, 지속적인 통합 및 지속적인 배포를 포함하는 일련의 엔지니어링 작업과 관련이 있다.

SRE는 DevOps와 기본적인 원칙을 서로 공유한다. 많은 경우 SRE는 DevOps에서의 특정 영역의 구체적인 구현이라고 설명한다. 그들 스스로가 개발자이기도 한 SRE는 개발팀과 운영팀간의 장벽을 제거하는데 도움이 되는 솔류션을 제공한다.

DevOps 성공을 위한 주요 요소들은 아래와 같다.

1. 사일로 조직의 통합
2. 실패를 상수로 받아들인다.
3. 점진적 구현과 개선
4. 자동화 시스템의 활용
5. 모든 것을 측정

SRE는 DevOps의 아래 요소들을 충족한다.

사일로 조직의 통합

• SRE는 개발자와 정보와 책임을 공유한다.
• SRE는 개발자가 사용하는 것과 동일한 도구를 사용하며, 반대의 경우도 마찬가지다.

실패를 상수로 받아들인다.

• SRE는 위험을 감수한다.
• SRE는 SLI(Service Level Indicatiors)와 SLO(Service Level Objectives)를 사용해서 오류와 가용성을 정량화 한다.

점진적 구현과 개선

• SRE는 실패비용을 줄임으로써, 신속하게 올바른 방향으로 이동하도록 지원한다.

자동화 시스템의 사용

• SRE는 일상적인 업무(수고라고 하는)의 자동화에 집착한다.

모든 것을 측정한다.

• SRE는 값을 측정하기 위한 방법을 정의한다.
• SRE는 근본적으로 시스템작동의 문제가 소프트웨어의 문제라고 믿는다.

DevOps는 문화이고 SRE는 구체적인 실천규칙이라고 볼 수 있을 것 같다. SRE라는 용어에도 나와있듯이 신뢰성은 SRE의 핵심이다. 여기에서 신뢰성은 모든 경우에 안전하며 최고의 성능을 보장한다는 의미가아닌, 적절한 수준의 신뢰성을 의미한다.

사람들은 최선이라는 단어에 어떤 경외감을 가지고 있다.

1. 이게 정말 최선이라고 생각하십니까 ?
2. 100% 안전하다고 장담할 수 있습니까 ?
3. 소비자에게 최선의 경험을 줄 수 있나요 ?

불경하게도 SRE는 "적절한 수준의 신뢰성"을 논한다. 하지만 달성가능하고 측정가능하기 위해서는 "적절한 수준의 신뢰성"을 목표로 해야 한다. 왜냐하면 신뢰성의 기준은 무한히 높아질 수 있고, 무한한 것에 대한 측정가능,달성가능한 목표를 세울 수 없기 때문이다.

• 신뢰성의 기준은 무한히 높아질 수 있다. : 100% 신뢰성은 불가능하기 때문이다.
• 신뢰성을 확보하기 위한 비용은 기하급수적으로 늘어난다.

초기에는 약간의 비용으로 신뢰성을 크게 높일 수 있지만, 신뢰성이 높아질 수록 투자대비 효율이 떨어진다. 따라서 적절한 수준의 신뢰성 목표를 정하고 이를 측정하기 위한 툴과 시스템을 만들어야 한다.

SRE는 구체적인 행동 규범을 담고 있다. 이들 규범을 이용해서 시스템이 안정적인지, 사용 가능한 상태인지를 측정 할 수 있다. 서비스의 신뢰성을 측정할 수 있다. SRE는 SLO, SLI, SLA 와 같은 측정도구를 제공한다.

SRE의 가장 기본이 되는 성공조건은 가용성(availability)다. 사용 할 수 없는 시스템은 해당 기능을 수행 할 수 없으므로 실패로 측정된다. SRE에서 가용성은 시스템이 특정 시점에 의도한 기능을 수행 할 수 있는지의 여부를 정의 한다.

SRE는 가용성에 대한 정확한 수치 목표를 설정하려고 했다. 이 목표를 SLO(Service-Level Objective)"서비스 수준 목표" 라고 한다. SRE는 SLO를 설정해서 시스템이 "충분히 안정적"으로 실행되는지를 측정하며, 향후의 아키텍처 변경사항등에 대해서 논의할 근거로 삼는다. 충분히 안정적이라는 제한사항에 주의해야 한다. 완전하게 작동하는이 목표가 아니다.

새로운 서비스를 오픈했다고 가정해보자. SRE 엔지니어는 소프트웨어 개발자(품질관리자가 될 수도 있다.)와 협업해서 (보통은 소수점이겠으나 이해하기 쉽게 실패율을 높게 잡았다.)10% 까지의 실패를 허용한다는 목표치를 만들 수 있을 것이다. 세부적으로는 특정 유저에게서 발생하는 실패인지, 특정 API에서 발생하는 실패인지, 전체 API에서 발생하는 실패인지에 따라서 목표치를 수립할 수 있는데, 이 목표치가 SLO가 된다.

SLO는 모니터링 시스템을 통해서 정확하게 측정할 수 있어야 한다. 지난 주에는 서비스가 잘 되고 있는 것 같았다. SRE에서는 이번에 약간의 실패가 있는 것 같다는 평가는 사용 할 수 없다. 서비스가 SLO를 충족하는지, 충족하지 않는지 둘 중 하나로 표현되야 한다. SLO를 충족하지 않는다면 문제를 찾아서 해결해야 하고, SLO를 충족한다면, 추이를 모니터링 한다.

모든 서비스에는 SLO가 있어야 한다. 개발에 직접적인 이해당사자는 높은 서비스 안정성과 낮은 안정성 사이에 객관적 판단을 내릴 수 없으므로 외부 SRE 엔지니어와 함께 목표를 만들어야 한다. 즉

• 높은 서비스 안정성 : 비용 증가 와 개발지연
• 낮은 서비스 안정성 : 개발 속도 향상

사이에서 적절한 수준을 찾아야 한다. 무리한 일정을 맞추기 위해서 낮은 서비스 안정성을 목표로 하거나, (엔지니어링 수준에 대한 과도한 집착등으로) 개발이 지연되는 경우를 어렵지 않게 찾아볼 수 있다.

인터넷 서비스를 개발한다고 가정해보자. 예를들어 네트워크 품질이 90% 정도라고 하면, 서비스 안정성을 99%로 맞추는 건 의미가 없다. 95% 수준으로 하고, 다른 영역에 자원을 투자하는게 더 나을 것이다.

이제 서비스를 측정을 해야 한다. 이것을 SLI라고 한다. 지난 주에 시스템이 SLO를 어느정도 달성했는지를 판단하기 위한 근거자료로 SLI를 검토한다. SLI는 구체적이어야 한다. 아래와 같은 것들이 SLI가 될 수 있을 것이다.

1. 쿼리 성공과 실패의 비율
2. HTTP 404, 500 에러의 비율
3. Long query의 갯수
4. 응답까지 걸린 시간

이들 SLI 지표를 이용해서 404의 비율을 2% 미만으로 한다. 500의 비율을 1% 미만으로 한다. 응답의 90% 이상이 500msec 안에 있어야 한다 등의 서비스 수준 목표를 설정할 수 있다.

이제 "지난 주 서비스에 문제가 없었던 것 같습니다"가 아닌, 지난주 응답의 95%가 500msec에 있었다. 그러므로 SLO를 달성했다고 정확히 보고 할 수 있다.

AWS에서 SLI 지표는 CloudWatch로 수집 할 수 있을 것이다.

• Site Reliability Engineering - How Google Runs Production Systems
• 사이트 신뢰성 엔지니어링 : 바로 위 문서의 번역서다.
• Site Reliability Engineering - google
• The Site Reliability Workbook - Practical Ways to Implement SRE

• Site Reliability Engineering - wikipedia
• SRE(사이트 신뢰성 엔지니어링) 소개 - Learn, Microsoft Docs