SRE 기본: 사이트 안정성 엔지니어링에서 기대할 수 있는 것

사이트 안정성 엔지니어링은 소프트웨어 엔지니어링 도구와 원칙을 IT 운영에 통합하는 관행입니다. SRE는 안정적이고, 탄력적이며, 효율적이고 확장성 있는 인프라와 서비스를 구축하고 유지관리합니다. SRE는 확장 가능한 시스템의 안정성을 개선합니다. 설계상 복원력이 뛰어난 시스템을 구축하고, 소프트웨어와 자동화를 사용하여 계속 성장하는 인프라를 관리합니다. 이는 수동으로 관리하는 것보다 훨씬 지속 가능한 방식입니다.

사이트 안정성 엔지니어는 IT 운영을 관리하고 자동화하는 책임을 맡고 있는 사람들입니다. 소프트웨어 엔지니어링 전문성을 바탕으로 시스템의 복원력과 가용성을 유지하고, 문제를 자동으로 해결합니다. 이 역할은 새로운 애플리케이션의 제공 및 배포를 감독하여 잠재적인 중단 및 장애를 방지합니다.

Google 엔지니어링 부사장 Benjamin Treynor Sloss는 2003년에 '사이트 안정성 엔지니어링'이라는 용어를 처음 만들면서 'SRE는 소프트웨어 엔지니어에게 운영 팀을 설계하도록 요청할 때의 결과물'이라고 말했습니다. 그 자신도 이 일을 담당한 적이 있습니다.¹

Google의 신입사원일 때 그는 빠르게 확장되는 운영과 대규모 분산 인프라를 관리하기 위한 엔지니어링 솔루션을 찾는 업무를 맡았습니다. 회사의 인프라가 급속도로 확장됨에 따라, 새로운 서비스를 수동으로 관리하면서 동시에 같은 속도로 혁신을 지속할 수 있을 만큼의 엔지니어를 고용하는 것은 사실상 불가능한 일이었습니다. 대신 Treynor의 팀은 혁신과 시스템 안정성 간의 균형을 유지하여 지속적인 학습과 개선의 문화를 조성했습니다.  

곧 Google의 SRE 팀은 점점 규모가 커지면서, 서비스의 안정성과 신뢰성을 유지하는 동시에 새로운 기능을 프로덕션 환경에 빠르게 배포하는 데 집중하게 되었습니다. 몇 년 지나지 않아, 더 많은 기업들이 Google과 동일한 문제에 직면하게 되었습니다. 서비스의 가용성과 안정성을 유지하면서 대규모의 분산된 인프라를 관리해야 했습니다. 곧 사이트 안정성 엔지니어링 관행은 Google을 넘어 현대 IT 운영의 핵심으로 자리 잡았습니다.

오늘날의 디지털 우선 세상에서 모든 규모의 기업은 고가용성, 확장성, 회복력이 뛰어난 시스템에 의존하게 되었습니다. 웹사이트든 모바일 앱이든 한 번의 장애는 금전적 손실, 고객 경험 저하, 운영 비효율성으로 이어질 수 있습니다. 그래서 SRE가 모든 회사에서 필수적인 역할을 합니다. 

SRE는 경쟁사와의 격차를 좁히고, 시장에서 뒤처지지 않도록 하는 데 큰 역할을 합니다. 가용성 문제를 며칠이 아닌 몇 분 만에 해결할 수 있으며, 사용자 수에 관계없이 빠른 페이지 로딩 속도를 보장합니다. 

대기업에서는 SRE들이 같은 업무를 더 큰 규모로 수행합니다. 사전 모니터링 및 사고 관리를 통해 안정성을 자동화하고 성능을 최적화하며 시스템 장애를 방지합니다. SRE는 개발팀과 운영팀 간의 협업을 촉진하여 안정적이고 효율적인 시스템을 구축합니다.

사이트 안정성 엔지니어링의 핵심은 소프트웨어 개발 접근 방식으로 프로덕션의 운영 문제를 해결하는 것입니다. 다른 핵심 원칙으로는 위험을 수용하고, 자동화를 사용하며, 서비스 수준 목표(SLO) 및 서비스 수준 지표(SLI)를 설정하는 것입니다.

SRE는 어떤 시스템도 완벽하게 작동할 수 없다는 것을 인정합니다. 장애와 중단은 혁신 프로세스의 일부로 예상됩니다. SRE는 실패를 피하려고 노력하는 대신, 허용 가능한 위험 수준을 파악하는 데 집중합니다.

