최근에 저 스스로도 의문이지만 다른 분들로 부터 많이 받는 질문 중의 하나가,
'DevOps와 SRE의 차이가 무엇인가요?' 입니다.
DevOps vs SRE 혹은 그냥 두개의 단어만 가지고 Googling을 하면 수 많은 비교글들을 찾을 수 있긴 하지만,
각각의 정의를 나열할 뿐 정작 그래서 뭐가 다른지에 대한 실질적으로 표현한 글은 찾을수 없었던 것 같고..
자동화 (CI/CD)를 통한 개발, 배포적인 면에서는 차이가 없어 보이며 어떤 부분에서는 개발에서 진행하면 DevOps, 기존 운영에서 진행하면 SRE로 표현 하는 등 실질적인 차이점에 대하여 정리된 내용은 없는것 같아
저 스스로도 정리도 할겸 DevOps vs SRE의 차이점을 제 나름대로 재 정의해 보고자 합니다.
우선 SRE를 처음으로 정의한 Site Reliability Engineering에 따르면
"class SRE implements interface DevOps"
로 정의 하고 있습니다.
뭔가 engineer스러운 표현 이기도 하고 이써빌리티 한것 같기도 하지만 개인적으로 오히려 더 헷갈리는 표현이라고 생각 드는 부분도 있긴 합니다.
해서 Wikipedia에서 각 항목을 어떻게 정의 하는지 한번 살펴 보겠습니다.
DevOps 정의 살펴보기
로 정의 하고 있으며 간략히 번역하면
DevOps는 기존의 개발팀(Dev)와 운영팀 (Ops)를 결합한 'practice'이다.
라고 말씀 드릴 수 있을것 같습니다.
DevOps를 정의 할때 위 내용에 추가하여 항상 따라오는 설명이 DevOps는 단순히 개발팀과 운영팀을 조직 및 기능적으로 결함 한 것이 아닌 문화 철학, 방식 및 도구의 조합으로 표현 하고 있습니다.
무언가 글로써 설명하려니 어려운데 제 나름대로 DevOps를 실제 동작하는 방식과 결합하여 다시 표현해 보면,
CI/CD (Continuous Integration/Continuous Delivery or Deployment) 및 Automation을 통하여 기존의 개발과 운영을 (프로세스, 조직, 문화적으로) 분리하여 개발 완료 후 변경 관리, 검증, 배포 프로세스등을 통해 통제하에 상용계/운영계 환경에 적용 하고, 개발팀은 기능 개발을 통해 패키지를 배포하는 역할을(개발), 운영팀은 해당 패키지를 상용계에 적용하며 그 이후에 대한 관리를(운영) 하던 분리된 개념에서 하나의 팀, 프로세스, 문화적으로 개발 - 테스트 - 배포를 자동화 하여 좀더 agile 하게 적용하는 방법론으로 얘기 할 수 있을것 같습니다.
출처 : WIKIPEDIA https://en.wikipedia.org/wiki/DevOps_toolchain#
다르게 표현 하자면,
안정적인 서비스의 운영이라는 목표를 이루기 위해 기존에는 ‘상용계 적용 전에 다양한 절차와 검증 과정을 통하여 최대한의 안정성을 확보하는 방향’으로 진행 되었다면, 최근의 트랜드는 ‘개발 + 운영 조직, 문화, 프로세스의 결합을 통하여 문제를 빠른 수정, 배포를 통해 지속적으로 문제를 개선하여 안정성을 확보 하는 방향’으로 변화한 결과물이라고 정의 할 수 있을 것 같습니다.
SRE(Site Reliability Engineering) 정의 살펴보기
Site reliability engineering(SRE) is a set of principles and practices that incorporates aspects of software engineering and applies them to infrastructure and operations problems.
사이트 신뢰성 엔지니어링(SRE)은 IT 운영에 대한 소프트웨어 엔지니어링 접근 방식입니다. SRE 팀은 소프트웨어를 툴로 활용하여 시스템을 관리하고, 문제를 해결하고, 운영 테스크를 자동화합니다.
좀더 설명을 덧붙이면,
서비스의 신뢰성 (Service Reliability)를 측정 가능한 지표로 정의 하고 그 지표를 달성하기 위한 프로세스 및 툴을 자동화 하되, 해당 지표를 기준으로 변경 혹은 배포 주기를 조정 하는 소프트웨어 공학론 혹은 방법론으로 정의 할수 있을것 같습니다.
출처 : Squadcast https://www.squadcast.com/blog
말이 좀 복잡한데 ㅜㅜ
예전부터 사용되어 오던 Service Level Agreement (SLA) 지표를 기준으로 추가적인 현재의 운영 안정화 상태를 몇가지 추가적인 지표로 정의 하고 (Service Level Object, Service Level Index, Error budget 등) 해당 지표를 기준으로 신규 기능 개발 (Development 및 DevOps automation)에 좀더 투자 할지 아니면 안정화에 더 투자 할지를 조정 하는 방법론이라고 할 수 있을것 같습니다.
다르게 표현하면 DevOps와 유사하게 ‘개발 - 테스트 - 배포까지 자동화 (automation) 하여 agile한 개발 및 빠른 배포를 통해 빠른 문제 해결을 통해 서비스를 안정화 시키되 그 주기나 속도 혹은 안정화 정도를 측정하는 지표를 수립하여 전체적인 서비스의 안정성을 확보한다’ 정의 하고 싶습니다.
물론 SRE workbook을 전체적으로 살펴 보면 저러한 지표를 수립하기 위한 방법론, 툴, 실제 장애나 문제 발생시 대응 방안등 SRE를 단순히 몇가지 지표로만 정의 하기 보단 Reliability를 확보하기 위한 다양한 내용을 포함 하는 것 전체를 SRE로 표현하는 것이 맞을것 같습니다.
DevOps와 SRE
위 내용들을 최근에 IT업계 및 실 생활에서 뜨거운 자동화관련 아이템인 ‘자동차 자동운전 시스템’에 비유하여 DevOps와 SRE를 비교하여 설명해 보면,
자동운전시스템을 개발 하여 실제 도로에 적용 하는 부분을 DevOps 혹은 automation으로 비유 한다면,
실질적인 운전 자체는 큰 사고나 이상 없이 잘 동작 한다 하더라도 어린이 보호 구역이나 고속도로에서 동일한 속도로 차가 이동해서는 안 될 것이며 같은 유형의 도로라 하더라도 날씨, 노면의 상태, 커브의 각도, 차선의 개수 등에 따른 조정이 필요하다고 생각 되고 그 최대 제한속도를 조정하는 지표를 정의 하고 (SLO, SLI, Error budget) 그 지표에 따라 안정성 여부를 판단 및 확보하는 것을 SRE로 비유 가능 하지 않을까 합니다.
결과적으로 DevOps와 SRE를 다른 개념으로 이해하거나 상호 배척되는 프로세스로 생각하시는 분들도 있는것 같습니다.
개인적으로 생각하기엔 SRE를 적용하기 위한 기본 layer로서 automation(혹은 DevOps)가 있다고 생각되며 일반적으로 SRE만 얘기 하시는 분들은 표현만 다르게 할 뿐 DevOps 혹은 CI/CD를 기본으로한 automation을 바탕으로 Reliability의 개념을 추가하여 확장 하는 것으로 받아 들이는 것으로 정의 하는 것이 맞지 않을까 합니다.
즉, 자동화도 좋은데 자동화를 통해 빠르게 빠르게 속도만 높이면 되는 것이 아니라
어느정도의 속도가 적절한지를 판단하는 지표나 방법을 추가한 내용이 SRE라 표현 하고 싶습니다.
참고로 현재의 SpaceONE는 다양한 경험과 지식을 가지고 있는 개발팀을 바탕으로 시장에 충분히 매력이 있는 상품으로 완성해 왔고 상품 자체적으로도 여러가지 장점도 많지만 그 바탕에는 aglie한 개발 방법론을 기본으로 한 최적화된 DevOps 프로세스를 이미 갖춘 결과도 있다고 생각 됩니다.
여기에 위 말씀 드린 SRE 방법론을 도입하여 고객에게 조금 더 안정적으로 제공되는 서비스가 되도록 하는것이 저희 임무라고 생각하고 있습니다.