어느 날 지인을 만났는데, 본인을 SRE팀이라고 소개하였다. SRE라는 단어를 처음 들었던 나는 도대체 SRE가 뭐하는 팀인가 궁금해졌다. 검색 결과 SRE와 DevOps의 차이를 비교하는 글들을 여럿 찾아볼 수 있었다.
하지만, 여러 글들을 찾아보면서도... 차이가 잘 이해가 가지 않는 것 같아서 직접 정리하면서 이해해보려고 한다..
1. DevOps (Development + Operations)
DevOps란 말 그대로 Development와 Operations의 합성어이다.
개발팀과 운영팀을 나누지 않고 병합하여, 엔지니어가 개발에서 테스트, 배포, 운영까지 모두 수행하는 것을 말한다.
개발팀은 개발에 치중하고, 운영팀은 운영에 치중하기 때문에 때로는 이해 관계가 불일치해서 트러블이 생기는 경우가 있다. DevOps는 이러한 문제를 줄이고자 개발팀과 운영팀을 병합하여 이해 관계가 일치하도록 한다. DevOps의 이러한 철학으로 서로 다른 두 팀의 프로세스를 이해하면 조직 사일로가 크게 줄어들어 개발에서 프로덕션 환경으로 코드를 더 빠르게 이동하면서 실패를 줄일 수 있다.
2. DevOps의 특징
2-1. Cross Functional Team
개발 ~ 테스트 ~ 배포 ~ 운영을 모두 다 할수있는 사람들을 모아서 하나의 팀을 만드는 것이 아니라,
각 담당자들을 모아서 하나의 팀으로 만들라는 의미이다.
2-2. Widely Shared Metrics
자기 자신의 업무만 신경쓰는 것이 아니라 팀원 모두가 알고있는 하나의 공유된 지표가 필요하다.
서비스를 개발만 하는것이 아니라 운영에서 잘 돌아가고 있는지, 사용자의 반응은 어떠한지 등을 모두 인지하고 있어야 한다.
2-3. Automating repetitive tasks
CI / CD를 이용하여 반복적인 작업들을 자동화한다. 빌드 - 배포 - 테스트의 과정을 자동화하여 좀 더 효율적으로 일하고 신간을 줄일 수 있다. 인력들이 반복적인 작업을 계속 하는것은 여러모로 손해인데다, 자동화 작업을 하는 과정에서 시스템 전체에 대한 이해도가 높아진다.
2-4. Post Mortems
장애나 이슈가 있을때 혼자만 알지말고, 팀원들과 공유한다.
2-5. Regular Release
짧은 주기로 정기적인 배포를 통해서 빠르게 서비스의 기능을 개선하고 고객들의 VoC를 반영해 나간다.
3. SRE (Site Reliability Engineering)
SRE (사이트 안정성 엔지니어링)이란 조직이 해당 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지우너하는 엔지니어링 분야이다. 여기서 핵심이 되는 단어는 안정성이다.
100% 안정적인 시스템은 존재하지 않으므로 적절한 수준의 안정성을 달성하기 위해서 일련의 작업들을 수행하는 것이 SRE의 기본이라고 볼 수 있다.
SRE는 구글의 소프트웨어 엔지니어로 구성된 팀에서부터 시작되고 확산되어 나갔다. 동시에 DevOps라고 하는 문화가 같이 확산되기 시작하였는데, 이 둘에는 차이점이 있다.
DevOps가 개발과 운영의 사일로 현상을 해결하기 위한 방법론이자 하나의 조직문화에 대한 방향성을 제공한다면,
SRE는 DevOps에 적용하기 위한 구체적인 Practice라고 생각하면 된다.
| DevOps | SRE |
| 문화로 인식 | 규범으로 인식 |
| 개발과 운영의 사일로 현상을 해결하기 위한 문화 | 안정성을 위한 엔지니어링 |
| 저는 DevOps 엔지니어 or DevOps 개발자 입니다. | 저는 SRE 입니다. |
| 모니터링/식별 가능 , 자동화 | |
4. SRE 특징
4-1. Metric & Monitoring (측정값 & 모니터링)
모니터링 지표를 정의하고, 이 지표를 모니터링 시스템에 올리는 일이다. 서비스에 대한 지표를 SLI (Service Level Indictor)라는 것을 정하고, 각 지표에 대한 안정성 목표를 SLO (Service Level Objective)로 정해서 관리한다.
* SLI (서비스 수준의 척도) : 기능적인 요구사항이 아닌 응답 속도, 가용성, 처리량 등 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정할 수 있는 척도
* SLO (서비스 수준의 목표) : SLI에 의해 측정된 서비스 수준의 목표 값 혹은 일정 범위의 값을 의미한다.
#SLO는 다음과 같이 표현할 수 있다.
SLI <= 목표치
최솟값 <= SLI <= 최댓값
SRE에서 가장 중요한점 중 하나는 모든것을 데이터화하고, 의사결정을 데이터를 기반으로 한다.
4-2. Capacity Planning (용량 계획)
시스템을 운영하는데 필요한 충분한 하드웨어 리소스를 확보하는 작업을 한다. 비지니스 성장에 의한 증설 혹은 이벤트나 마케팅 행사, 새로운 제품 출시드응로 비정상적인 리소스 요청에 대해서도 유연하게 대응할 수 있어야 한다.
4-3. Change Management (변경 관리)
사람이 변경관리 했을때 발생하는 문제를 최소화하고 자동화하는 방향으로 작업을 진행한다.
시스템 장애의 원인은 대략 70%가 시스템에 변경을 줄 때 발생한다고 한다. 그만큼 시스템의 안정성에 있어서 변경관리가 중요하다.
4-4. Emergency Response (장애 처리)
시스템 안정성이란 장애가 발생하지 않고 얼마나 오랫동안 정상 작동했는지??? 장애가 발생했을 때 복구에 걸리는 시간은얼마인지??? 를 모두 계산하여야 한다. 최대한 장애가 발생하지 않고 연속적으로 작동하여야 하고, 장애가 발생하더라도 빠르게 복구되어야 한다.
장애 복구 단계에서 사람이 직접 복구하게 되면 더 많은 시간이 발생하게 되므로, 각 단계별로 자동화한다면 장애 처리를 더욱 빠르게 할 수 있게 된다.
DevOps와 SRE 주요 차이점 정리
| DevOps | SRE | |
| 주요 관심 | 개발 배포 과정 통합 | 확장성, 운영지표, 자동화 |
| 담당자 | 개발에 관심 있는 운영팀 | 운영에 관심 있는 개발팀 |
| 측정 지표 | 주로 시스템 Telemetry | 서비스 수준 목표(SLO)의 최소/최대치(SIO) |
| 적용 기업 | 온-프레미스에서 클라우드로 전향하는 기업 | 클라우드-네이티브 환경에서 IT 서비스 기업 |
참고자료 : blog.creation.net/devops-vs-sre-vs-choas-engineering