SRE

서비스가 멈추지 않고 돌게 하는 일을 소프트웨어를 짜서 해내는 일하는 방식입니다. 운영 팀이 손으로 하던 일을 대신할 프로그램을 만듭니다. 얼마나 버텨야 하는지를 숫자로 먼저 정해 둡니다. 무엇을 할지는 그 숫자를 기준으로 정합니다.

쉽고 빠른 이해

서비스를 멈추지 않게 굴리는 일을 프로그램을 짜서 하는 방식입니다. 사람이 손으로 되풀이하던 일을 찾아 프로그램으로 옮기는 것이 그 실체입니다.

이렇게 하지 않으면 손으로 받는 일이 서비스가 커진 만큼 같이 늡니다. 그 일을 받는 팀도 같이 커집니다. 개발 팀과 운영 팀이 갈리면 두 팀의 목표가 서로 반대쪽을 향하게 됩니다.

도는 순서는 이렇습니다.

1. 서비스가 얼마나 버텨야 하는지를 숫자로 정합니다. 그 숫자는 엔지니어가 아니라 사업 부서가 정합니다
2. 그 숫자가 허용하는 실패의 양을 계산해 둡니다. 그 안에서는 바꾸다 멈춰도 됩니다
3. 손으로 되풀이하는 일을 찾아 프로그램으로 옮깁니다

대가는 그 숫자를 정하는 품입니다. 목표 숫자를 엔지니어링 안에서 못 정해 사업 부서를 불러 따로 뽑아야 합니다. 남이 쓰던 방식도 자기 상황과 성숙도에 맞춰 다시 재야 합니다.

상세

화분이 몇 개뿐일 때는 아침마다 물뿌리개를 들고 하나씩 물을 줍니다. 화분이 백 개로 늘면 물 주는 사람을 더 들이는 대신, 정해진 시각에 저절로 물이 나가는 호스와 타이머를 직접 달아 둡니다. 그러고 나면 사람은 잎이 시든 화분을 살피는 데 시간을 씁니다.

SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링)는 본래 운영 팀이 해 오던 일을 소프트웨어 엔지니어가 맡는 방식입니다. 사람의 노동을 대신할 자동화를 직접 설계하고 구현해 그 일을 해냅니다. 운영과 소프트웨어 엔지니어링을 합친 분야입니다. 그 소프트웨어 엔지니어링은 인프라와 운영 문제에 적용됩니다. 제품 기능을 짓는 대신 응용 프로그램을 굴릴 시스템을 짓는 쪽이라는 뜻입니다.

자동화가 대신하는 것은 사람이 되풀이하던 손일입니다. 사건이 왜 났는지 알아내는 일은 사람이 맡습니다.

판단의 기준이 되는 그 숫자는 예를 들면 「99.99% 쓸 수 있게 한다」 같은 가용성 목표입니다. 이 숫자를 먼저 정해 두고 무엇을 고칠지와 무엇을 내보낼지를 그 숫자에 비춰 정합니다.

이 이름은 두 가지를 가리킵니다. 일하는 방식이기도 하고 그 방식으로 일하는 엔지니어이기도 합니다. 아래에서 사람을 가리킬 때는 「SRE 엔지니어」라고 적습니다.

SRE 팀이 맡는 여덟 갈래

이 방식으로 일하는 팀이 한 서비스에 대해 어디까지 책임지는지를 Google SRE Book 이 여덟으로 적어 둡니다. 서로 다른 일 같지만 전부 같은 서비스 하나에 걸리는 것들입니다.

• 가용성 — 그 서비스를 쓸 수 있는 시간의 비율
• 지연 시간 — 요청 하나를 받아 처리해 돌려주기까지 걸리는 시간
• 성능 — 주어진 자원으로 그 서비스가 내는 처리량
• 효율 — 그 성능을 내는 데 드는 자원의 양
• 변경 관리 — 새 설정과 새 기능을 프로덕션에 내보내는 절차
• 모니터링 — 그 서비스가 지금 어떤 상태인지를 재서 사람에게 알리는 장치
• 비상 대응 — 사건이 났을 때 받아서 처리하는 당번과 절차
• 용량 계획 — 앞으로 필요할 자원을 미리 잡아 두는 일