위험을 수용한다는 것은 안정성을 개선하고 새로운 코드를 배포하면서도 사용자에게 미칠 수 있는 영향을 어떻게 균형 있게 관리할 것인지에 대한 기준점을 찾아내는 일입니다. 서비스의 안정성을 개선하는 데 필요한 시간, 에너지 또는 기타 자원은 허용 가능한 위험으로 간주됩니다. 그 이상은 허용되지 않는 위험입니다. 하지만 어느 정도의 위험을 허용할 수 있을까요? 그 과정의 어느 시점에서 사용자 경험이 저하되기 시작할까요? 

SRE의 핵심 원칙은 네 가지 요소에 기반을 둡니다.

1. 사용자에게 허용 가능한 수준의 안정성(SLO 및 SLI 설정에 따라 결정)

2. 안정성 개선 비용(자동화 및 도구 포함)

3. 개선되지 않을 위험성 

4. 비용 대비 위험(오류 예산을 통해 확인)

위험을 수용하는 데 있어 핵심은 조직 문화적인 관점인 경우가 많습니다. 시스템 안정성 엔지니어는 비처벌적 문화 속에서 일하면서 실패로부터 학습하고, 예방 조치를 도입함으로써 시스템 안정성을 지속적으로 강화하고 애플리케이션 성능을 개선합니다.

오류 예산
오류 예산은 위험을 이해하고 관리하기 위한 명확한 지표로서, 특정 기간 동안 서비스가 허용할 수 있는 다운타임이나 오류 발생 횟수를 의미합니다.

허용 가능한 수준의 시스템 불안정성(오류 예산이라고도 함)은 혁신과 안정성의 균형을 맞추는 데 도움이 됩니다. 엔지니어는 오류 예산이 허용하는 선에서 배포 속도를 높이고 새로운 기능을 출시하는 등 위험을 감수해보는 것이 좋습니다. 이 임계값에 도달하면 엔지니어는 시스템을 안정화하여 안정성을 개선합니다.

SRE 팀은 SLO에 따라 허용 가능한 오류 수준(또는 다운타임)을 결정하여 오류 예산을 계산합니다. 즉, SLO에서 허용하는 오류 범위입니다.

서비스 수준 목표 또는 SLO는 일정 기간 동안의 성과에 대한 목표 값입니다. 설계 단계부터 엔지니어링 팀과 비즈니스 이해관계자 모두 이러한 목표를 이해하여 의사 결정의 기준이 되는 명확한 기대치를 설정해야 합니다. 

서비스 수준 지표(SLI)는 서비스 성능을 측정합니다. 일반적으로 SLI는 서비스 지연 시간, 가용성, 처리량, 오류율 등과 같은 사용자 우선순위를 나타냅니다. 

SLO나 SLI는 정지된 개념이 아닙니다. 시간이 지남에 따라 발전하며, 정기적인 검토와 개선이 필요합니다.

마침내, 자동화입니다. SRE는 수동적이고 반복적인 작업을 자동화로 대체하기 위해 노력합니다. 수고를 줄인다는 것은 시스템 안정성을 개선하고 더 빠르고 효율적으로 혁신한다는 의미입니다.

일부 SRE 팀은 배포, 인시던트 대응 및 테스트를 위한 자동화 도구를 개발하는 데 최대 절반의 시간을 할애합니다. 시간이 지남에 따라 고급 자동화 기능은 서비스 안정성과 최적의 성능을 보장하면서 확장 비용을 절감하는 데 도움이 됩니다.

모니터링과 통합 가시성은 사이트 안정성 엔지니어에게 중요합니다. 서비스가 제대로 작동하고 있는지, 얼마나 잘 작동하는지, 어디에 문제가 있는지 등을 명확히 보여주기 때문입니다. 

모니터링은 사이트 안정성 엔지니어가 문제를 신속하게 감지하고 해결하는 데 도움을 줍니다. 통합 가시성은 시스템 성능에 대해 실시간 및 과거의 인사이트를 제공하여 알 수 없는 문제를 해결합니다. 추적, 로그, 메트릭은 주요 통합 가시성 시그널입니다.

사이트 안정성 엔지니어링의 네 가지 골든 시그널은 대기 시간, 트래픽, 오류, 포화도입니다. 이러한 메트릭은 분산 시스템에서 서비스의 상태와 성능을 나타내는 애플리케이션 안정성의 기초입니다. 

• 지연 시간은 시스템이 요청에 응답하는 데 걸리는 시간입니다(성공 또는 오류 포함). 지연 시간이 높으면 엔지니어가 즉시 주의를 기울여야 할 성능 문제가 있다는 뜻입니다.

• 트래픽은 시스템의 수요를 측정합니다. 시스템에 따라 초당 트랜잭션 수 또는 초당 HTTP 요청 수로 나타낼 수 있습니다. 사이트 안정성 엔지니어는 트래픽을 사용하여 사용자 경험이 저하되고 있는지를 판단합니다.

