DevOps와 SRE의 다른 점

Contents

(2020년 1월)지금으로 부터 약 13년전 구글은 제품 생산 관리 방식을 바꾸기로 결졍한다. 개발팀은 새로운 기능을 만들어서 제품에 적용하는데 집중했지만 운영 그룹은 만들어진 제품을 안정적으로 유지하려고 노력했다. 두 조직의 이해가 상충했다. 이러한 긴장은 다른 경험, 기술 세트, 평가 기준의 차이로 발생했다.

구글의 운영 책임자 중 한명인 Ben Treynor는 두 그룹간의 격차를 해소하려고 노력했으며 그결과 혁신적인 솔루션을 생각했다. 시스템 관리자만으로 구성된 Ops 팀을 구성하는대신에 연구/개발 배경과 사고방식을 갖춘 소프트웨어 엔지니어로 구성된 팀을 만드는 것이다. 이 팀은 개발 그룹과 작업하는 방식을 풍부하게 하며, 개발과 운영 모두에 최적화할 수 있는 목표를 수립하고 솔류션을 자동화 할 수 있다. 시스템이 클라우드화 된다는 것은 시스템이 소프트웨어화 된다는 의미다. 이러한 조직 구성은 클라우드 환경에서의 품질관리에 새로운 방향을 제시했다.

그래서 사이트 신뢰성 엔지니어링이라는 역할이 만들어졌다. 구글에 따르면 SRE 엔지니어는 제품이 안정적인 운영을 담당하지만 동시에 새로운 기능과 운영 개선을 위해서 노력한다. 구글은 SRE 팀이 50%의 소프트웨어 엔지니어와 50%의 시스템 관리자로 구성되어야 한다고 결정했다. 엔지니어들은 소프트웨어를 사용해서 문제를 해결하고, 기존에 수작업으로 하던 것을 자동화 하면서 주어진 일을 완벽하게 해결됐다. 이들은 개발팀과 쉽게 통합되었으며 코드 품질 개선과 자동화, 테스트를 장려했다.

SRE의 가치가 받아들여지면서 DropBox, NetFlix, Github와 같은 기업들이 SRE 활동을 하고 있다. 이들은 SRE 리더십의 선두에 있는 것으로 유명하다. SRE 채용으로 검색해보면, 국내에도 SRE를 도입하는 회사가 늘어나는 것 같다.

이 회사들이 SRE 엔지니어에게 요구하는 것들은 아래와 같다.

• 상호 의존적인 플랫폼간의 연계성에 대한 이해
• 서비스에서 발생되는 직/간접적인 원인을 찾고 해결할 수 있어야 한다.
• Ansible, Chef, Puppet, Saltstack 등 설정 자동화 소프트웨어에 대한 경험
• 메시지큐, Elasticsearch, Springboot, REDIS 등 웹 애플리케이션 서비스를 구성하는 환경들에 대한 경험
• CICD 틀의 사용 경험, 개발에서 배포까지의 각 단계에서 필요한 시스템 분석, 디자인, 코딩, 테스팅, 디버깅, 문서화에 대한 경험.
• MSA 플랫폼에 대한 경험
• Docker 혹은 kubernetes에 대한 지식

SRE의 정의와 요구사항이 DevOps와 비슷하다는 걸 알 수 있다.

DevOps는 조직의 IT 부서가 민첩하고 효과적으로 움직일 수 있도록 돕기위해 개발된 활동/운동이다. SRE도 DevOps와 마찬가지로 제품의 운영 관리에 대한 조직의 요구를 해결하는 방법론이다. 그러나 두 개 활동에는 서로 다른 차이점이 있다.

