SRE 관행의 수용

사이트 안정성 엔지니어링은 새로운 개념이 아닙니다. 운영 문제와 작업에 소프트웨어 엔지니어링 기술과 원칙을 적용하는 관행은 ‘사이트 안정성 엔지니어’라는 직책이 정의되기 전에도 이미 존재했습니다. 그러나 소프트웨어를 구축하고 유지관리하는 데 선제적인 접근방식을 도입하면, 운영 효율성, 데이터 기반 로드맵 계획, 일반적인 업타임 및 안정성의 측면에서 장기적인 성공을 거둘 수 있습니다. 이러한 모든 혜택 덕분에 SRE는 광범위하게 채택되고 있습니다.

이 글에서는 사이트 안정성 엔지니어링을 수행하는 데 필요한 사항, 조직이 SRE를 도입하는 방법, SRE 성숙 과정에서 염두에 두어야 할 핵심 원칙과 모범 사례들을 살펴볼 예정입니다.

SRE란?

사이트 안정성 엔지니어링(Site Reliability Engineering, SRE)은 데브옵스와 운영 문제에 소프트웨어 엔지니어링 전문 지식을 적용하는 관행입니다. 보통은 안정성과 성능 문제를 해결하기 위해 코드를 선제적으로 작성하고 내부 애플리케이션이나 서비스를 개발하는 것을 의미합니다. SRE는 수년간 존재해왔지만, 2016년 3월 사이트 안정성 엔지니어링: Google이 프로덕션 시스템을 운영하는 방법(Site Reliability Engineering: How Google Runs Production Systems)이 발표되면서 보편화되었습니다.

SRE는 복잡한 용어입니다. 사이트 안정성 엔지니어는 물론 개발 및 IT 팀, 사이트 신뢰성 엔지니어링에서 도입한 일반적인 관행과도 관련이 있기 때문입니다.

SRE 팀은 대부분 조직과 그 조직이 지원하는 서비스에 따라 다르게 구성됩니다. 때로는 사이트 안정성 엔지니어(SRE)가 개발 팀에 투입되기도 합니다. 이는 SRE가 로드맵 계획 과정에서 문제를 해결하고 QA 팀과 긴밀하게 협력하여, 배포 기능에서 스테이징, 그리고 프로덕션 환경의 관리에 이르는 모든 작업을 공동으로 수행할 수 있다는 의미입니다.

또 다른 접근 방식은 SRE 팀을 독립적인 그룹으로 구성하는 것입니다. SRE 팀 전체가 애플리케이션 및 인프라 모니터링, 안정성 지표 수립, 새 릴리스의 문제 추적, 호출 시 업무 처리 등에 집중합니다. 팀이 어떻게 구성되는지에 상관 없이, 모든 SRE의 공통된 이니셔티브는 안정성과 성능입니다.

데브옵스 vs. SRE

데브옵스(DevOps) 관행이 빠르게 수용되면서, “SRE가 데브옵스와 어떻게 다른가?"라는 생각을 하게 됩니다. 일반적으로 두 용어는 따로 떼어 놓을 수 없습니다. SRE는 데브옵스 문화와 수용에 반드시 포함되지는 않지만, 데브옵스 여정에서 앞으로 나가려는 조직들은 대부분 SRE를 구현합니다. 데브옵스의 성숙도가 높아질수록, SRE 관행을 도입할 가능성도 높아집니다.

SRE와 데브옵스가 어떻게 다른가는 크게 중요하지 않습니다. 그보다 데브옵스 관행을 강화하는 데 도움이 되는 SRE 팀과 운영 모델을 어떻게 구축할 것인가가 더 중요합니다. 개발 팀과 IT 팀에 SRE 프레임워크를 통합하거나, SRE를 독립적인 사업부로 구성할 경우, SRE의 일반적인 책임을 이해할 필요가 있습니다.

SRE 팀의 책임

사이트 안정성 엔지니어는 애플리케이션, 서비스 및 인프라의 측면에서 성능과 안정성이 실질적으로 무엇을 의미하는지 정의할 책임이 있습니다. 새로운 모니터링 솔루션을 구축하는 일에서부터 기술 지원 팀을 위한 맞춤형 앱을 구축하는 일까지 일상적인 업무의 범위는 다양합니다. 버그를 수정하거나, 새로운 기능을 제공하기 위해 새로운 코드를 운영 환경에 배포하는 것일 수도 있고, 인시던트에 실시간으로 대응하고 지원 팀과 긴밀하게 협력하여 긍정적인 고객 경험을 제공하는 것일 수도 있습니다.

