사이트 신뢰성 엔지니어링(Site Reliability Engineering)은 운영을 소프트웨어 문제로 다룰 때 얻는 결과다. 프로덕션 서비스의 신뢰성을 책임지고, 그것을 사용자 쪽에서 측정하며, 시간의 절반 이상을 운영 작업을 손으로 하는 대신 그 작업을 없애는 코드를 쓰는 데 보내는 엔지니어 팀이다. SRE는 이름만 바꾼 시스템 관리자도, 호출기를 든 DevOps 엔지니어도 아니다. 이 역할에는 정의된 범위, 정의된 관찰 대상, 그리고 개발자와의 정의된 관계가 있다. 이 글은 그 세 가지를 모두 다룬다.

이 글은 Budget for Failure 시리즈의 1부다. 사이트 신뢰성 엔지니어링이 무엇이고 어떻게 하는지를 다루는 4부작이다. 1부와 2부는 101 수준이다. 역할, 그리고 그 역할이 돌아가는 숫자(SLI, SLO, SLA, 에러 버짓)를 다룬다. 3부와 4부는 201 수준이다. SRE가 코드베이스에서 장악해야 하는 것, 그리고 클라우드든 자체 데이터센터든 공급자 쪽에서 점검할 것을 다룬다. 예시는 AWS 위에 있지만, 실천 자체는 AWS에 국한되지 않는다.

이 역할은 어디서 왔는가

이 용어는 Google에서 나왔다. Ben Treynor Sloss가 2003년에 첫 팀을 만들었고, 나중에 SRE 책에서 한 줄로 설명했다. SRE는 소프트웨어 엔지니어에게 운영 팀을 설계하라고 요청했을 때 일어나는 일이다. 성장하는 서비스에 대한 엔지니어의 답은 트래픽에 비례해 운영자를 고용하는 것이 아니었다. 운영자의 일을 자동화하고, 팀이 받아들일 수 있는 수작업의 양에 단단한 상한을 두는 것이었다.

DevOps와의 관계는 역시 Google의 표현으로 "class SRE implements interface DevOps"라고 흔히 요약된다. DevOps는 원칙의 집합이다. 공동 소유, 작은 변경, 자동화, 측정. SRE는 그 원칙의 구체적 구현 하나이며 의견이 붙어 있다. 신뢰성을 정확히 어떻게 측정하는지, 그리고 측정 결과가 서비스가 충분히 신뢰할 만하지 않다고 말할 때 정확히 무슨 일이 일어나는지 같은 것들이다.

SRE가 책임지는 것

SRE 책은 그 범위를 한 문장으로 나열한다. SRE 팀은 자기 서비스의 가용성, 지연, 성능, 효율성, 변경 관리, 모니터링, 긴급 대응, 용량 계획을 책임진다. 이것을 한 주의 업무로 풀어 쓰면 다음과 같다.

  • 가용성과 지연. 사용자에게 "동작한다"가 무엇을 뜻하는지 숫자로 정의하고, 측정하고, 지켜내는 것. 2부 전체가 이 주제다.
  • 변경 관리. 대부분의 장애는 변경이 원인이다. SRE는 변경을 안전하게 만드는 장치를 소유한다. 점진적 롤아웃, 자동 롤백, 그리고 릴리스가 건강하다는 증거.
  • 모니터링과 알림. 어떤 신호가 새벽 3시에 사람을 깨울 가치가 있고 어떤 것이 대시보드에 머물러야 하는지 결정하는 것. 조치가 필요 없는 호출은 알림의 결함이고, SRE는 그것을 다른 결함과 똑같이 고친다.
  • 긴급 대응. 온콜(on-call)을 서고, 명확한 지휘 구조로 사건을 운영하며, 먼저 서비스를 복구하고 그다음에 진단하는 것.
  • 포스트모템(postmortem). 사건 이후, 무슨 일이 일어났고 어떤 체계적 수정이 그 장애 유형을 막는지에 대한 비난 없는 서면 분석. 비난 없음은 기술적 요구사항이다. 처벌을 예상하는 사람은 자기가 본 것을 보고하지 않게 된다.
  • 용량 계획. 여유가 얼마나 있고, 수요가 어떻게 늘고 있으며, 새 용량이 도착하는 데 얼마나 걸리는지 아는 것. 클라우드에서는 분 단위, 온프레미스에서는 월 단위다.
  • 효율성과 성능. 무제한의 여유 용량으로 산 신뢰성은 엔지니어링이 아니다. 요청당 비용도 SRE의 숫자다.
  • 토일 제거. 아래에서 다룬다. 나머지 전부를 가능하게 하는 부분이기 때문이다.