여덟을 관통하는 것은 판단 기준입니다. 무엇을 맡든 「지금 괜찮은가」에 느낌이 아니라 숫자로 답합니다. 그 숫자를 무엇이라 부르는지는 아래 소절에서 봅니다.

판단에 쓰는 세 숫자

사용자가 무엇을 원하는지에 대한 직관과 경험과 이해를 써서 지표와 목표와 계약을 정의합니다.

지표는 예를 들면 「5분 동안 잰 요청 지연이 100밀리초 미만인가」 같은 것입니다. 목표는 그것이 「지난 28일 동안 99.95%」여야 한다는 것입니다. 이 한 벌을 그대로 공개한 회사가 있습니다. 아래 예시 절에서 봅니다.

목표와 계약을 가르는 쉬운 방법은 「목표를 못 지키면 무슨 일이 생기나」를 묻는 것입니다. 명시적인 결과가 없으면 그것은 거의 틀림없이 목표 쪽입니다.

신뢰성 목표의 세 갈래

이 숫자들이 재는 것은 한 가지가 아닙니다. 어떻게 갈라 재는지는 문서마다 다릅니다. 세 문서가 같은 것을 어떻게 갈랐는지 나란히 봅니다.

가용성부터 봅니다. AWS(Amazon Web Services)의 Well-Architected Framework 는 신뢰성 기둥에서 가용성을 워크로드를 쓸 수 있는 시간의 비율로 정의합니다. 워크로드는 한 서비스를 이루어 함께 돌아가는 자원과 코드의 묶음입니다. 쓸 수 있다는 것은 필요할 때 합의된 기능을 성공적으로 수행한다는 뜻입니다.

Azure Well-Architected Framework 는 신뢰성 목표를 세 갈래로 가릅니다.

• 가용성 목표 — 서비스에 닿을 수 있고 제 기능이 도는 상태를 어느 수준까지 지킬지 정한 기준
• 정확성 목표 — 결과가 맞느냐를 정한 기준. 도는 것과 별개로 일관된 품질로 제 기능을 제대로 수행하는지를 봅니다
• 복구 목표 — 무너진 뒤 돌아오는 것을 재는 기준. 아래 둘로 잽니다
  • 복구 시간 목표(RTO, Recovery Time Objective) — 사건이 난 뒤 서비스를 못 쓰는 상태로 둘 수 있는 최대 시간
  • 복구 지점 목표(RPO, Recovery Point Objective) — 사건 때 잃어도 되는 데이터 구간의 최대 길이

같은 기관의 설계 원칙 문서는 이것을 성질로도 적습니다. 믿을 만한 워크로드가 갖춰야 할 성질입니다.

• 결함을 알아챈 다음 견뎌 낸다. 그동안에도 계속 돈다
• 견디는 선을 넘는 중단이 나면 합의된 복구 목표 안에 되돌아온다
• 약속한 시간 동안 약속한 품질로 쓸 수 있다

전제는 하나입니다. 실패가 안 난다고 가정할 수 없다는 것입니다. 분산 시스템 위에서 도는 워크로드라면 더 그렇습니다.

AWS Well-Architected Framework 는 같은 것을 다르게 가릅니다. 클라우드에서 신뢰성을 떠받치는 첫째 요소는 회복력입니다. 회복력은 다음을 해내는 능력입니다.

• 인프라나 서비스 중단에서 되돌아온다
• 수요에 맞춰 컴퓨팅 자원을 동적으로 확보한다
• 잘못된 설정이나 일시적인 네트워크 문제 같은 중단을 완화한다

여기까지가 세 문서가 신뢰성을 가른 방식입니다. 이름은 달라도 셋 다 무엇을 어디까지 지킬지를 미리 정해 둔 기준입니다.