• 오류는 실패한 요청의 비율을 나타냅니다. 명시적 실패(예: HTTP 500), 암시적 실패(예: HTTP 200이지만 콘텐츠 오류가 있는 경우), 또는 정책에 따른 식패(예: 1초 이상 걸리는 요청은 실패로 간주)가 포함될 수 있습니다. 시스템에 따라 SRE는 특정 유형의 오류를 다른 것보다 우선시하고 반복되는 문제를 해결할 수 있습니다.

• 포화도는 시스템의 전체 용량 또는 서비스가 얼마나 포화된 상태인지를 나타냅니다. 이는 가장 제약이 있는 리소스나 시스템이 처리할 수 있는 남은 부하에 따라 다양한 방법으로 측정할 수 있습니다.

사이트 안정성 엔지니어는 이 네 가지 골든 시그널을 통해 용량 계획, 시간 경과에 따른 시스템 안정성 개선, 인시던트 대응 및 관리, 문제의 근본 원인 찾기에 집중할 수 있습니다. 


하지만 네 가지 골든 시그널만으로는 복잡한 분산 시스템을 완전히 안정화할 수 없습니다. 분산 추적이 필요한이유가 바로 여기에 있습니다. 분산 추적은 모든 성능 수치를 맥락에 맞게 배치합니다.

앞서 언급했듯이 SRE에서는 사고와 장애를 피할 수 없는 일로 생각합니다. 그러나 모든 인시던트에는 여전히 응답이 필요합니다. 효과적인 인시던트 대응 계획에는 분류 절차, 명확한 통신 프로토콜, 그리고 에스컬레이션 경로가 포함됩니다.

사후 분석도 못지않게 중요합니다. 사후 분석은 책임을 추궁하는 것이 아니라, 문제로부터 배우는 건설적인 과정입니다. 엔지니어는 각 인시던트를 기록하고, 근본 원인을 파악한 뒤 개발 팀과 협력하여 코드를 수정하거나 재발 방지를 위한 도구를 구축하는 데 집중해야 합니다. 

사고 관리에 대해 더 깊이 알아보세요.

용량 계획은 오늘과 내일의 서비스 안정성을 보장합니다. 과잉 프로비저닝과 과소 프로비저닝을 모두 방지합니다. 

SRE 팀은 과거 사용 패턴을 분석하고 향후 리소스 수요를 예측합니다. 비효율적인 부분을 찾아내고, 실시간 정보를 기반으로 리소스를 최적화 및 재할당하며, 변화하는 데이터에 따라 이러한 계획을 정기적으로 업데이트합니다. 

사이트 안정성 엔지니어는 용량 계획을 통해 시스템이 성장과 수요 급증을 처리할 수 있도록 보장합니다.

변경 사항은 종종 운영 중단으로 이어지며, 이는 기존 IT 운영 팀도 증명할 수 있습니다. 그러나 사이트 안정성 엔지니어는 중단을 두려워하고 따라서 변화를 두려워하는 것이 아니라 세 가지 모범 사례를 통해 변화를 수용합니다.

• 점진적이고 통제된 롤아웃으로 잠재적인 문제의 영향을 최소화하고 문제를 조기에 발견합니다.

• 모니터링으로 실시간으로 문제를 정확하게 감지합니다.

• 롤백 계획을 세워 문제가 발생할 경우 변경 사항을 안전하고 신속하게 되돌리는 절차를 확립합니다.  

가능한 경우에는 이 세 가지 관행을 모두 자동화해야 합니다.

Elastic Observability는 기술 스택 전반에서 통합 가시성 메트릭을 수집, 모니터링, 분석하기 위한 통합 솔루션을 제공합니다. Elastic Observability를 사용하면 모든 소스에서 통합 가시성 메트릭을 수집, 저장, 시각화할 수 있으며 Elastic의 Search AI Platform을 통해 문제 해결 속도를 높일 수 있습니다. 


대화형 검색과 에이전트형 AI를 Elastic Observability와 결합하여 독점 데이터와 런북을 포함하도록 확장된 상황 인식 채팅 환경을 구축하세요. Elastic AI Assistant는 사이트 안정성 엔지니어가 로그 메시지와 오류를 해석하고, 코드를 최적화하고, 보고서를 작성하고, 심지어 런북을 식별하고 실행하는 데까지 도움을 줄 수 있습니다. 문제 해결을 가속화하고, 협업을 촉진하며, 지식을 확보하여 모든 사용자의 역량을 강화하고 안정성을 보장하세요.

Elastic이 지원하는 통합 가시성에 대해 자세히 알아보세요.