사이트 안정성 엔지니어는 고객이 제품을 어떻게 경험하는지 알고, 고객의 시점에서 시스템의 성능과 안정성을 추적하는 방법을 이해하는 데 핵심적인 역할을 합니다. SRE 팀은 개발 팀이 배포한 것과 고객 경험 사이에서 서비스경계가 어디인지 정확히 구분할 필요가 있습니다. 그리고 내부 팀이 위험을 사전에 식별하고 더 나은 소프트웨어를 제공하는 데 도움을 줄 수 있도록 안정성과 성능 문제를 모니터링할 방법을 찾아야 합니다.

SRE 팀은 제품 및 개발 팀과 지식을 공유하고 조직 전체에서 안정성을 일관되게 정의합니다. 모든 사람이 같은 목표를 위해 협업해야만 엔지니어링 팀이 새로운 기능을 릴리스하거나 기존 운영 환경을 개선할 때 데이터 기반의 의사 결정을 내릴 수 있습니다.

사이트 안정성 엔지니어링 원칙 및 관행

Google은 SRE 원칙 및 관행의 핵심을 크게 ‘위험 포용’으로 정의하고 있습니다. 사이트 안정성 엔지니어는 지속적으로 혁신하며 새로운 소프트웨어를 제공해야 하는 조직의 필요성과 운영 환경의 안정성 및 성능 유지 간에 균형을 유지합니다. 예를 들어, 서비스에서 비핵심적인 어떤 부분이 고객에게 영향을 주지 않는다면 업타임을 99.999%로 유지할 필요가 없을 것입니다. 안정성 작업으로 인해 소프트웨어 배포의 수명주기가 크게 지연이 되는데, 고객의 입장에서 서비스가 눈에 띄게 개선되지는 않는다면 작업은 그저 시간 낭비일 뿐입니다.

개발 팀과 운영 팀의 상반되는 요구 사항 사이에서 균형을 유지하는 데 도움을 주기 때문에, SRE 관행은 데브옵스 수용과 더불어 계속 증가하는 추세입니다. 사이트 안정성 엔지니어는 지속적인 통합/지속적인 배포(CI/CD)와 소프트웨어 배포 워크플로우에 프로세스를 추가해 성능과 안정성을 향상시키지만, 속도를 위해 안정성을 희생해야 하는 때를 알고 있습니다. 데브옵스 팀과 긴밀하게 협력해 애플리케이션 및 인프라의 핵심 구성 요소를 이해함으로써, SRE는 중요하지 않은 구성 요소에 대해서도 알 수 있습니다.

팀 전체에서 애플리케이션과 시스템의 상태에 대한 투명성을 확보하는 것은 사이트 안정성 엔지니어가 허용되는 위험 수준을 결정하는 데 도움이 됩니다. 원하는 서비스 가용성 수준과 합리적으로 허용 가능한 성능 문제는 어떤 서비스를 지원하느냐에 따라 달라집니다. SRE 원칙 및 관행은 실험적 사고를 수용하며 지원하는 서비스의 상태를 선제적으로 이해하기 위한 노력이 필요합니다.

SRE 운영 및 성숙도 모델

사이트 안정성 엔지니어는 다양한 업무를 수행하지만, 소프트웨어 엔지니어라는 직함도 유지하고 있습니다. 그렇다면 조직의 사이트 안정성 엔지니어링 관행이 얼마나 성숙한지 어떻게 알 수 있을까요? 다행히도, 효과적인 SRE 운영 모델을 구축하고 기업의 성숙도를 추적할 수 있는 빠른 방법이 있습니다.

SRE 운영 모델에는 일반적으로 세 가지 요소가 포함되며, 단계별로 달성할 수 있습니다.

1. SRE 관행을 전담하는 팀(또는 최소 직원 한 명)이 필요합니다.
2. 제품, 개발 및 운영 팀들 간의 긴밀한 통합과 영향이 필요합니다.
3. 워크플로우를 자동화하고 애플리케이션이나 시스템의 거의 모든 부분에 대해 자율적으로 코드를 작성할 수 있는 권한이 필요합니다.

SRE 성숙도는 SRE 운영 모델의 이 세 가지 요소에서 조직이 어떤 위치에 있느냐로 판단할 수 있습니다. SRE 팀을 새로 만들려고 하거나 처음으로 사이트 안정성 엔지니어를 고용했다면 이제 여정의 시작 부분에 있는 것입니다. 팀이 구성되어 있고, 로드맵, QA, 배포 워크플로우, 인시던트 관리 프로세스에서 중요한 부분을 차지하게 되었다면 SRE 관행이 어느 정도 성숙된 것입니다.