에러 버짓

목표 숫자를 정하고 나면 그 숫자가 허용하는 실패의 양도 같이 정해집니다. 그 몫을 에러 버짓이라고 부릅니다. 에러 버짓은 1 에서 가용성 목표를 뺀 값입니다. 99.99% 쓸 수 있는 서비스는 0.01% 만큼 못 쓰는 상태입니다. 허용된 그 0.01% 가 그 서비스의 에러 버짓입니다. 1년으로 치면 52분입니다. 넘겨 쓰지만 않으면 무엇에든 쓸 수 있습니다.

「쓴다」는 것은 서비스가 그만큼 흔들리는 것을 감수한 채 변경을 내보낸다는 뜻입니다. 이 장치가 들어오면 SRE 엔지니어의 목표가 「장애 0」이 아니게 됩니다. SRE 엔지니어와 제품 개발자는 이 예산을 써서 기능 출시 속도를 최대로 끌어올리는 것을 함께 목표로 삼습니다. 장애는 더 이상 일어나서는 안 되는 사건이 아니라 혁신 과정에서 예상되는 일이 됩니다. 두 팀은 장애를 두려워하는 대신 관리합니다.

그 목표 숫자를 세우는 것은 기술 문제가 아닙니다. 제품 문제입니다. 시스템의 가용성 목표는 사업 부서나 제품 부서가 세웁니다.

이 장치는 100% 가 거의 모든 것에 대해 틀린 신뢰성 목표라는 관찰에서 나왔습니다. 심박 조율기와 잠김 방지 브레이크가 눈에 띄는 예외입니다. 일반적으로, 어떤 소프트웨어 서비스나 시스템에서든 100% 가 옳은 목표가 아닌 까닭은 100% 쓸 수 있는 시스템과 99.999% 쓸 수 있는 시스템을 사용자가 구별하지 못하기 때문입니다.

배경

복잡한 컴퓨팅 시스템은 오래 시스템 관리자가 굴려 왔습니다. 있는 소프트웨어 부품을 모아 맞물리게 배치해 서비스를 만드는 방식입니다. 그 서비스를 굴리는 동안 그때그때 생기는 사건과 업데이트에도 대응합니다. 시스템 관리자에게 필요한 기술이 제품 개발자의 것과 뚜렷이 달라서, 둘은 개발 팀과 운영 팀으로 갈렸습니다. 직접 비용은 분명합니다. 변경 관리와 사건 처리를 사람의 개입에 기대는 팀으로 서비스를 굴리면, 팀 크기가 시스템이 만들어 내는 부하를 따라 필연적으로 같이 커집니다.

덜 드러나지만 조직에는 더 비싼 값이 따로 있습니다. 갈라진 두 팀은 배경과 기술과 유인이 서로 다릅니다.

• 같은 상황을 다른 낱말로 말합니다
• 위험과 기술적 해결 가능성에 대해 다른 가정을 갖습니다
• 제품이 어느 정도까지 안정적이어야 하는지를 서로 다르게 전제합니다

갈림은 유인에서 그치지 않고 소통과 목표로, 끝내는 신뢰와 존중으로 번집니다. 장애 대부분은 어떤 변화에서 나옵니다. 새 설정, 새 기능 출시, 새 유형의 트래픽이 그런 변화입니다. 그래서 소프트웨어를 얼마나 빨리 프로덕션에 내보낼 수 있는가를 두고 두 팀의 목표는 근본적으로 맞섭니다.

그래서 필요했던 것은 사람을 더 넣는 쪽이 아니라, 시스템 관리자가 손으로 하던 그 일을 해낼 시스템을 만드는 쪽이었습니다. Google 은 제품을 굴릴 소프트웨어 엔지니어를 뽑아 그런 시스템을 만들게 하는 길을 골랐습니다. 응용 프로그램을 믿을 만하게 굴리려면 여러 능력이 필요합니다. 성능 모니터링 · 알림 · 디버깅 · 문제 해결이 그것입니다.