1. DevOps는 역할이 아닌 문화다. 따라서 업무는 개인에게 할당해서 하는게 아니고 팀 단위로 수행한다. 반면 SRE는 고가용 서비스를 만들고 유지하는 관행으로 소프트웨어 전문가에게 주어지는 역할이다.
2. SRE는 때때로 DevOps 활동을 수행한다. DevOps 엔지니어는 때때로 (기존 시스템 관리자와는 업무 환경이 다르기는 하지만)시스템 관리자를 고용하는데 사용하는 작업 이름일 뿐이다. 조직에서 DevOps는 자동화 부분에 더 중점을 두지만 SRE는 시스템 가용성, 관찰 가능성, 규모 산정과 같은 측면에 중점을 둔다.
3. DevOps 엔지니어는 전체 SDLC(Software Development Life Cycle)를 이해하고 실제로 개선된 프로세스를 지원하기 위한 툴을 제공하는 실무 기술을 보유한 엔지니어다. DevOps에서 CICD와 MSA, 그리고 이를 위한 툴들이 필수적으로 나오는 이유다. 일반적으로 이러한 기술은 시스템 관리자와 개발자로서의 수년간의 경험을 필요로 한다. SRE의 주요 업무는 사이트(일명 플랫폼/서비스)가 무엇이든 상관 없이 항상 운영되도록 하는 것이다.
4. DevOps는 개발조직이 서비스를 구축 및 관리하는 등의 작업에서의 우선순위를 제공 할 수 있도록 측정 가능한 메트릭을 제공하는 데 중점을 둔다. 소프트웨어 엔지니어, 시스템 엔지니어, 아키텍트 및 숙련된 기술셋이 필요하기 때문에 DevOps를 이끌 수 있는 스페셜리스트(혹은 수석)를 찾는 것은 매우 어렵다. SRE는 배포 후 시스템 상태와 가용성을 개선하는데 중점을 두고, 응용 프로그램과 서비스 모니터링을 처리하기 위해 노력한다.

대기업은 많은 부서로 구성된 복잡한 조직 구조를 가지고 있다. 각 부서는 다른 부서와 의사소통이 잘 되지 않는 경우가 많으며 자신이 속한 조직의 성과를 우선시하다보니 결과적으로 전체적인 그림을 보지 못하고 일을 하게 된다. 이로 인한 좌절(나는 부속품일 뿐인가 ?), 배포 지연(업무조율을 위한 회의 하느라 시간 소비)으로 높은 비용이 발생 할 수 있다. "외부인의 시각을 가진 내부인들로 구성된 집단"인 셈이다. 이러한 현상을 사일로 이펙트라고 한다.

DevOps는 사일로 이펙트를 제거해서 부서간 비전을 공유하고 효과적으로 정보가 공유되도록 지원함으로써 하나의 그룹으로 연결한다.

SRE는 사일로 이펙트를 이야기하지 않는다. SRE는 모든 사람들이 토론 할 수 있는 방법을 논의하고 이를 구축하는 것을 중요하게 생각한다.

• SLA를 검토한다.
• SLA를 달성하기 위한 SLO를 수립한다.
• SLO를 측정하기 위한 SLI를 계획한다.
• SLO, SLI 활동을 위한 정책과 툴을 설정하고 프로세스를 수행한다.

이는 SRE이 DevOps의 구현으로 이미 사일로 이펙트를 잘 관리하고 있을 것이라 가정하기 때문에 가능한 시나리오다.

DevOps는 자동화를 지향한다. (가장 중요한)문화가 설정되고나면, 자동화에 많은 노력을 투입한다. 자동화는 개발에서 부터 배포, 모니터링까지 전 과정을 아우르며 따라서 DevOps에 대한 거버넌스가 만들어지고 나면, 실행 측면에서는 자동화된 CICD 파이프라인 구축업무를 하게 된다.

DevOps에서 CICD가 개발&배포의 자동화에 촛점을 맞추는 반면 SRE는 장애비용을 줄이기 위해서 CICD를 구축한다. SRE도 카나리아 릴리즈, 블루/그린 배포등 DevOps에서 사용하는 방법을 사용한다. 하지만 SRE는 운영관점보다는 아키텍처의 개선, 새로운 기술 구현과 같은 보다 실험적인 작업을 수행한다.