SRE가 보는 것

인프라에서 온 DevOps 엔지니어는 리소스를 보는 경향이 있다. CPU, 메모리, 디스크, 노드 수. SRE는 한 계층 위, 사용자가 경험한 것에서 시작하고, 리소스 메트릭은 그것을 설명하는 데만 쓴다. 표준 출발점은 SRE 책의 모니터링 장에 나오는 네 가지 골든 시그널이다.

신호답하는 질문AWS에서 있는 곳
지연요청이 얼마나 걸리는가, 성공과 실패를 나눠서?ALB TargetResponseTime 백분위수, API Gateway Latency, 애플리케이션 트레이스
트래픽시스템에 얼마나 많은 수요가 걸려 있는가?ALB RequestCount, SQS 전송 메시지 수, Lambda Invocations
에러요청 중 몇 퍼센트가 실패하는가?ALB HTTPCode_Target_5XX_Count와 HTTPCode_ELB_5XX_Count, Lambda Errors
포화가장 제약된 리소스가 얼마나 찼는가?max_connections 대비 RDS 연결 수, 큐 나이, ECS CPU 예약, 서비스 쿼터 사용량

두 가지 세부가 SRE의 읽기 방식을 일상적인 읽기와 구분한다. 지연은 평균이 아니라 항상 분포로 읽는다. 99번째 백분위수가 불행한 사용자들이 있는 곳이다. 그리고 포화는 실제로 가장 먼저 부딪힐 한계를 기준으로 읽는데, 그것은 CPU인 경우가 드물다. 데이터베이스 연결 풀, NAT 게이트웨이의 포트 할당, 계정 수준 Lambda 동시성, EBS 볼륨의 IOPS 예산이다.

네 가지 신호 너머로, SRE는 다음 달의 사건을 예고하는 것들을 주시한다. 변경의 빈도와 실패율, 가장 오래된 미패치 의존성의 나이, 지난주에 수작업으로 보낸 시간, 온콜 엔지니어가 받은 호출 횟수.

50퍼센트 규칙과 토일

SRE를 직함만 더 나은 운영 팀과 구분하는 특징은 상한이다. Google의 모델에서 SRE는 몇 분기 평균으로 시간의 최소 50퍼센트를 엔지니어링 작업에 쓴다. 나머지는 운영 작업에 갈 수 있다. 티켓, 온콜, 수동 작업.

그 수동 부분에는 토일(toil)이라는 이름과 정밀한 정의가 있다. 프로덕션 서비스 운영에 묶인 작업 중 수동이고, 반복적이며, 자동화 가능하고, 전술적이며, 지속적 가치가 없고, 서비스가 커지는 만큼 선형으로 늘어나는 경향이 있는 것. 멈춘 워커 재시작, 수동 인증서 교체, 쿼터 요청 승인, 개발자를 위한 데이터베이스 복사. 하나하나는 작다. 합쳐지면 다섯 명짜리 팀이 엔지니어링을 전혀 할 수 없는 이유가 된다.

상한은 SRE에게 거절할 명분을 준다. 토일이 팀 시간의 절반을 넘으면, 대응은 영웅적 분투가 아니다. 가장 큰 원인을 자동화하거나, 운영 부하를 그것을 만들어내는 팀에게 줄어들 때까지 돌려주는 것이다. 온콜도 같은 논리를 따른다. SRE 책은 지속 가능한 부하를 온콜 교대당 약 두 건의 사건으로 잡는다. 각 사건에는 후속 조치와 포스트모템이 필요하고, 하룻밤에 다섯 번 호출받는 사람은 둘 다 하지 못하기 때문이다.

SRE가 개발자를 돕는 방식

이 역할의 최악의 형태는 관문이다. 개발자가 릴리스를 벽 너머로 던지고 신뢰성 팀이 통과 여부를 결정한다. 유용한 형태는 개발자를 고객으로, 신뢰성을 SRE가 그들을 위해 만드는 제품으로 다룬다. 구체적인 네 가지 형태가 있다.

포장된 도로(paved road). 구조화된 로깅, 메트릭, 트레이싱, 헬스 체크, 카나리와 롤백이 있는 배포 파이프라인, 합리적인 알람이 이미 연결된 채로 도착하는 서비스 템플릿. 기본값을 택한 개발자는 런북을 읽지 않고도 신뢰할 수 있는 서비스를 얻는다. SRE 팀이 내놓는 것 중 가장 가치가 높다.