그 능력이 없으면 운영하는 팀은 문제에 반응만 할 수 있습니다. 미리 피하는 쪽으로 움직이지 못합니다. 중단은 시간 문제가 됩니다.

토일

손으로 받는 그 일에는 이름이 있습니다. 운영 서비스를 굴리는 일 가운데 아래 성질을 띠는 것을 토일이라고 부릅니다.

• 손으로 한다
• 되풀이된다
• 자동화할 수 있다
• 그때그때의 대응이다
• 오래 남는 값이 없다
• 서비스가 자랄수록 선형으로 늘어난다

마지막 성질이 가름자입니다. 어떤 일에 드는 노력이 서비스 크기나 트래픽이나 사용자 수에 비례해 같이 커지면 그 일은 토일일 가능성이 큽니다. 뒤집으면, 이상적으로 관리되고 설계된 서비스는 자원을 더 넣는 한 번의 작업 말고는 추가 작업 없이 최소 열 배까지 커질 수 있습니다.

flowchart TD
    subgraph T["토일이 남아 있는 서비스"]
        T1["서비스 1배 · 손으로 받는 일 1배"] --> T2["서비스 10배 · 손으로 받는 일 10배"]
    end
    subgraph I["이상적으로 관리되고 설계된 서비스"]
        I1["서비스 1배 · 손으로 받는 일 1배"] --> I2["서비스 10배 · 자원을 더 넣는 한 번의 작업 말고는 추가 작업 없음"]
    end

예시

아래 값은 실제 조직이 공개한 것입니다. 모두 미리 정해 둔 상한입니다. 넘겼는지로 무엇을 할지가 갈립니다.

GitLab 이 공개한 한 벌

에러 버짓을 뽑으려면 먼저 목표를 세워야 합니다. 여기서 말하는 목표가 앞에 나온 서비스 수준 목표(SLO)입니다. GitLab 핸드북은 그 목표가 목표값과 지표와 기간으로 이뤄진다고 적습니다. 예로 아래 한 벌을 듭니다.

95 백분위수는 잰 값을 작은 것부터 늘어놓았을 때 아래에서 95% 자리에 오는 값입니다. 백 번 가운데 95번은 이 값보다 빨랐다는 뜻입니다.

셋을 합치면 「지난 28일 동안, 5분 동안 잰 API 요청 지연의 95 백분위수가 100ms 미만인 것이 99.95%」가 됩니다. 에러 버짓은 1 에서 목표값을 뺀 0.0005 입니다. 28일을 분으로 바꾸어 곱하면 20.16분입니다. 이 20.16분이 28일 동안 목표를 어기며 써도 되는 몫입니다. 그 안에서는 변경을 내보내다 서비스가 흔들려도 목표를 지킨 것으로 칩니다.

무엇을 오류로 셀지도 정해 두었습니다. 500 상태 코드로 끝난 웹 요청을 셉니다. 처리되지 않은 예외 때문에 실패한 백그라운드 작업도 셉니다. 뒤엣것은 GitLab 이 백그라운드 작업을 돌리는 데 쓰는 Sidekiq 에서 난 것입니다.

토일과 온콜에 매긴 상한

Google 의 SRE 조직은 운영 업무, 곧 토일을 각 SRE 엔지니어 시간의 50% 아래로 유지하는 것을 공표한 목표로 두고 있습니다. 각자의 시간 가운데 최소 절반은 앞으로의 토일을 줄이거나 서비스에 기능을 더하는 엔지니어링 프로젝트 작업에 써야 한다는 뜻입니다. Google 은 SRE 엔지니어가 하는 운영 업무의 양을 잽니다. 넘치는 운영 업무는 제품 개발 팀으로 돌려보내는 식으로 이 상한을 지킵니다.