DevOps에서 실패는 상수(발생 할 수 밖에 없다)라는 것을 받아들이는 것에서 시작한다. 그리고 실패에서 학습하면서 점진적으로 개선한다. DevOps에서는 시스템이 내결함성을 완벽하게 유지하는 것 보다 결함을 허용하되 서비스가 계속되는 방법을 찾는 것을 중요하게 생각한다. 여기에 대해서는 Netflix Simian Army 문서를 읽어보자.

Netflix Simian army에서 사용하는 방법은 카오스 엔지니어링(Chaos Engineering)으로 널리 알려져 있다. 주요 키워드만 정리했다.

1. Latency Monkey : RESTful 클라이언트/서버 계층에 인공적으로 지연(latency)를 유도해서 적절하게 응답하는지 측정한다.
2. Security Monkey : 잘못 구성된 AWS Security group과 같은 보안 위반, 취약점을 유도한다. 문제를 모니터링 하고, 문제가 발생한 인스턴스에 대한 조치를 취하는지를 확인한다. SSL 및 DRM 인증서의 유효기간이 만료되더라도 서비스를 지속할 수 있는지 확인한다.
3. Janitor Monkey : 클라우드 환경에 혼란과 낭비가 없는지 확인한다. 사용하지 않는 리소스는 자동으로 검색해서 폐기하는지 확인한다.
4. Conformity Monkey : 모범사례를 따르지 않는 인스턴스를 찾아서 종료한다.
5. Doctor Monkey : 비정상적인 인스턴스(혹은 소프트웨어)를 실행한다. 모니터링 시스템이 비정상적인 인스턴스를 감지해서 서비스에서 제거되는지 확인한다.
6. Chaos Gorilla : 전체 Amazon 가용 영역의 중단을 유도한다. 서비스에 영향을 주지 않고 관리자의 개입 없이 서비스가 사용 가능한 가용영역에서 재조정되는지 확인한다.

언젠가는 카오스 엔지니어링을 정리해야 겠다.

SRE는 시스템 장애가 발생 할 때마다 원인을 파악해서 문제가 발생하지 않도록 방법을 찾는 활동을 수행한다. 또한 실패를 허용하는데, 이 실패는 오류예산이라고 하는 숫자로 관리한다. 즉 SLI, SLO와 SLA를 정의 한 후 특정 품질을 만족하기 위해서 들어가는 예산을 결정한다. 당연히 100%는 불가능 하기 때문에, 그 이하로 예산을 산정한다. 예를 들어 매월 가동율 목표를 99.9%로 잡았다면, 43분 까지의 다운은 허용 한다. 예산은 결국 시간이므로 예산이 허용한도 내에 있다면, 다른 업무에 예산(시간)을 투자한다. 만약 예산을 초과했다면 다음 달에는 릴리스가 일시 중지된다.

SRE는 DevOps와 경쟁하지 않는다. SRE는 구글이 DevOps를 수행하는 과정에서 서비스 안정성을 확보하기 위해서 수행했던 활동을 정의하기 위해서 선택한 이름이다. 추상 클래스와 구현의 관계이기 때문에 활동의 일부분을 그대로 사용하거나 덮어쓰거나 확장하도록 선택할 수 있다.

DevSecOps와 BizDevOps역시 DevOps의 구현이다. 이들 역시 DevOps에서 해오던 활동이다. DevOps를 활발히 하고 있는 조직이라면 애자일과 결합해서 사업, 개발, 운영의 경계를 허물기 위한 활동을 하고 있을 거다.

보안도 마찬가지다. 클라우드 환경에서 예전 온프레미스 방식으로 보안활동을 했다가는 DevOps(클라우드)가치가 손상되기 때문에 클라우드 시대에 맞는 보안정책을 다시 수립하고 있다. 개발관점에서는 시큐어코딩, 코드 취약점 점검, 코드 분석등의 작업을 CICD에 통합하고 있다. 인프라 관점에서는 보안설정을 코드화(IaC)하면서, 개발>리뷰>적용>모니터링의 개발 프로세스를 태우고 있다.

DevOps가 정착되면서 구체적인 구현물들이 나오는 단계라고 볼 수 있겠다.

• The Netflix Simian Army : 카오스 엔지니어링에 대한 아이디어를 제공하고 있다.