프로덕션 준비 리뷰(production readiness review). 새 서비스가 실제 트래픽을 받기 전에 SRE가 개발자와 함께 훑는다. 무엇에 의존하는가, 각 의존성이 느려지면 무슨 일이 일어나는가, 타임아웃은 얼마인가, 어떻게 롤백하는가, 누가 호출받는가. 설계를 바꿀 수 있을 만큼 이른 시점에 하는 설계 리뷰다. 3부에서 무엇을 볼지 다룬다.

에러 버짓(error budget). 언제 빠르게 출시해도 안전하고 언제 속도를 늦춰야 하는지 양쪽에 알려주는, 공유되고 사전에 합의된 숫자. 릴리스가 "너무 위험한지"에 대한 논쟁을 하나의 측정값으로 대체한다. 2부에서 만든다.

공유 온콜. 자기 서비스의 호출기를 직접 드는 개발자는 다른 코드를 쓴다. 많은 조직이 서비스를 개발자 교대에서 시작하고, 신뢰성 기준을 충족해야 SRE로 옮기며, 기준 아래로 떨어지면 다시 돌려보낸다. SRE의 일은 좋은 알림과 좋은 런북으로 그 교대를 인간적으로 만드는 것이지, 상류의 누구도 고통을 느끼지 못하도록 그것을 대신 흡수하는 것이 아니다.

SRE와 DevOps: 일이 달라지는 지점

파이프라인, Terraform, Kubernetes를 운영하며 먹고산다면 툴링 대부분은 그대로 가져갈 수 있다. 바뀌는 것은 각 도구가 답하는 질문이다.

DevOps 엔지니어로서 당신은SRE로서 당신은 추가로
CI/CD 파이프라인을 만든다어떤 증거가 롤아웃을 자동으로 멈추는지 결정하고, 각 릴리스가 신뢰성을 얼마나 소모하는지 측정한다
CPU, 메모리, 디스크에 알람을 건다사용자에게 보이는 증상에만 호출하고, 리소스 메트릭은 진단용으로 둔다
인프라를 코드로 프로비저닝한다그 인프라의 장애 도메인과 쿼터, 공급자의 컨트롤 플레인이 다운됐을 때 벌어지는 일을 안다
사건을 고친다사건을 운영하고, 포스트모템을 쓰고, 그 장애 유형을 제거하는 수정을 내보낸다
요청받으면 작업을 자동화한다토일을 숫자로 추적하고, 팀 시간의 절반을 넘지 못하게 막는다
애플리케이션 코드를 개발자의 영역으로 둔다그 코드를 읽고, 타임아웃과 재시도를 리뷰하고, 풀 리퀘스트를 보낸다

마지막 행이 대부분의 인프라 엔지니어가 과소평가하는 부분이다. 서비스의 코드를 읽지 못하는 SRE는 장애를 바깥에서 관찰할 수밖에 없다. 신뢰성은 함수가 느린 의존성을 어떻게 다루는지에서 결정되고, 그것은 클러스터가 아니라 저장소 안에 있다.

실패 모드와 주시할 것

이름만 바꾸기. SRE 직함과 똑같은 티켓 큐를 받은 운영 팀은 아무것도 바꾸지 않은 것이다. 토일 상한과 그에 따르는 권한이 없으면 엔지니어링할 시간이 없고, 직함은 포부를 설명할 뿐이다.

문지기. 릴리스를 승인하는 신뢰성 팀은 조직이 우회해 가는 병목이 된다. 영향력은 포장된 도로와 데이터에서 오지, 거부권에서 오지 않는다.

영웅. 모든 시스템을 알고 모든 장애를 고치는 엔지니어 한 명은 월급을 받는 단일 장애점이다. "Sam이 20분 만에 해결했다"로 끝나는 사건에는 박수가 아니라 런북이 필요하다.

숫자 없는 신뢰성. "가능한 한 신뢰할 수 있게"는 계획할 수도, 인력을 배치할 수도, 기능과 맞바꿀 수도 없다. 이 글의 모든 것은 서비스가 얼마나 신뢰할 수 있어야 하는지, 그리고 지금 그런지 말할 수 있느냐에 달려 있다. 그것이 SLI, SLO, 에러 버짓의 어휘이고, 2부의 주제다.

다음으로 읽을 글

AWS, 클라우드 아키텍처, SRE 실무, CI/CD 파이프라인, Linux 등에 대한 컨설팅은 ercanermis.com에서 시작하라.

참고 자료