온콜은 정해진 교대 시간 동안 호출을 받아 사건에 대응하는 당번입니다. 운영 업무에 붙어 있을 때 SRE 엔지니어는 8시간에서 12시간짜리 온콜 교대 한 번에 평균 두 건까지만 사건을 받아야 합니다. 이 정도라야 온콜 당번에게 다음을 할 시간이 납니다.

• 사건을 정확하고 빠르게 처리한다
• 뒷정리를 해 서비스를 정상으로 되돌린다
• 사후 분석까지 한다

두 상한 모두 사람이 손으로 받는 양을 미리 잘라 둔 것입니다. 앞의 GitLab 값이 서비스에 매긴 상한이라면 이 둘은 사람에게 매긴 상한입니다.

사용처

이 방식을 들이는 값은 두 군데서 납니다. 목표 숫자를 엔지니어링 안에서 정할 수 없어 바깥에서 받아 와야 합니다. 남이 쓰던 방식을 그대로 옮겨 올 수도 없습니다. 아래에서는 그 숫자를 어디서 받고 어디까지 적용하는지가 곳마다 어떻게 갈리는지를 봅니다.

응용 범주별 가용성 목표

AWS Well-Architected Framework 는 신뢰성 기둥에서 응용 범주별로 흔히 쓰는 가용성 설계 목표를 적어 둡니다. 그 목표를 지킬 때 1년 동안 허용되는 최대 중단 시간도 같이 적습니다.

같은 방식을 들이더라도 배치 작업과 통신 워크로드가 같은 숫자를 쓰지는 않습니다. 반대쪽 끝에는 에러 버짓의 출발점 자체가 서지 않는 물건이 있습니다. 앞에서 예외로 꼽은 심박 조율기와 잠김 방지 브레이크입니다.

목표를 정하는 주체

Azure Well-Architected Framework 는 신뢰성 목표를 사업 이해관계자와 함께 하는 워크숍에서 도출하라고 적습니다. 도출한 다음은 이 순서입니다.

1. 워크로드 모니터링과 시험으로 그 목표를 다듬는다
2. 내부 이해관계자와 현실적인 기대치를 맞춘다
3. 계약으로 그 기대치를 고객에게 전달한다

숫자를 받아 오려면 엔지니어링 바깥의 사람들을 불러 모아야 합니다. 이 방식을 들이는 값의 하나가 그 품입니다.

처음 들일 때 줄이는 범위

GitLab 은 Google SRE Book 을 권할 만한 읽을거리로 소개합니다. 다만 같은 수준의 정교함에 이르려면 자기네 상황과 성숙도와 추가 요구를 감안해야 한다고 적습니다. 그래서 처음에는 에러 버짓 목표를 이미 쓰던 가용성 접근에 곧바로 묶는 쪽으로 시작했습니다. 앞으로 정교함을 더 올릴 것으로 봅니다.

이미 목표를 넘긴 곳을 더 손보는 쪽으로도 가지 않습니다. GitLab 핸드북이 든 예에서는 목표가 99.95% 인 엔드포인트가 이미 99.97% 를 내고 있습니다. 앞의 한 벌에 나온 99.95% 와 같은 목표값입니다. 그 경우 추가 작업이 필요 없습니다. 그 상태에서 일부러 더 올리는 것은 조기 최적화로 볼 수 있다고 적습니다.

경계

데브옵스와 같은 이름인가. 아닙니다. 다만 두 이름을 어디서 가르는지는 문서마다 갈립니다.

데브옵스의 핵심 원칙은 SRE 의 원칙·관행과 여러 대목에서 일치합니다.

• 시스템의 설계와 개발의 각 단계에 정보 기술 부문이 참여한다
• 사람의 노력보다 자동화에 크게 기댄다
• 엔지니어링 관행과 도구를 운영 업무에 적용한다