SRE 사업부가 워크플로우를 자동화하고 애플리케이션을 구축하며 모니터링 및 알람 솔루션을 보유하거나 거의 모든 대화에 참여할 수 있는 자율적인 권한을 가지고 있는 경우라면, 비로소 완전한 SRE 성숙도에 도달한 것입니다. 성과 및 안정성에 대한 우려사항이 있다면, 너무 늦을 때까지 묻어 두는 것보다 사전에 터놓고 논의하는 것이 좋습니다.

모니터링, CI/CD 및 조직 자동화

사이트 안정성 엔지니어는 모든 것을 자동화할 수 있습니다. 문제를 선제적으로 감지, 완화 또는 해결할 수 있다면 자동화를 해야 합니다. SRE는 지속적인 통합 및 배포 관행에서 운영 환경 모니터링에 이르기까지, 모든 것에 대해 어느 정도 파악하고 있어야 합니다. 성능과 안정성 문제를 선제적으로 파악할 방법이 있다면, 그러한 변경 사항을 구현할 권한이 있어야 합니다.

자동화, 모니터링, 인공 지능, 머신 러닝과 관련된 데브옵스 및 IT 역량은 SRE 팀이 문제를 파악하고 이에 대응하며 해결할 때 큰 이점을 제공합니다. 성숙한 데브옵스 및 SRE 관행을 보유한 조직은 스테이징 단계에서 문제를 식별하고, 자동화된 인시던트 관리 워크플로우와 자체 해결 시스템을 구축할 수 있습니다. SRE는 애플리케이션 및 인프라에서 어떤 구성 요소가 핵심적인지 판단함으로써, 주요 문제를 일으킬 수 있는 요소들의 범위를 좁힐 수 있습니다.

서비스 수준 관행(SLI, SLO 및 SLA)

SRE 팀은 서비스 수준을 사용해 디지털 제품과 서비스의 실질적인 상태를 모든 이해 관계자들에게 전달할 수 있습니다. 이를 위해서는 긍정적인 고객 경험을 제공하는 데 핵심적인 요소를 파악하고 측정하는 것이 필요합니다. 특히, 하나 이상의 구성 요소가 외부 고객에게 기능을 노출시키는경우 알고 있어야 합니다. 이런 교차 지점을 시스템 경계라고 합니다. 시스템 경계는 사이트 안정성 엔지니어가 시스템의 성능 및 안정성의 실제 상황을 설명하기 위해 서비스 수준 지표와 목표를 측정 지표에 적용하는 지점입니다.

• 서비스 수준 표시기(SLI)는 시스템의 가용성을 파악하기 위한 핵심 측정 지표입니다.
• 서비스 수준 목표(SLO)는 시스템에서 기대하는 가용성에 대해 설정한 목표입니다.
• 서비스 수준 계약(SLA)은 시스템이 SLO를 충족하지 못할 경우 어떻게 되는지를 설명하는 법적 계약입니다.

SRE가 항상 서비스 수준 관리에 대한 책임을 지는 것은 아니지만, 서비스 수준이 책임 범위에 포함되는 경우가 많습니다. SLI를 추적하고 SLO에 연결하면, 시스템 성능에 대한 목표를 설정할 수 있습니다. Google의 SRE 지침은 레이턴시, 트래픽, 오류 및 포화를 서비스 수준의 4가지 골든 시그널로 정의합니다. 예를 들어, API 호출을 확인하고 고객이 좋은 경험을 하려면 성공해야 하는 일반적인 요청의 비율(SLO)을 기준으로 성공/실패 요청 수(SLI)를 추적할 수 있습니다.

SRE 팀은 고객에게 어느 정도 수준의 SLA를 보장해 줘야 할지 보다 잘 이해하기 위해, 애플리케이션과 서비스 내의 핵심 구성 요소에 대해 엄격한 SLO를 설정합니다. 이를 기준으로 팀은 SLO를 준수하려면 얼마나 신속하게 문제를 해결해야 하는지 이해하기 위한 방법으로 오류 예산을 적용할 수 있습니다. 서비스 레벨은 팀이 메트릭을 집계하고 전체 조직에서 업타임, 성능 및 안정성을 투명하게 파악할 수 있도록 해줍니다. 비즈니스 리더들은 서비스 수준을 사용해 여러 팀, 애플리케이션, 서비스 등의 규정 준 수 여부를 한눈에 모니터링하고 시스템 상태를 포괄적으로 파악할 수 있습니다.

SRE 모범 사례의 도입

SRE 모범 사례와 원칙을 도입하는 일은 하루 아침에 되는 일이 아닙니다. 팀과 시스템을 선제적으로 모니터링하여 성능 및 안정성 문제를 해결하는 데는 시간과 노력이 필요합니다. 하지만 데브옵스 팀 뿐만 아니라, 고객들이 사이트 안정성 엔지니어링을 활용하기로 한 결정을 고마워할 것입니다.