Google SRE Book 은 두 방향을 다 열어 둡니다. 데브옵스는 몇몇 핵심 SRE 원칙을 더 넓은 범위의 조직과 관리 구조와 인력으로 일반화한 것으로 볼 수 있습니다. 같은 식으로 SRE 는 몇 가지 고유한 확장이 붙은 데브옵스의 특정 구현으로 볼 수도 있다고 적습니다.

CNCF(Cloud Native Computing Foundation)의 클라우드 네이티브 용어집은 선을 다르게 긋습니다. 비슷한 점이 있지만 데브옵스는 코드를 프로덕션에 올리는 데 초점을 맞춥니다. SRE 는 프로덕션에서 도는 코드가 제대로 도는지를 보장한다고 적습니다.

어느 서술을 따르든 둘은 같은 것의 다른 이름이 아닙니다. 한쪽은 어느 것이 더 넓은지를 고르지 않고 양방향으로 읽습니다. 다른 한쪽은 맡는 구간으로 갈라 코드를 올리는 데까지와 올라간 뒤를 나눕니다. 누가 적었느냐에 따라 답이 갈리는 물음입니다.

flowchart TD
    subgraph A["Google SRE Book 의 서술 · 어느 것이 더 넓은지 고르지 않는다"]
        X["데브옵스"]
        Y["SRE"]
        X ---|"양쪽 어느 방향으로도 읽는다"| Y
    end
    subgraph B["CNCF 용어집의 서술 · 맡는 구간을 앞뒤로 가른다"]
        P["코드"] --> Q["데브옵스 · 프로덕션에 올리기까지"]
        Q --> R["SRE · 올라간 코드가 제대로 도는지"]
    end

위 상자에서 화살표가 없는 선은 방향을 고르지 않았다는 뜻입니다. 아래 상자의 화살표는 앞뒤 순서가 있다는 뜻입니다.

여담

이 이름은 한 사람이 자기 팀을 설계한 데서 나왔습니다. 사이트 신뢰성 엔지니어링이 무엇이냐는 물음에 Google SRE Book 1장을 쓴 Benjamin Treynor Sloss 가 답한 적이 있습니다. 소프트웨어 엔지니어에게 운영 팀을 설계해 보라고 시켰을 때 벌어지는 일이라고 적습니다.

2003년 Google 에 들어가 엔지니어 일곱 명의 프로덕션 팀을 맡았습니다. 그때까지 소프트웨어 엔지니어링만 해 온 사람이었습니다. 자기가 그 팀에서 SRE 엔지니어로 일한다면 이렇게 돌아갔으면 하는 모양으로 팀을 짰다고 적습니다. 그 팀이 자라 오늘날 Google 의 SRE 팀이 되었습니다.

관련 항목

이것이 지키기로 정하는 숫자

서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 에러 버짓 · 가용성 · 지연 · 오류율 · 처리량 · 신뢰성

무너진 뒤 돌아오는 것을 재는 목표

복구 시간 목표 · 복구 지점 목표 · 평균 복구 시간 · 평균 무고장 시간 · 재해 복구 · 업무 연속성

이것이 사람 손에서 프로그램으로 옮기는 작업

토일 · 자동화 · 코드형 인프라 · 설정 관리 · 롤백 · 카나리 배포 · 점진적 롤아웃 · 변경 관리 · 용량 계획

장애가 났을 때 밟는 단계

온콜 · 사고 대응 · 사고 관리 · 사후 분석 · 비상 대응

숫자를 재고 사람을 부르는 수단

모니터링 · 알림 · 관측성 · 로그 · 대시보드 · Prometheus · 골든 시그널

신뢰성을 떠받치는 성질

회복력 · 정적 안정성 · 운영 우수성 · 내결함성 · 중복화

이것과 일이 겹치는 이웃 분야

데브옵스 · 인프라 · 플랫폼 엔지니어링 · 릴리스 엔지니어링 · QA와 테스트 · 신뢰성 공학

이것이 굴리는 시스템이 놓이는 인프라

클라우드 · 쿠버네티스 · 클러스터 · 컨테이너 · 로드 밸런서 · 오토스케일링